Security exception raised by java.util.Properties.store() when using openjdk-16-jdk

Bug #1939339 reported by Rick Hillegas
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
openjdk-11 (Debian)
New
Unknown
openjdk-16 (Ubuntu)
Confirmed
Undecided
Unassigned
openjdk-lts (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Since JDK 11, the Ubuntu "open jdk" packages have a defect which does not appear in the actual Open JDK distros available from java.net. The problem was discovered by Derby users (see https://issues.apache.org/jira/browse/DERBY-7122) and reported as an Open JDK bug (see https://bugs.openjdk.java.net/browse/JDK-8272157).

This is the problem: When trying to persist a java.util.Properties object, an exception is raised when running under the java SecurityManager. The exception occurs when java.util.Properties.store0() calls java.util.Properties.getFormattedTimestamp() in order to format the timestamp required by the contract of java.util.Properties.store(). The getFormattedTimestamp() method does not appear in Open JDK. There the timestamp is formatted thusly:

bw.write("#" + new Date().toString());

The exception stack trace (see the repro below) is:

Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getenv.SOURCE_DATE_EPOCH")
 at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
 at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
 at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
 at java.base/java.lang.System.getenv(System.java:1016)
 at java.base/java.util.Properties.getFormattedTimestamp(Properties.java:1599)
 at java.base/java.util.Properties.store0(Properties.java:926)
 at java.base/java.util.Properties.store(Properties.java:868)
 at DERBY_7122.main(DERBY_7122.java:37)

At a minimum, could someone explain (with CVE numbers if available) the security risk incurred by probing the value of the Linux environment variable SOURCE_DATE_EPOCH?

Here is a sample program which demonstrates this problem. This program runs fine on Open JDK distros from java.net.

import java.io.PrintWriter;
import java.util.Properties;

/**
 * Demonstrate that Properties.store() fails under a security manager on Ubuntu.
 */
public class DERBY_7122
{
    private static final String PROPERTY_FILE_NAME = "/tmp/derby-7122.properties";
    private static final String SECURITY_POLICY_FILE_NAME = "/tmp/derby-7122.policy";
    private static final String SECURITY_POLICY_FILE_URL = "file:" + SECURITY_POLICY_FILE_NAME;

    private final static String POLICY_FILE_PROPERTY = "java.security.policy";

    private static final String SECURITY_FILE_CONTENTS =
        "grant\n" +
        "{\n" +
        " permission java.io.FilePermission \"/tmp/-\", \"read,write,delete\";\n" +
        "};\n"
        ;

    public static void main(String... args) throws Exception
    {
        // write the policy file
        try (PrintWriter pw = new PrintWriter(SECURITY_POLICY_FILE_NAME))
        { pw.write(SECURITY_FILE_CONTENTS); }

        // start up a security manager using the policy file we just wrote
        System.setProperty( POLICY_FILE_PROPERTY, SECURITY_POLICY_FILE_URL );
        System.setSecurityManager( new SecurityManager() );

        // create a small Properties object
        Properties props = new Properties();
        props.setProperty("foo", "bar");

        // write the properties to disk.
        props.store(new PrintWriter(PROPERTY_FILE_NAME), "this fails on ubuntu with JVMs at level 11 and higher");
    }

}

summary: Security exception raised by java.util.Properties.store() when using
- openjdk-16-jdk-headless
+ openjdk-16-jdk
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openjdk-16 (Ubuntu):
status: New → Confirmed
Revision history for this message
Art O Cathain (art-home) wrote :

The bug also affects Debian 10.10

art@server:/tmp$ java -version
openjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment (build 11.0.12+7-post-Debian-2deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.12+7-post-Debian-2deb10u1, mixed mode, sharing)
art@server:/tmp$ java DERBY_7122
Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getenv.SOURCE_DATE_EPOCH")
        at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
        at java.base/java.security.AccessController.checkPermission(AccessController.java:897)
        at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
        at java.base/java.lang.System.getenv(System.java:999)
        at java.base/java.util.Properties.getFormattedTimestamp(Properties.java:1590)
        at java.base/java.util.Properties.store0(Properties.java:932)
        at java.base/java.util.Properties.store(Properties.java:874)
        at DERBY_7122.main(DERBY_7122.java:39)

Revision history for this message
Rick Hillegas (rhillegas) wrote :

Stuart Marks (from the Open JDK team) has found the problematic code in https://packages.debian.org/unstable/java/openjdk-16-source and identified two bugs in it, including the one responsible for this behavior. For that bug, he has recommended a fix. Please see his analysis at https://bugs.openjdk.java.net/browse/JDK-8272157

It would be great if an Ubuntu engineer could coordinate with Stuart, perhaps via the Open JDK issue, and apply the bug fixes he recommends. Thanks.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openjdk-lts (Ubuntu):
status: New → Confirmed
Vladimir Petko (vpa1977)
tags: added: fr-3396
Vladimir Petko (vpa1977)
tags: added: reviewed
Changed in openjdk-11 (Debian):
status: Unknown → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.