Mac OS X Buffer Overflow Found

MacDork writes "Well, if default settings in Mac OS X made Lance Ulanoff excited, this is really going to make him do the monkey boy dance... SecurityFocus's Bugtraq mailing list just posted a buffer overflow, in the utility for mounting and probing ISO 9660 file systems. No exploits were mentioned. No word on whether 'Max' alerted Apple or anyone outside of the Bugtraq mailing list though." Also, 'Max' made entirely unfounded, sweeping statements about the general quality of Mac OS X from this one little item, but oh well. When you're on top, you make a tempting target.

Comments

Looks low risk to me...

[MarkusQ]

From looking at the posting, I don't see any demonstration (or even any indication) that this is exploitable. What I see is that, if you put a goobered up CDROM in the drive (or use perl to simulate same)...

...it won't work.

Yes, it might be possible to craft some clever exploit in the usual way, but that is by no means easy and is often impossible (depending mostly on what gets allocated around the buffer).

And if it is exploitable? Will we see a rash of strangers in London Fog coats trying to slip CDs into unsuspecting Macs? We already prevent that, since anyone who could do that could do anything they wanted anyway, up to and including installing an old copy of BeOS over OSX anyway.

-- MarkusQ

Re:Looks low risk to me...

[ag0ny]

And if it is exploitable? Will we see a rash of strangers in London Fog coats trying to slip CDs into unsuspecting Macs? We already prevent that, since anyone who could do that could do anything they wanted anyway, up to and including installing an old copy of BeOS over OSX anyway.

That's not the way it works. The problem is a typical input validation problem in a setuid root binary. You don't need a CD. In fact, you don't even need physical access to the computer.

This is a privilege scalation vulnerability. If exploitable, this means that someone with non-superuser access to the computer could exploit the (as of yet unconfirmed) vulnerabilty in this binary to gain superuser privileges.

You must take into account that you don't need to be a local user in order to run this program. Some other vulnerability or misconfiguration can be used first in order to run an exploit against the cd9660.util binary.

Re:Looks low risk to me...

[You're All Wrong]

"I don't see any demonstration (or even any indication) that this is exploitable."

Then what the fuck is "#2 0x41414141 in ?? ()"?

To me, that looks like user data in the stack frame.
To me, that means that an arbitrary jump can be executed.
To me, that means that arbitrary NUL-less code can be executed.

And the chances of there existing NUL-less BSD PPC shell-code are what, you ask?

Here's your answer -
0x7CC63278, 0x2F867FFF, 0x41BC005C, 0x7C6802A6,
0xB0C3FFF9, 0xB0C3FFF1, 0x38867FF0, 0x38A67FF4,
0x38E67FF3, 0x7CA52278, 0x7CE72278, 0x7C853A14,
0x7CC419AE, 0x7C8429D6, 0x7C842214, 0x7C043A14,
0x7CE72850, 0x7C852A14, 0x7C63212E, 0x7C832214,
0x7CC5212E, 0x7CA52A78, 0x44FFFF02, 0x7CE03B78,
0x44FFFF02, 0x4BFFFFA9, 0x2F62696E, 0x2F73685A,
0xFFFFFFFF, 0xFFFFFFFF

All someone's got to do is calculate the offset for the overwritten return stack to contain such that it calls the above code. That could be calculated with just 2 more probes with perl - use 'abcdefghijklmnopqrstuvwxyz' x 20 and 'abcdefghijklmnopqrstuvwxyz123456789' x 16
and tell me the values read off the stack.

If anything you should be thankful that 'Max' didn't publish real live exploit code, as then the script kiddies would be doing their best to run it already. At least this way they need to still fill in the gaps. Gaps that unfortunately I've just had to explain on a very public forum because a Mac user had his head in the clouds.

YAW.

Re:Looks low risk to me...

[freerangegeek]

Excuse me, but to execute a mount I have to at least have a shell on the affected machine, right? I may not need console access, but I do need shell access.

And, by default, the firewall is ON, and sshd is disabled, so 'by defualt' I do need local access. And to execute a 'shell capable' program I can't just mail an attachment to the user, the user has to actively open it.

Admittedly, this is a serious problem that needs fixing, but this won't be narachi, codered, etc. I'll bet you we have a fix in less than 2 weeks available for download via the system update command. (probably less)

Lee

Harsh, but not incorrect

[MSG]

"Max" was definitely harsh, but he's not entirely out of line. cd9660.util *is* a SUID binary, and one would expect educated developers to take that into account and carefully validate any and all input. It's just what you *do* in a SUID program.

This type of attack is nothing new, and this vulnerability may be an indication that security isn't being taken seriously.

So... Darwin users/developers. Does this problem affect the open source Darwin? Just how many SUID binaries do you find on Darwin?

Re:You aren't doing a thing for Apple's image

[steeviant]

Apple isn't "on top" of much of anything that I can think of. small/midrage servers? That's Linux-dominated. Workstations? That's Windows-dominated. I suppose they have more users than the other BSD variants, for what that's worth.

Or more users than all of the other Unix systems put together if you're talking about the desktop.

Apple sell more Unix than any other vendor in the world at the moment, so they are on top in at least one respect.

When OSX becomes popular...

[eyeball]

Unfortunately, when OSX becomes popular enough, it will become a huge security target. But it won't be security exploits that pose a problem, it will be the same problems that plague Windows today:

Just like in the Windows world, it's social engineering that causes installation and execution of quasi-legal applications like Comet Cursor and Bonsai Buddy, as well as downright unethical and illegal programs (virus and worms) that get installed when a user is told "click on the .exe to see boobies." No type of security can possibly stop that type of human behavior (being an IT I'm convinced that education, warnings, and even threats can't stop it).

Details:

[Jesrad]

The error lies in the cd9660.util_main.m file from the isoutil package, specifically, right in the start of the main function:

if ( (myError = DoVerifyArgs( argc, argv, &mnt_flag )) != 0 )
goto AllDone;

/* Build our device name (full path), should end up with something like: */
/* /dev/disk1s2 */
strcpy( &myDeviceName[0], DEVICE_PREFIX );
strcat( &myDeviceName[0], argv[2] );

The strcat function fails with the huge devicename. DoVerifyArgs should check the length of argv[2] to be under 255 characters, but it only checks if it is longer than 2 characters:

/* Make sure device (argv[2]) is something reasonable */
myDeviceLength = strlen( argv[2] );
if ( myDeviceLength < 2 )
{
goto ExitThisRoutine;
}

I'll make a quick fix and test it.

Re:Please explain

[You're All Wrong]

NUL is '\0' the byte valued 0.

C uses '\0' to delimit strings. Therefore a strcat will not go past the first '\0' in the shellcode (or whatever exploit it is you're trying to run).

So, if the code you want to run needs '\0's in it it must build those values on the fly. (e.g. subtract any value from itself and you instantly have a register loaded with 4 zeroes.) If you need opcodes that have 0 somewhere in them, then you need to self-modify, or you need to find a way to write what you want without using such opcodes. Most people go for the former.

That's all there is to being NUL-less. It's easy on x86, but slightly more challenging on fixed-length opcode machines (RISCs and VLIWs). Similarly, avoiding just '\0' is pretty easy - the real skill is from avoiding anything but [a-zA-Z0-9] such that you can pass some input sanitisers. (See posts by Herbert Kleebauer on alt.lang.asm for examples of ascii-only executables (one was called 'beth.com' IIRC, google should find it).)

To calculate the jump, just work out which of the 512 'A's are the 4 that you can see in the debugger stack trace. It's easiest to work this out by not having every character in the overflowing string being the same character. That's why I suggest 'abcdef...'
If you now see the backtrace as containing 0x66676869 then you know it was one of your 'fghi's that you're now looking at. However you don't know which one yet, so try again with a different repeated string with a different length, and 'triangulate'. Or simply use a single probe with a string that doesn't repeat, such as "aaabacad....azbabbbcbd....bzcacbcccd..."
Anyway, that tells you where in the string you need to put the address that you want to jump to. The next problem is working out what that address should be. This you can get from the debugger.

Read Aleph One's "smashing the stack for fun and profit" for more info. Once you can do it on one architecture, you'll be equipped to do it pretty much on all of them.

Have fun, but remember to practice safe hex.
YAW.

Re:You aren't doing a thing for Apple's image

[geoffspear]

I wish editors would reject stories that are just blatently biased

Well, that would pretty much leave Slashdot with the Science and Ask Slashdot categories, and nothing else. Show me a fair and balanced story about SCO or RIAA.