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 <e...@zusammenkunft.net>: > 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 > >
