Tuesday, September 12, 2017

BlueBorne and the Power Mac TL;DR: low practical risk, but assume the worst

Person of Interest, which is one of my favourite shows (Can. You. Hear. Me?) was so very ahead of its time in many respects, and awfully prescient about a lot else. One of those things was taking control of a device for spying purposes via Bluetooth, which the show variously called "forced pairing" or "bluejacking."

Because, thanks to a newly discovered constellation of flaws nicknamed BlueBorne, you can do this for real. Depending on the context and the flaw in question, which varies from operating system to operating system, you can achieve anything from information leaks and man-in-the-middle attacks to full remote code execution without the victim system having to do anything other than merely having their Bluetooth radio on. (And people wonder why I never have Bluetooth enabled on any of my devices and use a wired headset with my phone.)

What versions of OS X are likely vulnerable? The site doesn't say, but it gives us a couple clues with iOS, which shares the XNU kernel. Versions 9.3.5 and prior are all vulnerable to remote code execution, including AppleTV version 7.2.2 which is based on iOS 8.4.2; this correlates with a XNU kernel version of 15.6.0, i.e., El Capitan. Even if we consider there may be some hardening in contemporary desktop versions of macOS, 10.4 and 10.5 are indisputably too old for that, and 10.6 very likely as well. It is therefore reasonable to conclude Power Macs are vulnerable.

As a practical matter, though, an exploit that relies on remote code execution would have to put PowerPC code somewhere it could execute, i.e., the exploit would have to be specific to Power Macs. Unless your neighbour is, well, me, this is probably not a high probability in practice. A bigger risk might be system instability if an OS X exploit is developed and weaponized and tries spraying x86 code at victim systems instead. On a 10.6 system you'd be at real risk of being pwned (more on that below). On a PowerBook G4, they wouldn't be able to take your system over, but it has a good chance of getting bounced up and down and maybe something damaged in the process. This is clearly a greater risk for laptops than desktop systems, since laptops might be in more uncontrolled environments where they could be silently probed by an unobserved attacker.

The solution is obvious: don't leave Bluetooth on, and if you must use it, enable it only in controlled environments. (This would be a good time to look into a wired keyboard or a non-Bluetooth wireless mouse.) My desktop daily drivers, an iMac G4 and my trusty Quad G5, don't have built-in Bluetooth. When I need to push photos from my Pixel, I plug in a USB Bluetooth dongle and physically disconnect it when I'm done. As far as my portable Power Macs in the field, I previously used Bluetooth PAN with my iBook G4 for tethering but I think I'll be switching to WiFi for that even though it uses more power, and leave Bluetooth disabled except if I have no other options. I already use a non-Bluetooth wireless mouse that does not require drivers, so that's covered as well.

Older Intel Mac users, it goes without saying that if you're on anything prior to Sierra you should assume the worst as well. Apple may or may not offer patches for 10.10 and 10.11, but they definitely won't patch 10.9 and earlier, and you are at much greater risk of being successfully exploited than Power Mac users. Don't turn on Bluetooth unless you have to.

Very Soon Now(tm) I will be doing an update to our old post on keeping Power Macs safe online, and this advice will be part of it. Watch for that a little later.

Meanwhile, however, the actual risk to our Power Macs isn't the biggest question this discovery poses. The biggest question is, if the show got this right, what if there's really some sort of Samaritan out there too?

Sunday, September 10, 2017

Irma's silver lining: text is suddenly cool again

In Gopherspace (proxy link if your browser doesn't support it), plain text with low bandwidth was always cool and that's how we underground denizens roll. But as our thoughts and prayers go to the residents of the Caribbean and Florida peninsula being lashed by Hurricane Irma, our obey your media thought overlords newspapers and websites are suddenly realizing that when the crap hits the oscillating storm system, low-bandwidth text is still a pretty good idea.

Introducing text-only CNN. Yes, it's really from CNN. Yes, they really did it. It loads lickety-split in any browser, including TenFourFox and Classilla. And if you're hunkered down in the storm cellar and the radio's playing static and all you can get is an iffy 2G signal from some half-damaged cell tower miles away, this might be your best bet to stay current.

Not to be outdone, there's a Thin National Public Radio site too, though it only seems to have quick summaries instead of full articles.

I hope CNN keeps this running after Irma has passed because we really do need less crap overhead on the web, and in any disaster where communications are impacted, low-bandwidth solutions are the best way to communicate the most information to the most people. Meanwhile, please donate to the American Red Cross and the Salvation Army (or your relief charity of choice) to help the victims of Hurricanes Harvey and Irma today.

Tuesday, September 5, 2017

TenFourFox FPR3b1 available

TenFourFox Feature Parity Release 3 beta 1 is now available (hashes, downloads, release notes). This release has two major updates: first, a whole lot more of the browser has AltiVec in it. All of the relevant call sites that use the slower OS X memory search function memchr() were either converted to the VMX-accelerated version that we introduced for JavaScript in FPR2, or, if the code simply checks to see if a character is there but doesn't need to know where it is, our VMX-accelerated haschr(). This occurs in lots of places, including event handling, font validation and even the network stack; not all of them are hot, but all of them benefit.

The second major change is additional JavaScript ES6 and ES7 compatibility. It's not sufficient for us simply to copy over later versions of JavaScript from browser versions between 45 and 52; besides the fact they may require platform support we don't implement, they don't have our JIT, our PowerPC-specific optimizations and our later updates which would need to be backported and merged, they don't have our accumulated security patches, and they don't have some of the legacy features we need to continue to support 45-era add-ons (particularly legacy generator and array comprehensions). This hybrid engine maintains backwards compatibility but has expanded syntax that fixes some issues with Dropbox (though we still have a couple other glitches to smoke out), Amazon Music and Beta for Pnut, and probably a number of other sites. There is a limit to how much I can cram into the engine and there is a very large frontend refactor around Fx51 which will probably not be easily backported, but there should be more improvements I can squeeze in.

There was also supposed to be a new feature for delaying video decoding until the rest of the page had loaded to improve throughput on YouTube and some other sites, but YouTube introduced its new site design while I was testing the feature, and unfortunately the "lazy loading" technique they appear to be using now means the browser cannot deterministically compute when video will start competing with layout for resources. I'm thinking of a way to retool this but it will not be an enabled part of FPR3. One idea is to forge dropped frames into MSE's statistics early so it shifts to a lower quality stream for a period of time as a "fast start;" another might be to decouple the media state machine from the decoder more completely. I haven't decided how I will attack this problem yet.

In miscellaneous changes, even after desperate begging Imgur would not fix their site sniffer to stop giving us a mobile version using the default TenFourFox user agent (this never used to happen until recently, btw), even if just an image by itself were requested. I got sick of being strung along by their tech support tickets, so this version just doesn't send any user agent to any Imgur site, unless you explicitly select something other than the default. Take that, Imgur. The reason I decided to do this for Imgur specifically is because their mobile site actually causes bugs in TenFourFox due to a hard CoreGraphics limit I can't seem to get around, so serving us the mobile site inappropriately is actually detrimental as opposed to merely annoying. Other miscellaneous changes include some widget tune-ups, more removal of 10.7+ specific code, and responsiveness tweaks to the context menu and awesome bar.

Last but not least, this release has a speculative fix for long-running issue 72 where 10.5 systems could end up with a frozen top menu bar after cycling repeatedly through pop-up menus. You'll notice this does not appear in the source commits yet because I intend to back it out immediately if it doesn't fix the problem (it has a small performance impact even on 10.4 where this issue does not occur). If you are affected by this issue and the optimized build doesn't fix your problem, please report logging to the Github issue from the debug version when the issue triggers. If it does fix it, however, I will commit the patch to the public repo and it will become a part of the widget library.

Other than that, look for the final release on or about September 26. Post questions, concerns and feedback in the comments.