Sunday, January 7, 2018

Actual field testing of Spectre on various Power Macs (spoiler alert: G3 and 7400 survive!)

Tip of the hat to miniupnp who ported the Spectre proof of concept to PowerPC intrinsics. I ported it to 10.2.8 so I could get a G3 test result, and then built generic PowerPC, G3, 7400, 7450 and G5 versions at -O0, -O1, -O2 and -O3 for a grand total of 20 variations.

Recall from our most recent foray into the Spectre attack that I believed the G3 and 7400 would be hard to successfully exploit because of their unusual limitations on speculative execution through indirect branches. Also, remember that this PoC assumes the most favourable conditions possible: that it already knows exactly what memory range it's looking for, that the memory range it's looking for is in the same process and there is no other privilege or partition protection, that it can run and access system registers at full speed (i.e., is native), and that we're going to let it run to completion.

miniupnp's implementation uses the mftb(u) instructions, so if you're porting this to the 601, you weirdo, you'll need to use the equivalent on that architecture. I used Xcode 2.5 and gcc 4.0.1.

Let's start with, shall we say, a positive control. I felt strongly the G5 would be vulnerable, so here's what I got on my Quad G5 (DC/DP 2.5GHz PowerPC 970MP) under 10.4.11 with Energy Saver set to Reduced Performance:

  • -arch ppc -O0: partial failure (two bytes wrong, but claims all "success")
  • -arch ppc -O1: recovers all bytes (but claims all "unclear")
  • -arch ppc -O2: same
  • -arch ppc -O3: same
  • -arch ppc750 -O0: partial failure (twenty-two bytes wrong, but claims all "unclear")
  • -arch ppc750 -O1: recovers all bytes (but claims all "unclear")
  • -arch ppc750 -O2: almost complete failure (twenty-five bytes wrong, but claims all "unclear")
  • -arch ppc750 -O3: almost complete failure (twenty-six bytes wrong, but claims all "unclear")
  • -arch ppc7400 -O0: almost complete failure (twenty-eight bytes wrong, claims all "success")
  • -arch ppc7400 -O1: recovers all bytes (but claims all "unclear")
  • -arch ppc7400 -O2: almost complete failure (twenty-six bytes wrong, but claims all "unclear")
  • -arch ppc7400 -O3: almost complete failure (twenty-eight bytes wrong, but claims all "unclear")
  • -arch ppc7450 -O0: recovers all bytes (claims all "success")
  • -arch ppc7450 -O1: recovers all bytes (but claims all "unclear")
  • -arch ppc7450 -O2: same
  • -arch ppc7450 -O3: same
  • -arch ppc970 -O0: recovers all bytes (claims all "success")
  • -arch ppc970 -O1: recovers all bytes, but noticeably more slowly (and claims all "unclear")
  • -arch ppc970 -O2: partial failure (one byte wrong, but claims all "unclear")
  • -arch ppc970 -O3: recovers all bytes (but claims all "unclear")

Twiddling CACHE_HIT_THRESHOLD to any value other than 1 caused the test to fail completely, even on the working scenarios.

These results are frankly all over the map and only two scenarios fully work, but they do demonstrate that the G5 can be exploited by Spectre. That said, however, the interesting thing is how timing-dependent the G5 is, not only to whether the algorithm succeeds but also to whether the algorithm believes it succeeded. The optimized G5 versions have more trouble recognizing if they worked even though they do; the fastest and most accurate is actually -arch ppc970 -O0. I mentioned the CPU speed for a reason, too, because if I set the system to Highest Performance, I get some noteworthy changes:

  • -arch ppc -O0: recovers all bytes (claims all "success")
  • -arch ppc -O1: partial failure (eight bytes wrong, claims all "unclear")
  • -arch ppc -O2: partial failure (twenty bytes wrong, claims all "unclear")
  • -arch ppc -O3: partial failure (twenty-three bytes wrong, claims all "unclear")
  • -arch ppc750 -O0: almost complete failure (one byte recovered, but claims all "unclear")
  • -arch ppc750 -O1: partial failure (five bytes wrong, claims all "unclear")
  • -arch ppc750 -O2: complete failure (no bytes recovered, all "unclear")
  • -arch ppc750 -O3: almost complete failure (thirty bytes wrong, but claims all "unclear")
  • -arch ppc7400 -O0: recovers all bytes (claims all "success")
  • -arch ppc7400 -O1: partial failure (four bytes wrong, but claims all "unclear")
  • -arch ppc7400 -O2: complete failure (no bytes recovered, all "unclear")
  • -arch ppc7400 -O3: same
  • -arch ppc7450 -O0: recovers all bytes (claims all "success")
  • -arch ppc7450 -O1: partial failure (eight bytes wrong, but claims all "unclear")
  • -arch ppc7450 -O2: partial failure (seven bytes wrong, but claims all "unclear")
  • -arch ppc7450 -O3: partial failure (five bytes wrong, but claims all "unclear")
  • -arch ppc970 -O0: recovers all bytes (but three were "unclear")
  • -arch ppc970 -O1: recovers all bytes, but noticeably more slowly (and claims all "unclear")
  • -arch ppc970 -O2: partial failure (nineteen bytes wrong, claims all "unclear")
  • -arch ppc970 -O3: partial failure (eighteen bytes wrong, claims all "unclear")

The speed increase causes one more scenario to succeed, but which ones do differ and it even more badly tanks some of the previously marginal ones. Again, twiddling CACHE_HIT_THRESHOLD to any value other than 1 caused the test to fail completely, even on the working scenarios.

What about more recent Power ISA designs? Interestingly, my AIX Power 520 server configured as an SMT-2 two-core four-way POWER6 could not be exploited if CACHE_HIT_THRESHOLD was 1. If it was set to 80 as the default exploit has, however, on POWER6 the exploit recovers all bytes successfully (compiled with -O3 -mcpu=power6). IBM has not yet said as of this writing whether they will issue patches for the POWER6.

I should also note that the worst case on the G5 took nearly seven seconds to complete at reduced power (-arch ppc7400 -O0), though the best case took less than a tenth of a second (-arch ppc970 -O0). The POWER6 took roughly three seconds. These are not fast attacks for the limited number of bytes scanned.

Given that we know the test will work on a vulnerable PowerPC system, what about the ones we theorized were resistant? Why, I have two of them right here! Let's cut to the chase, friends, your humble author's suspicions appear to be correct. Neither my strawberry iMac G3 with Sonnet HARMONi CPU upgrade (600MHz PowerPC 750CX) running 10.2.8, nor my Sawtooth G4 file server (450MHz PowerPC 7400) running 10.4.11 can be exploited with any of ppc, ppc750 or ppc7400 at any optimization level. They all fail to recover any byte despite the exploit believing it worked, so I conclude the G3 and 7400 are not vulnerable to the proof of concept.

The attacks are also quite slow on these systems. To run on the lower clock speed Sawtooth took almost 5 seconds in realtime, even at -arch ppc7400 -O3 (seven seconds in the worst case), and pegged the processor during the test. Neither system has power management and ran at full speed.

That leaves the 7450 G4e, which as you'll recall has notable microarchitectural advances from the 7400 G4 and differences in its ability to speculatively execute indirect branches. What about that? Again, some highly timing-dependent results. First, let's look at my beloved 1GHz iMac G4 (1GHz PowerPC 7450), running 10.4.11:

  • -arch ppc -O0: almost complete failure (twenty-nine bytes wrong, claims all "success")
  • -arch ppc -O1: recovers all bytes (claims all "success")
  • -arch ppc -O2: same
  • -arch ppc -O3: partial failure (one byte wrong, but still claims all "success")
  • -arch ppc750 -O0: recovers all bytes (claims all "success")
  • -arch ppc750 -O1: recovers all bytes (claims all "success")
  • -arch ppc750 -O2: recovers all bytes (claims all "success")
  • -arch ppc750 -O3: partial failure (one byte wrong, correctly identified as "unclear")
  • -arch ppc7400 -O0: almost complete failure (twenty-nine bytes wrong, claims all "success")
  • -arch ppc7400 -O1: partial failure (one byte wrong, but still claims all "success")
  • -arch ppc7400 -O2: same
  • -arch ppc7400 -O3: partial failure (one byte wrong, correctly identified as "unclear")
  • -arch ppc7450 -O0: almost complete failure (twenty-nine bytes wrong, claims all "success")
  • -arch ppc7450 -O1: partial failure (one byte wrong, but still claims all "success")
  • -arch ppc7450 -O2: recovers all bytes (claims all "success")
  • -arch ppc7450 -O3: partial failure (one byte wrong, correctly identified as "unclear")

This is also all over the place, but quite clearly demonstrates the 7450 is vulnerable and actually succeeds more easily than the 970MP did. (This iMac G4 does not have power management.) Still, maybe we can figure out under which circumstances it is, so what about laptops? Let's get out my faithful 12" 1.33GHz iBook G4 (PowerPC 7447A), running 10.4.11 also. First, on reduced performance:

  • -arch ppc -O0: recovers all bytes (claims all "success")
  • -arch ppc -O1: recovers all bytes (claims all "success")
  • -arch ppc -O2: recovers all bytes (claims all "success")
  • -arch ppc -O3: partial failure (two bytes wrong, only one correctly identified as "unclear")
  • -arch ppc750 -O0: partial failure (one byte wrong, correctly identified as "unclear")
  • -arch ppc750 -O1: partial failure (one byte wrong, but still claims all "success")
  • -arch ppc750 -O2: same
  • -arch ppc750 -O3: recovers all bytes (claims all "success")
  • -arch ppc7400 -O0: partial failure (one byte wrong, but still claims all "success")
  • -arch ppc7400 -O1: recovers all bytes (claims all "success")
  • -arch ppc7400 -O2: partial failure (two bytes wrong, only one correctly identified as "unclear")
  • -arch ppc7400 -O3: recovers all bytes (claims all "success")
  • -arch ppc7450 -O0: recovers all bytes (claims all "success")
  • -arch ppc7450 -O1: partial failure (one byte wrong, but still claims all "success")
  • -arch ppc7450 -O2: recovers all bytes (claims all "success")
  • -arch ppc7450 -O3: recovers all bytes (claims all "success")

This succeeds a lot more easily, and the attack is much faster (less than a quarter of a second in the worst case). On highest performance:

  • -arch ppc -O0: recovers all bytes (claims all "success")
  • -arch ppc -O1: recovers all bytes (but one byte is "unclear")
  • -arch ppc -O2: recovers all bytes (but one byte is "unclear")
  • -arch ppc -O3: recovers all bytes (claims all "success")
  • -arch ppc750 -O0: partial failure (one byte wrong, correctly identified as "unclear")
  • -arch ppc750 -O1: recovers all bytes (claims all "success")
  • -arch ppc750 -O2: partial failure (one byte wrong, correctly identified as "unclear")
  • -arch ppc750 -O3: recovers all bytes (claims all "success")
  • -arch ppc7400 -O0: recovers all bytes (claims all "success")
  • -arch ppc7400 -O1: recovers all bytes (claims all "success")
  • -arch ppc7400 -O2: recovers all bytes (claims all "success")
  • -arch ppc7400 -O3: partial failure (one byte wrong, correctly identified as "unclear")
  • -arch ppc7450 -O0: recovers all bytes (claims all "success")
  • -arch ppc7450 -O1: recovers all bytes (claims all "success")
  • -arch ppc7450 -O2: recovers all bytes (but one byte is "unclear")
  • -arch ppc7450 -O3: partial failure (one byte wrong, correctly identified as "unclear")

This almost completely succeeds! Even the scenarios that are wrong are still mostly correct; these varied a bit from run to run and some would succeed now and then too. The worst case timing is an alarming eighth of a second.

What gets weird is the DLSD PowerBook G4, though. Let's get out the last and mightiest of the PowerBooks with its luxurious keyboard, bright 17" high-resolution LCD and 1.67GHz PowerPC 7447B CPU running 10.5.8. The DLSD PowerBooks are notable for not allowing selectable power management ("Normal" or automatic equivalent only), and it turns out this is relevant here too:

  • -arch ppc -O0: complete failure (no bytes recovered but some garbage, all "unclear")
  • -arch ppc -O1: complete failure (no bytes recovered but mostly garbage, all "unclear")
  • -arch ppc -O2: complete failure (no bytes recovered but some garbage, all "unclear")
  • -arch ppc -O3: complete failure (no bytes recovered but mostly garbage, all "unclear")
  • -arch ppc750 -O0: complete failure (no bytes recovered but half garbage, all "unclear")
  • -arch ppc750 -O1: complete failure (no bytes recovered but some garbage, all "unclear")
  • -arch ppc750 -O2: same
  • -arch ppc750 -O3: same
  • -arch ppc7400 -O0: almost complete failure (only one byte recovered, but all "unclear")
  • -arch ppc7400 -O1: complete failure (no bytes recovered, all "unclear")
  • -arch ppc7400 -O2: complete failure (no bytes recovered but all seen as "E", all "unclear")
  • -arch ppc7400 -O3: complete failure (no bytes recovered but some garbage, all "unclear")
  • -arch ppc7450 -O0: complete failure (no bytes recovered, all "unclear")
  • -arch ppc7450 -O1: complete failure (no bytes recovered but half garbage, all "unclear")
  • -arch ppc7450 -O2: same
  • -arch ppc7450 -O3: same

This is an upgraded stepping of the same basic CPU, but the attack almost completely failed. It failed in an unusual way, though: instead of using the question mark placeholder it usually uses for an indeterminate value, it actually puts in some apparently recovered nonsense bytes. These bytes are almost always garbage, though one did sneak in in the right place, which leads me to speculate that the 7447B is vulnerable too but something is mitigating it.

This DLSD is different from my other systems in two ways: it's got a slightly different CPU with known different power management, and it's running Leopard. Setting the iBook G4 to use automatic ("Normal") power management made little difference, however, so I got down two 12" PowerBook G4s with one running 10.4 with a 1.33GHz CPU and the other 10.5.8 with a 1.5GHz CPU. The 10.4 12" PowerBook G4 was almost identical to the 10.4 12" in terms of vulnerability, but it got interesting in on the 10.5.8 system. In order, low, automatic and highest performance:

  • -arch ppc -O0: recovers all bytes (claims all "success")
  • -arch ppc -O1: partial failure (four bytes wrong, but still claims all "success")
  • -arch ppc -O2: partial failure (five bytes wrong, but still claims all "success")
  • -arch ppc -O3: partial failure (four bytes wrong, but still claims all "success")
  • -arch ppc750 -O0: partial failure (two bytes wrong, but still claims all "success")
  • -arch ppc750 -O1: partial failure (two bytes wrong, both garbage, but still claims all "success")
  • -arch ppc750 -O2: partial failure (one byte wrong, correctly identified as "unclear")
  • -arch ppc750 -O3: partial failure (four bytes wrong, but still claims all "success")
  • -arch ppc7400 -O0: recovers all bytes (claims all "success")
  • -arch ppc7400 -O1: partial failure (one byte wrong, but still claims all "success")
  • -arch ppc7400 -O2: recovers all bytes (claims all "success")
  • -arch ppc7400 -O3: partial failure (two bytes wrong, but still claims all "success")
  • -arch ppc7450 -O0: recovers all bytes (claims all "success")
  • -arch ppc7450 -O1: recovers all bytes (claims all "success")
  • -arch ppc7450 -O2: recovers all bytes (claims all "success")
  • -arch ppc7450 -O3: partial failure (four bytes wrong, but still claims all "success")

  • -arch ppc -O0: recovers all bytes (claims all "success")
  • -arch ppc -O1: partial failure (thirteen bytes wrong, all "T", correctly identified as "unclear")
  • -arch ppc -O2: partial failure (nine bytes wrong, some "u", correctly identified as "unclear")
  • -arch ppc -O3: partial failure (eight bytes wrong, correctly identified as "unclear")
  • -arch ppc750 -O0: partial failure (thirteen bytes wrong, all "-", correctly identified as "unclear")
  • -arch ppc750 -O1: partial failure (fifteen bytes wrong, correctly identified as "unclear")
  • -arch ppc750 -O2: partial failure (fifteen bytes wrong, some "@", correctly identified as "unclear")
  • -arch ppc750 -O3: partial failure (sixteen bytes wrong, correctly identified as "unclear")
  • -arch ppc7400 -O0: recovers all bytes (claims all "success")
  • -arch ppc7400 -O1: partial failure (seven bytes wrong, correctly identified as "unclear")
  • -arch ppc7400 -O2: partial failure (eleven bytes wrong with three garbage bytes, correctly identified as "unclear")
  • -arch ppc7400 -O3: partial failure (eleven bytes wrong, all garbage, correctly identified as "unclear")
  • -arch ppc7450 -O0: recovers all bytes (claims all "success")
  • -arch ppc7450 -O1: partial failure (ten bytes wrong, correctly identified as "unclear")
  • -arch ppc7450 -O2: partial failure (seventeen bytes wrong, all "h", correctly identified as "unclear")
  • -arch ppc7450 -O3: partial failure (twelve bytes wrong, all "b", correctly identified as "unclear")

  • -arch ppc -O0: recovers all bytes (claims all "success")
  • -arch ppc -O1: partial failure (three bytes wrong with two garbage bytes, correctly identified as "unclear")
  • -arch ppc -O2: partial failure (eight bytes wrong, all various garbage bytes, correctly identified as "unclear")
  • -arch ppc -O3: partial failure (six bytes wrong, correctly identified as "unclear")
  • -arch ppc750 -O0: partial failure (four bytes wrong, all various garbage bytes, correctly identified as "unclear")
  • -arch ppc750 -O1: partial failure (four bytes wrong, correctly identified as "unclear")
  • -arch ppc750 -O2: partial failure (eleven bytes wrong, correctly identified as "unclear")
  • -arch ppc750 -O3: partial failure (four bytes wrong, all various garbage bytes, correctly identified as "unclear")
  • -arch ppc7400 -O0: recovers all bytes (claims all "success")
  • -arch ppc7400 -O1: partial failure (three bytes wrong, but still claims all "success")
  • -arch ppc7400 -O2: partial failure (six bytes wrong, correctly identified as "unclear")
  • -arch ppc7400 -O3: partial failure (four bytes wrong, correctly identified as "unclear")
  • -arch ppc7450 -O0: recovers all bytes (claims all "success")
  • -arch ppc7450 -O1: partial failure (four bytes wrong, correctly identified as "unclear")
  • -arch ppc7450 -O2: partial failure (three bytes wrong, but still claims all "success")
  • -arch ppc7450 -O3: partial failure (eight bytes wrong, all various garbage bytes, correctly identified as "unclear")

Leopard clearly impairs Spectre's success, but the DLSDs do seem to differ further internally. The worst case runtime on the 10.5 1.5GHz 12" was around 0.25 seconds. The real test would be to put Tiger on a DLSD, but I wasn't willing to do so with this one since it's my Leopard test system.

Enough data. Let's irresponsibly make rash conclusions.

  • The G3 and 7400 G4 systems appear, at minimum, to be resistant to Spectre as predicted. I hesitate to say they're immune but there's certainly enough evidence here to suggest it. While there may be a variant around that could get them to leak, even if it existed it wouldn't do so very quickly based on this analysis.
  • The 7450 G4e is more vulnerable to Spectre than the G5 and can be exploited faster, except for the DLSDs which (at least in Leopard) seem to be unusually resistant.
  • Power management makes a difference, but not enough to completely retard the exploit (again, except the DLSDs), and not always in a predictable fashion.
  • At least for these systems, cache size didn't seem to have any real correlation.
  • Spectre succeeds more reliably in Tiger than in Leopard.
  • Later Power ISA chips are vulnerable with a lot less fiddling.

Before you panic, though, also remember:

  • These were local programs run at full speed in a test environment with no limits, and furthermore the program knew exactly what it was looking for and where. A random attack would probably not have this many advantages in advance.
  • Because the timing is so variable, a reliable attack would require running several performance profiles and comparing them, dramatically slowing down the effective exfiltration speed.
  • This wouldn't be a very useful Trojan horse because sketchy programs can own your system in ways a lot more useful (to them) than iffy memory reads that are not always predictably correct. So don't run sketchy programs!
  • No 7450 G4 is fast enough to be exploited effectively through TenFourFox's JavaScript JIT, which would be the other major vector. Plus, no 7450 can speculatively execute through TenFourFox's inline caches anyway because they use CTR for indirect branching (see the analysis), so the generated code already has an effective internal barrier.
  • Arguably the Quad G5 might get into the speed range needed for a JavaScript exploit, but it would be immediately noticeable (as in, jet engine time), not likely to yield much data quickly, and wouldn't be able to do so accurately. After FPR5 final, even that possibility will be greatly lessened as to make it just about useless.

I need to eat dinner. And a life. If you've tested your own system (Tobias reports success on a 970FX), say so in the comments.

Friday, January 5, 2018

More about Spectre and the PowerPC (or why you may want to dust that G3 off)

UPDATE: IBM is releasing firmware patches for at least the POWER7+ and forward, including the POWER9 expected to be used in the Talos II. My belief is that these patches disable speculative execution through indirect branches, making the attack much more difficult though with an unclear performance cost. See below for why this matters.

UPDATE the 2nd: The G3 and 7400 survived Spectre!

(my personal favourite Blofeld)

Most of the reports on the Spectre speculative execution exploit have concentrated on the two dominant architectures, x86 (in both its AMD and Meltdown-afflicted Intel forms) and ARM. In our last blog entry I said that PowerPC is vulnerable to the Spectre attack, and in broad strokes it is. However, I also still think that the attack is generally impractical on Power Macs due to the time needed to meaningfully exfiltrate information on machines that are now over a decade old, especially with JavaScript-based attacks even with the TenFourFox PowerPC JIT (to say nothing of various complicating microarchitectural details). But let's say that those practical issues are irrelevant or handwaved away. Is PowerPC unusually vulnerable, or on the flip side unusually resistant, to Spectre-based attacks compared to x86 or ARM?

For the purposes of this discussion and the majority of our audience, I will limit this initial foray to processors used in Power Macintoshes of recent vintage, i.e., the G3, G4 and G5, though the G5's POWER4-derived design also has a fair bit in common with later Power ISA CPUs like the Talos II's POWER9, and ramifications for future Power ISA CPUs can be implied from it. I'm also not going to discuss embedded PowerPC CPUs here such as the PowerPC 4xx since I know rather less about their internal implementational details.

First, let's review the Spectre white paper. Speculative execution, as the name implies, allows the CPU to speculate on the results of an upcoming conditional branch instruction that has not yet completed. It predicts future program flow will go a particular way and executes that code upon that assumption; if it guesses right, and most CPUs do most of the time, it has already done the work and time is saved. If it guesses wrong, then the outcome is no worse than idling during that time save the additional power usage and the need to restore the previous state. To do this execution requires that code be loaded into the processor cache to be run, however, and the cache is not restored to its previous state; previously no one thought that would be necessary. The Spectre attack proves that this seemingly benign oversight is in fact not so.

To determine the PowerPC's vulnerability requires looking at how it does branch prediction and indirect branching. Indirect branching, where the target is determined at time of execution and run from a register rather than coding it directly in the branch instruction, is particularly valuable for forcing the processor to speculatively execute code it wouldn't ordinarily run because there are more than two possible execution paths (often many, many more, and some directly controllable by the attacker).

The G3 and G4 have very similar branch prediction hardware. If there is no hinting information and the instruction has never been executed before (or is no longer in the branch history table, read on), the CPU assumes that forward branches are not taken and backwards branches are, since the latter are usually found in loops. The programmer can add a flag to the branch instruction to tell the CPU that this initial assumption is probably incorrect (a static hint); we use this in a few places in TenFourFox explicitly, and compilers can also set hints like this. All PowerPC CPUs, including the original 601 and the G5 as described below, offer this level of branch prediction at minimum. Additionally, in the G3 and G4, branches that have been executed then get an entry in the BHT, or branch history table, which over multiple executions records if the branch is not taken, probably not taken, probably taken or taken (in Dan Luu's taxonomy of branch predictors, this would be two-level adaptive, local). On top of this the G3 and G4 have a BTIC, or branch target instruction cache, which handles the situation of where the branch gets taken: if the branch is not taken, the following instructions are probably in the regular instruction cache, but if the branch is taken, the BTIC allows execution to continue while the instruction queue continues fetching from the new program counter location. The G3 and 7400-series G4 implement a 512-entry BHT and 64-entry, two-instruction BTIC; the 7450-series G4 implements a 2048-entry BHT and a 128-entry, four-instruction BTIC, though the actual number of instructions in the BTIC depends on where the fetch is relative to the cache block boundary. The G3 and 7400 G4 support speculatively executing through up to two unresolved branches; the 7450 G4e allows up to three, but also pays a penalty of about one cycle if the BTIC is used that the others do not.

The G5 (and the POWER4, and most succeeding POWER implementations) starts with the baseline above, though it uses a different two-bit encoding to statically hint branch instructions. Instead of the G3/G4 BHT scheme, however, the G5/970 uses what Luu calls a "hybrid" approach, necessary to substantially improve prediction performance in a CPU for which misprediction would be particularly harmful: a staggering 16,384-entry BHT but also an additional 16,384-entry table using an indexing scheme called gshare, and a selector table which tells the processor which table to use; later POWER designs refine this further. The G5 does not implement a BTIC probably because it would not be compatible with how dispatch groups work. The G5 can predict up to two branches per cycle, and have up to 16 unresolved branches.

The branch prediction capabilities of these PowerPC chips are not massively different from other architectures'. The G5's ability to keep a massive number of unresolved branch instructions in flight might make it actually seem a bit more subject to such an attack since there are many more opportunities to load victim process data into the cache, but the basic principles at work are much the same as everything else, so none of our chips are particularly vulnerable or resistant in that respect. Where it starts to get interesting, however, is when we talk about indirect branches. There is no way in the Power ISA to directly branch to an address in a register, an unusual absence as such instructions exist in most other contemporary architectures such as x86, ARM, MIPS and SPARC. Instead, software must load the instruction into either of two special purpose registers that allow branches (either the link register "LR" or the counter register "CTR") with a special instruction (mtctr and mtlr, both forms of the general SPR instruction mtspr) and branch to that, which can occur conditionally or unconditionally. (We looked at this in great detail, with microbenchmarks, in an earlier blog post.)

To be able to speculatively execute an indirect branch, even an unconditional one, requires that either LR or CTR be renamed so that its register state can be saved as well, but on PowerPC they are not general purpose registers that can use the regular register rename file like other platforms such as ARM. The G5, unfortunately in this case, has additional hardware to deal with this problem: to back up the 16 unresolved branches it can have in-flight, LR and CTR share a 16-entry rename mapper, which allows the G5 to speculatively execute a combination of up to 16 LR or CTR-referencing branches (i.e., b(c)lr and b(c)ctr). This could allow a lot of code to be run speculatively and change the cache in ways the attacker could observe. Substantial preparation would be required to get the G5's branch history fouled enough to make it mispredict due to its very high accuracy (over 96%), but if it does, the presence of indirect branches will not slow the processor's speculative execution down what is now the wrong path. This is at least as vulnerable as the known Spectre-afflicted architectures, though the big cost of misprediction on the G5 would make this type of blown speculation especially slow. Nevertheless, virtually all current POWER chips would fall in this hole as well.

But the G3 and G4 situation is very different. The G3 actually delays fetch and execution at a b(c)ctr until the mtctr that leads it has completed, meaning speculative execution essentially halts at any indirect branch. The same applies for the LR, and for the 7400. CTR-based indirect branching is very common in TenFourFox-generated code for JavaScript inline caches, and code such as mtlr r0:blr terminates nearly every PowerPC function call. No fetch, and therefore no speculative execution, will occur until the special purpose register is loaded, meaning the proper target must now be known and there is less opportunity for a Spectre-based attack to run. Even if the processor could continue speculation past that point, the G3 and 7400 implement only a single rename register each for LR and CTR, so they couldn't go past a second such sequence regardless.

The 7450 is a little less robust in this regard. If the instruction sequence is an unconditional mtlr blr, the 7450 (and, for that matter, the G5) implements a link stack where the expected return address comes off a stack of predicted addresses from prior LR-modifying instructions. This is enough of a hint on the 7450 G4e to possibly allow continued fetch and potential speculation. However, because the 7450 also has only a single rename register each for LR and CTR, it also cannot speculatively execute past a second such sequence. If the instruction sequence is mtlr bclr, i.e., there is a condition on the LR branch, then execution and therefore speculation must halt until either the mtlr completes or the condition information (CR or CTR) is available to the CPU. But if the special purpose register is the CTR, then there is no address cache stack available, and the G4e must delay at an mtctr b(c)ctr sequence just like its older siblings.

Bottom line? Spectre is still not a very feasible means of attack on Power Macs, as I have stated, though the possibilities are better on the G5 and later Power ISA designs which are faster and have more branch tricks that can be subverted. But the G3 and the G4, because of their limitations on indirect branching, are at least somewhat more resistant to Spectre-based attacks because it is harder to cause their speculative execution pathways to operate in an attacker-controllable fashion (particularly the G3 and the 7400, which do not have a link stack cache). So, if you're really paranoid, dust that old G3 or Sawtooth G4 off. You just might have the Yosemite that manages to survive the computing apocalypse.

Thursday, January 4, 2018

Is PowerPC susceptible to Spectre? Yep.

UPDATE: Yes, TenFourFox will implement relevant Spectre-hardening features being deployed to Firefox, and the changes to will be part of FPR5 final. We also don't support SharedArrayBuffer anyway and right now are not likely to implement it any time soon.

UPDATE the 2nd: This post is getting a bit of attention and was really only intended as a quick skim, so if you're curious whether all PowerPC chips are vulnerable in the same fashion and why, read on for a deeper dive.

If you've been under a rock the last couple days, then you should read about Meltdown and Spectre (especially if you are using an Intel CPU).

Meltdown is specific to x86 processors made by Intel; it does not appear to affect AMD. But virtually every CPU going back decades that has a feature called speculative execution is vulnerable to a variety of the Spectre attack. In short, for those processors that execute "future" code downstream in anticipation of what the results of certain branching operations will be, Spectre exploits the timing differences that occur when certain kinds of speculatively executed code changes what's in the processor cache. The attacker may not be able to read the memory directly, but (s)he can find out if it's in the cache by looking at those differences (in broad strokes, stuff in the cache is accessed more quickly), and/or exploit those timing changes as a way of signaling the attacking software with the actual data itself. Although only certain kinds of code can be vulnerable to this technique, an attacker could trick the processor into mistakenly speculatively executing code it wouldn't ordinarily run. These side effects are intrinsic to the processor's internal implementation of this feature, though it is made easier if you have the source code of the victim process, which is increasingly common.

Power ISA is fundamentally vulnerable going back even to the days of the original PowerPC 601, as is virtually all current architectures, and there are no simple fixes. So what's the practical impact to Power Macs? Well, not much. As far as directly executing an attacking application, there are a billion more effective ways to write a Trojan horse than this, and they would have to be PowerPC-specific (possibly even CPU-family specific due to microarchitectural changes) to be functional. It's certainly possible to devise JavaScript that could attack the cache in a similar fashion, especially since TenFourFox implements a PowerPC JIT, but such an attack would -- surprise! -- almost certainly have to be PowerPC-specific too, and the TenFourFox JIT doesn't easily give up the instruction sequences necessary. Either way, even if the attacker knew exactly the memory they wanted to read and went to its address immediately, the attack would be rather slow on a Power Mac and you'd definitely notice the CPU usage whether it succeeded or not.

There are ways to stop speculative execution using certain instructions the processor must serialize, but this can seriously harm performance: speculative execution, after all, is a way to keep the processor busy with (hopefully) useful work while it waits for previous instructions to complete. On PowerPC, cache manipulation instructions, some kinds of special-purpose register accesses and even instructions like b . (branch to the next instruction, essentially a no-op) can halt speculative execution with a sometimes notable time penalty. I think there may be some ways we can harden the TenFourFox JIT with these instructions used selectively to reduce their overhead, though as I say, I don't find such attacks very practical on our geriatric machines in general.

Anyway, you can sleep well, because everybody's all in the same boat. Perhaps it's time to dust off those old strict CPUs. The world needs a port of Classilla to the Commodore 64. :)

Thursday, December 28, 2017

TenFourFox FPR5b1 available

TenFourFox Feature Parity Release 5 beta 1 is now available (downloads, hashes, release notes).

The biggest changes are lots and lots of AltiVec: additional AltiVec decoding acceleration for VP9 (you need MSE enabled to make the most of this, or things like YouTube will default to VP8), more usage of our VMX-accelerated string search package, and (new in this version) AltiVec-accelerated PNG image decoding. There are also a number of minor but notable improvements to layout compatibility, DOM and HTML5 support (most notably true passive event listeners, which should improve scroll and general event performance on some sites), as well as some additional efficiency improvements to JavaScript. FPR5 also marks mostly the end of all of the Quantum-related platform changes we can safely backport to our fork of 45; while there will be some additional optimization work, I will primarily be concentrating on actual new support rather than speedups since most of the low-hanging fruit and some of the stuff I have to jump a little for has already been plucked.

There are two somewhat more aggressive things in this version. The first is to even more heavily throttle inactive or background tabs to reduce their impact; the normal Firefox runs animation frames on background tabs at 1Hz but this version reduces that to a third (i.e., a tick every three seconds instead of one). It's possible to make this even more aggressive, including just not ticking any timers in background tabs at at all, but I'm a little nervous about halting it entirely. Neither approach affects audio playing in inactive or background tabs, which I tested thoroughly in Amazon Music and YouTube. This should make having multiple tabs open and loaded a bit less heavyweight, particularly on single processor Macs.

The second has to do with session store. Currently, every 25 seconds (Firefox has a default of 15), the browser serializes its state and writes it out to disk so you can pick up where you left off in the event of a crash. I'm loathe to completely halt this or make the interval much more than 60 seconds, but I also know that this does drag on the browser and can also spin SSD write cycles. This version increases it to 30 seconds, but also reduces the number of forward pages written (up to 5 instead of unlimited), and also purges old closed tabs more aggressively -- Firefox purges these after about two weeks, but we now purge old tabs every 24 hours, which I thought was a good compromise. This means much less data is written and much less cruft accumulates as you browse, reducing the browser's overhead and memory usage over longer uptimes. However, I know this may upset those of you who have tab closure regret, so advise if this drives you nuts even though I am unlikely to reverse this change completely.

This version is timed to come out with Firefox ESR 52.6.0, which is not scheduled for release until January 23, so don't panic if you don't see much commit activity in Github for awhile. 52.8.0, scheduled for May 7, will be the transition point to 60ESR. More on that when we get there.

For FPR6, I'm looking at a couple features to get us more HTML5 support points, and possibly something like date-time input controls or <details> and <summary> support. This may also be the first release with built-in adblock, though the adblock support will only be basic, will not be comprehensive, and may include blocking certain tracking scripts as well as image ads. It won't be enabled by default.

Party safe on New Years'.

Monday, December 4, 2017

TenFourFox FPR4 SPR1 available

TenFourFox "FPR4.1" (officially Feature Parity Release 4, Security Parity Release 1) is available for testing (downloads, hashes; release notes pending revision). This is an urgent security and bugfix update which repairs a serious information leak in Private Browsing mode that affects all versions of Firefox (and TenFourFox) to at least version 35. I also included a bugfix for an edge case in our internal AltiVec-accelerated strchr() implementation which was discovered when I expanded its usage to other portions of the browser. Mozilla is chemspilling updated versions of Fx57 and ESR52; I plan to follow suit and the fixed version will go live this afternoon-evening Pacific time assuming no problems. There are no other changes in this release. If you are rolling your own build, pull the tree at release FPR4 and add the relevant patches from issues 440 and 451.

FPR5 is coming along very well. If I could sum up the changes in two words, it would be "MOAR ALTIVEC." Two other words I'd use are "stay tuned" and "totally awesome" and "amazing programmer" and "very modest."

Sunday, November 12, 2017

The security blanket blues revisited, or: keeping your Power Mac safe in an Intel world

Way back in 2012 I wrote a fairly basic piece on Power Mac security, and ever since then I've promised repeatedly to do an update for what's happened in between. So here it is.

The usual advice well-meaning but annoying people will give us Power Mac users is, "there are many security holes in your machine, so you shouldn't ever use it on the Internet." The first part is true. The second part is, at least right now, not. You just have to understand where the vulnerabilities lie, patch the holes you can, and mitigate the vulnerabilities that you can't. However, doing so is absolutely imperative and absolutely your responsibility. If some easily remotely exploitable bug surfaces that cannot be mitigated or blocked, I'll change my tune here, but that's not presently the case.

The most important thing to keep in mind is that, as virtually all the regular readers of this blog know, Power Macs use a completely different architecture than the majority of what's out there today, and this has important security ramifications. The vast majority of presently extant low-level exploits like buffer overflows and use-after-frees broadly depend on being able to deposit Intel or ARM machine code in memory and have it executed by the victim application, but our instruction set and (often) memory layout are completely different, so any such exploit would have to be specific to PowerPC to successfully execute. At worst, an non-PowerPC exploit of this type would just crash the application or, in extreme cases, the machine. While the more security conscious amongst you will (correctly) point out this is a special example of "security by obscurity," that doesn't mean this heterogeneity isn't an advantage. Attackers go where the money is, and it's not our machines. No current Intel Mac can easily generate code that will run on a Power Mac without a lot of work either.

But our systems definitely do not sail above the fray. Where we are most practically vulnerable falls under two major categories: information leakage, and cross-platform attacks. In the first case, unsecured networking, weak encryption or other flaws could leak private data such as passwords, credentials or personal data from our computers to an attacker; in the worst case they could allow an attacker to masquerade as you to other services or sites. In the second case, applications on your computer could be duped into performing tasks on behalf of an attacker using a payload that is not specific to a particular machine type, but can run anywhere the cross-platform environment they utilize exists (such as Java, Flash, Microsoft Word macros, scripting languages like shell scripts, JavaScript, etc.) and is able to exploit flaws in that environment to take over any machine that can run the code. In the worst case, an attacker could gain administrator access and complete control of the system, and because the exploit is not architecture-dependent, we could potentially run the poisoned code too.

So as promised, here's an updated practical guide to keeping your beloved Power Mac safe, or at least safer, today 11 years and nine operating system releases after the last Power Mac rolled off the assembly line. This post is hardly comprehensive and you should not assume it covers all relevant deficiencies, but, for the record, these are the recommendations I myself use on my own systems. I reference prior blog posts here you can read for more details, but this guide will cover the basic notions and try to give you an idea of priority. Please note: this document primarily applies to systems running 10.4 and later. The classic Mac OS through OS 9.2.2 has an extremely small attack surface because of its radically different architecture, and while browsers on OS 9 (including, though this is improving, Classilla) are subject to information leakage attacks and should not run Flash or Java, other kinds of attacks are almost impossible upon it. There are a few exceptions noted below. For 10.0 through 10.3, however, there are sadly much fewer good options for securing these systems, and I would simply advise putting them behind a good firewall and assuming everything you do on them is not secured.

Obviously, I also assume for the below that you're running the current version of TenFourFox and can securely download additional tools if necessary!

General recommendations

Make sure your clock is set correctly: certificate verification will fail if your clock is off more than a few minutes in either direction. Particularly on 10.4 systems (but also observed on 10.5), systems with long durations of uptime without sleeping or being shutdown may go out of synchronization with any time server you use. The first and easiest way to reestablish the connection to your timeserver is either by rebooting, or unchecking and then re-checking the time server checkbox in System Preferences. If your system is powered on and off regularly you may not have a need even to do this much. However, if this is insufficient and you are comfortable with the command line, you could try the more definitive solution in our article.

Consider using a non-admin account for basic activities: this will ensure that, if a old PowerPC-compatible exploit or Trojan horse is around and does get through, the damage is limited. At least one well-known OS X Trojan horse circulated in a PowerPC-compatible version as late as 2012!

Why do I have to enter my password? Consider this every time you're asked for it; a little paranoia is just good common sense. Ask yourself, does this application actually need administrative access? Or is this program doing something other than it claims?

Security issues with connectivity and networking

Built-in networking: On OS X, enable the built-in firewall in System Preferences (Sharing, Firewall) and enable stealth mode, and if you can, also Block UDP Traffic from the Advanced menu within that preference pane. This substantially reduces the surface for incoming network threats. Using a hardware firewall is even better, especially in combination, as well as disabling UPnP on your router if your applications don't require it; in fact, my personal daily drivers live on a specially secured wired network that cannot directly route to the Internet. There are a number of possible exploits in the network-accessible components of 10.4 and 10.5 and simply preventing access to them in this fashion is probably the best approach. Note that UDP is still necessary for some kinds of protocols such as local Windows file and printer sharing (in that case, blocking it at the router level rather on individual Macs would be more appropriate), and disabling UPnP may be problematic for some applications.

WiFi: All Power Macs are subject to the KRACK attack and there is no known client-side fix (more info). The problem can be mitigated by going into your router settings and selecting WPA2 (not just WPA!) AES-CCMP as your only means of Wi-Fi security, which some routers may abbreviate to just "AES." Do not use TKIP. Routers may also be vulnerable, particularly if your router is itself a client to another WiFi network such as being in repeater mode; you should check to see if a firmware update is available, and consider another router if necessary.

Although AES-CCMP is much more resistant to attacks than TKIP and an attacker cannot actually join a network secured with it, they could clone your access point to a second access point with the same SSID and MAC/BSSID on a different channel and entice you to transparently connect to that. This is not very likely in a controlled home environment, but it could be an issue for public Wi-Fi or close quarters like dorms or apartments. Immediately disable Wi-Fi if you see two copies of the same network; it could be an attempt to snare you. See our article for a more in-depth way of detecting such an attack.

If you are on a public Wi-Fi connection you can't control, you should assume your connection is completely insecure (the same applies for WEP, such as on Mac OS 9, which does not support WPA2 natively, or WPA). Use a VPN if you have it available, and/or only connect to secure hosts, such as over HTTPS and SSH, to layer your connection with a secondary level of encryption. A better browser can help ... like, I dunno, TenFourFox. Just a suggestion.

Bluetooth: All Power Macs are potentially vulnerable to BlueBorne-based attacks, though the practical likelihood of being exploited is low (more info). These attacks are generally low-level and would need to be specific to PowerPC to function, but could be a source of system instability if a malicious Bluetooth device is broadcasting poison packets with Intel or ARM code embedded in them. Keep Bluetooth off if you don't need it except in controlled environments; when tethering, if a malicious device is likely to be in range, Wi-Fi is probably safer even with the caveats above.

Hardening OS X

These are well-known vulnerabilities in OS X which can be, in some cases, exploited remotely.

sudo at the wrong time: Because a password is not required to change the system date and time (either with System Preferences or using systemsetup from the command line), an attacker can set the clock wrong and then dupe vulnerable versions of the sudo utility, which allows you to run commands with administrator permissions, to acquire that same administrative access without authentication. This is due to a convenience in sudo where repeated use within a certain interval does not require a password; thus, the simplest and most secure solution is to always require a password. Start a Terminal window (or start /Applications/Utilities/Terminal) and enter the following commands:

  • sudo visudo (enter your password)
  • Using the vi editor which then appears, add the line Defaults timestamp_timeout=0 at the end. If you don't know how to use vi, type these key strokes:

    • 0G (the number zero, and a capital G)
    • o (lower case "o")
    • Defaults timestamp_timeout=0
    • Press the ESCape key and then type :wq! (colon, lower case "w", lower case "q", exclamation point) and press ENTER.

If you get an error, you did it wrong; start over. See the original article for more information.

RootPipe/systemsetupusthebomb: This is an actual flaw in another privileged system component called writeconfig that can be exploited to write arbitrary files with root permissions, also giving an attacker administrative access. The simplest fix is to go to System Preferences, and under Security, check "Require password to unlock each secure system preference" (and make sure the lock at the lower left is locked). Now any known use of the vulnerable tool will either fail or at least prompt you for a password. This covers all known exploits for this component, but for a more comprehensive approach (that may have side effects), see the original article.

Shellshock: The version of the Bourne again shell (bash) that comes with all PowerPC versions of OS X is susceptible to Shellshock, a collection of methods of causing the shell to execute arbitrary commands passed to it through environment variables. Although of particular concern to anyone using their machine as a server, it is possible to use this exploit even on single-user systems in more limited circumstances. All versions prior to 4.3.30 are vulnerable. If you have never fixed this on your system, then download the patched version of bash 4.3.30 that we provide as a community service and follow these directions exactly:

  1. Put the file in your home directory and double-click to decompress it. You should be left with a file named bash-4.3.30-10.4u. Do not change the name.
  2. Close all terminal windows and programs if they are open, just to make sure you won't stomp on bash while a program is trying to call it. Start /Applications/Utilities/Terminal and have exactly one window open.
  3. In that Terminal window, type these commands exactly as shown. If you get any errors, STOP and ask for help.

    • exec tcsh
    • chmod +x bash-4.3.30-10.4u

      (IMPORTANT! If you replaced /bin/bash (and/or /bin/sh) with any earlier version using these commands, DO NOT ENTER THE NEXT TWO COMMANDS. If you have never replaced them, then do go ahead; these will put the old ones in a safe place just in case.)

    • sudo mv /bin/bash /bin/bash_old (enter your password)
    • sudo mv /bin/sh /bin/sh_old (enter your password; if you don't get prompted again, you need to fix sudo with the steps above!)

      Everybody does these:

    • sudo cp bash-4.3.30-10.4u /bin/bash (enter your password)
    • sudo cp bash-4.3.30-10.4u /bin/sh (enter your password)

  4. Restart your Mac as a paranoia to make sure everything is using the new copy of bash.

If you're not sure, bash --version will display what you're running (mine says GNU bash, version 4.3.30(5)-release (powerpc-apple-darwin8.11.0). The version we provide is universal and will work on PowerPC and Intel from 10.4 through at least 10.9. If you want to check if your version is correctly behaving, see the original article for a test battery.

Other vulnerabilities in OS X built-in software

Although there aren't updates for most of these, you should at least be aware of the actual risk, and how to reduce it.

Some of the entries in this and the following sections reference plugins. These are usually stored in /Library/Internet Plug-Ins, but there may be per-user plugins installed in Library/Internet Plug-Ins in your home folder. You can disable them as recommended below by simply moving them to another folder, or deleting them outright if appropriate.

Java: Java is not safe on Power Macs; all versions of Java provided on any PowerPC-compatible version of Mac OS or OS X have serious well-known vulnerabilities. In particular, exploits such as Flashback can obtain system access in a cross-platform fashion. If the Java plugin is on your computer, it should be removed or disabled (or use TenFourFox, natch, which won't even run it), and you should only run signed Java applets from trusted sources if you must run them at all.

QuickTime: There are historical PowerPC-based exploits for certain codecs in QuickTime, though none of these are known to be circulating now, and no specific PowerPC-based exploit is known for QT 7+ generally. (While QT 6.0.3 in OS 9/Classic is technically vulnerable, the limitations of OS 9 make the exploit difficult and it would have to be specific to both OS 9 and PowerPC.) It is possible for QuickTime playlists and certain other kinds of scriptable content to be used to load data over the network, but they can be only interacted with in limited ways, and to actually use them for executable data would require a PowerPC-compatible attack. While such an attack is feasible and possible, it isn't very likely to occur or succeed on a Power Mac. This mode of attack can be minimized further by removing or disabling the QuickTime Plugin (or use TenFourFox, natch, which won't even run it); removing the Plugin won't affect using the QuickTime Player. and the built-in image and PDF viewer libraries also have known holes, but no known specific PowerPC-based attacks which would be required to exploit them. The built-in PDF toolkit doesn't understand JavaScript in PDF files or embedded Flash, and as a result is much safer than using the real Adobe Acrobat Reader (which you should really only use for protected documents). If you don't mind the speed, you can also use the built-in PDF viewer in TenFourFox by going to Preferences, TenFourFox and checking the preference to enable it, though our internal viewer currently supports even fewer features than Preview. TenFourFox also can view many images by simply dragging them to any open browser window. Again, while an attack through a malicious image or PDF file is feasible and possible, it isn't very likely to occur or succeed on a Power Mac. This mode of attack can be minimized further by removing any Internet plugins that furnish PDF access in the browser, including and especially the Adobe Acrobat plugin (or use TenFourFox, natch, which doesn't even run them and implements its own sandboxed PDF viewer).

WebKit and Safari: Safari, and many other software packages, uses the version of WebKit on the system to render web pages and other network, HTML and image assets; it is, essentially, the built-in "WebKit shell." With the exception of OmniWeb, every PowerPC-compatible WebKit-based browser (Safari, iCab, Roccat, Stainless, Demeter, Shiira, etc.) relies on the version of WebKit the operating system provides, which means they inherit all the bugs and security issues of the built-in WebKit framework as well as any bugs in the shell they provide. (Gecko-based browsers bring their own libraries with them, but we're the only Gecko-based browser still updated for PowerPC OS X.)

I'm sure all of you are enthusiastic daily drivers of TenFourFox, but WebKit should also be updated because of how many other apps depend on it. For 10.5, of course, the best solution is Tobias' Leopard WebKit. Leopard WebKit not only includes a very current WebKit framework, but also includes an updated OS Security framework, and can relink WebKit shells and other programs using a provided utility.

Unfortunately, a similar supported option is not available for 10.4. TenFourKit, also written by Tobias, does update the system framework somewhat but does not include security or encryption updates, and has not received any updates since 2012; it's basically the same version as the framework built-in to the OmniWeb browser. For this reason, you should avoid Safari and other WebKit shell applications like iCab on 10.4, as they will not be sufficiently protected, and you should be cautious of apps that attempt to display web pages over the network since the vast majority will use the built-in WebKit also. Because the OS's security framework is also not current, many secure sites will either not connect properly, or throw inexplicable errors.

Currently all WebKit shells support, and will instantiate, plugins (TenFourFox doesn't). I still advise disabling them or removing them where appropriate, but if you can't do this, ClickToPlugin will at least reduce drive-by risk in Safari. Mail uses the built-in system WebKit (as above), and may have other deficiencies which are not patched. These deficiencies likely require PowerPC-specific exploits, though Apple Mail's general lack of updates implies other vulnerabilities likely lurk such as information leaks and inadequate connection security. Although Tenfourbird (an unaffiliated project) was once a solid and secure alternative, it has not been maintained since version 38.9 as of this writing, so unfortunately I am no longer able to generally recommend it. The simplest and safest approach is simply to use a webmail service instead in TenFourFox or Leopard WebKit unless you absolutely must have a local mail client; in that case, I would use Tenfourbird over Apple Mail, since it is at least more up to date.

Major third-party and optional software vulnerabilities

Your web browser: Currently TenFourFox (10.4+), Leopard WebKit (10.5 only) and Roccat (10.5 only) are known to be updated on a semi-regular basis (we issue TenFourFox releases with security updates, updated certificates and pinned keys every six weeks simultaneously with Firefox ESR updates). No other browser is current, though at least a re-linked WebKit shell will have fewer vulnerabilities. Note that Roccat also needs to be relinked with Leopard WebKit for maximum security.

Flash: Flash is not safe on Power Macs; all PowerPC-compatible versions of Adobe Flash Player have serious well-known vulnerabilities. The cross-platform Rosetta Flash exploit is able to steal credentials and cookies with 10.1 and earlier versions of Flash, and the recommended server mitigation does not fix the problem in these versions (only Flash 10.2+). Furthermore, Flash applets have been previously demonstrated to attack network settings in a cross-platform fashion, and there are other sandbox escape vulnerabilities that have been reported. Although unofficial "later" versions of the Flash plugin have circulated for Power Macs, these are still Flash 10.1 internally with a bumped version number and do not actually have any fixes. Unless you have content that absolutely cannot be viewed without Flash, you should remove or disable the Flash plugin (or use TenFourFox, natch, which won't even run it); a tool like SandboxSafari or the experimental PopOut Player can help reduce the risk for legacy content that still requires it.

Microsoft Office and OpenOffice/NeoOffice/LibreOffice: None of these office applications is currently updated for Power Macs and all of them have potential vulnerabilities to Word and Excel macro viruses, though the OpenOffice derivatives are much less likely to be successfully exploited. For Word it is unlikely you will want macros enabled (and you should definitely turn them off in the preferences except for those rare situations in which they are needed), but this could be a real issue for Excel power users. Office v.X, and Office 98 in Classic/Mac OS 9, are probably too old to be effectively pwned, but many macro attacks against Office 2004 and 2008 will run on Power Macs and the Open XML Converter can be attacked in some of the same ways. Microsoft, damn their Redmond hides, does not offer any of the updaters prior to Office 2008 for download anymore, but I've archived some of them on the Gopher server. For Office 2008, start here (note that you may need to download earlier service packs, which are currently still available as of this writing). Note that Office 2008 cannot run Visual Basic for Applications (VBA), which is a drop in functionality but also a reduction in attack surface, nor can the OpenOffice alternatives. NeoOffice has not been updated for PowerPC in some time; 5.2.0alpha0 is the last version of LibreOffice for Power Macs and is generally my recommendation, but you can also download OpenOffice 4.0.0. All will run on 10.4+.

Note that while iWork/Numbers does support some Excel macros, it does not support VBA and seems to have some issues interpreting macros in general, so it is less likely to be exploited. The venerable AppleWorks nee ClarisWorks is also not known to have any serious vulnerabilities.

Adobe Acrobat and Adobe Acrobat Reader: Acrobat allows embedded Flash and JavaScript, which also makes it a scriptable cross-platform target, and Adobe Acrobat is no longer updated on PowerPC OS X. (The classic Mac OS version is less vulnerable because it implements less functionality, but it may have compatibility issues with more recent documents.) The only thing you should use Acrobat for is creating PDFs, and viewing protected documents. Otherwise, make sure your PDFs open by default in Preview using the Get Info box in the Finder. Do not use the Acrobat plugin. It should be disabled or removed (or use TenFourFox, natch, which won't even run it).

Microsoft Virtual PC (and other PC emulators): I won't belabour this point except to say this depends greatly on what you run inside the emulator. Remember that a virtual machine installation of Windows can be just as hosed as a real installation, and can be an even greater malware risk if it has network access. Some Linuces will still run in VPC (I used to use Knoppix). Otherwise, stick to Windows and patch patch patch, and/or completely disable networking or enable bridged mode, which uses your Mac as a firewall for the emulated PC, as appropriate.

* * *

Watch this blog as other security-related posts appear. Yes, your Power Mac has holes, but until such time as they can't be plugged or the system is no longer fit for your purpose, nothing says the only choices are a forced upgrade or sit unprotected. So far we've made our systems last over a decade. I think we can still safely keep them viable a while longer.

Friday, November 10, 2017

TenFourFox FPR4 available

TenFourFox Feature Parity Release 4 final is now available (downloads, hashes, release notes). It will become live on Monday "evening" as usual. There is no debug version for final since the only reason I was doing that for the last FPR or two was to smoke out issue 72, for which the fix now appears to be sticking (but, as usual, there will be one for FPR5b1).

For FPR5 the big goals are expanded AltiVec (enable strchr() everywhere else, finish as much as possible of the AltiVec VP9 intra predictors), some DOM and Web compatibility improvements, and some additional performance improvements primarily in the session store module and the refresh driver. More on those soon.