Java and the NTFS Path weakness

[Bernd]

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 <ecki at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210118/cc992de0/attachment.htm>