Great bounty for a fairly simple bug, the showSaveFilePickerwould allow JavaScript to provide options including a default filename, which could include `%envrionment% vars on Windows. The JavaScript could then access the name of the saved file in the resulting promise.

Trivial instance of client-sided validation, in this case to enforce a timeout they were using the device’s time. So by changing the time on the device you can make more attempts at the pin.

A chain of issues going from an XSS to a remote file download in a server-side PDF renderer, leading to remote-code execution. The XSS initally seemed a bit weak as the application had no secrets or even authentication so attacking other users would not provide much gain. They did notice a feature that would render a PDF for a given page, they could inject HTML that would be rendered into the PDF but not Javascript.

With HTML injection they could inject content, but with a configuration option $isRemoteEnabled the renderer wouldn’t fetch remote file. This setting wasn’t respected for remote fonts downloaded because of an injected font-family src:url(...) CSS rule. These fonts would be downloaded (on versions before 0.8.5) to lib/fonts the filename would be slightly modified in a deterministic way, and the extension would remain unchanged. The file did need to be loadable by php-font-lib but that is all.

So by injecting PHP code into a font’s copyright section, and then navigating to the font’s file directly code execution on the server could be gained.

There are two huge red flags to me here:

1. Storing everything under the webroot is a bad idea, especially user controlled content.
2. Storing arbitrary content with an attacker influenced name. In this case they already had a lookup system to find the appropiate font files, so keeping the font names (and extension) is unnecessary. By not giving control of the filename and using a truely random name, even given poor security around the webroot would have made it difficult to exploit.

Simple container escape compared to several we’ve covered in the past, the sysctls passed into the pinns utility are delimited by a + which can be maliciously included in a value to inject otherwise blocked sysctls. There is some minimal validation on the sysctls being passed in to ensure the keys don’t match any sensitive keys, however an attacker can set a value to +sensitive.key=othervalue to smuggle in a blocked option.

Smuggling in a kernel.core_pattern could be used to execute an arbitrary file as root on the host to handle a crash dump. This would require a fairly privileged attacker who is able to deploy pods but may not have underlying access to the host system. It could also be useful as part of a chain.