Security notes: sudo and OS X, more reasons you should not use Java

Busy week for security. There is growing consternation over a blended exploit in the OS X sudo utility (1.6 and later, which applies to all Macs from at least 10.4 up, including Intel Macs through 10.8.4) that can be abused to give a logged-in attacker root privileges. sudo is a tool that allows allowed users (on OS X, that's anyone who is an administrative user) to achieve root privileges without knowing what the root password is, and from there can do any task, nefarious or necessary. This exploit takes advantage of a well-intentioned sudo convenience where if you've authenticated already within a certain period, usually a few minutes, it won't ask you for the password again. Let's also combine this with the knowledge that OS X does not require root privileges to set the date and time of the machine, either from System Preferences or using the systemsetup CLI tool. Did you figure out the flaw yet? If you set the clock to a time period sufficiently back in the past, and the user you are attacking, impersonating or sitting down at their machine has ever successfully run sudo from the Terminal before, you can become root as often as you like because their credentials will not have "expired." This means you can merrily install malware, snoop on their files, force them to use the metric system, copy their Michael Bolton album boxed sets, etc. Just because you don't use the Terminal doesn't mean you're not vulnerable; if they can get on your system and run applications, even remotely, they can exploit this hole.

How to fix it? Well, you could build and install a new sudo, but here's a better idea: force sudo to always make you enter your password, which is just more secure in the first place. In the Terminal, type sudo visudo, enter your password, and in the configuration file add this line: Defaults timestamp_timeout=0

Save the file and exit the editor. Test it with back-to-back sudo bash commands. You should always be asked for a password. Now it doesn't matter what the clock is set to; you won't give away the store. I've tested this on 10.4 and 10.6; I see no reason why it won't work on 10.5, 10.7 or 10.8. 10.3 and earlier users, if sudo -V says a version that is 1.6 or later, you are also vulnerable. This may be fixed in a future 10.6 update, but really, this is just a safer way to use a tool that can be very dangerous if misconfigured.

Also, if it's [a day in the week ending in -day], it's time for another Java exploit. In the MITRE security note, they say "Oracle has not commented on claims from another vendor that this issue allows remote attackers to bypass the Java sandbox," which, because Larry Ellison is a turdbucket, almost certainly means that this vulnerability can escape the Java sandbox. That also means that this is a cross-platform privilege escalation, because the sandbox runs platform-independent code, and Java 1.5 is already known to be vulnerable and will never be updated for Power Macs. If you are running Java applets on any version of PowerPC OS X, you need to surrender your power cord, now.

On BaselineCompiler progress, we are now passing 87 tests so far and slowly getting to phase 4. Also, our friend at Tenfourbird found a methodjit bug and created a fix that we will take for 17.0.9 and 22.0.2 (if there is one) (issue 239). Thanks, t_mrc!

Let's go out to launch: a gentle position statement

I generally don't comment much on what people do with what I release, because part of open source is that people get to do with it what they want to. However, I'm already getting questions, so let's make sure everything is made clear.

Adam Albrec today released a launcher allowing users to switch back and forth between TenFourFox 17.0.x (for the unsupported plugin support it still contains) and whatever the current version is (which doesn't, and won't, due to Mozilla's removal of QuickDraw and Carbon plugin support), with the intention of a "best of both worlds" compromise. He's welcome to do whatever he wants, of course; this is entirely his work and his to support. Here is my official position, and Adam is aware of it:

• I always welcome development in the TenFourFox ecosystem, including the projects I endorse (Tenfourbird), have endorsed (AuroraFox) and have concerns about (this one). I certainly salute his loyalty to the PowerPC community.
• Plugins have not been supported in TenFourFox since version 6.0, and turning them back on puts the browser in an unsupported configuration. I stand by my plugins policy with regard to security and changes to the underlying plugin architecture.
• Mozilla continues to change the way profiles are implemented. Right now, between 17 and TenFourFox.next, whatever it is (22 or 24), there is little difference and the upgrades are handled transparently. When Firefox 24 becomes the new ESR, that will no longer be guaranteed, like I no longer guarantee it between 3.6 and 17.
• 17.0.x is a branch with a finite lifetime. There will be, at most, two more releases, namely 17.0.9 and 17.0.10. Penetration toolkits are already incorporating specific exploits against old Firefox versions, and some of these exploits are cross-platform (they are not specific to the Intel architecture), so using an old version of Firefox for an extended period of time is never a good idea if you're doing security-sensitive activity like bill pay and banking. I can't endorse, by default, a strategy to make using an older insecure version more favourable even if the intentions are good.

But, the silver lining is that folks still write PowerPC-compatible software. And activity on that front is always welcome, for which Adam is to be commended, even if I have concerns about the nature of the software itself. Questions are welcome in the comments section.

Save. Save now. Save.

You are out of memory

I think BaselineCompiler is far enough to declare it at phase 3 (i.e., basically working, but still has bugs and does not yet pass the test suite), so I've dropped a "save point" tonight per my promise in the last blog post for those of you in the audience who are interested. It is still suffering from some significant glitches but is now able to run about half of V8 successfully and I think this is far enough to try to get everything else to pass (since that will be easier than figuring out all the places it could go wrong in V8), so if you're interested in helping out the changesets are now available from the downloads tab. I have not tried to actually build the rest of the browser yet; just build up to js/src inclusive only. You should apply it to mozilla-aurora at the designated rev, not to tip unless you think merging patches is a great way to spend your day. Follow along in issue 224.

Also, as promised, I've made available the customized gdb I'm using for this work. In addition to optimizing getting registers from the current frame and stifling the warning about gdb being unable to find object files, it adds two new commands: ct, which skips a trap instruction inserted into the code and automatically continues in one step, and sii, which is a macro to step through 10 instructions at once. For my next trick, I aim to make it stop spuriously removing display items on traps, but I haven't figured out how to do that reliably yet. Source and a binary for PPC 10.4/10.5 are available from the downloads tab. It is based on gdb-768, which is the debugger Apple includes with Xcode 3.

I am going to try to get a 24 beta out at the same time as 17.0.10, the last 17 release, but you should assume we will have at least one more interim 22 release before then; I don't think I'm going to be ready with a 24 beta for 17.0.9.

Firefox 23 goes boom, Baseline takes off

Mozilla is pushing out Firefox 23.0.1. This fixes several bugs in 23 specifically and does not affect us, so there will be no chemspill (the issues fixed are not relevant to 22).

I'm not happy with some of Mozilla's choices for 23. The biggest one that sticks in people's craws is removing the "Enable JavaScript" checkbox. Yes, some dolts will uncheck that, and then ask where the cute kitty videos went to and why their AOLmail won't work, but it's also handy for systems surfing specific websites that don't need scripting (NoScript isn't getting any smaller these days). Also, the mixed security content blocking is messing up a handful of sites, you can't hide the tab bar anymore even if there's only one tab (though in fairness this would probably hose Australis), and it is no longer possible to have separate search engines for the address bar and the search box. You haven't noticed this yet, because 22 still does things the old way.

Mind you, Mozilla does have some not-bad reasons for removing these options (or at least for some of them). I didn't say they were good, necessarily, but they are not-bad; a case can be made. That said, it's cheesing off a lot of users. Sometimes the right change never has the right time, even if it has all the right reasons. Long story short, I am strongly considering keeping the JavaScript checkbox at least in 24, and then we can think about whether this is a change we want to drag along once 24 lifts off. How many of you use that checkbox? Speak!

Back on the development side, PowerPC BaselineCompiler's first script has opened the floodgates (I almost typed "floodgaps"), as predicted, because to get that first simple script to run required a lot of machinery to be online and operational: we have to have an assembler, we have to be able to emit instructions, we have to be able to link branches and calls, and we have to be able to move things around in memory and keep everything in sync. Now that this underlying machinery is tested and mostly proven, the complexity of the code generation can ramp up fast because much smaller changes have much bigger effects. With some tweaks, we've been able to run since Thursday all of the following:

• var i=0
• var i=2; print(i);
• print("hello world!\n");
• var i=2;i=i+3;print(i);
• var i=2;i=i+3;if(i==5)print("five");else print("not five");
• function f(x) { print("hello world"); } f(); f();
• function f(x) { print("hello world"); } f(f());
• function f(x) { print(x); return x; } f(f("hello world"));
• var i;for(i=0;i<5;i++){print("loop"); } print(i);
• var i,j=0;for(i=0;i<5;i++){ j+=i; } print(j);

This is getting very close to phase 3, where the basic functionality is declared "working." I still have to test the rest of the integer math and string packages, as well as floating point operations, recursion and on-stack compilation. Much of this is in cross-platform code, but a very nice thing about BaselineCompiler is that the inline caching code is completely under our control. Inline caches are an important component of just-in-time compilation of dynamic languages like JavaScript, because they allow type specialization of sections of code ("oh, this looks like an integer, so I can make certain optimizeable assumptions about this, assuming it's an integer") that can be built on the fly. I'm pretty proud of some of the optimizations this makes possible. I still don't see the speed being much better than 70-75% that of methodjit, let alone faster, but it should be good enough.

Once we get to this point, I'm going to drop a "save point" for the interested, get the test suite to pass, and then attack the rest of Firefox 24. It's going to be tight for September, but we'll try our hardest.

It can walk! It can walk!

% gdb7 --args ../../dist/bin/js --baseline-eager --no-ti --no-ion
-e 'var i=0'
GNU gdb 6.3.50-20050815 (Apple version gdb-768 TenFourFox patch 1)
(Sat Jul 27 01:39:28 GMT 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "powerpc-apple-darwin"...
warning: --arch option not supported in this gdb.
Reading symbols for shared libraries ......... done

(gdb) run
Starting program: /Volumes/BruceDeuce/src/mozilla-24a/obj-ff-dbg/
dist/bin/js --baseline-eager --no-ti --no-ion -e var\ i=0
warning: Could not find malloc init callback function.  
Make sure malloc is initialized before calling functions.
Reading symbols for shared libraries .............................
.......................................+++ done
cx = 01e097c0 cx->data = 01e18240
cx = 01e097c0 cx->data = 01e18240
callVM: descriptor 833 (frameSize 48 argSize 4)
callVM: descriptor 1025 (frameSize 48 argSize 16)
cx = 01e097c0

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f848a0 in ?? ()
(gdb) set $pc+=4
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f9bec8 in ?? ()
(gdb) set $pc+=4
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f9a208 in ?? ()
(gdb) set $pc+=4
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f9a234 in ?? ()
(gdb) set $pc+=4
(gdb) cont
Continuing.
return address: 00f9bf90
offset: 000000e0
searching -- try 000000e0 000000e0
searching -- try 00000098 000000e0

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f9a28c in ?? ()
(gdb) set $pc+=4
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f94948 in ?? ()
(gdb) set $pc+=4
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f94974 in ?? ()
(gdb) set $pc+=4
(gdb) cont
Continuing.
FallbackICSpew cx = 01e097c0

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f949e8 in ?? ()
(gdb) set $pc+=4
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f9bfe4 in ?? ()
(gdb) set $pc+=4
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f84a58 in ?? ()
(gdb) set $pc+=4
Cannot access memory at address 0x103
(gdb) cont
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00f84a74 in ?? ()
(gdb) set $pc+=4
(gdb) cont
Continuing.
cx = 01e097c0 cx->data = 01e18240 data = 01e18240

Program exited normally.

And in case it wasn't obvious: BaselineCompiler for PowerPC ran its first script successfully tonight! Damn, all those months of work finally paid off!

More later.

22.0.1 available

Sorry -- after much unintended delay, 22.0.1 is now available (downloads, release notes). This brings the browser to security parity with 23 except for Ion-related stuff, which is irrelevant to us, and has some performance tweaks for garbage collection, cores, opacity and gradients. It also fixes the font reference leak which regressed in 19 and shouldn't ask for updates quite so frequently. It will be a good interim release until the disposition of 24 is better resolved. More on that later.

Speaking of security, Dan DeVoto has a nice post on getting TenFourFox to work with Tor. Just make sure you have NoScript enabled, and as he points out, consider masking your user agent.

On a totally unrelated note, but because I know there are some Amigaphiles in the audience, picked up an Amiga 3000 with an A3070 streamer from fleaBay. 2MB/8MB chip/fast, running WB 2.1; I cut out the ticking timebomb known as the battery (battery holder on its way) and cleaned it up, and it boots like a champ. Took a bit of cussing and screaming but it now can talk to my old Apple external CD-ROM as cd0: with AmiCDROM (bless you, Aminet) and I got the absolutely ancient version of CrossDOS on it to read a floppy from the Power Mac 7300 so I could transfer drivers to it (as di0:, not the usual pc0:). If anyone's selling a Picasso video card or an A2065 or Ariadne network card, send me an E-mail. I like this machine a lot more than the A1200 I owned back in the day, and it works in with the office a lot better than my A500. It's pretty sweet.

Thank you for holding, please continue to hold

I'm trying to get 22.0.1 out but one of the security patches made the browser somewhat unstable and I'm trying to figure out which one. I've got it narrowed down to one of three. I apologize for this taking so long, so I'll throw in a couple of performance boosters stolen from 24-25 as a way of making amends for being tardy (these are very safe enhancements, and make gradients and CSS menus a bit snappier). ETA this weekend because I want to test it thoroughly before I make a release. Fortunately, I know it's something I did personally, because 22.0 itself is just fine, so it's just a matter of backing things out until it sticks.

BaselineCompiler is now to the point where it will generate the final inline cache code before terminating successfully on our agonizingly simple test case ("var i=0"). I haven't finished debugging that yet, but the light at the end of the tunnel is finally visible, if very, very distant. There seems to be some glitch with the JSContext * BaselineCompiler is passing and logging that I haven't figured out yet, but I've worked around that temporarily to get the meat of the work moving along. If I can get this passing tests by the first or second week of September -- which is doable, but a very big if -- then we might be able to get ESR24 up before ESR17 runs out. I would like this very trivial test case to be fully functional by this weekend, and then I will make a code dump for those who wish to collabourate. However, I am on standby call this weekend for my actual paying job, and 22.0.1 has priority above 24, so I have rather less time right now to work on this than I would like.

I've been so busy trying to get BaselineCompiler to lift off that I haven't really had time to work on the transition from Google Code to SourceForge. For the time being, we will continue to clear out old alpha/beta/test releases periodically to keep us below quota. Once we are out of space and out of things to clear out, or January 2014 comes and Google refuses to let us upload anything, then we start uploading to SourceForge. Old versions will remain here until Google kills that too someday. I really haven't had time to go through issues and manually move them over, let alone the wiki, so we're going to leave them where they are for the foreseeable future.

In the news category, IBM is looking to open up the POWER architecture a la ARM through a new group called the OpenPower Consortium, starting with the next-generation POWER8 series. Recall that PowerPC came out of the AIM alliance (that is, Apple, IBM and Motorola), back in the deep dark ages when dinosaurs roamed the earth and used Power Mac 7100s to hunt mammals. However, Freescale (Motorola "today") has since gone their own way with embedded PowerPC, not a market IBM has historically desired, and Apple is of course completely out of the POWER racket, so IBM is looking for more partners to keep Power Architecture viable. One of the names mentioned is, intriguingly, Google, suggesting that the Googleplex may be interested in making their own CPUs as well as their own servers. Another one is Nvidia, which will enhance its CUDA GPU parallel computing environment for Power Architecture to make it more attractive as a big-iron number crunching platform (and that's a market IBM does like being in). Server builder Tyan is presumably looking at customizing their servers and motherboard lines for POWER CPUs, though their press release is a little opaque. While existing Power licensees will still be doing what they're doing, it's an interesting move to get the big iron POWER chips a little more circulation: while IBM will maintain control of the ISA, like ARM does, OpenPower members will get to customize the hardware and add more system-on-a-chip functionality, and presumably do so at favourable licensing rates. And, hey, look how well ARM did. Time will tell.

17.0.8 replaced

As suspected, Mozilla respun 17.0.8 due to an incomplete security fix (but not the "Reddit 0-day" -- we're not actually vulnerable, only old versions). Analysis shows this is cross-platform code and we can also be compromised by the incomplete patch, so I replaced 17.0.8 with new versions. If you are using 17.0.8, please grab it again, or your version will not have the fix. Same changesets from 17.0.7 apply. This will become live shortly along with our newest translation, Asturian (thanks to mikelglez for the work, and, as always, Chris T for coordinating our localizers).

Reddit-reported "0-day" security issue in 17

Reddit is reporting a drive-by exploit on the Tor anonymizing network targeting Firefox 17 (general warning about links to dodgy and possibly-illegal-in-your-jurisdiction stuff on Tor applies; this is Reddit, after all). I don't use Tor, personally, but although while the exploit is currently limited to a site on the .onion network it is of course possible for it to be placed on the Net at large. I can't tell if it affects only 17, or if other versions are vulnerable, but this specific exploit uses x86 shellcode targeted at Windows and the most it can get a Power Mac to do is crash. (In fact, with our extremely large stack it's arguable it can even do that.) This bug is already public, so I'm not giving away anything here. Mozilla is investigating.

Because we are not exploitable with this particular technique, we won't pull 17.0.8 just for this. Mozilla has found an incomplete fix on one of the other security issues which we might be vulnerable to, however (I'm still analyzing how we handle it), so stay tuned.

UPDATE: Hacker News has some of the backstory, for the interested.

UPDATE THE SECOND: It appears this bug was already fixed, thankfully, in 17.0.7; the exploit is specifically targetted at Tor users which lack an autoupdate.

17.0.8 available (plus: goodbye, OS/2)

Current CD: REO Speedwagon, You can Tune a piano, but you can't Tuna fish. "Roll With The Changes" seems like a particularly apropos track these days.

17.0.8 is available for testing from the Downloads tab (release notes). There are no TenFourFox-specific fixes in this release and the changesets are the same as 17.0.7's and apply without modification, so use those for building. Assuming no major issues, it will convert to release on Monday evening Pacific time as usual.

There are only two more scheduled releases for ESR17 left to occur: 17.0.9, to coincide with 24.0, and 17.0.10, to coincide with 25.0 (and ESR24's 24.0.1). At that point, only a chemspill would force a 17.0.11, and then only up until 26.0/24.0.2, when ESR24 becomes the only maintained ESR branch and Mozilla upstream support for ESR17 is terminated. 17 has been a strong, solid stable branch and I'll be sad to see it go. I don't yet know what this will mean for Tenfourbird.

I'm still not able to get simple scripts to run yet in BaselineCompiler under (what is now) 24-beta; I think I'm accidentally pushing wrong or bogus values on the stack, and the JavaScript VM routines are barfing on them. (When I said everything is on the stack, I mean everything.) Some inquiries of whomever was around on #jsapi were sympathetic but ultimately unhelpful, so I'm just going to have to keep plugging at it. I'll be uploading an initial set of changesets soon so those of you with some ideas can have a look, and there is also some activity from someone at IBM about getting PowerPC better supported by Firefox, so I'm hoping they'll have some thoughts on it even though OS X PowerOpen ABI is a bit different from Linux SysV ABI. There's even a Firefox build waterfall for Linux ppc64, which should help to flag any big-endian regressions from future code earlier.

I'm still hoping I can get a 24 beta ready to coincide with 24.0, which is six weeks away. If I can do that, and it's not a train wreck, then we switch people to 24 with 24.0.1 and 17.0.10. If I can't, we issue a 22 beta and use it as a transitional release for stable branch users until I get 24 working, or if I can't do so in a timely manner (two or three version cycles), we give up and drop source parity. We will not make a release without a JIT; we rely heavily on it and the interpreter has been deoptimized in 24 and up to simplify the code, making it a very poor alternative option. (I shudder to think what will happen to PPC Linux Firefox users.) If there is no JavaScript JIT, source parity ends, period, full stop. Whatever happens, 17.0.10 is our final 17.x release.

With respect to 22, there is no draft of the security updates for 23 yet for me to read through, so I will probably not be able to backport fixes until later this coming week. At that point a 22.0.1 will be released (not 22.1); this will be the basis for the "stable branch 22" 22.0.2, if required, and will contain the aforementioned fixes for issues 231 (for 10.4 and 10.5), 232, 233 and 234. None of these issues really affect 17, so they will not be backported. Expect this build to be available probably Friday or Saturday. Remember, 23 has no more methodjit, so there is no point in trying to port it separately of 24.

In other news, Mozilla is discussing removing OS/2 support from the build system due to incompatible changes (note that these changes are, mercifully, unlikely to affect us directly). This is sad but not altogether unexpected, since not even ESR17 works right on OS/2; a porting effort is underway but the chance of it becoming fully operational before ESR17 support ends seems very remote. Another venerable tier-3 build bites the dust.

Also, I finally managed to get a pre-order in for a FirefoxOS phone. Geeksphone, realizing they have a lot of pent-up demand which was not met by the five or six devices they built for FirefoxOS developers (he says with irritation), has now started taking pre-orders for the Peak Plus, a GSM dual-core Snapdragon device with decent specs that hits most of what I need in a handset. In this era of crony capitalism surveillance, we need a third way besides Google and Apple (don't say Microsoft; they were even deeper in it than that lot) for the devices that are intertwined with most everything we do, and Mozilla is large enough and trustworthy enough to be able to pose a plausible alternative. As a side benefit, its open architecture means it's likely to work a lot better with our older Macs. It lists for €149, and with tax and shipping to the USA it ended up being around US$240, which is staggeringly reasonable for an unlocked device even considering the penalty of moving to a new mobile operating system. Look for a review in this blog when I get it in September and a comparison with my Galaxy Nexus handset (bought new and unlocked for $650), which just got the "nothing" 130MB upgrade to Android 4.3 in which nothing changed but the camera app. Well, that's modern life for you.