Sunday, November 11, 2018

ICYMI: what's new on Talospace

In the shameless plug category, in case you missed them, two original articles on Talospace, our sister blog: making your Talos II into an IBM pSeries (yes, you can run AIX on a Talos II with Linux KVM), and roadgeeking with the Talos II (because the haters gotta hate and say POWER9 isn't desktop ready, which is just FUD FUD FUD).

Thursday, November 8, 2018

Friday, November 2, 2018

TenFourFox FPR11b1 available

TenFourFox Feature Parity 11 beta 1 is now available (downloads, hashes, release notes). As mentioned, FPR11 and FPR12 will be smaller in scope due to less low-hanging fruit to work on and other competing projects such as the POWER9 JIT, but there are still new features and improvements.

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.

FPR11 also has a more comprehensive fix for sites that use Cloudflare Rocket Loader, a minor speedup to the JavaScript JIT, and new support for two JavaScript features (Symbol.hasInstance and Object.getOwnPropertyDescriptors). In addition, for a small additional speed boost, CSS error reporting is now disabled by default except for debug builds (JavaScript error reporting is of course maintained). If you want this back on, set layout.css.report_errors to true.

After a lot of test cases and poring through bug reports, I think that the issue with Citibank is issue 533. Sites that use that combination of front-end deployment tools will not work in Firefox 50 or lower, which worryingly may affect quite a few, and it seems to be due to the large front-end refactor that landed in Firefox 51. The symptom is usually an error that looks like "this is undefined" in the JavaScript console. Like the other two looming JavaScript issues we are starting to face, this requires a large amount of work and is likely to have substantial regressions if I can get it finished (let alone get it building) at all. I'm looking through the changes to see if any obviously affect the scope of this to see if the actual error that is reported can be worked around, but it may just be masking some bigger problem which requires much more surgery and, if so, would not be feasible to fix unfortunately either.

Thursday, November 1, 2018

OS X kernel exploit in ICMP: Power Macs vulnerable?

I've been puzzling over this for a couple hours, and without a known working proof of concept (which has not yet been revealed) I'm mostly guessing, but I don't believe that Power Macs are vulnerable to CVE-2018-4407.

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.