Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[lgtm] Fix LGTM-reported issues. (#1074)
Remember CodeQL (5a0097b)? CodeQL basically runs [GitHub LGTM][0] on source code, looking for possible security issues. Now that CodeQL is running, we can begin addressing reported issues. Problems found include: * Result of call that may return NULL dereferenced unconditionally * HttpClient created with CheckCertificateRevocationList disabled * Arbitrary file write during archive extraction ("Zip Slip") * Local-user-controlled data in path expression ~~ Result of call that may return NULL dereferenced unconditionally ~~ If **calloc**(3) returns `nullptr`, we shouldn't pass it on to `MultiByteToWideChar()` or `WideCharToMultiByte()` without validation. ~~ HttpClient created with CheckCertificateRevocationList disabled ~~ Apparently the `HttpClient` default constructor is "bad"; we should instead use the [`HttpClient(HttpMessageHandler)` constructor][1], provide our own `HttpClientHandler`, and ensure that [`HttpClientHandler.CheckCertificateRevocationList`][2] is True. ~~ Arbitrary file write during archive extraction ("Zip Slip") ~~ `tools/java-source-utils` (69e1b80) extracts the `.java` files within `.jar`/`.aar`/.etc files to use for type resolution, as I couldn't find an easier way to get `com.github.javaparser` to use Java source code for type resolution purposes unless the Java source code was on-disk. Unfortunately, the `.jar` extraction code was susceptible to "Zip Slip", wherein an entry in the `.jar` may overwrite unexpected files if it has an entry name of e.g. `../../this/is/really/bad.java`. Fix this by verifying that the target filename stays within the target directory structure, and skip the entry when the name is invalid. ~~ Local-user-controlled data in path expression ~~ LGTM is complaining that `tools/java-source-utils` (69e1b80) accepts user-controlled data. These warnings will be *ignored* because the app is *unusable* without "user-controlled data"; consider these `java-source-utils --help` fragments: Java type resolution options: --bootclasspath CLASSPATH ':'-separated list of .jar files to use for type resolution. -a, --aar FILE .aar file to use for type resolution. -j, --jar FILE .jar file to use for type resolution. -s, --source DIR Directory containing .java files for type resolution purposes. DOES NOT parse all files. These are all user-controlled, and they are necessary to allow `java-source-utils` to *work*. Similarly: Output file options: -P, --output-params FILE Write method parameter names to FILE. -D, --output-javadoc FILE Write Javadoc within XML container to FILE. LGTM complains that `--output-javadoc FILE` accepts a user-controlled path which may control directory separator chars, and *this is intentional*; using it would be annoying if that weren't true! These uses can be ignored by appending the comment `// lgtm [java/path-injection-local]`. [0]: https://github.com/marketplace/lgtm [1]: https://learn.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.-ctor?view=netstandard-2.0#system-net-http-httpclient-ctor(system-net-http-httpmessagehandler) [2]: https://learn.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.checkcertificaterevocationlist?view=net-7.0
- Loading branch information