Wednesday, May 30, 2012

13.0 available

13.0 is now available. In addition to the new changes introduced overall, Tobias demonstrated that the browser can stand up and run with -mdynamic-no-pic, which disables position-independent code in the executable and the dylibs. For those unfamiliar with PIC, it allows libraries to move around in memory, but requires a level of indirection because instead of directly calling a routine you must call a PIC stub, which does the actual call. Since TenFourFox is the only app using its own internal libraries, and only one instance can run at a given time (except for certain unusual circumstances), this is entirely acceptable and improves the browser's smoothness a fair degree. This won't translate much into benchmark changes (most benchmarks including Peacekeeper are disproportionately swayed by our JavaScript JIT, which already generates code finalized to memory address), but the browser will feel a bit more responsive, and that's good. Because we don't know how this will behave completely yet, the change will not be backported to stable. However, even with binary extensions I have no reason to believe that this will cause any major issue; Tobias has been using such a build, and I've been running 13 with it on both my quad G5 and the Luxo G4.

A lingering bug is bug 757262, probably caused by a significant change in plugin architecture in bug 90268. Let me reiterate that plugins are still not supported, and even 10.5 is having some serious problems with plugin architecture that will probably cause our deprecated plugin support to stop working completely after 10.5 support is removed from Firefox. Nevertheless, if you are bitten by this bug (i.e., the plugin you enabled "against medical advice" fails to shut down when a tab is closed), you are encouraged to follow up in that bug. Don't report it here. Mozilla has decided not to respin since the proposed fix is speculative and no one has proven it works because the manifestation is maddeningly uneven.

This version also fixes the last of the graphical glitches with Azure (mostly issues with CTGradient), puts WebM back to single threaded (not ported to stable either), and fixes the endian problem with WOFF fonts. Smooth scrolling is disabled by default, only enabled for those who previously had it enabled; that's the only new difference between Fx13 and us. Remember, the change in how graphics are painted will affect how the browser reportedly acts, but does appear to be an overall win. We can expect the graphics stack and painting operations to change further as Mozilla tries to wring more efficiency out; most of this is likely to land in the Fx15/16 timeframe.

Some odds and ends. As a followup to our security on Power Macs post, Sophos has a list of viruses and malware listed by OS X version and architecture. Although an alarming number will work on PPC, all of those PPC-capable or Universal malware packages appear to be trojans, so you have to run them; none of the listed compatible attacks can be mounted without user assistance. The trick is to make sure you are not caused to receive them by a drive-by download, let alone execute them, and again, your browser can be a great help (or a horribly effective vector) with such software. Scriptable components like Flash and Java can be caused to download such software under false pretenses if their sandbox protections are subverted -- that is exactly the vector that Flashback used -- and it's yet another reason we need to leave those in the dust.

We are starting to deploy official localizations for German, French and Polish. There is an existing Japanese language pack, but so far they have indicated they would prefer to maintain it separately, and we have not yet heard back from our Chinese (zh-TW) translator. Chris is coordinating our l10n/i18n efforts. Please test these (they are only compatible with 10.0.x) and ensure they work to your satisfaction; I plan to roll these out with 10.0.5. Langpacks will not be offered for unstable branch to reduce load on our localizers.

WebGL nerds will want to look at bug 684882. While looking at 10.5 bugs to determine what we would need to backport in a 10.5-less future, comments 16, 37 and maybe 75 imply what needs to be fixed to enable WebGL and/or OpenGL acceleration on Leopard. I won't be doing this here on 10.4Fx because 10.4 doesn't support OpenGL 2.0 at all, so that's that, but those of you working on Leopard-specific ports including AuroraFox may wish to see if this gives you some pointers. Disabling texture minification appears to be the trick (but it has to be disabled completely) and a putative patch is in comment 16 in that bug. Obviously it will only work on those handful of cards and configurations where OpenGL 2.0 is operational, so this will only benefit a minority of Leopard users with a minority of configurations.

Finally, I am watching Mozilla's progress on Australis, the new Firefox UI. Some of the prerequisites for how the tab bar is to be drawn and designed (bug 625989 and dependencies) have me somewhat worried that there may be no good equivalents on 10.4, and a few comments imply that even 10.5 may have issues with it. It is entirely possible that Australis will land after 10.5 support in Firefox ends (we still don't know when this will be), and if it does, it is guaranteed Mozilla will use 10.6+ APIs of which some are almost certain not to have an effective or extant 10.4 equivalent. As we dropped visual parity with Firefox in 8.0, if it came to that, we would simply just not implement Australis and block installable themes that depend on it.

10.0.5 is holding for some last-minute landings; I aim to have it ready by Friday or Saturday. In the meantime, release notes and architecture builds:

Friday, May 18, 2012

13.0 changesets available

13.0 is now in the beta channel and I am typing this blog post in it. The new Blogger is still freaking treacle in January; I'd switch to Wordpress or something else, but Google still owes me some ad buxx and this is where people expect to find this blog, so I just turn the G5 up to Highest performance and type away.

The biggest change people will notice in Firefox 13 (and TenFourFox 13) is bug 598482. This greatly reworks how the graphics stack handles updates by almost totally eliminating the ability to have synchronous painting of the window, and instead connects everything up to the central refresh timer so that paints are batched and executed asynchronously. The result is some noticeable improvements in benchmarks because the browser is doing less unnecessary work (Peacekeeper increases to almost 660 on my quad G5), but there's occasionally a tiny lag in the UI because there is no way to trigger a synchronous paint anymore in the widget library. We notice this more because our title bar is drawn differently than Firefox's is (they use CoreUI; we use CoreGraphics to do it "by hand"); our titlebar is still drawn synchronously, so it appears first, but the rest of the window repaints at a random brief interval after when the refresh driver wakes up. Like most such title bar irregularities, using a Persona fixes it. A definitive fix is simply to rework the theme and the way we draw chrome completely, and I plan to (issue 16), but I'll talk more about that at the end. I expect graphics performance to improve further when bug 539356 lands.

13 also enables SPDY by default. Not many sites are using SPDY; as of this writing the only two big ones were Google and Twitter. SPDY improves network throughput, and it does seem to for us as well, but most of the overhead of rendering Google and Twitter isn't the network, so it's not really much different. There is no way to tell from the browser whether the site supports SPDY, btw; there are a few add-ons that will report the status if you're curious, but since functionally it doesn't differ any from SSL, I don't really see the point.

Another important user-facing feature is that tabs-refresh-on-demand is now default (so that tabs saved from previous sessions only load when you actually go to that tab instead of eighty tabs trying to squeeze out of your DSL line when you start the browser), and the new tab page. I actually don't care much for the new tab page -- it reminds me too much of Safari's, which I didn't like either -- but you can move things around and pin them, and you can also turn it off by clicking the little cube icon at the upper right.

Mozilla made two changes in 13 that I turned off. The first one is enabling smooth scroll by default: this is too slow on all but very simple sites, even on the G5; I might reconsider this after bug 702463. If you already have it enabled, of course, then it is still enabled. The second change they made was to compile everything with -ffunction-sections -fdata-sections, which is ostensibly to help trim binary fat, but caused an approximate 5% regression in just about every benchmark I test with and the small savings in code size are not worth it, so that's backed out too.

In other local changes, I landed a temporary endian fix for WOFF downloadable fonts (so Acid3 works again), and also removed our hack to make WebM decoding multi-threaded because Mozilla's testing seemed to imply it actually makes the current video pipeline slower. (This is not true of 10, so it will remain in the stable branch.)

While binaries for 13 are not yet ready, a number of you have asked for advance changesets to build your own or to play with them, and I will start making them available with this release; here you go.

I have my four eyes on two things in Mountain View. The first is, of course, IonMonkey, the new JavaScript engine. It is now to the point where the browser can allegedly stand up with it, but there are a number of tests that do not pass, and the engine is still not in mozilla-central. Reading the patches, it looks like IM will initially be paired with methodjit+TI ("JM+TI" -- the current JavaScript JIT in Firefox that we also use) in the same way that JM+TI was paired with the old tracejit (r.i.p.), so we should be able to just turn Ion off to start with and thus buy some time to get it working. Tracejit was fully functional for five entire releases (4 through 9), so we can assume we will have a similar grace period to get up to date. Unfortunately, even when IM eventually passes all the tests, benchmark results as of this writing show it's way behind Google V8 and even behind JM+TI, so it is very unlikely to be actually in the tree much before 17 or 18.

The second thing afoot is that Mozilla has started to float ending support for 10.5 again; recall that this was already circulated for the 13 timeframe, but that has obviously already come and gone as mozilla-central is currently on 15. While I still hold that Mozilla killed 10.4 and PPC support way too soon, they have supported 10.5 far longer than I thought they would, and their case is strengthened by Google planning to drop Chrome and Chromium support for 10.5 by "version" 22 -- note that Chromium hasn't been able to actually build on 10.5 for almost a year already.

The current proposal is that Mozilla would end 10.5 support for Firefox 16, but I'd prefer them to end it for 18 so that 17ESR still has 10.5 support in it and we can still use it as a dependable stable release. Since dropping 10.5 means losing a lot of legacy code we depend on (and a lot more work to merge), for 17 we would spin our current widget and theme libraries into Tiger-specific directories separate from Mozilla's code and maintain them independently. We would have to backport some changes required by the cross-platform portion of Firefox as it evolves, but it would be less work than the other way, and it also puts us in a better position for when 10.6 support ends as well because 10.7 has runtime and system requirements we will not be able to emulate. With our widget and theme thus separate from the mainline, I can finally rework how they are drawn, and I am strongly considering using brushed metal to work in better with the OS rather than the slight gradient we use now (remember that we haven't been at visual parity with Firefox since 8.0; if Australis imposed system requirements we would not be able to meet, under this scheme we could simply drop it entirely and continue to develop what we have). If Mozilla ignores us and decides to drop 10.5 in 16 anyway, I may accelerate this timetable. It's not a killer, but it may require us to fall away from them sooner.

10.0.5 and 13 binaries will probably be available in a week or two.

Wednesday, May 9, 2012

The security blanket blues

Briefly before the main piece, it seems that Fx 12 was not one of Mozilla's finer moments. Besides our broken web fonts, which was an endianness issue introduced by Google and picked up by Mozilla downstream, there was a rather nasty regression in JavaScript causing many scripts to run incorrectly and several other QA issues. I am hoping Mozilla fixes these in the 13 cycle, but many of the important fixes have not landed yet. It may be even later than beta 3, but that's when I plan to start the port regardless.

Also, Mozilla changed the login system for Builder.AMO, on which the QuickTime Enabler was stored, and now I can't get back in. I can recover the code, but this sucks, and we may need to rebuild against a new Add-on SDK anyway due to memory improvements landed for Fx15. So, for the time being, the QTE will remain at the same version for the lifetime of 10, and I will work on rebuilding it in the Fx15 timeframe against the new SDK.

Anyway, security. A recent piece in Computerworld gives the chilling statistic that half of all Macs will no longer be receiving security updates by this summer, assuming that Apple continues their current trend of ending security updates for version n-0.2 when version n comes out (so 10.6 ended updates for 10.4; 10.7 ended them for 10.5; 10.8 will end them for 10.6). Considering Microsoft is still supporting Windows XP, admittedly unwillingly, this seems pretty lousy behaviour.

In particular, this thinly disguised attempt at maximizing hardware sales screws those Intel Macs that can't be updated to 10.7 (or those of us that realize the utter trainwreck that is Lion and/or still need Rosetta), but in PowerPC land, even if Tim Cook grew the conscience for his userbase his predecessor never had, we can assume Apple doesn't give a flying cancerous pancreas about us. PPC is dead technology to Cupertino and that's that.

Because one of the goals for TenFourFox is security -- and security is the goal for Classilla, which if I grow an extra pair of hands might allow me to complete the security audit by the American Tricentennial -- I think it's worth a blog post to talk about exactly what security issues Power Mac users face. Both 10.4 and 10.5 are equally unsupported now and they won't ever be again (I intentionally won't talk about 10.1-10.3 here; there are very few good reasons for New World Macs not to be on at least 10.4, and beige Macs are better off in OS 9). If you are like me and believe it is not unreasonable to expect a long life out of your computer, then you'd better be prepared to do the legwork to keep it safe. Not only is a compromised computer a risk to you and your data, it can also be a source of misery for people on your network. At my normal workplace we are wrestling with a worm preying on the local Exchange server to pump out spam, and it all came from someone incautiously loading drive-by malware onto their office PC from some link they clicked. Moreover, while no PowerPC machines were known to be exploited by the recent Flashback worm, our previous analysis shows that the flaw was real; it's just that the actual payload was Intel-only, so it could not run even though it was possible to gain the privileges it would have required to be successful.

Surprisingly, the biggest improvement to our current security situation comes from, of all companies, Apple themselves. Believe it or not, One Infinite Loop is doing us a big (unintended?) solid by dropping PowerPC support like a hot potato. Xcode 4, which is the most current major version, does not support the 10.4 and 10.5 SDKs, and although it can be coerced with some difficulty into building x86 and x86_64 binaries for them, it won't build PowerPC code at all. To make a PowerPC binary, you must explicitly use Xcode 3, which won't run on 10.7 or any later version of OS X. Furthermore, to make a PowerPC binary that can run on 10.4, you must use Xcode 3 and explicitly link against the 10.4 SDK and build Universal or PPC, none of happens by default (heck, for that matter, linking against the 10.5 SDK is not by default either). Making malware that runs on a Power Mac will get harder and harder as the user base slowly dwindles, and this doesn't seem like much payoff for the typical money-grubbing phisher. I doubt Apple did this out of love and affection for us, but it is an unexpected benefit.

Most attacks nowadays won't work on Power Macs, anyway. A buffer overflow or stacksmash or other kind of specific low-level code attack requires that the malicious code written by the attacker be built in PowerPC machine language. Relatively few existed during the Power Mac's reign, almost all of them dating from pre-OS X days, and they all but disappeared after the 2006 Intel debacle transition when attackers moved to the much more familiar x86 architecture. Any attack that requires the processor to execute malicious code directly must be in PPC machine code; if it's in x86, it'll merely crash. The security elite reading this entry will immediately dismiss the rest of it as an appeal to "security by obscurity," and I entirely concur. But when the primary motivation of most attacks today is monetary, obscure just doesn't make enough dough. Laziness and the profit motive are the noblest goals. ;)

We do have to worry about cross-platform attacks, however, and there are no shortage of those. The Flashback worm was one example: by allowing Java to escalate privileges, anything could have been in that payload -- if it had been another Java-based executable, say, then the worm would have been able to run on Power Macs, and we'd be just as shot. Flash has been used as a cross-platform attack vector, as have the scripting capabilities of Adobe Acrobat Reader, and macro viruses in Word. And, of course, your Virtual PC instance is just as susceptible to a virus as the real thing if you run an unpatched version of Windows in it. Plus, a trojan written in a cross-platform language like Python, Java, Perl or whatnot will probably alarmingly run just fine on a Power Mac. These attacks are particularly dangerous because they hit us just as easily as the PCs and Intel Macs they are targetted at, even though we weren't the actual target (we're just gravy on the cake, or something).

Similarly, you need to make sure the browser you are using doesn't leak data and helps to insulate you against running insecure code. But you're using TenFourFox, so you already have an updated browser that doesn't run insecure plugins. Right? Right.

Security issues with what comes with OS X

Built-in networking: Enable the built-in firewall, and, if you can, enable stealth mode and disable UDP from System Preferences. Some applications require UDP, but see if you can work without it. Using a hardware firewall is even better. There are some potential exploits with the network-accessible components of 10.4 and 10.5, and simply preventing access to them is probably the best approach. If you intend to use Apache or some other server software with your Power Mac, probably better just to install Linux PPC and use that except if you are serving to an internal, trusted network.

QuickTime: There are PPC-based exploits for certain codecs in QuickTime, though none of these are known to be circulating now, and no specific PPC-based exploit for QT 7+. (While QT 6.0.3 in 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 PPC-compatible attack. An attack designed for Intel Macs wouldn't work.

Preview.app: Preview.app and the built-in image and PDF viewer libraries do have known holes, but no known PowerPC-based exploits. 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). This TidBITS article says it all, really. Eventually TenFourFox will have the pdf.js extension when Firefox gets it, but it's slow even on supported Firefox systems, so Preview is still going to render much service for most people.

Java: Just don't. If you use TenFourFox, it is disabled by default; otherwise, disable and destroy the Java plugin if it exists. Java is no longer safe on Power Macs.

Mail.app: There are probably multiple specific ways to attack this application, mostly by blended attacks on the individual components such as the image viewer, etc. (and see below about Webkit). However, almost all of them would require PowerPC-specific code. That said, with Tenfourbird available, why take the risk?

Safari.app and system WebKit: oh gawd no. But here's something you might not have thought of: applications that use the built-in system WebKit components to view HTML are just as vulnerable to attack as Safari. This includes, notably, iCab 4 (but not 3), and many RIA-based applications. However, it does not include OmniWeb, which has its own updated WebKit, nor Tobias' leopard-webkit, of course.

Security issues with common applications

Adobe Flash: I think I've already voiced my objections to Flash. At least one cross-platform worm was created with Flash to attack local networks, and there will be others. Because it is scriptable, many malicious tasks can be executed on a Power Mac. If you use TenFourFox, it and other plugins are disabled; otherwise, disable and destroy the Flash plugin if it exists. For the doubters in the audience: I have not used Flash since TenFourFox 6 disabled plugins last year. I mean it.

Adobe Acrobat: Acrobat allows embedded Flash and JavaScript, which also makes it a scriptable cross-platform target. The only thing you should use Acrobat for is creating PDFs, and protected documents. Otherwise, make sure your PDFs open by default in Preview. Do not use the Acrobat plugin.

Microsoft Office: Office has a number of exploitable holes through macro viruses. For Word, I can think of few reasons you would want macros enabled, but this is a real problem with Excel. v.X and 98 in Classic are probably too old to be effectively pwned, but many macro attacks against 2004 will run on Power Macs, and the Open XML Converter can be attacked in some of the same ways. Fortunately, Microsoft has been kinder to us Power Mac users than Apple has, and you can get updates for all of these issues from Mactopia. Office 2008 is much less susceptible than 2004, but this is because it lacks VBA altogether (greatly limiting its utility), and it is noticeably slower than 2004 or v.X. iWork does not seem to suffer from any of these issues, nor does dear old AppleWorks, so those are safe alternatives. OpenOffice and NeoOffice also get regular updates.

Microsoft Virtual PC (and other PC emulators): This depends greatly on what you run. Remember that a virtual machine installation of Windows can be just as hosed as a real installation. Some Linuces will still run in VPC (I used to use Knoppix). Otherwise, stick to Windows XP and patch patch patch, and/or take advantage of disabling networking or enabling bridged mode.

We need to be realistic and realize our dear Power Macs are not absolutely invulnerable, but we can make them practically so. While I respect those who run Linux on their Macs, for me I need Classic compatibility and the ability to run the apps I've paid good money for over the years (part of what also keeps me from switching to Intel, besides my general bigotry against x86 ISA), and there is no substitute for 10.4 or to a lesser extent 10.5. I run my Macs behind a hardware firewall and I practice what I preach in software. If we're judicious, careful and methodical, we can be nearly as functional as anyone else on the hardware we paid good money for and faithfully maintain.

By the way, I detest the new Blogger. It's slow, and trying to send a complaint about it being slow was even freaking slower. I don't enjoy upgrades for upgrades' sake, and Google is great at this kind of self-gratifying nonsense. Let's hope they forget about Google Code so that it doesn't get "upgraded" either.

Monday, April 23, 2012

So long, Firefox 3.6

Firefox 3.6 now disappears into the great Mercurial repo in the sky, its angel wings flapping slightly in the breeze. Mozilla 1.9.2 lives on for the moment in some separately-maintained third party builds and in Camino, but tomorrow there will be no more Fx3.6 and no more official Mozilla support for OS X PowerPC.

On that note, 10.0.4 is now in the release channel and advertised to users. PowerPC forever.

Saturday, April 21, 2012

10.0.4 released

Normally I would be at some fancy event with gorgeous blondes hanging off both arms and one or two attached to each foot regaling the crowd with my newest Theory of Everything, but you get bored doing that several times a day, so I built 10.0.4 instead now that Mozilla has finally seen fit to tag the branch. One of the changes Mozilla dropped busted the build, so that is fixed in the changesets. Please test it out before resuming your use of 12.

Speaking of 12, the failure on Acid3 is due to issue 146, which is an endian problem in the Open Type Sanitizer introduced by Mozilla bug 712217. It affects most downloadable fonts, in fact; you could get around it by disabling the OTS in about:config but I would really discourage that since the OTS is there to protect you from malicious or iffy fonts. The fix is pretty straightforward and I will push it upstream since it probably also affects SPARC. If I respin 12 it will be in there, otherwise 13. It does not affect 10.0.x.

Release notes and architectures:

Friday, April 20, 2012

12.0 available (10.0.4 to follow)

I don't know what's going on with ESR 10.0.4 (there is no tagged build as of this writing), but 12 is signed off and has build tags, so we're shipping. I will build ESR 10 tomorrow regardless of whether there are build tags or not because we need to get basic testing by you, the basic testing basic audience, basically before we basically ship.

As promised, TenFourFox 12 contains a CoreGraphics backend to Azure, the 2D API Mozilla is developing to improve graphics performance. Azure right now is only used for canvas elements, but this is in more places than you'd think (for example, pdf.js, the JavaScript PDF reader, uses canvas and this backend is noticeably faster), so the improvement is more than you might suspect. The shipped backend with regular Firefox requires features of 10.5, but fortunately most of the features have undocumented private API versions in 10.4, particularly the compositing operators, so the port was relatively straightforward in that respect. It also relies on CGGradient, which is a CoreGraphics convenience interface to CGShading that was introduced in 10.5; we use Chad Weider's public domain CTGradient object instead to act as a gradient-style veneer over CGShading and then a custom Objective-C++ glue object to connect Mozilla's C++ interface to CTGradient's Objective-C interface. Finally, the regular Fx backend uses CGContextShowGlyphsAtPositions to display text, which is not in 10.4's CoreGraphics or private CoreText, so we just use a loop and good old CGContextShowGlyphsAtPoint (CGContextShowGlyphsWithAdvances is not suitable for a variety of reasons, not least being std::vector doesn't act quite right in 10.4). The only leftover bug on our part is a strange edge case with gradients where a terminal alpha-only stop can leave a strange dark fringe and I suspect this is actually a bug in CTGradient.

You will notice one particular difference between Cairo-based canvas and Azure CG canvas, depending on the fonts you have installed and their supported faces. If your Helvetica, say, lacks an italic, then if you ask for italic in that font you'll just get roman, whereas Cairo would try to simulate it. Strictly speaking I think CG has the correct behaviour here, and actually the CG backend works better with weird fonts in pdf.js as well that don't even display with Cairo.

Using CoreGraphics also introduces a modicum of hardware acceleration, which works on both 10.4 and 10.5. Stretching the canvas (such as in this GameBoy emulator when you press ESC) uses hardware to stretch it rather than software, and certain other CoreGraphics operations can also be accelerated by the graphics card. The proof is in the benchmarks. Not only compare TenFourFox 12 against 11, but try turning gfx.canvas.azure.enabled off and see what it does to your Peacekeeper scores. CoreGraphics accelerates these operations up to 60%. I can't wait for them to expand it to other components in the graphics stack, particularly SVG and HTML5 video blitting.

Other than that, 12 is a pretty blah release. There are some new CSS and DOM properties, but that's really it. Memory usage seems a bit worse due to a new font shape cache they are using, but this improves text-heavy pages, so it's hard to call it a bad tradeoff. The big changes in tab control and SPDY-by-default don't start appearing until Fx13.

In TenFourFox-specific news, this release improves XPCOM performance from JavaScript by simplifying the PowerPC assembly used for xptcall. It's a marginal win, but it's a win everywhere (issue 137). Java is also now disabled by default again, even if you have ignored my professional advice and turned on plugins, as reported by Chris (issue 141). This last fix will also occur in 10.0.4ESR stable, and the stable release will also have the blocklist disabled.

Release notes and architecture builds (watch for 10.0.4 probably tomorrow evening Pacific):

Wednesday, April 4, 2012

Poisoned coffee

The Flashback trojan which is making the rounds can mount an attack through the vulnerable JVMs in 10.4 and 10.5 (and as we all know, Apple is no longer issuing security updates for PowerPC at all). I don't know if Flashback can penetrate PPC systems or merely crashes them, but there are enough cross-platform components within the attack that it seems at minimum possible. (Note to Classilla users: the JVM is too old in OS 9 and the cross-platform components require a Unix shell, so the most Flashback can make you do is bomb.)

UPDATE: Some people are linking to this post to try to warn PowerPC users that we are also vulnerable, but I have seen many people express disbelief because to date no one knows of any PPC systems that have actually been infected.

Well, let me disabuse you of the notion we are resistant to the attack: the CVE in question exploited by Flashback a/k/a Flashfake is CVE-2012-0507 and Oracle themselves say Java 2 Standard Edition 5.0 update 33 and before are vulnerable. J2SE 5.0 corresponds to Java VM 1.5, which is the JVM in use on 10.4 and 10.5 PowerPC, and no version of Apple Java for 10.4 or 10.5 is at update 33. So the hole exists. (There is an OpenJDK 7 available for 10.5 at least, but there is no browser plugin for it and the vulnerable JVM is still on your system, so you must take specific steps to disable the old system VM and also disable Java in your browser.)

But wait, it gets worse. The hole in question is a "sandbox violation" meaning it allows Java code that would normally run in an unprivileged environment to run with privileges. Read that sentence again: it allows Java code to do it, not merely native code. The malicious bootloader which Flashback/Flashfake uses to mount its attack will run on PowerPC because it is written in Java. When Flashback/Flashfake starts up, it initiates the sandbox exploit and, now possessing privileges, runs its bootloader which then grabs an actual native binary. The bootloader is crossplatform and works on Windows and Mac OS X. The binary the bootloader fetches and then executes is the true payload. MSDN has an excellent analysis.

The true (and as near as I can tell, the only) reason Power Macs are resistant so far is because the binary that is loaded is not compiled for PPC. That's it. The actual attack works. If the evil brains in a .jar behind Flashback were to compile their payload as a Universal binary and link it to an appropriate PPC SDK, the payload would also run, and the system would be exploited. So turn off Java now. It is no longer safe on Power Macs. Don't make your system's safety dependent on how lazy the Flashback authors are.

Back to the previous article ...



Java requires a (surprise!) plugin to run in TenFourFox, so by default we are not vulnerable, and even if you enable plugins "against medical advice" the Java plugin preference is specifically set to hide the Java plugin by default as well. You would have to turn on both preferences to actually get the exploit to occur (assuming that it can attack Power Macs), so we are safe from this attack in the vast majority of configurations.

Mozilla has started blocking old versions of the Java Plugin on Windows because of the BlackHole exploit kit which takes advantage of the same vulnerability, and they will extend this block to the Mac shortly. I don't know if we will take this code since it will block everyone from using Java, even those taking reasonable precautions, because there is no way to update the system JVM. It might be nice for someone in their copious spare time to look at porting one of the Java SDK clones to 10.4, you know, between saving the world and doing the dishes.

The CoreGraphics accelerated backend I talked about in the last post is now able to partially render text too. Still get crashes with gradients, so still not ready for primetime.