Re: Java and the NTFS Path weakness
Hello, bad news everyone. The second Windows Filesystem related security bug reported by Jonas Lykkegaard which allows crashing Windows with a unpriveledged read access also affects JVM and it is not filtered by Path.of. Which means bot new File(bad).exists() and Files.readAllLines(Path.of(bad)) will crash Windows immediatelly. I verified this on the latest Windows Server 2019 January Security Update. var bad = ".\\globalroot\\device\\condrv\\kernelconnect" Gruss Bernd Am Mo., 18. Jan. 2021 um 01:39 Uhr schrieb Bernd : > Hello, > > you might have seen the media coverage on a Microsoft Windows 10 and > Windows Server problem where a certain NTFS internal path causes the > Windows driver to claim corruption and mark the filesystem dirty. (Some > even reported actual corruption of their filesystems). > > The java.nio Path seems to be resistance against that, as it detects an > illegal path itself: > > | Welcome to JShell -- Version 11.0.9.1 > | For an introduction type: /help intro > > jshell> var bad = "C:\\:$i30:$bitmap"; > bad ==> "C:\\:$i30:$bitmap" > > jshell> new File(bad).toPath() > | Exception java.nio.file.InvalidPathException: Illegal char <:> at index > 3: C:\:$i30:$bitmap > |at WindowsPathParser.normalize (WindowsPathParser.java:182) > |at WindowsPathParser.parse (WindowsPathParser.java:153) > |at WindowsPathParser.parse (WindowsPathParser.java:77) > |at WindowsPath.parse (WindowsPath.java:92) > |at WindowsFileSystem.getPath (WindowsFileSystem.java:229) > |at File.toPath (File.java:2292) > |at (#6:1) > > jshell> Paths.get(bad) > | Exception java.nio.file.InvalidPathException: Illegal char <:> at index > 3: C:\:$i30:$bitmap > |at WindowsPathParser.normalize (WindowsPathParser.java:182) > |at WindowsPathParser.parse (WindowsPathParser.java:153) > |at WindowsPathParser.parse (WindowsPathParser.java:77) > |at WindowsPath.parse (WindowsPath.java:92) > |at WindowsFileSystem.getPath (WindowsFileSystem.java:229) > |at Path.of (Path.java:147) > |at Paths.get (Paths.java:69) > |at (#7:1) > > jshell> Path.of(bad) > | Exception java.nio.file.InvalidPathException: Illegal char <:> at index > 3: C:\:$i30:$bitmap > |at WindowsPathParser.normalize (WindowsPathParser.java:182) > |at WindowsPathParser.parse (WindowsPathParser.java:153) > |at WindowsPathParser.parse (WindowsPathParser.java:77) > |at WindowsPath.parse (WindowsPath.java:92) > |at WindowsFileSystem.getPath (WindowsFileSystem.java:229) > |at Path.of (Path.java:147) > |at (#8:1) > > (not sure if there is a way to construct a path without that > normalization). > > Unfortunally, however, the java.io.File and its IO functions to not > provide this protection, when you call > > jshell> new File(bad).exists() > $9 ==> false > > (or some other methods accessing the file) you will see the crash message > in the event log. > > I am not sure if Java should or could filter that (however since java.nio > already does it might be an option, not sure however if Microsoft would be > faster and fixing that problem). But I thought I mention this here in case > you have Java server applications which derive file names from untrusted > user input (including uncompressing ZIP files). > > Gruss > Bernd > >
Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]
On 1/17/2021 9:29 PM, Valerie Peng wrote: On Fri, 15 Jan 2021 01:45:07 GMT, Valerie Peng wrote: Marked as reviewed by weijun (Reviewer). _Mailing list message from [Michael StJohns](mailto:mstjo...@comcast.net) on [security-dev](mailto:security-dev@openjdk.java.net):_ Sorry - I'm coming to this a bit late. Any chance of adding the logic for generatePublic() from a PKCS8 RSA private key??? RFC3477 has the PKCS1 RSAPrivateKey ASN1 which includes the modulus and publicExponent - so it should be a pretty straight forward add to generate a public key. PKCS11 2.40 started requiring that the publicExponent be stored with the private key to allow for the public key to be regenerated from a private key object.?? Going forward,? it might be a good idea to modify the RSAPrivate(Crt)KeyImpl class to store the publicExponent if provided. Mike You are correct that for RSA private CRT keys the necessary values are there for figuring out its corresponding public keys. This change is about adding support for PKCS#1 encoded RSA keys and be able to translate them into PKCS#8 encoded keys and/or extract various key specs out of them. If you already have PKCS#8 RSAPrivateCrtKey obj from SunRsaSign provider, you can call its getPublicExponent() method and use that to create a RSAPublicKeySpec and generate RSA public key with it. If you are using 3rd party impl which does not return the public exponent value somehow, then you can translate it using the RSA key factory impl from SunRsaSign provider and then repeat the fore-mentioned step. Will this address your need? If not, could you elaborate the usage that you have in mind? Not sure if you are suggesting a new KeyFactory.generatePublic() method which take a PrivateKey or else. Mike, We can continue your feedback with a separate RFE since this RFE is just about adding support for PKCS#1 encoding. I need to wrap this up before my upcoming trip this Wed, hope that's ok with you. Thanks! Valerie - PR: https://git.openjdk.java.net/jdk/pull/1787 No worries - I got busy with other things for a few days. To answer your other question, I've had a few cases where the public key for a private key has been misplaced and where we needed it back. Ideally, it should be possible to take a PrivateKey object (in whatever form including just PrivateKey) and run it through the KeyFactory to extract a PublicKey. I've used the technique you suggest above before (and the related multiply the private scalar against G for EC keys) to retrieve the data needed to build a public key, but each of these is a bit ad hoc. I'd really prefer to have a standard pattern for all key types. About 4 years or so ago (e.g. when 2.40 was released), the PKCS11 group started requiring that the private keys include the attributes necessary to retrieve the public key - for RSA it was the public exponent, and for EC it was the public point (which could be stored or regenerated upon demand). It may be time to think about doing something similar here and going forward for any given asymmetric key type. That's a more general RFE than just updating the current implementing classes, but as far as I can tell, doesn't change any of the APIs, but may change the factory class implementation guidance. An interesting addition would be to have the Impl classes implement both the appropriate public key and private key interfaces.
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v14]
> This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at > http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update package info to credit LMX algorithm - Changes: - all: https://git.openjdk.java.net/jdk/pull/1292/files - new: https://git.openjdk.java.net/jdk/pull/1292/files/772abef6..38369702 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1292=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1292=12-13 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v13]
> This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at > http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html > > old PR: https://github.com/openjdk/jdk/pull/1273 Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge branch 'master' into 8248862 - Correct range used by nextBytes - Merge branch 'master' into 8248862 - Use annotation for properties. Add getDefault(). - Merge branch 'master' into 8248862 - Introduce RandomGeneratorProperties annotation - Merge branch 'master' into 8248862 - 8248862: Implement Enhanced Pseudo-Random Number Generators Added coverage testing - 8248862: Implement Enhanced Pseudo-Random Number Generators Cleanups from Chris H. - 8248862: Implement Enhanced Pseudo-Random Number Generators Propagate exception - ... and 30 more: https://git.openjdk.java.net/jdk/compare/061ffc47...772abef6 - Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1292=12 Stats: 13205 lines in 26 files changed: 11043 ins; 2046 del; 116 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292
Re: RFR: 8257733: Move module-specific data from make to respective module [v4]
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote: >> This PR is not stale; it's just still waiting for input from @AlanBateman. > > @magicus Can the CharacterDataXXX.template files move to > src/java.base/share/classes/java/lang? @AlanBateman When I moved the charset templates, I found this gold nugget: # Copy two Java files that need no preprocessing. $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/%.java: $(CHARACTERDATA_TEMPLATES)/%.java.template $(call LogInfo, Generating $(@F)) $(call install-file) GENSRC_CHARACTERDATA += $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataUndefined.java \ $(SUPPORT_OUTPUTDIR)/gensrc/java.base/java/lang/CharacterDataPrivateUse.java What this means is that we have two "template" files that are just compiled as java files, but only after being copied to gensrc. :-) That definitely needs cleaning up, but this PR is large enough as it is, so I will not do it now. - PR: https://git.openjdk.java.net/jdk/pull/1611
Re: RFR: 8257733: Move module-specific data from make to respective module [v5]
> A lot (but not all) of the data in make/data is tied to a specific module. > For instance, the publicsuffixlist is used by java.base, and fontconfig by > java.desktop. (A few directories, like mainmanifest, is *actually* used by > make for the whole build.) > > These data files should move to the module they belong to. The are, after > all, "source code" for that module that is "compiler" into resulting > deliverables, for that module. (But the "source code" language is not Java or > C, but typically a highly domain specific language or data format, and the > "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. > When such data is changed, most of the time build-dev (or the new build > label) is involved, even though this has nothing to do with the build. While > this is annoying, a worse problem is if the actual team that needs to review > the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Move characterdata templates to share/classes/java/lang. - Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/68b252b5..c4894348 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1611=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1611=03-04 Stats: 4 lines in 9 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611
Re: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v4]
> - The MD5 intrinsics added by > [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that > the `int[] x` isn't actually needed. This also applies to the SHA intrinsics > from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to > make it acceptable to use inline and replace the array in MD5 wholesale. This > improves performance both in the presence and the absence of the intrinsic > optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element > arrays), but allocating the array lazily gets most of the speed-up in the > presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length)Cnt Score > Error Units > MessageDigests.digestMD516 15 > 2714.307 ± 21.133 ops/ms > MessageDigests.digestMD5 1024 15 > 318.087 ±0.637 ops/ms > MessageDigests.digest SHA-116 15 > 1387.266 ± 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 > 109.273 ±0.149 ops/ms > MessageDigests.digestSHA-25616 15 > 995.566 ± 21.186 ops/ms > MessageDigests.digestSHA-256 1024 15 > 89.104 ±0.079 ops/ms > MessageDigests.digestSHA-51216 15 > 803.030 ± 15.722 ops/ms > MessageDigests.digestSHA-512 1024 15 > 115.611 ±0.234 ops/ms > MessageDigests.getAndDigest MD516 15 > 2190.367 ± 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 > 302.903 ±1.809 ops/ms > MessageDigests.getAndDigestSHA-116 15 > 1262.656 ± 43.751 ops/ms > MessageDigests.getAndDigestSHA-1 1024 15 > 104.889 ±3.554 ops/ms > MessageDigests.getAndDigest SHA-25616 15 > 914.541 ± 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 > 85.708 ±1.394 ops/ms > MessageDigests.getAndDigest SHA-51216 15 > 737.719 ± 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 > 112.307 ±1.950 ops/ms > > GC: > MessageDigests.getAndDigest:·gc.alloc.rate.norm MD516 15 > 312.011 ±0.005B/op > MessageDigests.getAndDigest:·gc.alloc.rate.normSHA-116 15 > 584.020 ±0.006B/op > MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-25616 15 > 544.019 ±0.016B/op > MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-51216 15 > 1056.037 ±0.003B/op > > Target: > Benchmark (digesterName) (length)Cnt > Score Error Units > MessageDigests.digestMD516 15 > 3134.462 ± 43.685 ops/ms > MessageDigests.digestMD5 1024 15 > 323.667 ±0.633 ops/ms > MessageDigests.digest SHA-116 15 > 1418.742 ± 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 > 110.178 ±0.788 ops/ms > MessageDigests.digestSHA-25616 15 > 1037.949 ± 21.214 ops/ms > MessageDigests.digestSHA-256 1024 15 > 89.671 ±0.228 ops/ms > MessageDigests.digestSHA-51216 15 > 812.028 ± 39.489 ops/ms > MessageDigests.digestSHA-512 1024 15 > 116.738 ±0.249 ops/ms > MessageDigests.getAndDigest MD516 15 > 2314.379 ± 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 > 307.835 ±5.730 ops/ms > MessageDigests.getAndDigestSHA-116 15 > 1326.887 ± 63.263 ops/ms > MessageDigests.getAndDigestSHA-1 1024 15 > 106.611 ±2.292 ops/ms > MessageDigests.getAndDigest SHA-25616 15 > 961.589 ± 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 > 88.646 ±0.194 ops/ms > MessageDigests.getAndDigest SHA-51216 15 > 775.417 ± 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 > 112.904 ±2.014 ops/ms > > GC > MessageDigests.getAndDigest:·gc.alloc.rate.norm MD516 15 > 232.009 ±0.006B/op >
Re: RFR: 8257733: Move module-specific data from make to respective module
On 2021-01-15 19:27, mark.reinh...@oracle.com wrote: Feature JEPs are living documents until such time as they are delivered. In this case it would not be appropriate to update JEP 201, which is as much about the transition from the old source-code layout as it is about the new layout as of 2014. At this point, and given that we’d already gone beyond JEP 201 prior to this change (with `man` and `lib` subdirectories), what’d make the most sense is a new informational JEP that documents the source-code layout. Informational JEPs can, within reason, be updated over time. So I take it I need to create a new informational JEP. :-) Fine, I can do that. I assume I mostly need to extract the parts of JEP 201 that describes the (then "new") layout, update wording to show that this is a description of the current layout, and add the new additions. It'll be a very short JEP, but in this case, that's probably a virtue. /Magnus
Re: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v3]
> - The MD5 intrinsics added by > [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that > the `int[] x` isn't actually needed. This also applies to the SHA intrinsics > from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to > make it acceptable to use inline and replace the array in MD5 wholesale. This > improves performance both in the presence and the absence of the intrinsic > optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element > arrays), but allocating the array lazily gets most of the speed-up in the > presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length)Cnt Score > Error Units > MessageDigests.digestMD516 15 > 2714.307 ± 21.133 ops/ms > MessageDigests.digestMD5 1024 15 > 318.087 ±0.637 ops/ms > MessageDigests.digest SHA-116 15 > 1387.266 ± 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 > 109.273 ±0.149 ops/ms > MessageDigests.digestSHA-25616 15 > 995.566 ± 21.186 ops/ms > MessageDigests.digestSHA-256 1024 15 > 89.104 ±0.079 ops/ms > MessageDigests.digestSHA-51216 15 > 803.030 ± 15.722 ops/ms > MessageDigests.digestSHA-512 1024 15 > 115.611 ±0.234 ops/ms > MessageDigests.getAndDigest MD516 15 > 2190.367 ± 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 > 302.903 ±1.809 ops/ms > MessageDigests.getAndDigestSHA-116 15 > 1262.656 ± 43.751 ops/ms > MessageDigests.getAndDigestSHA-1 1024 15 > 104.889 ±3.554 ops/ms > MessageDigests.getAndDigest SHA-25616 15 > 914.541 ± 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 > 85.708 ±1.394 ops/ms > MessageDigests.getAndDigest SHA-51216 15 > 737.719 ± 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 > 112.307 ±1.950 ops/ms > > GC: > MessageDigests.getAndDigest:·gc.alloc.rate.norm MD516 15 > 312.011 ±0.005B/op > MessageDigests.getAndDigest:·gc.alloc.rate.normSHA-116 15 > 584.020 ±0.006B/op > MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-25616 15 > 544.019 ±0.016B/op > MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-51216 15 > 1056.037 ±0.003B/op > > Target: > Benchmark (digesterName) (length)Cnt > Score Error Units > MessageDigests.digestMD516 15 > 3134.462 ± 43.685 ops/ms > MessageDigests.digestMD5 1024 15 > 323.667 ±0.633 ops/ms > MessageDigests.digest SHA-116 15 > 1418.742 ± 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 > 110.178 ±0.788 ops/ms > MessageDigests.digestSHA-25616 15 > 1037.949 ± 21.214 ops/ms > MessageDigests.digestSHA-256 1024 15 > 89.671 ±0.228 ops/ms > MessageDigests.digestSHA-51216 15 > 812.028 ± 39.489 ops/ms > MessageDigests.digestSHA-512 1024 15 > 116.738 ±0.249 ops/ms > MessageDigests.getAndDigest MD516 15 > 2314.379 ± 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 > 307.835 ±5.730 ops/ms > MessageDigests.getAndDigestSHA-116 15 > 1326.887 ± 63.263 ops/ms > MessageDigests.getAndDigestSHA-1 1024 15 > 106.611 ±2.292 ops/ms > MessageDigests.getAndDigest SHA-25616 15 > 961.589 ± 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 > 88.646 ±0.194 ops/ms > MessageDigests.getAndDigest SHA-51216 15 > 775.417 ± 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 > 112.904 ±2.014 ops/ms > > GC > MessageDigests.getAndDigest:·gc.alloc.rate.norm MD516 15 > 232.009 ±0.006B/op >
