Sunday, July 20, 2014
Friday, July 18, 2014
Starting in 31, language packs are now available on SourceForge also; you can get them from the download area, organized out by version.
I'm putting the final touches on Yosemitespoof, because Apple deserves a little ribbing now and then from those they've left behind. The annual statistics post is coming up too.
Wednesday, July 16, 2014
I'm now working on the final build for 31.0. Issue 280 is fixed in this release for G5 users, the only remaining major issue; a minor cosmetic annoyance on low end Tiger systems is issue 282 but this can be dealt with during the release cycle. It looks like generational garbage collection was too crashy, so Mozilla has reverted that and ESR31 will be (like us) exact rooting only. This is good news, because serious problems outside of GGC now have a much better chance to get fixed since both B2G and ESR31 won't use it.
Thanks to Chris T's hard work and our localizers, we have the same set of language packs for 31 that we did for 24, which is great. Also, I'm going to include a link to the Japanese translation, which is maintained outside of our framework. Although Yosemite is still technically in preview, I'm going to rip it off early (minus that freaking annoying cloud animation) like we did for Mavericks since the whole design-change thing fits in perfectly with the Australis shift. You'll enjoy the pastiche.
I'm monitoring future changes in Firefox and there is a lot of activity around resurrecting the foundered Electrolysis (E10S) project that was originally scheduled for 4.0 way back when. Electrolysis, put simply, is multi-process Firefox -- chrome, i.e., the browser interface, runs in a separate process, and content, i.e., the websites you visit, runs in (at least) another. This improves security and responsiveness dramatically, but could use substantially more memory, may be overall slower on uniprocessor Power Macs (such as all PowerPC laptops), and might not even work. Right now, E10S will crash TenFourFox because the 10.4 SDK doesn't implement the process spawning library routines -- we have to do that ourselves (issue 66) -- and if we do it, there might be a whole class of new bugs to deal with since we don't know if there are endian issues with passing information or serializing objects and there could be operating system bugs that get exposed in the implementation. It would only be a net positive if it didn't suck, though that's true of everything, I guess.
Mozilla is pushing Electrolysis as a marquee security feature for Pwn2Own 2015, which is roughly the Fx35 or Fx36 timeframe. Usually once a major architectural change becomes default, the other code path is quickly deprecated or deleted (and certainly unmaintained), and we would be at least two releases shy of the next ESR (Fx38). However, given the amount of work needed to even make it workable for Nightly users and the chaos it will cause with add-on incompatibility, I think it will be even longer before it becomes default in Nightly (and the countdown begins).
Make no mistake: I support, in broad strokes, what Mozilla is doing and it solves a whole class of bugs for them they can't solve any other way with the current single-process architecture. But it might not be a good thing for us, and it would require a lot of work with no guarantee of a payoff. If they enforce it and I can't make it work, that's a portkiller. We also need to watch what's going on with 10.6 support -- I'm still predicting it will be removed somewhere in this inter-ESR timeframe and I bet 10.7 support goes away at the same time. We're still relying on much of that old interface code and having to backport and merge all of it along with the 10.4/10.5 compatibility code we already have would be far more work than I could reasonably accomplish on the rapid-release timetable, at least as it stands right now. Watch Chrome very closely, because once Google gives Snow Leopard the axe, Mozilla will almost certainly follow suit.
Expect 31.0 final by this weekend for an on-time release next Tuesday.
Friday, July 11, 2014
Both Flashback and Rosetta Flash have something in common: they both attack the virtual machine which runs architecture-independent bytecode, in Java and Flash respectively. This is why the basic exploit works on Power Macs as well; we implement the same virtual machine so that the bytecode is machine-independent and doesn't have to be written for the actual CPU in use. In this kind of situation we're just bycatch. The exploit wasn't really targeted at us, but because we implement the same bytecode instruction set in the same way, we are vulnerable to the same problem. However, we don't get updates for Java or Flash anymore, so the exploit never gets patched.
This is the point at which the two issues diverge. Flashback exploited a weakness in the Java VM present in all versions, including PowerPC, allowing the program to escape its sandbox and do tasks it should not ordinarily be able to do. In Flashback's case, this was to download a regular binary program and execute it, allowing it to take control of the computer. If the authors of Flashback had thought of it and compiled that second binary as universal, it would have enabled them to take control of Power Macs as well. Even though the exploit is universal in the sense that it functions anywhere the vulnerable version of Java does, the payload it executed was not universal, so the attack failed -- but only for that reason. If a future attacker did build a PPC/x86 universal binary payload, they could still take advantage of the same flaw in the Java VM, and Power Macs would be able to execute the payload. Thus, Java is no longer safe to use on Power Macs running OS X.
Rosetta Flash proceeds differently. Flash applets are permitted to send cookie-bearing web requests to and from the domain that hosts it (which can contain, for example, login credentials and session information). This wouldn't help an attack much except when combined with a technology called JSONP, which is specifically designed to give scripts a way around the browser's built-in same-origin policy preventing documents and scripts on one origin from interacting with those on another. The details are pretty gnarly, but the basic notion is that JSONP facilitates an attacker controlling the output using a callback, and that output is a malicious SWF (the Flash applet format) encoded in ASCII that now can access the victim server with your credentials by combining Flash and JSONP's powers together. Now the attacker can do anything you can do, including post, read, send money ...
This attack is also, in a sense, universal, because it works on any vulnerable Flash implementation. However, it's not universal in the sense that a universal binary is universal, because it's not running a binary like Flashback does; the attack is accomplished with a single completely valid Flash applet that works on PowerPC and Intel. Furthermore, this exploit is fully weaponized: all an attacker needs to do is cut and paste the malicious SWF and put it up on a server with a crossdomain.xml allowing victim access. Since a lot of people update Flash slowly, this is a great opportunity for attackers. And we don't get updates at all!
The part that's particularly bad for us is even though the researcher who constructed Rosetta Flash also found a means for victim servers to combat it, the most productive way won't work on Flash 10.1 -- it needs 10.2. The callback can also be tainted so that the attacker can't meaningfully control it, but I consider that at best a temporary solution. Because the mitigations are inadequate and the attack will succeed against servers that do not guard against it, Flash is no longer safe to use on OS X Power Macs either.
However, people still want to use Flash on those really crappy sites that lock everything behind a Flash paywall, so people are still running Flash. Besides being a really bad idea, the fact is, it won't work forever anyhow: those sites are almost certainly the ones that will rely on DRM features in Flash that 10.1 will one day not implement. You need a better plan.
If you must run Flash, and if you do so you're making a big mistake, you really need to run it as separated from other things as possible and most importantly from the browser you use for logging into sites. If you run TenFourFox 24 or 31, as you should if you read this blog, then you are doing that already because 19+ won't run any plugins, including Flash. You could run it in another browser, but that browser itself needs to be up to date, and you should treat that browser as tainted and never use it for critical logins. Some folks have put it into a webapp with Fluid; this is not a terrible idea if you also install Tobias' Leopard WebKit so that at least a WebKit exploit won't ruin your day at the same time (if you're using 10.4, this is not an option). If you use MacTubes with Flash mode, you are essentially doing the same thing.
However, this won't protect you from the one day we get an exploit like Flashback's, and it won't protect you from future exploits. I practice what I preach. I have not used Flash since I banned it officially in TenFourFox 6 and completely in TenFourFox 19. I use MacTubes (in QuickTime mode, which has no known PowerPC exploits) and the QuickTime Enabler, and I won't use sites that demand I use a Flash-based player. If you install a user-agent switcher, you can pretend to be an iPad and many sites will give you an H.264 alternative the QTE will play.
You can also throw hardware at the problem. One very easy way is to get a Chromebook: these are cheap, they come available in ARM versions too for people like me who get hives buying x86 hardware, and ChromeOS has a built-in, constantly updated implementation of Flash. If you have Windows or OS X in a VM on your x86 Intel box, you could use that. You could even run it on a 10.6+ Intel Mac. But however you do it, you need to find an alternative. Flash isn't safe.
One other security note: Microsoft recently banned certificates impersonating major sites after the National Informatics Centre of India was compromised and used to generate malicious certs. This has been a chronic problem with SSL (previously, previously), but Firefox has never accepted the Indian NICCA root, and after this it almost certainly won't ever do so. We are therefore not vulnerable to this problem.
Finally, a shout-out to my friend Jon Schiefer, who completed his movie ALGORITHM and it had its first Hollywood screening last week. I was honoured to be consulted on the production and script; I'm surprised Jon still speaks to me after the amount of red ink I bled on early drafts. ALGORITHM will be free for streaming on July 13 only, so please visit the site on that date for more details and to see the film. Please support independent film and purchase a digital copy if you enjoyed it (DVDs and Blu-rays will hopefully be available in the very near future). This was made on a budget of $8,000 and everyone involved worked for a piece of the action. Let your support remind Hollywood that indie film drives America.
Tuesday, July 8, 2014
Well, Flash just got that sort of exploit, but it's worse, because this attack will work successfully against Power Macs too. "Rosetta Flash" (how appropriate!) can steal credentials and cookies by generating valid, malicious SWFs through JSONP that abuse Flash's ability to bypass the same-origin policy that would normally protect against such an attack.
There are ways that a service can protect itself from Rosetta Flash, but that's where it gets even worse for Power Mac users: the recommended server-side change to retard the attack won't work on Flash 10.1. Yes, you heard right. Even if the server implements the recommended server-side protection, Flash 10.1 will still download and execute the malicious SWF. And that's critical, because there is no Flash 10.2 or above for Power Macs, just various hacks that change the version number.
This exploit is fully weaponized, as they say in the biz. It's ready for any attacker to use. So Flash is dead: it is no longer safe for use on Power Macs, TenFourFox won't run it anyway, and if you are still using TenFourFox 17 to run Flash applets, I warned you this day would come.
So far all indications are that beta 3 is substantially faster than beta 2. I will make one last tweak to the garbage collector timeslice before release for a little better long term throughput. The only remaining bug is issue 280, which is a crash with the G5 using 7450 branching; I'm just going to revert to G5 branching as was originally in 24/26/29. I'm now starting to think that the performance delta might be a benchmark artifact anyway, and it's not worth the trouble to debug prior before release. Meanwhile, 31 will come out on schedule simultaneously with 24.7.0 to conclude ESR24. Another year of support ahead!
Friday, July 4, 2014
However, when I built the optimized version, it was still the same speed as beta 2 despite the debug build now being substantially faster. That didn't make any sense at all. Why would a debug build now beat the optimized build by almost a factor of two? It's not only bigger, it's deliberately more inefficient!
After about a week comparing source code, it became obvious that indeed there was nothing in Mozilla's debug code that was doing an operation with side effects or something getting cached that wasn't in the opt build. To prove that, I turned Mozilla's -DDEBUG on for the G5 opt build and the numbers indeed sank further. Incredibly, Shark would run the JS shell at least (even if it won't run the browser, so now I'm reexamining my theory about pilotfish -- perhaps it's just objecting to the size of XUL, which would not be surprising), and comparing the performance traces in Shark showed that the G5 opt build was slow across the board even in things that had no debug code at all, like C++ object constructors. WTF?
I don't have a good explanation for why DWARF-2 symbols weren't needed in 29 but are needed now; all I can think of is that somehow we crossed some internal maximum and we need the more efficient modern representation, even though the opt build does strip out most of the symbol table. This may have a consequence for debugging and crash reports, but I don't think we can go back to the old STABS symbols for 31. We'll just have to deal with the problems as they come up.
Your remaining homework:
- Now that we have substantially changed the browser foundation, we should reexamine some earlier performance conclusions. If you are on a multi-core Power Mac, such as a dual G4/G5 or the quad, try turning OMTC back on and restarting the browser. Does it help? Does it help on a uniprocessor Mac? It's hard for me to judge on my test systems. To try this, toggle layers.offmainthreadcomposition.enabled to true and restart the browser. The G5 seems a bit better, but it's a wash on the iMac, and the iBook is still questionably worse.
- The most important question: release 31 on time on July 22, or wait for 31.1? It's important to us to prove to the Mozilla community we're still a viable and well-maintained port, and I'd like to release on time to make that clear. However, if you have a good reason to wait, I'm willing to consider it; either way, though, we will release no later than 31.1. We need to stay current and ESR24 is going away.
One outstanding bug is a printing crash on Tiger Server only. I have never supported the Server versions of 10.4/10.5, mostly because I have no way to test them and I don't have a need to run OS X Server personally. However, if you're using it, please look at issue 279. While I will not hold the release to fix this and I don't have the ability right now to fix it myself, if you do, I will accept your patch as long as it doesn't regress the regular OS X client versions.
In July we will have our annual state of the Power Mac userbase, and I also have some fun future blog posts in the hopper on my expensive but incredibly fun Amiga 4000T (with Picasso IV, 68060 CPU card and Hydra NIC), and my old Wallstreet G3 now dualbooting Rhapsody 5.6 (Mac OS X Server 1.2) and OS 9.2.2. Plus, I picked up a Cube G4 when I was in Berkeley last week that's waiting for a power supply. The shell is in excellent shape with no major nicks or scuffs and I think it'll be a great test system for playing around with MorphOS in my copious spare time. If you're in the Bay Area and looking to pick up some more Power Macs, they've got plenty at M.A.C. on University and Shattuck and they're willing to deal. Check it out.
Tuesday, July 1, 2014
OMTC and generational GC will remain disabled for 31 just to give us every possible advantage.