Sunday, November 11, 2018
Thursday, November 8, 2018
Friday, November 2, 2018
The most notable one is my second attempt to get unique origin for data: URIs to stick (issue 525). This ran aground in FPR10 and had to be turned off because of compatibility issues with the Firefox 45 version of uBlock Origin, which would be too major an add-on for me to ignore breaking. FPR11 now has a shim in it to allow the old behaviour for data URL access initiated by the internal system principal (including add-ons) but use the new behaviour for web content, and seems to properly reject the same test cases while allowing uBlock to run normally. As before, we really need this in the browser to defend against XSS attacks, so please test thoroughly. Once again, if you experience unusual behaviour in this version, please flip security.data_uri.unique_opaque_origin to false and restart the browser. If the behaviour changes, then this was the cause and you should report it in the comments.
Thursday, November 1, 2018
In a nutshell, the exploit works by sending an abnormal and malicious ICMP packet over a local network to a vulnerable Mac. A vulnerable Mac will attempt to send an error back to the sender with a copy of the abnormal packet header, which has been constructed to be oversize and thus overflows the buffer used for the copy, potentially allowing remote code execution with the contents of the malicious packet.
The current and known vulnerable code dates to about OS X Yosemite (warning: long page). In this version additional code was added to compute the length of what to copy and select different types of buffers, and this later revision appears to be missing a critical line from the original BSD source code that would properly limit the length of what was copied. Prior versions of OS X have a different length calculation (warning: same long page) that doesn't seem to be exploitable in that fashion.
This is not to say that this exploit couldn't be made to work on a Power Mac (or, for that matter, 10.9 and earlier), but my best determination is that at worst the exploit wouldn't work as written. Even if it could, there are three mitigations: first, a remote code exploit would need to be PowerPC specific, which seems unlikely in this day and age; second, the attacker must be on the same network as you in most cases; and third, you can easily defend against it anyway, vulnerable or not, by (as I have previously recommended) enabling the firewall and stealth mode under Sharing > Firewall in System Preferences which disables ICMP replies and thus prevents this section of code from even executing in the first place.