Mac OS X Buffer Overflow Found 161
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.
Looks low risk to me... (Score:5, Interesting)
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
Re:Looks low risk to me... (Score:5, Insightful)
Re:Looks low risk to me... (Score:3, Interesting)
su:
makes me question it's usefulness even more
If one has physical access to the machine, it isn't secure; everyone knows this
Re:Looks low risk to me... (Score:4, Interesting)
Re:Looks low risk to me... (Score:2, Informative)
Re:Looks low risk to me... (Score:5, Interesting)
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... (Score:1, Interesting)
There is an open firmware password utility for all firmware Macs (I.e. post-Beige, Jobs era) that will require a password to boot from a CD or anything other than the primary boot drive.
Most Mac towers have a locakble case
Re:Looks low risk to me... (Score:2, Funny)
(For the humor impaired, it's supposed to be a joke)
Re:Looks low risk to me... (Score:5, Interesting)
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... (Score:2, Funny)
Exploitable! (Score:2)
Re:Exploitable! (Score:5, Informative)
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.
Does this work on a G5? (Score:3, Interesting)
Does anyone know if these eggs fly on a G5? Here is a perfect chance to test!
Re:Looks low risk to me... (Score:5, Insightful)
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
Re:Looks low risk to me... (Score:5, Informative)
Re:Looks low risk to me... (Score:4, Informative)
Way to go, Apple. (Actually, this probably dates back to NeXT.)
Re:Please explain (Score:5, Informative)
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.
Re:Looks low risk to me... (Score:3, Informative)
Well, BeOS doesn't run on any G3/G4/G5. Only original PowerMacs (601/603/603e/604/604e).
OSX only runs on NewWorld G3s and newer, so pretty much BeOS wouldn't be a threat, there. ;)
Linux on the other hand........
wtf (Score:2, Interesting)
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.
Re:wtf (Score:5, Insightful)
The difference is that Apple, unlike Microsoft, provides timely patches. Not timely excuses.
-- james
Re:wtf (Score:2, Insightful)
The difference is that Apple, unlike Microsoft, provides timely patches. Not timely excuses.
No, the difference is the grandparent poster quoted out of context. Pudge was referring to the "entirely unfounded, sweeping statements about the general quality of Mac OS X" that 'Max' made while reporting the bug, he wasn't trying to play down the fact a bug exists.
Re: timely patches? (Score:4, Interesting)
Happy ?
Re: timely patches? (Score:2)
Harsh, but not incorrect (Score:5, Interesting)
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:Harsh, but not incorrect (Score:3, Informative)
Or possibly that these developers are delving into a new area where they don't have all the answers yet. I expect that there will be many more security issues found - it's the nature of the game when building something new or something old in a new way. It happens; you fix it and move on.
Or you take the Max alternative - burn your bridges and execute any developer and his/her family a
Re:Harsh, but not incorrect (Score:5, Informative)
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
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;
if ( (myError = DoVerifyArgs( argc, argv, &mnt_flag )) != 0 )
goto AllDone;
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]:
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:Harsh, but not incorrect (Score:3, Interesting)
Re:Harsh, but not incorrect (Score:2, Interesting)
-ph!nk
What! (Score:2, Insightful)
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 th
Re:What! (Score:5, Informative)
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.
You aren't doing a thing for Apple's image (Score:5, Insightful)
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.
Re:You aren't doing a thing for Apple's image (Score:5, Insightful)
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.
Re:You aren't doing a thing for Apple's image (Score:3, Informative)
Ever heard of...(ahem)...
Adobe Photoshop, After Effects, InDesign, Illustrator, Acrobat, Logic Audio Platinum, Digidesign Protools, Macromedia Flash, Fireworks, Dreamweaver, Freehand, Apple Final Cut Pro, DVD Studio Pro, Shake, QuarkXPress, Microsoft Word, Excel, Powerpoint, Propellerheads Reason, TC Spark, Ableton Live, Corel Painter, Avid Xpress, Symphony, Media Composer
These are programs which people use every day to get work don
Re:You aren't doing a thing for Apple's image (Score:2)
"Max" does in fact make unsubstantiated statements about the quality of the software based on a single discovery, not to mention that he does not say that he notified Apple about the problem. Way to help improve a bad situation!
Apple isn't "on top" of much of anything that I can think of.
But they are on top; they make the best desktop OS out there, far better than anything Microsoft, Linux, or the B
Re:You aren't doing a thing for Apple's image (Score:2, Interesting)
I wish editors would reject stories that are just blatently biased, or at least reserve the right to re-summarize story submissions.
You've got me, I'm definitely biased. I think Apple is the greatest thing since sliced bread.
However, on the note of editorializing, who says they don't? My submission was exactly like my post [slashdot.org] except it used the 'monkey boy dance' line rather than 'wet dreams' line. I felt it was more appropriate for a general /. crowd :-) For the record, I have also posted this to bugr
Re:You aren't doing a thing for Apple's image (Score:2)
That's not my point -- you are certainly entitled to be biased. We all are. The problem is that the &story submission*, which should be reasonably objective, is very heavy with bias. For example, I don't like Microsoft much. However, when I submitted a story about them, I kept it pretty factual and free of inflamatory content. I had plenty of nasty comments...but I stuck them down in the comments section,
Re:You aren't doing a thing for Apple's image (Score:4, Informative)
Apple didn't "churn it out." It's derived from OpenStep Workspace Manager as anyone with any relevant knowledge of OS X would know. Hell it even states in it the man page:
"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."
Why would the Slashdot folks do something so stupid? All of their articles are biased. It's that biasness that gives whiny little wish-I-knew-it-all people such as yourself a place to bitch and moan and make people think you're smart.
Your village called. They want their idiot back. Shoo. Go on now. Shoo.
Re:You aren't doing a thing for Apple's image (Score:5, Funny)
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.
Oh God No. (Score:2)
Re:You aren't doing a thing for Apple's image (Score:4, Interesting)
Certainly this makes the OS a bigger target for fanboys of other operating systems trying to be the first to "prove" that Macs are somehow equally insecure.
In All My Years... (Score:5, Insightful)
Take this one [securitytracker.com] 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.
Re:In All My Years... (Score:2)
Re:In All My Years... (Score:2)
Re:In All My Years... (Score:4, Interesting)
No. Unless your definition of "remotely exploitable" includes the words "already has a shell account on the system". My definition doesn't.
Re:In All My Years... (Score:3, Informative)
Security comes in layers. I want as many layers as possible.
Re:In All My Years... (Score:2)
Re:In All My Years... (Score:2)
Re:In All My Years... (Score:2)
Re:In All My Years... (Score:4, Insightful)
And I'm well aware, as are virtually all Mac users, that we don't have the perfect OS by any means. It has it's issues. All of them do. Just ours has fewer issues than almost all others (especially compared to our user base), is probably the easiest to use (approx. 10 years of usage, never had to even deal with device drivers) and learn, has a decent amount of software support, has 0 viruses (besides the ones that affect all Microsoft products on all platforms), and is by far and away just the nicest looking. No one ever said it was perfect. Jaguar was the same way. And it's better now in Panther. And OS X will be better still in 10.4, and then 10.5, and so on. Things are as good as they ever have been, but they can only get better from here.
On a totally unrelated note, I'm updating my post reply policy for ACs.
Look, pudge.. (Score:2, Interesting)
-molo
Re:Look, pudge.. (Score:1)
Re:Look, pudge.. (Score:5, Informative)
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.
Re:Look, pudge.. (Score:5, Interesting)
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.
Re:Look, pudge.. (Score:2)
When OSX becomes popular... (Score:5, Insightful)
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
Re:When OSX becomes popular... (Score:4, Funny)
Lucky for us Mac users, that will never happen
Re:When OSX becomes popular... (Score:4, Funny)
Installation on OSX requires password (Score:2)
It doesn't solve it completely but helps.
Re:When OSX becomes popular... (Score:3, Funny)
That's why you don't, and won't, see malware on OS X - when the machine demands a password for some shite you think is dodgy, people stop and squint; they don't just click the big button that says 'Yes! Show me boobies!'
Re:When OSX becomes popular... (Score:2)
Probably flamebait but I can't resist (Score:3, Funny)
strcat (Score:2)
This is a beginner's mistake, aka Microsoft Mistake.
Ehh.. it don't work for me. (Score:2)
Re:Ehh.. it don't work for me. (Score:5, Informative)
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.
Didn't work for me either (Score:1, Informative)
Re:Didn't work for me either (Score:4, Informative)
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:
sarcasm (Score:2, Insightful)
Fix ? (Score:2)
Re:Fix ? (Score:2)
I'm not familiar with the code, but mounting filesystems does require root access, doesn't it? So that is propably why it's set-uid. Anyway there is still quite many set-uid programs in OS X, and it would be nice to see that number somehow reduced.
Re:Fix ? (Score:2)
How is this a serious exploit? (Score:2)
Care to elaborate?
local vs remote holes, overall quality (Score:5, Insightful)
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.
Details: (Score:5, Informative)
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.
DONE (Score:5, Informative)
Details of the fix (Score:5, Informative)
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.
There's a buffer overflow even in the fix... (Score:2, Informative)
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
Re:There's a buffer overflow even in the fix... (Score:2)
In fact the code should use strncpy and not use strcat in the first place...
Re:There's a buffer overflow even in the fix... (Score:2, Insightful)
Now, strlcpy() and strlcat() are relatively new, and may not have been available when this was written, but they are certainly available in Darwin now.
Danny
Re:There's a buffer overflow even in the fix... (Score:5, Funny)
Re:Details of the fix (Score:2)
Wouldn't it be better to use sizeof() for the maximum length comparison rather than hardcoding the number?
Re:Details of the fix (Score:2)
Re:Details: (Score:5, Insightful)
Windows has a root exploit, and we are dependent on Microsoft to get around to fixing it. Thanks to Darwin, we can fix our own OSX bugs much of the time.
Re:Details: (Score:5, Interesting)
A couple of things are worth noting about this bug. Firstly, it appears that the utiliy gets run by some other setuid process so the program didn't need to be setuid in the first place (looking at the files
It might be useful if someone were to trawl through the other related utilities to see if there are any more unchecked string copies. I didn't find he source to all these utilities but the msdos_util seems to have some unchecked sprintf() calls. While these are probably not security critical because hopefully the root process that calls them can't be fooled into passing bad arguments it's still indicative of a lack of care in programming.
Re:Details: (Score:2)
Can you test it on a G5? (Score:3, Interesting)
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.
Re:Can you test it on a G5? (Score:2)
I should at this point reference "Smashing the Mac for Fun & Profit" [securiteam.com].
From a chip designer's standpoint, it probably made the logic easier.
From a correctness standpoint, these flags may eventually have meaning. The correct implementation would be to claim the inst
Re:Details: (Score:2)
Further flaws in cd9660.util (Score:2)
It seems that the cd9660.util allows you to mount your CD to any location. This means that an attacker could insert a malicious CD into the drive, umount /Volumes/CD and remount the CD eg. at /var/cron/tabs allowing the attacker to "change" system critical files or fake any directory in the filesystem. This will result in system compromise.
This cd9660.util does look a bit suspicious, and I recommend that on computers where local compromise is an issue, you could think of removing the set-uid bit until a fix
Re:Details: (Score:2)
Why does it matter? (Score:2, Informative)
Re:Why does it matter? (Score:4, Informative)
Found another flaw (Score:4, Funny)
Re:Found another flaw (Score:2)
This one has been known for a loooong time, under both "ID10T" and "PEBCAK" names.
Re:Found another flaw (Score:2)
buffer overflow != exploit (Score:3, Insightful)
exploitable defects allowing unauthorized
priviledge escalation are bugs, not all bugs
are defects which can be exploited to effect
unauthorized priviledge escalation.
on top? (Score:2)
Re:on top? (Score:2, Interesting)
Re:on top? (Score:2)
I myself would certainly rather work with MacOS X than windows, but given complete choice I'll go with linux, which gives me power that isn't yet matured in the Mac GUI and lacks the proprietary ties.
Ye gods (Score:2)
I can imagine if someone were doing a major profiling job, and strcat were 10x faster than strncat and were inside the inner loop of the b
Re:Ye gods (Score:2)
Or for that matter, strlcpy and strlcat [openbsd.org]? (On systems that have them. From what I know - *BSDs, OS X, and Solaris.)