Showing posts with label shoutout. Show all posts
Showing posts with label shoutout. Show all posts

Friday, April 26, 2019

Another interesting TenFourFox downstream

Because we're one of the few older forks of Firefox to still backport security updates, TenFourFox code turns up in surprising places sometimes. I've known about roytam's various Pale Moon and Mozilla builds; the patches are used in both the rebuilds of Pale Moon 27 and 28 and his own fork of 45ESR. Arctic Fox, which is a Pale Moon 27 (descended from Firefox 38, with patches) rebuild for Snow Leopard and PowerPC Linux, also uses TenFourFox security patches as well as some of our OS X platform code.

Recently I was also informed of a new place TenFourFox code has turned up: OS/2. There's no Rust for OS/2, so they're in the same boat that PowerPC OS X is, and it doesn't look like 52ESR was ever successfully ported to OS/2 either; indeed, the last "official" Firefox I can find from Bitwise is 45.9. Dave Yeo took that version (as well as Thunderbird 45.9 and SeaMonkey 2.42.9) and backported our accumulated security patches along with other fixes to yield updated "SUa1" Firefox, Thunderbird and SeaMonkey builds for OS/2. If you're curious, here are the prerequisites.

Frankly, I'm glad that we can give back to other orphaned platforms, and while I'm definitely not slow to ding Mozilla for eroding cross-platform support, they've still been the friendliest to portability even considering recent lapses. Even though we're not current on Firefox anymore other than the features I rewrite for TenFourFox, we're still part of the family and it's nice to see our work keeping other systems and niche userbases running.

An update for FPR14 final, which is still scheduled for mid-May, is a new localization for Simplified Chinese from a new contributor. Thanks, paizhang! Updated language packs will be made available with FPR14 for all languages except Japanese, which is still maintained separately.

Friday, September 30, 2016

gdb7 patchlevel 4 available

First, in the "this makes me happy" dept.: a Commodore 64 in a Gdansk, Poland auto repair shop still punching a clock for the last quarter-century. Take that, Phil Schiller, you elitist pig.

Second, as promised, patchlevel 4 of the TenFourFox debugger (our hacked version of gdb) is available from SourceForge. This is a minor bugfix update that wallpapers a crash when doing certain backtraces or other operations requiring complex symbol resolution. However, the minimum patchlevel to debug TenFourFox is still 2, so this upgrade is merely recommended, not required.

Tuesday, July 5, 2016

Did Juno is a PowerPC?

Congratulations to NASA's Juno space probe team, which is now successfully in orbit around Jupiter. When you want radiation-hardened CPU designs (to guard against naughty things like cosmic rays flipping bits and zapping traces), you want BAE's RAD series, and that means you want ... PowerPC. Yes, Juno's brain is a lowly RAD750 running at 200MHz, essentially a beige Power Mac G3 with cojones of pure lead. It has 128MB of the baddest, meanest, toughest DRAM there is and 256MB of flash on board with a system bus providing 100Mbps of instrument bandwidth for pure awesome. The radiation around Jupiter, due largely to its intense magnetic fields acting essentially like gigantic particle accelerators, will expose the probe to the equivalent of a human getting 100 million dental X-rays in the course of a year (for me, that year was 6th grade); to enable it to survive its two year mission, NASA has encased the CPU and other critical components in a titanium box a third of an inch thick.

Remember: when you absolutely have to get to Jupiter, choose PowerPC. (Heck, Mars too.)

Tuesday, February 24, 2015

Two victories

Busted through my bug with stubs late last night (now that I've found the bug I am chagrined at how I could have been so dense) and today IonPower's Baseline implementation successfully computed π to an arbitrary number of iterations using the nice algorithm by Daniel Pepin:

% ../../../obj-ff-dbg/dist/bin/js --no-ion --baseline-eager -e 'var pi=4,top=4,bot=3,minus = true;next(pi,top,bot,minus,30);function next(pi,top,bot,minus,num){for(var i=0;i<num;i++){pi += (minus == true)?-(top/bot):(top/bot);minus = \!minus;bot+=2;}print(pi);}'
3.1738423371907505
% ../../../obj-ff-dbg/dist/bin/js --no-ion --baseline-eager -e 'var pi=4,top=4,bot=3,minus = true;next(pi,top,bot,minus,30000);function next(pi,top,bot,minus,num){for(var i=0;i<num;i++){pi += (minus == true)?-(top/bot):(top/bot);minus = \!minus;bot+=2;}print(pi);}'
3.141625985812036

Still work to be done on the rudiments before attacking the test suite, but code of this complexity running correctly so far is a victory. And, in a metaphysical sense, speaking from my perspective as a Christian (and a physician aware of the nature of his illness), here is another victory: a Mozillian's last post from the end stages of his affliction. Even for those who do not share that religious perspective, it is a truly brave final statement and one I have not seen promoted enough.

Thursday, October 2, 2014

Blog roll

Nothing new to report on TenFourFox right now -- still working on the patches for 34 -- but two blog posts from the retro-Mac community I wanted to highlight:

Riccardo Mori's rebuttal on doing practical work on classic Macs. If you're reading this blog, you're probably already sympathetic to his view, and since Riccardo is very complimentary to TenFourFox and Classilla my linking to his post is totally, unapologetically and shamelessly self-serving, but I think he hits the main points very well (original article for comparison).

Martin Kukač prepares his G5 for another decade, which is his retrofit of an older G5 useful to those of you trying to maintain your air-cooled DP systems. Fortunately, my quad is already ready to go another nine innings.

Friday, July 11, 2014

Clearing up misconceptions about Rosetta Flash and some additional security notes

Our little discussion over Rosetta Flash, the exploit that should have you dragging the Flash plugin out to the dumpster and setting fire to it, has gotten picked up by several other blogs and news sites. Ordinarily this would be highly gratifying, but along the way there have been a few questions and a couple misconceptions, so let's elucidate.

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.

Sunday, May 25, 2014

31: close to beta (plus: new QTE and Mac|Life goes Low End)

Good news: there's going to be another stable release; 31 builds, links, gets off the ground and generally works. Yay! 24 will go into maintenance mode until 31 is ready for prime time, but the chance is better than even money that we'll have an on-time launch.

Between 29 and 31, Mozilla reworked the basic layers canvas code and this fixed the display problem with Google Maps and a lot of other sites. Plus, there don't appear to be any new regressions with the graphics code switching to Moz2D, and our "blue thumbnails" patch sticks fine in 31, so that's a lot of potential problems avoided and repaired.

The four major bugs we have left are all holdovers from 29, except this one: Google Maps does display correctly now, but it crashes with a null pointer assertion within the JavaScript virtual machine even with the JIT off. This looks like an endian problem introduced with bug 912456 or a related patch; simply wallpapering the assertion to make the browser continue doesn't cause any crashes, but Google Maps won't download new map content, so that's not very helpful. I consider this a showstopper. However, I also have a good idea where the problem is.

The second major bug is that the current version of the QuickTime Enabler does indeed hang up in TenFourFox 29+, as reported by a couple folks earlier. This is a problem with the old Add-on SDK jetpack version in v116, confirmed in that the MacTubes Enabler, which has a later jetpack, doesn't do this. Both of them will need a jetpack update for 31, but I updated the QTE jetpack and added a couple minor bug fixes and released that as QTE v120. You can get it from the QuickTime Enabler wiki page. It will work with 24 and 31 both, and then the QTE and MTE will be refreshed again after 31 is released. So that should be solved.

The two remaining issues are also 29 holdovers and while I consider them important to fix, I don't consider them showstoppers. It does look like editing keys have regressed per your reports, but not all keys have, so I'm not sure what's going on (menu keys and productivity shortcuts, for example, all function). This looks like our bug, but while I intend to fix it I don't consider this a shipping blocker for 31.0. Also, we still have the problem where webcam audio does not work (and neither does video-with-audio). However, our patch to force webcam video and video-without-audio does work, so the webcam can still be used for snapshots as its primary use case, and this is also shippable even if it's suboptimal.

31 also uses Mozilla's new generational garbage collector (GGC), which is even more aggressive about memory than the exact rooting GC in 29. The settings 29 use that we experimentally determined earlier in this blog are tuned for the older conservative garbage collector and may be counterproductive with GGC. I will likely change the time slice and some other parameters for 31 beta, so if you are using these custom GC settings please revert them before upgrading or the browser may not perform well.

Other than that, the browser appears to work fine and I think we're in good shape for another successful stable branch. Once I have the Google Maps problem fixed, I'll grab the beta source when 31 migrates from aurora and we should have a full-spectrum 31 beta release available a few days after the 24.6.0 update. Speaking of, 24.6.0 will be a security update only; there are no bugs on our side that will land, and I am not likely to do further feature work on 24 as the switchover to 31ESR approaches.

By the way, if you've got a newsstand nearby, you might want to pick up the current (June 2014) issue of Mac|Life and their article on rejuvenating your old Mac:

Even though it's a relatively basic article and their tips won't be big news to most of this blog's denizens, it's nice to see classic Macs still getting coverage in major Mac publications, and they even have a little section on Linux and alternative operating systems. Thanks to @thedoctor on App.net for spotting their shouts-out to TenFourFox and Classilla -- that's how you know you've arrived.