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

Re:Ehh.. it don't work for me.

[GMontag451]

Read, comprehend, post, generally in that order.

The command line was just a demonstration of the vulnerability, not exploit code. All it was supposed to do was segfault. The attached gdb output shows that the 'A's overwrote one of the return addresses on the stack frame. That means it might be possible to jump to an arbitrary memory address and execute code, as root I might add.

Re:Look, pudge..

[pyrotic]

you have to realize that Apple has no experience when it comes to the world of Unix security.

They weren't great, but then who was back in the day.

Next were developing their unix since 1988, and Apple merged with them in 1998. Apple's current CTO is formerly of Next

A/UX, Apple's unix, ran on M68030 Macs in 1989

AIX, IBM's unix, ran on the PPC604 Newtork Servers in 1996

MK/Linux, Apple's Mach/Linux hybrid, ran on PPC Macs in 1996

MacOSX server has been going since 1999.

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.

DONE

[Jesrad]

Get the fix with source code here, just double-click the install.sh script, it will make, copy and setuid the file at the correct location. Somebody please test and review this !

Details of the fix

[Jesrad]

The change is in the DoVerifyArgs function, from:

myDeviceLength = strlen( argv[2] );
if ( myDeviceLength < 2 )
{
goto ExitThisRoutine;
}

to:

myDeviceLength = strlen( argv[2] );
// Added check for lengths of myDeviceName over 255 chars; 16/12/2003 Namu
if (( myDeviceLength < 2 ) || (myDeviceLength > 255))
{
goto ExitThisRoutine;
}

The tar.gz archive is just the same as the one from OpenDarwin, except for the fix in the code and the install.sh shell script that makes the utility, installs it under sudo, setuid's it and then cleans.

Re:Exploitable!

[Paradox]

Well, Mac machines ARE slightly harder since their instructions are aligned. You need to hit the alignment and the offset.

Is is different from the x86 variable-length world. There are 3 possible alignments.

In this scenario, it doesn't matter though, since it's a non-service.

Re:What!

[pudge]

All he said was that parts of MacOSX (sic) that didn't come from BSD were not very well written.

Because it implies anything written in Mac OS X may be written poorly, while nothing from BSD is. Note that the majority of security fixes lately in Mac OS X, that I recall, were in BSD code (esp. ssh). I'm not criticizing ssh or BSD or anyone, it's just a stupid statement for the guy to make. Fine, it's a bug, no need to attempt to impugn Apple's programmers over it. I've said similar statements about people who criticized the ssh crew's code, or abilities, when a new bug is found.

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:Harsh, but not incorrect

[brass1]

> So... Darwin users/developers. Does this problem affect the open source Darwin?

Well, for one, it made it easier for me to find the issue in the source tree: <a href="http://cvs.opendarwin.org/index.cgi/isoutil/ cd9660.util_main.m?rev=1.1.1.6&content-type=text/x -cvsweb-markup&cvsroot=apple">here</a>)

i nt main( int argc, const char *argv[] )
{
const char *myActionPtr;
int myError = FSUR_IO_SUCCESS;
char myRawDeviceName[256];
char myDeviceName[256];
int mnt_flag;

/* Verify our arguments */
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] ); <======

Now.. I personally wouldn't have used strcat in this case, strncat is your friend. One also notes DoVerifyArgs(), which does check the length of argv[2]:

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

Sigh.. to make sure it's not too short. I've seen worse, but I have also had a CS 202 prof who would fail a student for this kind of thing.

[ Three cheers for the paranoia in slash that made this post nearly impossible ]

Re:Looks low risk to me...

[Jesrad]

2 weeks ? Why wait ? Get the fix for this vulnerability, and another similar one freshly discovered, from here.