Tuesday, October 17, 2017

KRACK is wack on Power Macs

After WEP fell due to the 2001 Flurher-Mantin-Shamir attack, WPA2 became the standard way to secure a WiFi connection. Now, the mighty have fallen due to KRACK (Key Reinstallation AttACK), meaning no WiFi network is safe.

KRACK is particularly wack problematic because there are multiple varieties of attack and virtually every system tested was vulnerable to at least one of them:

The attacks concentrate primarily on the handshakes used to distribute keys, including the 4-way handshake used to bring up a new client ("supplicant"). This last point is particularly relevant because Mavericks and Sierra were both vulnerable to attacks on the 4-way handshake but iOS 10.3.1 is not.

We can confidently assume that 10.4 and 10.5 (and 10.6, for that matter) are vulnerable in the same or similar ways that at least 10.9.5 are (I'll dive into this in a moment), but the situation is really bad for Linux. wpa_supplicant 2.6 and prior are vulnerable to all of the variants, including current PPC Linux users and devices running Android 6.0+. These will almost certainly be patched eventually, even considering the shrinking support for 32-bit PowerPC in Linux. OpenBSD is also vulnerable, but patches emerged prior to the embargo, and its close relative NetBSD will likely be repaired in a similar fashion. Microsoft has quietly issued a Patch Tuesday update that covers KRACK. There are reports that the issue is already patched in current betas of macOS and iOS, but it's not clear yet if these patches will be backported to Sierra or El Capitan.

10.5 and earlier exclusively use the private framework Apple80211.framework for WiFi connectivity. Although the public wireless networking framework CoreWLAN was introduced with 10.6, the later private framework CoreWifi is not present and a comparison of symbols shows subsequent upgrades to Apple80211's functionality in Snow Leopard, so it is very likely in use invisibly there as well. Although this framework still exists in 10.12, it does not appear to be used or linked by CoreWLAN, implying it was since internally deprecated. Apple never documented this framework or made it open source, but there have been attempts to reverse engineer it. However, the necessary changes likely mean inserting more sanity checks during the key handshake, which would require a bit more than just patching the library in place. I've done a little preliminary disassembly of it but I haven't found where this critical section exists yet. However, there is a tool in this framework which will be very helpful to determine your actual risk; read on.

WPA2 has three major encryption protocols, only two of which are supported by PPC Mac OS X, namely TKIP (a legacy encryption protocol from WEP intended as an interim compatibility measure), and AES-CCMP, a more secure protocol which is supported in 10.3.3+ and is sometimes just abbreviated "AES" (incorrectly) or "CCMP." TKIP was deprecated in 2012, but is still often used. The last form is GCMP, which no Power Mac supports in OS X and is part of 802.11ac Gigabit WiFi. This turns out to be a blessing, because KRACK can actually recover the key from GCMP-based connections and forge packets in both directions. This is even worse than TKIP's exposure, despite being the older and historically more insecure means of encryption.

The router situation is probably worst of all. Many older WiFi access points will never receive firmware updates, and even if they do, just patching the router is insufficient; every connecting client must also be patched. Some information circulated earlier that said only patching the router is adequate to mitigate the risk, but the discoverer of the flaw is clear both clients and the router must be updated to eliminate the risk completely.

Given it's not currently clear how we can patch OS X, then, what can you do with your Power Mac? Well, obviously, if you have the ability to hardwire your system, that would be preferable. All of my desktop Power Macs connect to a secured internal network over wired Ethernet that cannot directly route to the Internet.

If your connection to the router you control is still using TKIP (or any form of WPA or WEP), you should make sure it is WPA2 AES-CCMP. Log into your router and look at your security settings and change them if necessary; while you're at it, also see if your manufacturer has a firmware update for your router. While AES-CCMP is still vulnerable to some of these attacks and traffic secured by it can be decrypted, the actual key cannot be forged, so an attacker cannot actually join your network and attack it in place; they would have to clone your WiFi router's MAC address to a new access point with the same name on a different channel that's in range. This might be a risk in a hotel or apartment building but probably not in your house unless your neighbour is naughty and needs a baseball bat education. (If you have an Apple AirPort base station, this old TidBITS article can help you with the steps.) You can confirm your setup by opening a Terminal and entering these commands ([...] means not important for this usage):

% cd /System/Library/PrivateFrameworks/Apple80211.framework/Resources/
% ./airport -s
1 Infrastructure networks found:
       SSID Security     Ch [...] BSSID
yournetwork WPA2 PSK      6 [...] 20:4e:7f:ff:fe:fd [...](AES2),[...]
% ./airport -I
[...]
            SSID: yournetwork
        Security: WPA2 PSK cipher: AES2

These steps use a command line utility called airport that comes with Apple80211.framework; you can see other commands with ./airport --help. The first airport command scans for access points. In place of the SSID yournetwork, you should see the name you assigned your router in its settings; its channel may or may not be six, its BSSID will almost certainly differ from this example, and you may see any number of other access points your PowerBook is in range of. What you should not see under ordinary circumstances are multiple copies of your network SSID with the same BSSID on multiple channels. If you do, something might be wrong!

The second airport command tells you what access point you are currently associated with. Verify the SSID matches the one you expect and that the security is WPA2 and AES2 (notice this appeared in the first command, too). Periodically recheck these commands as you get suspicious-looking new neighbours or black vans and helicopters show up on your block. Consider replacing your router if there is no update; this won't help your Power Mac, but it would potentially help other connecting devices that were themselves updated.

If you are connecting to a router you can't control, like a public access point in your coffee shop or hotel, you should treat any WiFi connection you make to it as if it were open and unencrypted and that an attacker can see and forge any traffic you generate. Though the commands above can give you an idea of your instantaneous risk, even if AES-CCMP is in use a wily attacker may choose to deploy their malicious access point intermittently or when you're not checking, so your best defense is to encrypt what you send and receive. Only use https:// URLs and prefer sites that use HTTP Strict Transport Security and HTTP Public Key Pinning, both of which TenFourFox supports, so that an initial HTTP-to-HTTPS redirect is less likely to be intercepted and stripped and it is much harder for an attacker to impersonate a HPKP-secured site. There are still some sophisticated ways to get around even these added precautions, however, so if you need to do something highly secure like banking or taxes I'd strongly advise going home and plugging into your router's Ethernet ports directly. Even a VPN might not be enough.

Meanwhile, I guess I'll be rewriting that Power Mac security rollup post again. Assuming the current state of AES-CCMP holds, though, there may be a way to design a tool to programmatically/automatically detect a forged connection even if the underlying vulnerability cannot be corrected. I have a few ideas about that. More later.

Thursday, October 12, 2017

OverbiteWX now available from AMO

OverbiteWX, the WebExtensions Gopher protocol add-on for Firefox, is now available from Mozilla Addons.

OverbiteWX is only for Firefox 56+. TenFourFox and Firefox 52ESR can still use OverbiteFF, which is a superior add-on in every respect for obvious reasons.

New OverbiteWX users, please read the directions thoroughly! And Mozilla, how about a spec for bug 1247628 so we can finally get TCP sockets working in WebExtensions? We can't even scratch our itch because you won't tell us what type of scratching you'll accept!

Thursday, October 5, 2017

Various and sundry: OverbiteWX is coming, TenFourFox FPR4 progress, get your Talos orders in and Microsoft's new browser has no clothes

This blog post is coming to you from a midway build of TenFourFox FPR4, now with more AltiVec string acceleration, less browser chrome fat, some layout performance updates and upgraded Brotli, OTS and WOFF2 support (current to what's in mozilla-central). Next up is getting some more kinks out of CSS Grid support, and hopefully a beta will be ready in a couple weeks for you to play with.

Meanwhile, for those of you using the Gopher enabler add-on OverbiteFF on Firefox, its successor is on the way for the Firefox self-inflicted add-on apocalypse: OverbiteWX. OverbiteWX requires Firefox 56 or higher and implements an internal protocol handler that redirects gopher:// URLs typed in the Firefox omnibox or clicked on to the Floodgap Public Gopher Proxy. The reason I've decided to create a new one instead of uploading a "WebExtensions-compatible" version is because, frankly, right now it's impossible. Because there is still no TCP socket API in WebExtensions, there is presently no way to implement a Gopher handler except via a web proxy, and this would be unexpected behaviour to an OverbiteFF user expecting a direct connection (which implemented a true nsIChannel to make the protocol once again a first class citizen in the browser). Since this means Gopher URLs you access are now being sent through an external service, albeit a benign one I run, I think you at least should opt in to that by affirmatively getting the new extension rather than being silently "upgraded" to a new version with (despite my best efforts) rather less functionality.

The extension is designed to be forward compatible so that in the near future you can select from your choice of proxies, and eventually, once Someone(tm) writes the API, true socket access directly to the Gopher server of your choice. It won't be as nice as OverbiteFF was, but given that WebExtensions' first and most important goal is to reduce what add-on authors can do to the browser, it may be as good as we get. A prototype is available from the Floodgap Gopher server, which, if you care about Gopher, you already can access (please note that this URL is temporary). Assuming no issues, a more fully-fledged version with a bit more window dressing should be available in AMO hopefully sometime next week.

TenFourFox users, never fear; OverbiteFF remains compatible. I've also been approached about a Pale Moon version and I'm looking into it.

For those of you following my previous posts on the Raptor Talos II, the next-generation POWER9 workstation with a fully-open-source stack from the firmware to the operating system and no x86 anywhere, you'll recall that orders are scheduled for fulfillment starting in Q4 2017. And we're in Q4. Even though I think it's a stellar package given what you get, it hasn't gotten any cheaper, so if you've got your money together or you've at least got a little headroom on the credit card it's time to fish or cut bait. Raptor may still take orders after this batch starts shipping, but at best you'll have a long wait for their next production run (if there is one), and at worst you might not get to order at all. Let Raptor know there is a lasting and willing market for an alternative architecture you fully control. This machine really is the best successor to the Power Mac. When mine arrives you'll see it first.

Last but not least, Microsoft is announcing their Edge browser for iOS and Android. "Cool," sez I, owner of a Pixel XL, "another choice of layout engines on Android" (I use Android Firefox, natch); I was rather looking forward to seeing the desktop Edge layout engine running on non-Microsoft phones. Well, no, it's just a shell over Blink and Chromium. Remember a few years ago when I said Blink would eat the Web? Through attrition and now, arguably, collusion, that's exactly what's happening.

Tuesday, September 26, 2017

TenFourFox FPR3 available ... when SourceForge is (also: Fx57 is yugly)

Sorry, everyone. I am well aware that SourceForge is down and you can't download TenFourFox FPR3 (or, for that matter, Classilla) right now. I don't have any control over that. If this keeps up more than a day or two, we'll see if we can get alternative hosting up somewhere.

Also, my office PC (Windows 7) is now on the Firefox 57 beta and it's ... really garish and ugly looking. Switching the layout to Compact and the theme to Light helps a little with the tab bar, but the KITT loading tab animation is distracting, the icons manage to be intrusive and bland simultaneously, and the new logo is a bad LSD trip (to say nothing of the fact half my extensions stopped working, and while I knew that was coming, most of them have no replacement because the APIs don't yet exist). While I thought Australis was a step backwards in terms of utility, at least it had some design consistency. Photon, on the other hand, is all over the place and it's an unwelcome change on top of everything else. I'm almost afraid to update Firefox on the MacBook Air.

But, to be fair, it is palpably faster. Much faster. I certainly can't argue that. Nevertheless, the compromises made are such that if it weren't for Google's relentless commitment to snoop on everything I do, I have to candidly say I'm not sure I'd be sticking with the new Firefox.

Sunday, September 24, 2017

TenFourFox FPR3 available

TenFourFox Feature Parity Release 3 is now available (downloads, hashes, release notes), after much delay due to Floodgap's gateway crapping its pants on Friday night. You'll be interested to know that it's a PowerPC too, by the way (a Motorola Freescale e300 series microcontroller, roughly equivalent to a 603e). There's a reason I have an SLA, which is to have a tech dispatched to Floodgap HQ in the dead of night to reflash the firmware which is specific to my ISP, but it also meant I spent Friday evening twiddling my thumbs instead of applying security patches. Sorry about that.

The fix for issue 72 did not stick, unfortunately, so I backed it out and replaced it with additional debugging code (thus, there is also a Debug version). Other than completing the rest of the relevant security updates, there are no other changes relative to the FPR3 beta. As usual expect this to go live tomorrow night sometime Pacific.

For FPR4, I have another large AltiVec upgrade in mind, and I would like to take a first pass at CSS Grid support and maybe also WOFF2 updates. In addition, because of the impending release of Firefox 57 "Judgment Day for XUL" this will be the first release of TenFourFox to have the "Get Add-ons" tab removed, since the Mozilla-specific pages will be hawking WebExtensions. You can still install old-style XUL addons compatible with the underlying Gecko 45 infrastructure; they'll just be something you have to separately download from AMO or whatever. While I might reintroduce this tab in the future, right now I don't have enough time to maintain a full-service legacy add-on site myself. However, if this is something Someone(tm) wants to work on and they can meet the technical requirements (and make a commitment to hosting it for an indefinite period), we can talk about it and see if you're the right fit for our community. Open a ticket on Github if you're that person.

Friday, September 22, 2017

JAEUA (Just another endangered Universal application), or, the three heads of Tutti II

On this blog, Universal doesn't mean that watered-down 32-bit/64-bit Intel nonsense. It means actually running on multiple system architectures, like 68K and PowerPC in the "fat binary" days, or PowerPC and Intel at the dawn of the OS X i386 era (as OS X has always been able to do even when Marklar was a skunkworks project thanks to NeXTSTEP).

So here's another one. I maintain an emulator of the first home computer I ever had as a kid, the Tomy Tutor, called Tutti II (the original Tutti was actually a simulator for the Commodore 64, and I wrote that too). It descends from an earlier emulator written for Windows called TutorEm which was conveniently SDL-based, so I made some endian fixes for PowerPC and ported it to OS X with some fixes and new features. Download it and play with the demo tape images on the page. It runs on any Mac that can run 10.4 or later, PowerPC or Intel. It runs just dandy on my Sierra-based i7 MacBook Air all the way down to my Tiger-based Sawtooth G4.

The point of this blog post isn't (merely) shameless self-promotion, though; there are some technical points I want to make too. Tutti II isn't just a Universal PowerPC/Intel app; it's actually a three-headed chimera. While the SDL dylib it uses is a relatively pedestrian ppc and i386 Universal library, if you run lipo on the core tutti executable itself you'll find three architectures: one for ppc750 (i.e., G3), one for ppc7400 (i.e., G4), and one for i386 (Intel 32-bit).

Why are there three versions? Because AltiVec. If you look at the source code, you'll find conditional defines for AltiVec acceleration mostly within the TMS 9918A video chip emulation which are used for bitmap splats and scales. This is part of what enables it to run well even on my 1GHz iMac G4. In fact, given that the Mach-O field for number of architectures is a 32-bit integer, you are likely to run out of file offset space (also a 32-bit integer) in a multi-architecture binary long before you run out of actual and artificial architectures to cram in it. Mac OS X looks at the binary and if your system has Intel, runs the Intel portion. If it's PowerPC and it has AltiVec, it runs the AltiVec version, and failing that, the G3 version. No runtime checking is required within the code itself. (The only reason I haven't bothered to do a ppc7450 or ppc970 version too and make it five-headed is because it runs so fast already they're not likely to yield much, if any, noticeable benefit.)

The second point is that this is made much easier because everything is 32-bit. Although Tutti II is mostly Cocoa-based internally and probably could be made to build 64-bit, Xcode 2.5 doesn't support 64-bit Intel compilation, the Universal 10.4 SDK is only 32-bit, and the specific 32-bit SDL 1.2.14 version I use occupies a narrow sweet spot where it uses CoreGraphics instead of QuickDraw for forward compatibility while still functioning on PowerPC 10.4. But, because it's 32-bit, I can build the entire app from the G5 on 10.4 with that library and everything easily descends from almost exactly the same code base. This may no longer be possible after macOS 10.14, whatever it's called (I'm hoping for "macOS Arvin"), ends the ability to run "32-bit applications without compromise." Apple doesn't say what that compromise might be, but my guess is either that the operating system will not include 32-bit components and they will be a separate download for some transitional period (like Rosetta in 10.6), or Intel Carbon applications will be entirely unsupported, as there is no 64-bit Carbon, or maybe even both. Apple may also choose to completely remove things like Intel QuickDraw at the same time, which hasn't been supported since 10.4 but does still run on current versions of macOS, and is only really meaningful for Carbon also. After these pieces are completely decommissioned, you'll have to run High Sierra or Snow Leopard in a VM, I suppose.

As I've mentioned before, this is bad for Power Macs because other than PowerPC bigots like me, what residual PowerPC application support remains is largely due to the fact it works without additional effort and it's more work to remove it than not to bother. I suspect many cross-builders have some old Power Mac or early Intel Mac in a corner with an Xcode that just happens to still build for PowerPC, and the binary it spits out still "just works" on modern Macs, so they leave it alone. Even codesigning didn't really change this much because these cross-platform builders don't like paying the Apple developer tax as much as I don't, so they don't need it (Tutti II is also not a signed application, and probably never will be). Once this is no longer possible, however, these builders will probably just remove PowerPC support entirely since it won't be compatible with newer versions of Xcode, so start preserving source code archives where you find them so you can maintain and build it yourself.

In my case, since I'm planning to move to POWER9 on Linux instead of whatever the next Mac Pro turns out to be, when 32-bit Mac apps are gone completely that will mean the end of Tutti II on current versions of macOS. There will still be a build for Power Macs, but since I'm actually looking into cross-compiling it for Windows, rather than chugging out a special 64-bit macOS build and maintaining it separately I'll just make current Mac users run the 32-bit Windows binary in WINE. That's just less work for me and satisfies my internal curmudgeon, so there.

Look for TenFourFox FPR3 final probably tomorrow or Sunday, depending on when the build cycle finishes.

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?