Slashdot Mirror
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.
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)...
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
When you're on top, you make a tempting target.
I see, so you buy into the argument that MS is only targetted because it's so popular?
I'm always amazed at how fast Mac users will resort to MS-style tactics and excuses.
"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?
Huh? How do you figure this? All he said was that parts of MacOSX that didn't come from BSD were not very well written. Whoopdeedoo - any operating system of that size will be likely to have some not so great code in it. It's beyond me how you managed to interpret Max's comment as an 'unfounded, sweeping statement' about the quality of MacOSX, given that 'parts' is a rather indeterminate quantity.
Blind, stupid fanaticism doesn't do anything to help Apple -- it just means that people ignore Mac fans.
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.
I've seen *tons* of vulnerability releases about companies that contain harsh criticism of their security policies. This is not unusual. At the least, Apple screwed up on an important utility. They can take their lumps, same as everyone else does when they screw up.
When you're on top, you make a tempting target.
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.
Frankly, "Max" may be biased. I suspect that he's mostly right -- that the hammered-on and designed-by-folks-with-security-experience BSD code is more reliable than the new stuff Apple churned out. I do know that "MacDork" definitely *is* biased.
I wish editors would reject stories that are just blatently biased, or at least reserve the right to re-summarize story submissions.
May we never see th
Take this one for example, which many considered to be a "big security issue". Basically it only was a problem:
- On laptops.
- When someone had sudo running in Terminal.
- When the computer was put to sleep.
- For 10-20 SECONDS after the computer was woken up, but before the clock was updated, someone with physical access to the computer could execute code.
What a massive, gaping, goatse proportioned hole. Who knew it was a bad idea to leave your computer running sudo just laying around in Starbucks while you went to the can? And Apple still had a patch out in a week or two. And in 10.3, passwords can be required to wake the computer, further negiating this and any similar problems.Now compare that to the 50 critical security fixes needed immediately for an install of a year old Windows XP disk. And the fact that there are about a hundred different ways to execute code in Windows, either legitimate or malicious, all across the system, even in the damn web browser.
Basically what I'm getting at here is that this is newsworth simply for the fact that it really isn't. I'd be willing to bet 0 people will have any problem with this before it is patched.
And on a personal note, "Max" sounds pretty fucking stupid and ignorent. "It appears that parts of MacOSX that didn't come from BSD are not very well written and have significant security issues." Oh boy! I found a buffer overflow that will effect no one and that I probably didn't even bother to inform Apple about before hand! I'm a L337 haX0r bitches! Now if he just would have thrown in something about how Apple is beleaguered and BSD is dying, we could just chaulk up "Max" as a lucky troll.
Request: ECM unit, 1000 km fullerene cable, 1 tactical nuclear weapon. Reason: Birthday party for foreign dignitary.
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:
.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).
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
_______
2B1ASK1
Reaction to bug/vunerablity/error reports: Windows User: Ahhh crap another bug/vunerablity/error how long shall I have to wait till that gets patched Linux User: Ahhh crap another bug/vunerablity/error better get the patch Mac OS User: What bug/vunerablity/error? There have never been any bugs/vunerablities/errors in Mac OS. Mac OS bugs/vunerablities/errors are just Windows propoganda. The bugs/vunerablities/errors are throwing themselves against the city walls. We are killing them!
Warning! This post may contain a pun!
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.
"When you're on top, you make a tempting target." I beleve it was ment as a sarcastic pun. After the recent plaming from other articles sayin that mac os x would have more holes found in it 'if' it were on top. This is s prity hard to exploit bug though. "Persuming" that u can execute malitious code think of the steps you would have to go through to get to actuallly execute the buged program? If by the time you can execute command line argument's then the OS is in trouble cause ne thing can be done. It doesnt seem likely that a hacker would gain acces to your computer just to run a buggy program that "may" or "may not" give them more access to your computer. It seems to me that all the mac bug's are hard to exploit as apposed to something like blaster and it's variants. Written on Windows XP BTW. Patched and fealing safe. Hardware router u know people :)
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.
Even OpenBSD has local root exploits, and they have been fixing them for years. A local exploit could be used to load a root program that listens on the network, so you fix it.
I've seen lots of security advisories make fun of or insult the product and company in question. Big deal, a programmer skilled enough to find a buffer overflow makes fun of Steve Jobs' product. Mr. Jobs can afford a gold thread hanky to wipe his tears, but more likely it just rolls off their backs; people have been making fun of Apple for decades.
In general, it is hard to program an OS, and once it is out there, easier to poke holes in it. That is why security is difficult. Fix the problem, review your code for similar problems, fix those, move on.
No. That command wasn't meant to give you root privileges; it was just a demonstration that there *is* a buffer overflow in this program. Makes me wonder why anyone hasn't noticed/told about this earlier. There is quite many set-uid and set-gid programs in OS X (I have 79), so maybe people have been lazy finding these things. This is hoply going to change some of that.
To check your set-uid and set-gid programs, use:
find / -perm +6000 -print
From man core:
I demand the Cone of Silence!
The error lies in the cd9660.util_main.m file from the isoutil package, specifically, right in the start of the main function:
/* Build our device name (full path), should end up with something like: */
/* /dev/disk1s2 */
if ( (myError = DoVerifyArgs( argc, argv, &mnt_flag )) != 0 )
goto AllDone;
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.
Maybe we deserve this world ?
Apple has no experience when it comes to the world of Unix security.
Er... this Mac OS X that Apple has... including all of it's developers... actually are NeXT's OpenStep (and NeXTSTEP before that) and NeXT employees that built the thing in the first place. In the late 80s.
Apple's got a pretty good idea of how Unix works.
There have been exploits found in Apache before. That does not imply Apache developers don't have a clue about web servers.
So, if an exploit has been found, it's only because it wasn't found before. There has been exploits for Linux, and I'm sure there will be more, like there will be more Mac OS X exploits to be found.
It's how Apple and the Linux community handles found exploits that matters. And how MS doesn't. unfortunately.
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 !
Maybe we deserve this world ?
Apple will just post a fix for it in Jan. if they've been already told about it. They have new OS update coming this week so it could include a fix for this issue as well if it's an easy fix.
The change is in the DoVerifyArgs function, from:
// Added check for lengths of myDeviceName over 255 chars; 16/12/2003 Namu
myDeviceLength = strlen( argv[2] );
if ( myDeviceLength < 2 )
{
goto ExitThisRoutine;
}
to:
myDeviceLength = strlen( argv[2] );
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.
Maybe we deserve this world ?
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.
Slashdot. It's Not For Common Sense
I had heard some suggestions that G5s didn't allow NOPs to overwrite their null bytes with random data. It seemed that the motorolla behavior for this was a bug to begin with, since those flags are reserved for future meaning, and as such the instruction is different if they are set.
:)
Does anyone know if these eggs fly on a G5? Here is a perfect chance to test!
Slashdot. It's Not For Common Sense
Hey,
I do not have a G5, nor do I know anyone with a G5. So I cannot test this, but I've heard some of my security-friends (like the super friends, only ugly, fat, and obnoxious instead of ugly, healthy and obnoxious) that the G5's don't allow the NOP's with non-0 flags.
This is probably the proper behavior. I'm convinced that Motorolla's acceptance of these facts was a bug, not a feature.
Could you test it and find out? I'm really curious.
Slashdot. It's Not For Common Sense
argv[2] gets strcat-ted with DEVICE_PREFIX:
// Added check for lengths of myDeviceName over 255 chars; 16/12/2003 Namu
DEVICE_PREFIX = "/dev/"
strcpy( &myDeviceName[0], DEVICE_PREFIX );
strcat( &myDeviceName[0], argv[2] );
and myDeviceName is declared as a 0..255 array.
So the right check should be:
myDeviceLength > 250
Even worse, there's the following code after the strcpy-strcat couple:
strcpy( &myRawDeviceName[0], RAW_DEVICE_PREFIX );
strcat( &myRawDeviceName[0], argv[2] );
and
RAW_DEVICE_PREFIX = "/dev/r"
myDeviceLenght should not be more than 249 character long.
So the right code should be:
myDeviceLength = strlen( argv[2] );
if (( myDeviceLength < 2 ) || (myDeviceLength > 249))
{
goto ExitThisRoutine;
}
NUL is '\0' the byte valued 0.
, 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.
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
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.
Your head of state is a corrupt weasel, I hope you're happy.
I found ANOTHER security flaw in OS X. It turns out that if I leave my password laying around, someone might actually pick it up and log on under my user name when I'm not around! The security folks at Apple are not doing their job.
A buffer overflow is a bug. While all
exploitable defects allowing unauthorized
priviledge escalation are bugs, not all bugs
are defects which can be exploited to effect
unauthorized priviledge escalation.
-I like my women like I like my tea: green-
...because there is no need for a patch. Just open Directory Access and uncheck a box. If you insist for running a patch you might be able to make the process into an AppleScript.
Happy ?
Maybe we deserve this world ?
3rd in the desktop? behind windows and what?