February patch set for TenFourFox

I was slack on doing the Firefox 128ESR platform rebase for TenFourFox, but I finally got around tuit, mostly because I've been doing a little more work on the Quad G5 and put some additional patches in to scratch my own itches. (See, this is what I mean by "hobby mode.")

The big upgrade is a substantial overhaul of Reader Mode to pick up interval improvements in Readability. I remind folks that I went all-in on Reader Mode for a reason: it's lightweight, it makes little demands of our now antiquated machines (and TenFourFox's antiquated JavaScript runtime), and it renders very, very fast. That's why, for example, you can open a link directly in Reader Mode (right-click, it's there in the menu), the browser defaults to "sticky" Reader Mode where links you click in an article in Reader Mode stay in Reader Mode (like Las Vegas) until you turn it off from the book icon in the address bar, and you can designate certain sites to always open in Reader Mode, either every page or just subpages in case the front page doesn't render well — though that's improved too. (You can configure that from the TenFourFox preference pane. All of these features are unique to TenFourFox.) I also made some subtle changes to the CSS so that it lays out wider, which was really my only personal complaint; otherwise I'm an avid user. The improvements largely relate to better byline and "fluff" text detection as well as improved selection of article inline images. Try it. You'll like it.

I should note that Readability as written no longer works directly on TenFourFox due to syntactic changes and I had to do some backporting. If a page suddenly snaps to the non-Reader view, there was an error. Look in the Browser console for the message and report it; it's possible there is some corner I didn't hit with my own testing.

In addition, there are updates to the ATSUI font blacklist (and a tweak to CFF font table support) and a few low-risk security patches that likely apply to us, as well as refreshed HSTS pins, TLS root certificates, EV roots, timezone data and TLDs. I have also started adding certain AI-related code to the nuisance JavaScript block list as well as some new adbot host aliases I found. Those probably can't run on TenFourFox anyway (properly if at all), but now they won't even be loaded or parsed.

The source code can be downloaded from Github (at the command line you can also just do git clone https://github.com/classilla/tenfourfox.git) and built in the usual way. Remember that these platform updates require a clobber, so you must build from scratch. I was asked about making TenFourFox a bit friendlier with Github; that's a tall order and I'm still thinking about how, but at least the wiki is readable currently even if it isn't very pretty.

WebP chemspill patch on Github

A fix is in the TenFourFox tree for MFSA 2023-40, a/k/a CVE-2023-4863, which is a heap overflow in the WebP image decoder. Firefox 45 would not ordinarily be vulnerable to this but we have our own basic WebP decoder using Google's library, so we are technically exploitable as well. I was working on a fix of my own but the PM27 fix that roytam1 cherrypicked is cleaner, so I've added that patch and one two (a followup was needed) more for correctness. Although this issue is currently being exploited in the wild, it would require a PowerPC-specific attack to be successful on a Power Mac. You do not need to clobber to update your build.

August patch set for TenFourFox

The next patch set has landed, bringing the TenFourFox security base up to 115ESR. This includes the usual new certificate roots and updates to pins, HSTS and TLDs, as well as applicable security updates such as a full pull-up to the browser's SCTP support (not that this is frequently used in TenFourFox but rather to make future patches a little more tractable). On the bug fix side there is an update to the ATSUI font blocklist (thanks Chris T) and a wallpaper for a JavaScript-related crash on apple.com (thanks roytam1). Finally, basic adblock has been made stricter and is now also targetting invasive fingerprinting scripts. This adds a bit more overhead to checking the origin but that all runs at native C++ speed, and ensures we're less likely to get bogged down running JavaScript that we'd really rather not.

As this is a base pullup, building this time around will require a full clobber, so be sure to clear out everything before you begin.

For our next set, I'm thinking of an update to Reader Mode, since I firmly believe that's one of the most useful modes to run TenFourFox in on limited Power Mac hardware. That's why we made it sticky and provided a way to automatically open it by site (under Preferences, TenFourFox) — on resource-limited systems a resource-light view of a resource-heavy page is pretty much the way to go. And isn't everything resource-heavy to a Power Mac?

Power Mac ransomware? Yes, but it's complicated

Wired ran an article today (via Ars Technica) about apparent macOS-compatible builds of LockBit, a prominent encrypting ransomware suite, such as this one for Apple silicon. There have been other experimental ransomware samples that have previously surfaced but this may be the first known example of a prominent operation specifically targeting Macs, and it is almost certainly not the last.

What caught my eye in the article was a report of PowerPC builds. I can't seem to get an alleged sample to analyse (feel free to contact me at ckaiser at floodgap dawt com if you can provide one) but the source for that assertion appears to be this tweet.

Can that file run on a Power Mac? It appears it's indeed a PowerPC binary, but the executable format is ELF and not Mach-O, so the file can only run natively on Linux or another ELF-based operating system, not PowerPC Mac OS X (or, for that matter, Mac OS 9 and earlier). Even if the raw machine code were sprayed into memory for an exploitable Mac application to be tricked into running, ELF implies System V ABI, which is similar but different from the PowerOpen ABI used for PowerPC-compatible versions of Mac OS, and we haven't even started talking about system calls. Rather than a specific build targetting Power Macs, most likely this is evidence that the LockBit builders simply ran every crosscompiler variation they could find on their source code: there are no natively little-endian 32-bit PowerPC CPUs, for example, yet there's a ppcle build visible in the screenshot. Heck, there's even an s390x build. Parents, don't let your mainframes out unsupervised.

This is probably a good time to mention that I've been working on security patches for TenFourFox and a couple minor feature adjustments, so stay tuned. It's been awhile but such are hobbies.

curl, Let's Encrypt and Apple laziness

The built-in version of curl on any Power Mac version of OS X will not be capable of TLS 1.1 or higher, so most of you who need it will have already upgraded to an equivalent with MacPorts. However, even for later Intel Macs that are ostensibly supported -- including my now legacy MacBook Air with Mojave I keep around for running 32-bit Intel -- the expiration of one of Let's Encrypt's root certificates yesterday will suddenly mean curl may suddenly cease connecting to TLS sites with Let's Encrypt certificates. Yesterday I was trying to connect to one of my own Floodgap sites, unexpectedly got certificate errors I wasn't seeing in TenFourFox or mainline Firefox, and, after a moment of panic, suddenly realized what had happened. While you can use -k to ignore the error, that basically defeats the entire idea of having a certificate to start with.

The real hell of it is that Mojave 10.14 is still technically supported by Apple, and you would think updating the curl root certificate store would be an intrinsic part of security updates, but you'd be wrong. The issue with old roots even affects Safari on some Monterey betas, making the best explanation more Apple laziness than benign neglect. Firefox added this root ages ago and so did TenFourFox.

If you are using MacPorts curl, which is (IMHO) the best solution on Power Macs due to Ken's diligence but is still a dandy alternative to Homebrew on Intel Macs, the easiest solution is to ensure curl-ca-bundle is up-to-date. Homebrew (and I presume Tigerbrew, for 10.4) can do brew install curl-ca-bundle, assuming your installation is current.

However, I use the built-in curl on the Mojave MacBook Air. Ordinarily I would just do an in-place update of the root certificate bundle, as I did on my 10.4 G5 before I started using a self-built curl, but thanks to System Integrity Protection you're not allowed to do that anymore even as root. Happily, the cURL maintainers themselves have a downloadable root certificate store which is periodically refreshed. Download that, put it somewhere in your home directory, and in your .login or .profile or whatever, set CURL_CA_BUNDLE to its location (on my system, I have a ~/bin directory, so I put it there and set it to /Users/yourname/bin/cacert.pem).

Questionable RCE with .webloc/.inetloc files

A report surfaced recently that at least some recent versions of macOS can be exploited to run arbitrary local applications using .inetloc files, which may allow a drive-by download to automatically kick off a vulnerable application and exploit it. Apple appeared to acknowledge the fault, but did not assign it a CVE; the reporter seems not to have found the putative fix satisfactory and public disclosure thus occurred two days ago.

The report claims the proof of concept works on all prior versions of macOS, but it doesn't seem to work (even with corrected path) on Tiger. Unfortunately due to packing I don't have a Leopard or Snow Leopard system running right now, so I can't test those, but the 10.4 Finder (which would launch these files) correctly complains they are malformed. As a safety measure in case there is something exploitable, the October SPR build of TenFourFox will treat both .webloc and .inetloc files that you might download as executable. (These files use similar pathways, so if one is exploitable after all, then the other probably is too.) I can't think of anyone who would depend on the prior behaviour, but in our unique userbase I'm sure someone does, so I'm publicizing this now ahead of the October 5 release. Meanwhile, if someone's able to make the exploit work on a Power Mac, I'd be interested to hear how you did it.

Floodgap.com down due to domain squatter attack on Network Solutions

Floodgap sites are down because someone did a mass attack on NetSol (this also attacked Perl.com and others). I'm working to resolve this. More shortly.

Update: Looks like it was a social engineering attack. I spoke with a very helpful person in their security department (Beth) and she walked me through it. On the 26th someone initiated a webchat with their account representatives and presented official-looking but fraudulent identity documents (a photo ID, a business license and a utility bill), then got control of the account and logged in and changed everything. NetSol is in the process of reversing the damage and restoring the DNS entries. They will be following up with me for a post-mortem. I do want to say I appreciate how quickly and seriously they are taking this whole issue.

If you are on Network Solutions, check your domains this morning, please. I'm just a "little" site, and I bet a lot of them were attacked in a similar fashion.

Update the second: Domains should be back up, but it may take a while for them to propagate. The servers themselves were unaffected, and I don't store any user data anyway.

TenFourFox FPR21 available

TenFourFox Feature Parity Release 21 final is now available for testing (downloads, hashes, release notes). Since the beta looks like it's working well, this release simply completes the upgrade with updates to the ATSUI font blacklist and all outstanding security patches, including backported fixes from the recent Mozilla security chemspill for CVE-2020-6819 and CVE-2020-6820. Note that while we are indeed vulnerable to those security issues and they are fixed in FPR21, they would require a PowerPC-specific attack to be successful. Assuming no issues, this will go live Monday evening Pacific time as usual.

In addition, language pack users should note that new langpacks are available for FPR21, thanks to Chris T's hard work as always. These updated langpacks have additional strings related to TLS 1.3 plus other sundry fixes; simply run the installer as in prior updates. They will go live on Monday too.

TenFourFox FPR19b1 available

TenFourFox Feature Parity Release 19 beta 1 is now available (downloads, hashes, release notes). I was originally going to do more iteration on Reader mode in FPR19, but in a possible recurrence of the issue that broke SourceForge downloads temporarily, a user reported on Tenderapp they had a site that was failing in the same way.

On the test system I was able to reproduce the problem and it was due to the selected cipher having insufficient cryptographic strength to pass HTTP/2 TLS profile validation. The selected cipher was one I added as a stopgap for FPR7 to fix another site which was still working (and did not use HTTP/2, hence it didn't exhibit the issue). Disabling that cipher restored the new failing site, but caused the site I put the workaround for in FPR7 to fail, so in no situation could I get both sites to be happy with the set available. Although I didn't really want to do this, the only real solution here was to upgrade NSS, the underlying cryptographic library, to add additional more modern ciphers to replace the older one that now needed to be reverted. With this in place and some other fixes, now both sites work, and this probably fixes others.

The reason I was reticent to update NSS (and the underlying NSPR library) was because of some custom changes and because I was worried changes in cipher coverage would break compatibility. However, there wasn't a lot of choice here, so I manually patched up our custom AltiVec-accelerated NSPR to a current release and spliced in a newer NSS overlaid with our build system changes. I tested this on a few sites I knew to be using old crypto libraries and they still seemed to connect fine, and as a nice side benefit some of the more modern ciphers are more efficient and therefore improve throughput a bit. It also makes the likelihood of successfully updating TenFourFox to support TLS 1.3 much higher; if this sticks, I may attempt this as soon as FPR20.

There are a couple sundry minor changes to be implemented at final release, mostly minor bug fixes, but I want to get this beta in testing as quickly as possible within the shrinking rapid release timeframe. I have otherwise intentionally limited the scope of FPR19 to mostly just the crypto upgrade so that we have a clear regression range. If you notice sites have stopped being accessible in FPR19, please verify they are working in FPR18 (people say "I remember it worked," but sites change more than TenFourFox does, so please check and save us some time here), and if it does indeed work in FPR18 report it in the comments so I can analyse the problem. I am very unlikely to revert this change given that it's necessary going forward and probably the best of the available options, but if I can add exceptions that don't compromise overall security I'm willing to do so in the name of supporting backwards compatibility with sites the browser used to be able to access. FPR19 goes final parallel with Firefox 73 and 68.5 somewhere around February 11.

TenFourFox not vulnerable to CVE-2019-17026

After doing some analysis late last night and today to determine if we need a chemspill build, I have concluded that TenFourFox is not vulnerable to CVE-2019-17026, or at least not to any of the PoCs or test cases available to me. This is the 0-day that was fixed in Firefox 72.0.1 and 68.4.1. Though a portion of the affected code exists in the TenFourFox code base, there doesn't seem to be a way to trigger the exploit due to various other missing optimizations and the oddities of our JIT. (Firefox 45-based browsers using our patches as upstream should bear in mind this may not be true for other architectures, however.) Absent evidence to the contrary it will be nevertheless patched as part of the standard security fixes in FPR19.

Stand by for FPR14 SPR1 chemspill

Mozilla has shipped a fix for MFSA2019-18 in Firefox 67.0.3 and 60.7.1. This exploit has been detected in the wild, and while my analysis indicates it would require a PowerPC-specific attack to be exploitable in official TenFourFox builds (the Intel versions may be directly exploited, however), it could probably cause drive-by crashes and we should therefore ship an urgent fix as well. The chemspill is currently undergoing confidence tests and I'm shooting to release builds before the weekend. For builders, the only change in FPR14 SPR1 is the patch for bug 1544386, which I will be pushing to the repo just as soon as I have confirmed the fix causes no regressions.

This chemspill also holds up the FPR15 beta which was actually scheduled for today. Unfortunately, the big JavaScript update I've been trying to make for the last couple cycles also ran aground and will not be in FPR15 either. There is a smaller one and some other improvements, so this is not an empty release, but I'll talk more about that in a few days.

ZombieLoad doesn't affect Power Macs

The latest in the continued death march of speculative execution attacks is ZombieLoad (see our previous analysis of Spectre and Meltdown on Power Macs). ZombieLoad uses the same types of observable speculation flaws to exfiltrate data but bases it on a new class of Intel-specific side-channel attacks utilizing a technique the investigators termed MDS, or microarchitectural data sampling. While Spectre and Meltdown attack at the cache level, ZombieLoad targets Intel HyperThreading (HT), the company's implementation of symmetric multithreading, by trying to snoop on the processor's line fill buffers (LFBs) used to load the L1 cache itself. In this case, side-channel leakages of data are possible if the malicious process triggers certain specific and ultimately invalid loads from memory -- hence the nickname -- that require microcode assistance from the CPU; these have side-effects on the LFBs which can be observed by methods similar to Spectre by other processes sharing the same CPU core. (Related attacks against other microarchitectural structures are analogously implemented.)

The attackers don't have control over the observed address, so they can't easily read arbitrary memory, but careful scanning for the type of data you're targeting can still make the attack effective even against the OS kernel. For example, since URLs can be picked out of memory, this apparent proof of concept shows a separate process running on the same CPU victimizing Firefox to extract the URL as the user types it in. This works because as the user types, the values of the individual keystrokes go through the LFB to the L1 cache, allowing the malicious process to observe the changes and extract characters. There is much less data available to the attacking process but that also means there is less to scan, making real-time attacks like this more feasible.

That said, because the attack is specific to architectural details of HT (and the authors of the attack say they even tried on other SMT CPUs without success), this particular exploit wouldn't work even against modern high-SMT count Power CPUs like POWER9. It certainly won't work against a Power Mac because no Power Mac CPU ever implemented SMT, not even the G5. While Mozilla is deploying a macOS-specific fix, we don't need it in TenFourFox, nor do we need other mitigations. It's especially bad news for Intel because nearly every Intel chip since 2011 is apparently vulnerable and the performance impact of fixing ZombieLoad varies anywhere from Intel's Pollyanna estimate of 3-9% to up to 40% if HT must be disabled completely.

Is this a major concern for users? Not as such: although the attacks appear to be practical and feasible, they require you to run dodgy software and that's a bad idea on any platform because dodgy software has any number of better ways of pwning your computer. So don't run dodgy programs!

Meanwhile, TenFourFox FPR14 final should be available for testing this weekend.

TenFourFox FPR13 SPR1 available

TenFourFox Feature Parity Release 13 Security Parity Release 1 ("FPR13.1") is now available and live (downloads, hashes, release notes). The Pwn2Own vulnerabilities do not work on TenFourFox in their present form (not only because we're PowerPC but also because of our hybrid-endian typed arrays and other differences), but I have determined that TenFourFox-specific variant attacks could be exploitable, so we are patched as well. This should also reduce the risk of crashes from attempts to exploit mainline x86 Firefox.

Meanwhile, H.264 support for TenFourFox FPR14 appears to be sticking. Yes, folks: for the first time you can now play Vimeo and other H.264-only videos from within TenFourFox using sidecar ffmpeg libraries, and it actually works pretty well! Kudos to Olga for the integration code! That said, however, it comes with a couple significant caveats. The first is that while WebM video tends not to occur in large numbers on a given page, H.264 videos nowadays are studded everywhere (Vimeo's front page, Twitter threads, Imgur galleries, etc.) and sometimes try to autoplay simultaneously. In its first iteration this would cause the browser to run out of memory if a large number of higher resolution videos tried to play at once, and sometimes crash when an infallible memory allocation fallibled. Right now there is a lockout in the browser to immediately halt all H.264 decoding if any instance runs out of memory so that the browser can save itself, but this needs a lot more testing to make sure it's solid, and is clearly a suboptimal solution. Remember that we are under unusual memory constraints because of the large amount of stack required for our JIT.

The second caveat with H.264 support is that while the additional AltiVec support in ffmpeg (TenFourFox is compatible with 2.8 and 3.4) makes H.264 decoding faster than WebM, it is not dramatically so, and you should not expect a major jump in video performance. (In fact, quite the opposite on pages like the above.) Because of that, and because I have to build and support ffmpeg library installers now, I am only officially supporting H.264 on G4/7450 and G5 based on the existing 1.25GHz minimum CPU requirement for web video (and you should really have 2GB or more of memory). There will not be an official TenFourFox ffmpeg build for G4/7400 and G3 (or, for that matter, Intel); while you can build it yourself mostly out of the box with Xcode 2.5 and I won't have any block in TenFourFox for user-created libraries, I will provide neither support nor ffmpeg builds for these architectures. Olga's current FFmpeg Enabler does work on 10.4 now and does support 7400 and my future 7450 version will run on a 7400, so early G4 users have a couple options, but either way you would be on your own. Sorry, there are enough complaints about TenFourFox performance already without me making promises of additional functionality I know those systems can't meet.

Back on the good news side, the AppleScript-JavaScript bridge is also complete and working. As a example, consider this script, which actually works in the internal test build:

tell application "TenFourFoxG5"
  tell front browser window
    set URL of current tab to "https://www.google.com/"
    repeat while (current tab is busy)
      delay 1
    end repeat
    tell current tab
      run JavaScript "let f = document.getElementById('tsf');f.q.value='tenfourfox';f.submit();"
    end tell
    repeat while (current tab is busy)
      delay 1
    end repeat
    tell current tab
      run JavaScript "return document.getElementsByTagName('h3')[0].innerText + ' ' + document.getElementsByTagName('cite')[0].innerText"
    end tell
  end tell
end tell

I'll let you ponder what it does until the FPR14 beta comes out, but it should be obvious that this would be great for automating certain tasks in the browser now that you don't have to rely on figuring out how to send the exact UI event anymore: you can just manipulate the DOM of any web page directly from AppleScript. Firefox still can't do that! (Mozilla can port over my code; I'd be flattered.)

The last things to do are a couple security and performance tweaks, and then one more desperate attempt to get Github working. I'm still not sure how feasible the necessary JavaScript hacks will be yet but come hell or high water we're on track for FPR14 beta 1 in early April.

Stand by for urgent security update

Pwn2Own came and went and Firefox fell with it. The __proto__ vulnerability seems exploitable in TenFourFox, though it would require a PowerPC-specific attack to be fully weaponized, and I'm currently evaluating the other bug. Builds ("FPR13 SPR1") including fixes for either or both depending on my conclusions will be issued within the next couple days.

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.

TenFourFox and Hack2Win

After a diligent analysis of the test cases and our existing code, TenFourFox is not known to be vulnerable to the exploits repaired in Firefox 62.0.3/60ESR. Even if the flaws in question actually existed as such in our code, they would require a PowerPC-specific exploit due to some architecture-dependent aspects of the attacks.

Fruitfly and the Power Mac

First, some updates on TenFourFox FPR10. There are a couple of security related changes, some DOM updates and some JavaScript ES6 compatibility updates which should fix a few site glitches. However, I'm also trying to track down a debug-only regression in layout present in at least FPR9 and possibly earlier, and there are at least two major sites broken that I do not have a clear understanding of why (and are not regressions). Unfortunately, it is unlikely there will be a solution in time since FPR10 is timed to come out with the next Firefox on October 23ish.

New information came to light recently regarding Fruitfly, also detected by some antivirus systems as Quimitchin, which was discovered quietly infecting machines in January 2017. An unusual Mac-specific APT that later was found to have Windows variants (PDF), Fruitfly was able to capture screenshots, keystrokes, images from the webcam and system information from infected machines. At that time it was believed it was at most a decade old, placing the earliest possible infections in that timeline around 2007 and thus after the Intel transition. The author, 28-year-old Phillip Durachinsky, was eventually charged in January of this year with various crimes linked to its creation and deployment.

Late last month, however, court documents demonstrated that Durachinsky actually created the first versions of Fruitfly when he was 14 years old, i.e., 2003. This indicates there must be a PowerPC-compatible variant which can infect systems going back to at least Panther and probably Jaguar, and squares well with contemporary analyses that found Fruitfly had "ancient" system calls in its code, including, incredibly, GWorld and QuickDraw ones.

The history the FBI relates suggests that early infections were initiated manually by him, largely for the purpose of catching compromising webcam pictures and intercepting screenshots and logins when users entered keystrokes suggesting sexual content. If you have an iSight with the iris closed, though, there was no way he could trigger that because of the hardware cutoff, another benefit of having an actual switch on our computer cameras (except the iMac G5, which was a bag of hurt anyway and one of the few Power Macs I don't care for).

Fruitfly spreads by attacking weak passwords for AFP (Apple Filing Protocol) servers, as well as RDP, VNC, SSH and (on later Macs) Back to My Mac. Fortunately, however, it doesn't seem to get its hooks very deep into the OS. It can be relatively easily found by looking for a suspicious launch agent in ~/Library/LaunchAgents (a Power Mac would undoubtedly be affected by variant A, so check ~/Library/LaunchAgents/com.client.client.plist first), and if this file is present, launchctl unload it, delete it, and delete either ~/.client or ~/fpsaud depending on the variant the system was infected with. After that, change all your passwords and make sure you're not exposing those services where you oughtn't anymore!

For the very early pre-Tiger versions, however, assuming they exist, no one seems to know how currently those might have been kicked off because those systems lack launchd. It's possible it could have insinuated itself as a login item or into the system startup scripts, or potentially the Library/StartupItems folder, but it's probable we'll never know for sure because whatever infected systems dated from that time period have either been junked or paved over. Nevertheless, if you find a file named ~/.client on your system regardless of version that you didn't put there, assume you are infected and proceed accordingly.

TenFourFox FPR8b1 available

TenFourFox Feature Parity Release 8 beta 1 is now available (downloads, release notes, hashes). There is much less in this release than I wanted because of a family member in the hospital and several technical roadblocks. Of note, I've officially abandoned CSS grid again after an extensive testing period due to the fact that we would need substantial work to get a functional implementation, and a partially functional implementation is worse than none at all (in the latter case, we simply gracefully degrade into block-level <div>s). I also was not able to finish the HTML <input> date picker implementation, though I've managed to still get a fair amount completed of it, and I'll keep working on that for FPR9. The good news is, once the date picker is done, the time picker will use nearly exactly the same internal plumbing and can just be patterned off it in the same way. Unlike Firefox's implementation, as I've previously mentioned our version uses native OS X controls instead of XUL, which also makes it faster. That said, it is a ghastly hack on the Cocoa widget side and required some tricky programming on 10.4 which will be the subject of a later blog post.

That's not to say this is strictly a security patch release (though most of the patches for the final Firefox 52, 52.9, are in this beta). The big feature I did want to get in FPR8 did land and seems to work properly, which is same-site cookie support. Same-site cookie support helps to reduce cross-site request forgeries by advising the browser the cookie in question should only be sent if a request originates from the site that set it. If the host that triggered the request is different than the one appearing in the address bar, the request won't include any of the cookies that are tagged as same-site. For example, say you're logged into your bank, and somehow you end up opening another tab with a malicious site that knows how to manipulate your bank's transfer money function by automatically submitting a hidden POST form. Since you're logged into your bank, unless your bank has CSRF mitigations (and it had better!), the malicious site could impersonate you since the browser will faithfully send your login cookie along with the form. The credential never leaked, so the browser technically didn't malfunction, but the malicious site was still able to impersonate you and steal your money. With same-site cookies, there is a list of declared "safe" operations; POST forms and certain other functions are not on that list and are considered "unsafe." Since the unsafe action didn't originate from the site that set the cookie, the cookie isn't transmitted to your bank, authentication fails and the attack is foiled. If the mode is set to "strict" (as opposed to "lax"), even a "safe" action like clicking a link from an outside site won't send the cookie.

Same-site cookie support was implemented for Firefox 60; our implementation is based on it and should support all the same features. When you start FPR8b1, your cookies database will be transparently upgraded to the new database schema. If you are currently logged into a site that supports same-site cookies, or you are using a foxbox that preserves cookie data, you will need to log out and log back in to ensure your login cookie is upgraded (I just deleted all my cookies and started fresh, which is good to give the web trackers a heart attack anyway). Github and Bugzilla already have support, and I expect to see banks and other high-security sites follow suit. To see if a cookie on a site is same-site, make sure the Storage Inspector is enabled in Developer tools, then go to the Storage tab in the Developer tools on the site of interest and look at the Cookies database. The same-site mode (unset, lax or strict) should be shown as the final column.

FPR8 goes live on June 25th.

Spectre Number 4, STEP RIGHT UP!

Updated based on IBM's documentation.

In the continuing saga of Meltdown and Spectre (tl;dr: G4/7400, G3 and likely earlier 60x PowerPCs don't seem vulnerable at all; G4/7450 and G5 are so far affected by Spectre while Meltdown has not been confirmed, but IBM documentation implies "big" POWER4 and up are vulnerable to both) is now Spectre variant 4. In this variant, the fundamental issue of getting the CPU to speculatively execute code it mistakenly predicts will be executed and observing the effects on cache timing is still present, but here the trick has to do with executing a downstream memory load operation speculatively before other store operations that the CPU (wrongly) believes the load does not depend on. The processor will faithfully revert the stores and the register load when the mispredict is discovered, but the loaded address will remain in the L1 cache and be observable through means similar to those in other Spectre-type attacks.

The G5, POWER4 and up are so aggressively out of order with memory accesses that they are almost certainly vulnerable. In an earlier version of this post, I didn't think the G3 and 7400 were vulnerable (as they don't appear to be to other Spectre variants), but after some poring over IBM's technical documentation I now believe with some careful coding it could be possible -- just not very probable. The details have to do with the G3 (and 7400)'s Load-Store Unit, or LSU, which is responsible for reading and writing memory. Unless a synchronizing instruction intervenes, up to one load instruction can execute ahead of a store, which makes the attack theoretically possible. However, the G3 and 7400 cannot reorder multiple stores in this fashion, and because only a maximum of two instructions may be dispatched to the LSU at any time (in practice less since those two instructions are spread across all of the processor's execution units), the victim load and the confounding store must be located immediately together or have no LSU-issued instructions between them. Even then, reliably ensuring that both instructions get dispatched in such a way that the CPU will reorder them in the (attacker-)desired order wouldn't be trivial.

The 7450, as with other Spectre variants, makes the attack a bit easier. It can dispatch up to four instructions to its execution units, which makes the attack more feasible because there is more theoretical flexibility on where the victim load can be located downstream (especially if all four instructions go to its LSU). However, it too can execute at most just one load instruction ahead of a store, and it cannot reorder stores either.

That said, as a practical matter, Spectre in any variant (including this one) is only a viable attack vector on Power Macs through native applications, which have far more effective methods of pwning your Power Mac at their disposal than an intermittently successful attempt to read memory. Although TenFourFox has a JavaScript JIT, no 7450 and probably not even the Quad is fast enough to obtain enough of a memory timing delta to make the attack functional (let alone reliable), and we disabled the high-resolution timers necessary for the exploit "way back" in FPR5 anyway. The new variant 4 is a bigger issue for Talos II owners like myself because such an attack is possible and feasible on the POWER9, but we can confidently expect that there will be patches from IBM and Raptor to address it soon.

Secure mail on Power Macs is not a good idea

Arguably it hasn't been a good idea for awhile, but the EFAIL hack now makes it possible to decrypt even previous encrypted messages as well as current ones. All known mail clients for PowerPC OS X that can render HTML are vulnerable, including Apple Mail, Thunderbird and Tenfourbird. Earlier clients that lack this functionality are not vulnerable to this specific exploit, but their encryption capabilities are likely insufficient or not otherwise current, so they should not be considered secure either.

The EFAIL vulnerability is not as severe as it might sound because a key requirement is that an attacker already have access to the encrypted messages. If you used the tips in our security recommendations for PowerPC OS X to improve the security of your computer and your network connection, the odds of this occurring are not zero because the attacker may have already collected them in the past through other means, but are likely to be fairly low with the holes that remain. The risk can be mitigated further by disabling HTML rendering of E-mail (that means all E-mail, however, which might be a dealbreaker), and/or disabling automatic decryption of such messages (for example, I already cut and paste encrypted messages I receive into GPG directly in a Terminal window; my E-mail client never decrypts them automatically). A tool like Little Snitch could also be employed to block unexpected accesses to external servers, though this requires you to know what kinds of access would be unexpected for such messages.

Even with these recommendations, however, there may be other potential edge cases such that until someone(tm) updates Thunderbird or another mailer on Power Macs, secure encrypted mail on our systems should be handled with extreme caution and treated as if it were potentially exposed. If you require this kind of security from your E-mail and you must use a Power Mac, you're probably better off finding a webmail service with appropriate security and using TenFourFox (the webmail service then handles this), or building and using an E-mail client on some other system that is more up to date that you can access remotely and securely (which is what I do myself).