testDsaBias still failing in OpenJDK 1.8.0.131

64 views
Skip to first unread message

Severyn Kozak

unread,
Aug 8, 2017, 8:53:57 AM8/8/17
to wycheproof-users
I'm investigating various documented OpenJDK vulnerabilities, and decided to look at CVE-2016-0695 in particular (since it's very well documented in Project Wycheproof with a working test and all). According to bugs.md, the vulnerability was fixed in Oracle's April 2016 CPU, which states that it affected Java SE 8u77 amongst others platforms. I'm running OpenJDK 1.8.0.131, so the vulnerability should've been fixed, but the `testDsaBias()` test is still failing. I reduced the OpenJDK testsuite to just include `DsaTest.class` and ran `bazel test OpenJDKTest`, which produced:

INFO: Found 1 test target...
FAIL: //:OpenJDKTest (see /home/sevko/.cache/bazel/_bazel_sevko/e3dc80d62859c30dd963cd56d3f40c3c/execroot/__main__/bazel-out/local-fastbuild/testlogs/OpenJDKTest/test.log).
Target //:OpenJDKTest up-to-date:
  bazel-bin/OpenJDKTest.jar
  bazel-bin/OpenJDKTest
INFO: Elapsed time: 22.123s, Critical Path: 22.02s
//:OpenJDKTest                                                           FAILED in 21.6s
  /home/sevko/.cache/bazel/_bazel_sevko/e3dc80d62859c30dd963cd56d3f40c3c/execroot/__main__/bazel-out/local-fastbuild/testlogs/OpenJDKTest/test.log

I've attached the full `test.log` file. Also, I added a print statement to report the crypto provider used by default, which turned out to be SUN. My full java version is:

$ java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

So, why would the test still fail? Is it a false positive, or is it possible the vulnerability was reintroduced? Or is it the `testBiasSha1WithDSA()` test case that I should be looking at, and not `testDsaBias()`?

p.s. this is an awesome project, thanks for making it happen
test.log

Severyn Kozak

unread,
Aug 10, 2017, 12:01:05 PM8/10/17
to wycheproof-users
Posting a follow-up with some interesting things that I discovered. I ran testDsaBias() against multiple versions of OpenJDK 8 (all downloaded from the Oracle archives) with the following results:

1.8.0_31-b13     failed
1.8.0_40-b26     failed
1.8.0_45-b14     failed
1.8.0_51-b16     failed
1.8.0_60-b27     failed
1.8.0_65-b17     failed
1.8.0_66-b17     failed
1.8.0_71-b15     failed
1.8.0_72-b15     failed
1.8.0_73-b02     failed
1.8.0_74-b02     failed
1.8.0_77-b03     failed
1.8.0_91-b14     -
1.8.0_92-b14     -
1.8.0_101-b13    -
1.8.0_111-b14    -
1.8.0_131-b11    failed
1.8.0_141-b15    -

"-" indicates a passing test

The test fails up until 8u77, which makes sense since, according to the Oracle CPU, that's when the vulnerability was first reported. It also makes sense that the test passes for most of the subsequent versions after 8u77, since the CPU reports that the fix was issued in 8u77. It's my understanding that this commit fixes the vulnerability. What's confusing is that the test fails for 1.8.0_131-b11, so I dug into the JDK8 mercurial repo to find out why.

If I understand correctly, src/share/classes/sun/security/provider/DSA.java is the only file that concerns the vulnerability since it contains the core DSA implementation.
  1. Looking at the history of that file at tag 8u77-b03 in the JDK repo, it looks like the fix commit (594e8dca337c) wasn't yet present, so it makes sense that the vulnerability is still present in that version and the test fails (commit history here)
  2. Looking at the history of that file in the next version that I tested, 8u91-b14, the fix commit gets introduced, so the test passes for 8u91-b14 (commit history here)
  3. Jumping forward to 8u131-b11, when the tests start failing again, it looks like 3 commits get introduced between 8u111-b14 (for which the tests passed) and 8u131-b11 (for which they fail):
    1. http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/3647a1ee5681
    2. http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/a956a914f3a4
    3. http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/31dae74ad077
    4. My guess is the above 3 commits reintroduce the vulnerability, making the tests fail
  4. By the time that we get to 8u141-b15, at which point the tests start passing again, another commit was introduced to the file: (commit history here)
    1. http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/3c8ea47635b6
    2. A quick glance at the diff implies that some security improvements surrounding the generation of K, which would explain why the tests start passing again
Does this sound like a correct assessment?

Daniel Bleichenbacher

unread,
Aug 10, 2017, 12:23:23 PM8/10/17
to Severyn Kozak, wycheproof-users
Yes. Oracle tried to correct a timing attack, but by doing so made the situation worse.
The latest fix is CVE-2017-10115.

On Tuesday, August 8, 2017 at 2:53:57 PM UTC+2, Severyn Kozak wrote:
I'm investigating various documented OpenJDK vulnerabilities, and decided to look at CVE-2016-0695 in particular (since it's very well documented in Project Wycheproof with a working test and all). According to bugs.md, the vulnerability was fixed in Oracle's April 2016 CPU, which states that it affected Java SE 8u77 amongst others platforms. I'm running OpenJDK 1.8.0.131, so the vulnerability should've been fixed, but the `testDsaBias()` test is still failing. I reduced the OpenJDK testsuite to just include `DsaTest.class` and ran `bazel test OpenJDKTest`, which produced:

INFO: Found 1 test target...
FAIL: //:OpenJDKTest (see /home/sevko/.cache/bazel/_bazel_sevko/e3dc80d62859c30dd963cd56d3f40c3c/execroot/__main__/bazel-out/local-fastbuild/testlogs/OpenJDKTest/test.log).
Target //:OpenJDKTest up-to-date:
  bazel-bin/OpenJDKTest.jar
  bazel-bin/OpenJDKTest
INFO: Elapsed time: 22.123s, Critical Path: 22.02s
//:OpenJDKTest                                                           FAILED in 21.6s
  /home/sevko/.cache/bazel/_bazel_sevko/e3dc80d62859c30dd963cd56d3f40c3c/execroot/__main__/bazel-out/local-fastbuild/testlogs/OpenJDKTest/test.log

I've attached the full `test.log` file. Also, I added a print statement to report the crypto provider used by default, which turned out to be SUN. My full java version is:

$ java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

So, why would the test still fail? Is it a false positive, or is it possible the vulnerability was reintroduced? Or is it the `testBiasSha1WithDSA()` test case that I should be looking at, and not `testDsaBias()`?

p.s. this is an awesome project, thanks for making it happen

--
You received this message because you are subscribed to the Google Groups "wycheproof-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wycheproof-users+unsubscribe@googlegroups.com.
To post to this group, send email to wycheproof-users@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/wycheproof-users/0ab26d11-1876-4986-bb86-45af255996d1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages