Impact
Zip Slip protections implemented in CVE-2023-24057 (GHSA-jqh6-9574-5x22) can be bypassed due a partial path traversal vulnerability.
This issue allows a malicious actor to potentially break out of the TerminologyCacheManager
cache directory. The impact is limited to sibling directories.
To demonstrate the vulnerability, consider userControlled.getCanonicalPath().startsWith("/usr/out")
will allow an attacker to access a directory with a name like /usr/outnot
.
Why?
To demonstrate this vulnerability, consider "/usr/outnot".startsWith("/usr/out")
.
The check is bypassed although /outnot
is not under the /out
directory.
It's important to understand that the terminating slash may be removed when using various String
representations of the File
object.
For example, on Linux, println(new File("/var"))
will print /var
, but println(new File("/var", "/")
will print /var/
;
however, println(new File("/var", "/").getCanonicalPath())
will print /var
.
The Fix
Comparing paths with the java.nio.files.Path#startsWith
will adequately protect againts this vulnerability.
For example: file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY)
or file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY_FILE.getCanonicalFile().toPath())
Other Examples
Vulnerability
|
for (ZipEntry ze; (ze = zipIn.getNextEntry()) != null; ) { |
|
String path = Path.of(Utilities.path(targetDir, ze.getName())).normalize().toFile().getAbsolutePath(); |
|
|
|
if (!path.startsWith(targetDir)) { |
|
// see: https://snyk.io/research/zip-slip-vulnerability |
|
throw new RuntimeException("Entry with an illegal path: " + ze.getName()); |
|
} |
While getAbsolutePath
will return a normalized path, because the string path
is not slash terminated, the guard can be bypassed to write the contents of the Zip file to a sibling directory of the cache directory.
Patches
All org.hl7.fhir.core libraries should be updated to 5.6.106.
Workarounds
Unknown
References
Impact
Zip Slip protections implemented in CVE-2023-24057 (GHSA-jqh6-9574-5x22) can be bypassed due a partial path traversal vulnerability.
This issue allows a malicious actor to potentially break out of the
TerminologyCacheManager
cache directory. The impact is limited to sibling directories.To demonstrate the vulnerability, consider
userControlled.getCanonicalPath().startsWith("/usr/out")
will allow an attacker to access a directory with a name like/usr/outnot
.Why?
To demonstrate this vulnerability, consider
"/usr/outnot".startsWith("/usr/out")
.The check is bypassed although
/outnot
is not under the/out
directory.It's important to understand that the terminating slash may be removed when using various
String
representations of theFile
object.For example, on Linux,
println(new File("/var"))
will print/var
, butprintln(new File("/var", "/")
will print/var/
;however,
println(new File("/var", "/").getCanonicalPath())
will print/var
.The Fix
Comparing paths with the
java.nio.files.Path#startsWith
will adequately protect againts this vulnerability.For example:
file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY)
orfile.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY_FILE.getCanonicalFile().toPath())
Other Examples
Vulnerability
org.hl7.fhir.core/org.hl7.fhir.r4b/src/main/java/org/hl7/fhir/r4b/terminologies/TerminologyCacheManager.java
Lines 99 to 105 in b0daf66
While
getAbsolutePath
will return a normalized path, because the stringpath
is not slash terminated, the guard can be bypassed to write the contents of the Zip file to a sibling directory of the cache directory.Patches
All org.hl7.fhir.core libraries should be updated to 5.6.106.
Workarounds
Unknown
References