Impact
MITM can enable Zip-Slip.
Vulnerability
Vulnerability 1: Scanner.java
There is no validation that the zip file being unpacked has entries that are not maliciously writing outside of the intended destination directory.
|
protected void unzip(String zipFilePath, String destDirectory) throws IOException { |
|
File destDir = new File(destDirectory); |
|
if (!destDir.exists()) { |
|
destDir.mkdir(); |
|
} |
|
ZipInputStream zipIn = new ZipInputStream(new FileInputStream(zipFilePath)); |
|
ZipEntry entry = zipIn.getNextEntry(); |
|
// iterates over entries in the zip file |
|
while (entry != null) { |
|
String filePath = destDirectory + File.separator + entry.getName(); |
|
if (!entry.isDirectory()) { |
|
// if the entry is a file, extracts it |
|
extractFile(zipIn, filePath); |
|
} else { |
|
// if the entry is a directory, make the directory |
|
File dir = new File(filePath); |
|
dir.mkdir(); |
|
} |
|
zipIn.closeEntry(); |
|
entry = zipIn.getNextEntry(); |
|
} |
|
zipIn.close(); |
|
} |
This zip archive is downloaded over HTTP instead of HTTPS, leaving it vulnerable to compromise in-flight.
|
download("http://fhir.org/archive/comparison.zip", f); |
Vulnerability 2: TerminologyCacheManager.java
Note: While these links point to only one implementation, both implementations of TerminologyCacheManager.java are vulnerable to this as their code seems to be duplicated.
While there is validation in this bit of logic that attempts to validate that the zip file doesn't contain malicious entries that escape the destination directory, the guard is insufficient.
|
public static void unzip(InputStream is, String targetDir) throws IOException { |
|
try (ZipInputStream zipIn = new ZipInputStream(is)) { |
|
for (ZipEntry ze; (ze = zipIn.getNextEntry()) != null; ) { |
|
String path = Utilities.path(targetDir, ze.getName()); |
|
if (!path.startsWith(targetDir)) { |
|
// see: https://snyk.io/research/zip-slip-vulnerability |
|
throw new RuntimeException("Entry with an illegal path: " + ze.getName()); |
|
} |
|
if (ze.isDirectory()) { |
|
Utilities.createDirectory(path); |
|
} else { |
|
Utilities.createDirectory(Utilities.getDirectoryForFile(path)); |
|
TextFile.streamToFileNoClose(zipIn, path); |
|
} |
|
} |
|
} |
|
} |
This is because the Utilities.path(String... path) method does not normalize the path, although it seems to be attempting to do so.
|
public static String path(String... args) throws IOException { |
|
StringBuilder s = new StringBuilder(); |
|
boolean d = false; |
|
boolean first = true; |
|
for (String arg : args) { |
|
if (first && arg == null) |
|
continue; |
|
first = false; |
|
if (!d) |
|
d = !noString(arg); |
|
else if (!s.toString().endsWith(File.separator)) |
|
s.append(File.separator); |
|
String a = arg; |
|
if (s.length() == 0) { |
|
if ("[tmp]".equals(a)) { |
|
if (hasCTempDir()) { |
|
a = C_TEMP_DIR; |
|
} else if (ToolGlobalSettings.hasTempPath()) { |
|
a = ToolGlobalSettings.getTempPath(); |
|
} else { |
|
a = System.getProperty("java.io.tmpdir"); |
|
} |
|
} else if ("[user]".equals(a)) { |
|
a = System.getProperty("user.home"); |
|
} else if (a.startsWith("[") && a.endsWith("]")) { |
|
String ev = System.getenv(a.replace("[", "").replace("]", "")); |
|
if (ev != null) { |
|
a = ev; |
|
} else { |
|
a = "null"; |
|
} |
|
} |
|
} |
|
a = a.replace("\\", File.separator); |
|
a = a.replace("/", File.separator); |
|
if (s.length() > 0 && a.startsWith(File.separator)) |
|
a = a.substring(File.separator.length()); |
|
|
|
while (a.startsWith(".." + File.separator)) { |
|
if (s.length() == 0) { |
|
s = new StringBuilder(Paths.get(".").toAbsolutePath().normalize().toString()); |
|
} else { |
|
String p = s.toString().substring(0, s.length() - 1); |
|
if (!p.contains(File.separator)) { |
|
s = new StringBuilder(); |
|
} else { |
|
s = new StringBuilder(p.substring(0, p.lastIndexOf(File.separator)) + File.separator); |
|
} |
|
} |
|
a = a.substring(3); |
|
} |
|
if ("..".equals(a)) { |
|
int i = s.substring(0, s.length() - 1).lastIndexOf(File.separator); |
|
s = new StringBuilder(s.substring(0, i + 1)); |
|
} else |
|
s.append(a); |
|
} |
|
return s.toString(); |
|
} |
The normalization only occurs if the path element starts with a path traversal payload. As an example, calling Utilities.path("/base", "/child/../test") will return the string "/base/child/../test".
This guard logic can, thus, be easily bypassed:
|
String path = Utilities.path(targetDir, ze.getName()); |
|
if (!path.startsWith(targetDir)) { |
|
// see: https://snyk.io/research/zip-slip-vulnerability |
|
throw new RuntimeException("Entry with an illegal path: " + ze.getName()); |
|
} |
Assuming an attacker can control the return value of ze.getName(), they can supply a value like /anything/../../../../zipsip-protection-bypass.txt.
Similarly, an attacker can control the contents of the Zip file via a MITM attack as this logic is used with resources not downloaded over HTTPS.
|
if (!version.equals(getCacheVersion())) { |
|
clearCache(); |
|
fillCache("http://tx.fhir.org/tx-cache/"+ghOrg+"/"+ghRepo+"/"+ghBranch+".zip"); |
|
} |
|
if (!version.equals(getCacheVersion())) { |
|
clearCache(); |
|
fillCache("http://tx.fhir.org/tx-cache/"+ghOrg+"/"+ghRepo+"/default.zip"); |
|
} |
Patches
Unknown
Workarounds
Unknown
References
JLLeitschuh Analyst
Impact
MITM can enable Zip-Slip.
Vulnerability
Vulnerability 1:
Scanner.javaThere is no validation that the zip file being unpacked has entries that are not maliciously writing outside of the intended destination directory.
org.hl7.fhir.core/org.hl7.fhir.validation/src/main/java/org/hl7/fhir/validation/Scanner.java
Lines 335 to 357 in 8c43e21
This zip archive is downloaded over HTTP instead of HTTPS, leaving it vulnerable to compromise in-flight.
org.hl7.fhir.core/org.hl7.fhir.validation/src/main/java/org/hl7/fhir/validation/Scanner.java
Line 136 in 8c43e21
Vulnerability 2:
TerminologyCacheManager.javaNote: While these links point to only one implementation, both implementations of
TerminologyCacheManager.javaare vulnerable to this as their code seems to be duplicated.While there is validation in this bit of logic that attempts to validate that the zip file doesn't contain malicious entries that escape the destination directory, the guard is insufficient.
org.hl7.fhir.core/org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/terminologies/TerminologyCacheManager.java
Lines 97 to 113 in f58b7ac
This is because the
Utilities.path(String... path)method does not normalize the path, although it seems to be attempting to do so.org.hl7.fhir.core/org.hl7.fhir.utilities/src/main/java/org/hl7/fhir/utilities/Utilities.java
Lines 617 to 675 in f58b7ac
The normalization only occurs if the path element starts with a path traversal payload. As an example, calling
Utilities.path("/base", "/child/../test")will return the string"/base/child/../test".This guard logic can, thus, be easily bypassed:
org.hl7.fhir.core/org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/terminologies/TerminologyCacheManager.java
Lines 100 to 104 in f58b7ac
Assuming an attacker can control the return value of
ze.getName(), they can supply a value like/anything/../../../../zipsip-protection-bypass.txt.Similarly, an attacker can control the contents of the Zip file via a MITM attack as this logic is used with resources not downloaded over HTTPS.
org.hl7.fhir.core/org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/terminologies/TerminologyCacheManager.java
Lines 66 to 73 in f58b7ac
Patches
Unknown
Workarounds
Unknown
References