Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

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.
This discussion has been archived. No new comments can be posted.

Mac OS X Buffer Overflow Found

Comments Filter:
  • by MarkusQ ( 450076 ) on Tuesday December 16, 2003 @01:36AM (#7732437) Journal

    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

    • by MSG ( 12810 ) on Tuesday December 16, 2003 @01:41AM (#7732456)
      The potential for exploit doesn't require you to insert a CD. It may be exploitable by command line arguments. If so, then there may be a vector for an attacker to begin privilege escalation if he can achieve access to a local account, in which case this would present a full root vulnerability to a remote user.
    • by Anonymous Coward
      [Jonathan-Dobbies-Computer:/Users/jsdobbie] guest% /System/Library/Filesystems/cd9660.fs max$ ls -la cd9660.util
      su: /System/Library/Filesystems/cd9660.fs: Permission denied.

      makes me question it's usefulness even more

      If one has physical access to the machine, it isn't secure; everyone knows this
    • by ag0ny ( 59629 ) <javi@@@lavandeira...net> on Tuesday December 16, 2003 @01:46AM (#7732481) Homepage
      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.
    • by Anonymous Coward
      -- 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. --

      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
      • Besides, most people would look for an eject button on the CD drive. The last Mac that I saw that had that was a Beige G3.

        (For the humor impaired, it's supposed to be a joke)
    • by You're All Wrong ( 573825 ) on Tuesday December 16, 2003 @07:01AM (#7733362)
      "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.
      • by Anonymous Coward
        We're talking about OS X here, not Windows. There are no script kiddies.
      • Right on. This is a classic overflow, and there is nothing magic about OS X that will make it hard to exploit.
      • by Paradox ( 13555 )
        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! :)
      • by freerangegeek ( 451133 ) on Tuesday December 16, 2003 @11:23AM (#7735539)
        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
      • by b1t r0t ( 216468 ) on Tuesday December 16, 2003 @12:03PM (#7735946)
        And the reason NUL-less shellcode is even possible under OS X is that it ignores the middle two bytes of system call instructions. (The high byte is the system call instruction, and the low byte is used for the system call number.)

        Way to go, Apple. (Actually, this probably dates back to NeXT.)

    • up to and including installing an old copy of BeOS over OSX anyway.

      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)

    by prockcore ( 543967 )
    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.
    • Re:wtf (Score:5, Insightful)

      by hype7 ( 239530 ) <u3295110NO@SPAManu.edu.au> on Tuesday December 16, 2003 @02:27AM (#7732615) Journal
      I'm always amazed at how fast Mac users will resort to MS-style tactics and excuses.


      The difference is that Apple, unlike Microsoft, provides timely patches. Not timely excuses.

      -- james
      • Re:wtf (Score:2, Insightful)

        by idontsmoke ( 651504 )
        I'm always amazed at how fast Mac users will resort to MS-style tactics and excuses.

        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.

  • by MSG ( 12810 ) on Tuesday December 16, 2003 @01:46AM (#7732479)
    "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?
    • This type of attack is nothing new, and this vulnerability may be an indication that security isn't being taken seriously.

      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
    • by brass1 ( 30288 ) <SlrwKQpLrq1FMNO@SPAMwhat.net> on Tuesday December 16, 2003 @02:56PM (#7737995) Homepage
      > 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 ]
    • What made the comment out of line was his remark that any code that did not come from the FreeBSD side of the road was of poor quality.

      -ph!nk
  • What! (Score:2, Insightful)

    by Anonymous Coward

    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.

    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)

      by pudge ( 3605 ) * <[ten.egdup] [ta] [todhsals]> on Tuesday December 16, 2003 @12:56PM (#7736490) Homepage Journal
      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.
  • by 0x0d0a ( 568518 ) on Tuesday December 16, 2003 @02:47AM (#7732665) Journal
    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.
    • by steeviant ( 677315 ) on Tuesday December 16, 2003 @03:53AM (#7732869)
      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.
    • Blind, stupid fanaticism doesn't do anything to help Apple -- it just means that people ignore Mac fans.

      "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
    • 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

      • You've got me, I'm definitely biased. I think Apple is the greatest thing since sliced bread.

        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,
    • by macdaddy ( 38372 ) on Tuesday December 16, 2003 @12:47PM (#7736401) Homepage Journal
      "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."

      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:

      Derived from the Openstep Workspace Manager filesystem utility programs.

      "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.

    • by geoffspear ( 692508 ) on Tuesday December 16, 2003 @01:33PM (#7736971) Homepage
      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.

      • That's all we need here, is an increase in Ask Slashdots. "Dead Slashdot, I need to plug in Christmas lights but the plug won't reach and I don't want to use a wireless device nor would I like to use an extension cord. Help me please."
    • by One Louder ( 595430 ) on Tuesday December 16, 2003 @03:01PM (#7738089)
      Apple isn't "on top" of much of anything that I can think of.
      I suspect he meant "on top" with regard to the lack of exploited security vulnerabilities. Nobody I know running MacOS X has ever had their machine actually compromised.

      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)

    by Bloodmoon1 ( 604793 ) <be@hyperion.gmail@com> on Tuesday December 16, 2003 @02:56AM (#7732683) Homepage Journal
    On OS X, about 2 of them, actually, I've seen 1 bug that COULD have posed a problem for me. Maybe I'm just not as big of a power user as I think I am, but I really fail to see how virtually any of the bugs/exploits/whatever that are found for OS X are any type of problem. Yes they need patched, but they almost don't seem worth mentioning except for the sheer novelty of it, and maybe as some sort of strange inferiority complex kick for Windows users, as a recent article [slashdot.org] seems to suggest.

    Take this one [securitytracker.com] for example, which many considered to be a "big security issue". Basically it only was a problem:
    1. On laptops.
    2. When someone had sudo running in Terminal.
    3. When the computer was put to sleep.
    4. 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.
    • Yes, most OS X security vulns are pretty low-key, certainly from a desktop point of view. But it was a slight mistrust of Apple security that made me go for vanilla BSD for our main public servers, and leave our (rather nice) XServes inaccessible behind a strong firewall. Now I feel vindicated - potential privilege escalation on a public server gives me the shivers.
  • Look, pudge.. (Score:2, Interesting)

    by molo ( 94384 )
    Pudge, you have to realize that Apple has no experience when it comes to the world of Unix security. MacOS (=9) hasn't traditionally been the target of as much scrutiny, and it doesn't have things like SUID binaries that will turn a simple bug into a security problem. Apple needs to play catchup for a while.

    -molo
    • MacOS equals nine didn't traditionally have things like multiuser security, process separation, paged memory management, or... anything. SUID binaries? In a way, they all were. Hell, you could freeze the OS just by holding the mouse button down.
    • Re:Look, pudge.. (Score:5, Informative)

      by pyrotic ( 169450 ) on Tuesday December 16, 2003 @06:36AM (#7733279) Homepage
      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.
    • Re:Look, pudge.. (Score:5, Interesting)

      by MouseR ( 3264 ) on Tuesday December 16, 2003 @09:43AM (#7734400) Homepage
      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.
    • You do realize that this was in the Open Source part of MacOS X, right?
  • by eyeball ( 17206 ) on Tuesday December 16, 2003 @04:00AM (#7732892) Journal
    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).

  • by captainkibble ( 725355 ) on Tuesday December 16, 2003 @04:00AM (#7732893) Homepage
    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!
  • It's kindergarten defensive coding: anyone with even less than half a brain does not use strcat without first being DAMN sure the destination's got enough room.

    This is a beginner's mistake, aka Microsoft Mistake.
  • I have MacOS 10.3.1 and tried cut-and-pasting his command line and got the Segmentation fault, but no root prompt. Perhaps Max is using an older version of the OS?
    • by GMontag451 ( 230904 ) on Tuesday December 16, 2003 @05:14AM (#7733093) Homepage
      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.

  • I have Mac OS X 10.2.8 (Jaguar) and I wasn't able to reproduce the behaviour described in Max's security post. It *does* throw a segmentation fault, but nothing happens afterwards. Neither it writes a core dump file, nor does it give any root privileges. Did someone with an older system try that? I can't find any confirmations that the issue exists. Thanks.
    • by Fulkkari ( 603331 ) on Tuesday December 16, 2003 @09:34AM (#7734303)
      nor does it give any root privileges

      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

      Neither it writes a core dump file

      From man core:

      NOTE


      Core dumps are disabled by default under Darwin/Mac OS X. To re-enable core dumps, a privlaged user must edit /etc/hostconfig to contain the line:

      COREDUMPS=-YES-
  • sarcasm (Score:2, Insightful)

    by zerosignull ( 604979 )
    "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 do
  • While some people waste their time ranting about Max's comment on the quality of some non-BSD parts of OS X, about whether this is a serious exploit (hint: it is) or whether it is newsworthy (it is, too), does anybody has a fix to propose besides removing the setuid bit (which, according to my quick and totally inconclusive test, serves no purpose) ?
    • does anybody has a fix to propose besides removing the setuid bit (which, according to my quick and totally inconclusive test, serves no purpose) ?

      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.

    • Seriously, I'm not sure how causing a segv in cdrom driver creates a security hole.

      Care to elaborate?
  • by 47PHA60 ( 444748 ) on Tuesday December 16, 2003 @08:46AM (#7733880) Journal
    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.
  • Details: (Score:5, Informative)

    by Jesrad ( 716567 ) on Tuesday December 16, 2003 @09:37AM (#7734334) Journal
    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 (Score:5, Informative)

      by Jesrad ( 716567 ) on Tuesday December 16, 2003 @10:00AM (#7734601) Journal
      Get the fix with source code here [namu.free.fr], 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 !
    • Re:Details: (Score:5, Insightful)

      by Arkham ( 10779 ) on Tuesday December 16, 2003 @10:36AM (#7734988)
      And THIS parent post, ladies and gentleman, is EXACTLY why open source is good, and why Apple was VERY SMART to release its Darwin source code under an open-source license.

      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)

      by nickovs ( 115935 ) on Tuesday December 16, 2003 @11:12AM (#7735415)
      I have to say thank-you for finding that, although of course now you've wasted the afternoon I just spent building a shellcode to exploit the bug :-) (With a 520 byte argument the return address is at 479 bytes through the argument!)

      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 /System/Library/Filesystems/*/*.util this is the only one that is setuid). This is fortunate because of the seond observation, which is that a cursory inspection reveals that other of these programs are also vulnerable (ufs.util needs a rather longer string but gives a segmentation fault with ufs.fs/ufs.util -p `perl -e "print 'A'x6750;"`).

      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.
      • Thank you for the info. I'll work on correcting that more thoroughly now.
      • 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.
      • I corrected this one, too. Get the fix at this place [namu.free.fr] and move the corrected binary in the right place (/System/Library/Filesystems/ufs.fs/). I included the source code obviously, but you'll need the full diskdev package (plus dependant packages) from the Apple developer.apple.com website, to build it.
    • 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

    • Wow, I never thought I'd see code like strcat(..., argv[...]); except in testing code. Very bad of whoever made this.
  • Why does it matter? (Score:2, Informative)

    by ITR81 ( 727140 )
    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.
  • by Anonymous Coward on Tuesday December 16, 2003 @02:45PM (#7737834)
    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.
  • by aminorex ( 141494 ) on Tuesday December 16, 2003 @04:22PM (#7739090) Homepage Journal
    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 MacOS X, it's a great system. But how does somewhere about last in the small server market, 3rd in the desktop, and nonexistant in the embedded or high end server or mainframe put it on top?
    • 3rd in the desktop? behind windows and what?
      • linux, don't keep up with the market these days eh? Mac is number 3 on the desktop now. Despite linux on the desktop is dead sayers.

        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.
  • About 15 years ago, I ran into a problem with strcat stomping all over my variables, and I thought, 'hunh, why didn't I use strncat instead?' And so I used strncat, and have every single time for every program I've ever written since then. And, aside from one time when I accidentally made the array size 2 instead of size 20, I haven't had that particular problem again.

    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
    • But aside from that, why in the world would anyone with half a brain use strcat when strncat is available? Really... I'm asking. Is there actually some reason?

      Or for that matter, strlcpy and strlcat [openbsd.org]? (On systems that have them. From what I know - *BSDs, OS X, and Solaris.)

You had mail, but the super-user read it, and deleted it!

Working...