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

 


Forgot your password?
Close
typodupeerror
×
Security Businesses OS X Operating Systems Apple

New Remote Root in Mac OS X 445

Posted by pudge from the batten-down-the-hatches dept.
Cysgod writes "I've released a security advisory detailing a new remote root vulnerability in Mac OS X 10.3, 10.2 and possibly earlier versions." The main thrust is that it exploits a problem in the DHCP client, to gain root access, and turning off various services can prevent attack. It is unclear why an exploit was made public before Apple resolved the problem. Apple's fix is apparently scheduled for a December release.
This discussion has been archived. No new comments can be posted.

New Remote Root in Mac OS X More

New Remote Root in Mac OS X

Comments Filter:

  • i thought i would never say this (Score:5, Funny)

    by Anonymous Coward on Wednesday November 26, 2003 @03:41PM (#7572285)

    thank goodness iam running Windows

  • Exploitability Questionable (Score:5, Informative)

    by marsipan ( 641873 ) * on Wednesday November 26, 2003 @03:41PM (#7572291) Homepage
    "In most cases, the Mac will need to be booted into the malicious environment to be exploitable by this flaw. (The netinfod process must be restarted to cause the malicious server to be inserted into the authentication source list.)"

    This definitely makes the exploit less likely...

    • Re:Exploitability Questionable (Score:4, Interesting)

      by gl4ss ( 559668 ) on Wednesday November 26, 2003 @03:49PM (#7572371) Homepage Journal
      how about public wlans? is it exploitable in a scenario like that?

      yeah i don't know if they use dhcp or what but i imagine so.

      (i don't have a laptop, thank you very much please give me one)

    • Re:Exploitability Questionable (Score:5, Funny)

      by Vandil X ( 636030 ) on Wednesday November 26, 2003 @04:55PM (#7572951)
      In most cases, the Mac will need to be booted into the malicious environment to be exploitable by this flaw.
      In the Windows world, we call this malicious environment "Internet Explorer".
    • Perhaps Someone can explain. As I understand macs dont by default go beyond the local netinfo/passwd file to authenticate unless instructed to do so. You can turn on directory access and enable authentication by ldap or remote net-info, but I dont beleive this on by default is it?

      if so this is pretty much a non-bug since it would require some idiot to both be doing remote authentication and be plugged into a dhcp network. For that matter one could just pretend to be a known authtication host and provi

    • Re:Exploitability Questionable (Score:5, Informative)

      by moof1138 ( 215921 ) on Wednesday November 26, 2003 @05:47PM (#7573343)
      Static automounts from directory services (which are what you need to exploit this) only get mounted at boot, if if certain directory services related processes get restarted that never get restarted in a normal setup, so you really need to boot a machine in a hostile environment for this to affect you. Dynamic automounts will get mouted at each login, but will not be mounted in a dangerous way.

      You can just go into Directory Access and uncheck LDAP and NetInfo to be immune to the issue even if you use DHCP. I always do this. While this guy thinks he is early in reporting this bug, rogue NetInfo servers are not a new thing (though rogue LDAP servers would be more recent). There used to be an article in NextAnswers from the late 80s about how to track them down. I always customized these settings when I first get a OS X system to avoid this very thing.

  • Default? (Score:5, Informative)

    by Phroggy ( 441 ) * <slashdot3@NOsPaM.phroggy.com> on Wednesday November 26, 2003 @03:41PM (#7572293) Homepage
    and on any network provided service, including ssh (which is turned on by default in certain versions of the affected software).

    I'm not aware that SSH was enabled by default in any version of Mac OS X.

    • Re:Default? (Score:5, Informative)

      by Darth_Foo ( 608063 ) on Wednesday November 26, 2003 @03:50PM (#7572381) Homepage
      I don't beleive it is in the client versions of OS X but it almost certainly is in OS X Server (which is also subject to the published vulnerability).

      • Re:Default? (Score:5, Informative)

        by nehril ( 115874 ) on Wednesday November 26, 2003 @04:41PM (#7572816)
        your OSX server is vulnerable only if it uses DHCP on an untrusted lan. if you're using dhcp for *servers* on an unsecured network.... well then you have more problems than this.

        the exploit as I understand is this: evil dhcp server gives you an IP addr and also an evil LDAP server, which if your mac is configured to do so, will allow the LDAP server to authenticate root level users too (besides other fun admin stuff like mount points).

        this behavior is actually useful for 'lab full of macs)' scenarios and, as I understand, has been an admin 'feature' since the NeXTStep days.

    • Re:Default? (Score:5, Informative)

      by Cysgod ( 21531 ) on Wednesday November 26, 2003 @04:33PM (#7572726) Homepage
      Hi there.

      It is important to note that having all your services turned off is *not* protection against this bug.

      The malicious LDAP server also gets to dictate your mountpoints to you. This means malicious executables can be mounted anywhere in your filesystem. Including places where they can be expected to be executed.

      A trivial exploit of this would be to replace the directory with crontabs and set up a crontab and an executable to run as root. Suddenly sshd *is* enabled.

      I'll try to answer other questions as I can. This got posted when I was horseback riding, I submitted it at 9am....

  • Call me an Apple Apologist, but.. (Score:5, Insightful)

    by grub ( 11606 ) <slashdot@grub.net> on Wednesday November 26, 2003 @03:42PM (#7572296) Homepage Journal

    OK, there's a hole. Still, when Apple (or OpenBSD) have a security hole it's newsworthy rather than just Business As Usual.. unlike other companies which promise security but can't deliver.

  • What does this mean to the average home user? (Score:4, Informative)

    by Anonymous Coward on Wednesday November 26, 2003 @03:42PM (#7572309)
    Assuming two scenarios:

    1. A home user with dialup, running no external services, with the firewall turned on.

    2. A home user with DSL/CABLE, running behind NAT. And for fun, let's add Airport. Also not running any services, firewall on.

    For the non-technical /. reader, is this vulnerability something to be seriously concerned about?

    • Re:What does this mean to the average home user? (Score:5, Insightful)

      by TheCrazyFinn ( 539383 ) on Wednesday November 26, 2003 @04:08PM (#7572526) Homepage
      Neither are vulnerable.

      The real worry is folks with an Airport card wandering around with their powerbook.

      The Exploit only works from the same subnet (As it relies on DHCP)
    • The theoretical risk if you use alot of public or unknown WAP's and can't account for how responsible/evil the owner of the WAP might be (who knows what nefarious acts those public WAP operators providing free broadband are up to...yeah, unlikely) is high as they could get root access and mount a directory with a new crontab that will start up a remote SSH daemon to access your computer with later. Hard to think someone would go through the trouble but you never know nowadays. Apple should have had a fix for this sooner or at least issued a Knowledgebase article.

      The fix is rudimentary, just go into your /Applications/Utilities folder, fire up the "Directory Access", uncheck a couple of boxes (the LDAP and NetInfo services)and you're done. Takes like 10 seconds to do, no reboot required, no other reconfiguration, no problems (under WinBlows, would have taken like 30 minutes of fruitless hunting around and a couple of reboots/patches and reconfiguration afterwards probably). Well, it would have taken 10 seconds if I hadn't already had these two services unchecked b/c some at www.OSXHints.com suggested that disabling unused directory services sped up your startup a little bit.

      If you need configuration information from a LDAP or NetInfo server (ie. at work), you could always create a new Location under your Network system preferences panel and go back to Directory Access, disable the relevant LDAP and NetInfo services on all your other locations except your work location. If you can't trust your work not to try to hack your computer with this exploit, you've got bigger fish to fry.

      For most home/SOHO users who are behind their own home router/firewalls and have otherwise trustworthy family members/roomates/co-inhibitants, this is a non issue (then again, if the people who live with you are trying to hack you are living with you, you have another far greater problems to deal with than this exploit : ). People on a shared subnet (like Cable Modem users) at risk if you're not behind a local/home hardware router/gateway device and someone else on your subnet wants to play "Hack the neighbor's Mac" with this exploit. I think you should be able to trust the DHCP information being handed to you by your DSL provider (again, if you can't then your problems go WAAAAAY beyond this exploit), no big deal. Correct me if I'm wrong but, I'm pretty sure my off the shelf LinkSys router doesn't know what to do with LDAP or NetInfo configuration info handed down by my ISP even if they did hand out any, and it certainly isn't set to pass it through to my internal subnet.

      But then again, what are you thinking NOT being behind at least a inexpensive (they're what, like under $100 now even with 802.11g?) NAT/SPI firewall that's up and running 24/7 regardless of how your computer is configured if you're on Cable Modem or DSL at home?

      In short, a easy fix and not really a problem for most home/SOHO users. You can breath easy now.

      DaveC

  • The Reason the exploit was made public.. (Score:5, Insightful)

    by Smitty825 ( 114634 ) on Wednesday November 26, 2003 @03:42PM (#7572310) Homepage Journal
    The exploit was made public before the official fix is that Apple had 48 days to fix the issue. Also, by releasing information about the exploit, Apple Sysadmins can make a minor change to their setup to prevent this exploit from occuring...

    Just because the exploit isn't public, doesn't mean that somebody else doesn't know!
    • also there's this timeline of events, which is quite revealing:

      History of this Advisory & Vendor Contact Log
      2003-10-09 Initial version of this advisory
      2003-10-09 Apple Computer notified
      2003-10-09 Apple Computer confirmed receipt and forwarded to eng. team
      2003-10-11 Minor edits, also added "Philosophical Issues" and "Path to Root"
      2003-10-14 Apple Computer assigns specific point of contact
      2003-10-14 Requested confirmation of issue with Apple Computer
      2003-10-15 Apple Computer confirms issue
      (2003-10-24 Original deadline given to Apple for acknowledging issue)
      (2003-10-24 Mac OS X 10.3 is released with this known issue)
      (2003-10-28 Mac OS X 10.3 Security Update released, does not address issue)
      2003-10-28 Requested update of fix status from Apple Computer
      2003-10-28 Apple Computer proposes Nov. 3 fix date
      2003-10-29 Apple Computer reneges on Nov. 3 date
      2003-10-29 Requested fix in "2 or 3 weeks" from Apple Computer
      (2003-11-04 Mac OS X 10.3 Security Update released, does not address issue)
      (2003-11-15 Mac OS X 10.3.1 is released with this known issue)
      2003-11-17 Requested update of fix status from Apple Computer
      2003-11-18 Requested update of fix status from Apple Computer
      (2003-11-19 Mac OS X 10.3.1 Security Update released, does not address issue)
      2003-11-19 Apple Computer replies "scheduled to go out in December's update"
      2003-11-19 Deadline of Nov. 26 given to Apple Computer
      2003-11-25 Minor edits, made "Path to Root" a little more work for the script kiddies
      2003-11-26 Advisory issued (48 days after initial vendor notification)

      • Re:The Reason the exploit was made public.. (Score:5, Insightful)

        by GigsVT ( 208848 ) on Wednesday November 26, 2003 @03:53PM (#7572411) Journal
        I do agree that's plenty of time, but it's still questionable to release the exploit at this stage. He could have disclosed, and then if Apple downplayed it saying it wasn't exploitable, then released the exploit.

      • Re:The Reason the exploit was made public.. (Score:5, Insightful)

        by Greedo ( 304385 ) on Wednesday November 26, 2003 @04:24PM (#7572649) Homepage Journal
        I have to say, I looked down that timeline as well and thought "Well, at least Apple is looking into the problem and has given a timeframe for an update (December)."

        Then, 5 days before December, they release the advisory.

        I don't think it's unreasonable for Apple to take some time confirming the exploit, and planning an update. Remember when they released an update that broke things?

        I *do* think it's unreasonable for Carrel to demand deadlines to Apple ... or anyone, really ... to fix their stuff. Especially when Carrel knows it's going to be fixed. Not much better than blackmail, if you ask me.

        • Re:The Reason the exploit was made public.. (Score:4, Insightful)

          by ZxCv ( 6138 ) * on Wednesday November 26, 2003 @04:34PM (#7572735) Homepage
          I don't think it's unreasonable for Apple to take some time confirming the exploit, and planning an update. Remember when they released an update that broke things?

          This exploit would take any qualified engineer at Apple less than a day to confirm, and it is serious enough that it shouldn't have to wait for a 10.x.z update to be fixed (and, in fact, 10.3 and 10.3.1, as well as in independent security update have all been released since Apple was notified of this issue). Any way that the entire system can be compromised remotely should be fixed immediately. Apple has released a few security updates that were completely independent of a whole system update, and they should have done exactly that in this case.

          I love OS X, but this is completely unacceptable. I'm just glad my Macs don't use dhcp.

          • Re:The Reason the exploit was made public.. (Score:5, Interesting)

            by burns210 ( 572621 ) <maburns@gmail.com> on Wednesday November 26, 2003 @05:25PM (#7573171) Homepage Journal
            but ssh and all services are turned off by default, so even if you get an IP from a malicious DHCP server, and they use the exploit, they can't login remotely to do anything. So unless the services have been turned on by the user, the security whole is, to an extent, moot. and should be fixed, but not panicked about.

          • Re:The Reason the exploit was made public.. (Score:5, Interesting)

            by valmont ( 3573 ) on Wednesday November 26, 2003 @07:32PM (#7574045) Homepage Journal

            The mere fact that it should be fixed immediately does not at all mean that Apple MUST just quickly hack something together and just release it to the public.

            Guess what, in theory, all computers SHOULD IMMEDIATELY be secure out of the box and never ever require any patch. But this is real life. not utopia.

            I have yet to see a tested, reliable proposed patch for this vulnerability at the open-source darwin resources. My guess is it is far from being a trivial fix, and chances are Apple wants to thoroughly test it before releasing it.

            All Carrel is doing is demanding a deadline that was different from what Apple told him. He could have very-well just waited another month before releasing his advisory. Chances of someone else finding out about it on their own *and* managing to slither their way onto vulnerable subnets, write and execute an exploit, all this within, say, at most 30 days from the day this story popped-up and the latest possible day in december, are fucking slim to none. It is also NOT like this vulnerability would allow a script writer to write a worm that could quickly spread to the internet. Sure, entire subnets could be affected at a time, but the exploit would remain WITHIN the subnet, spreading it out to other networks would require sending email viruses or other stupid PEBKAC-based annoyances. Oh and the victim machine has to be initiating a dhcp request for it to get owned, which typically only happens at boot/startup time, or connection/disconnection. I can see laptop on large corporate networks being vulnerable, but again, a malicious machine would have to make its way INSIDE the network: it needs to live within 802.11b/g range and/or local hub. The offending machine could very easily be traced and its owner hung by the balls.

            Yes Apple reneged on their original deadline, chances are they had good reason and were trying to address that botched 10.2.8 release to have a stable base system to release another security patch on. As long as they communicate timeline information back to him, they clearly are NOT giving him the run-around. December is not unreasonable provided what we get is a stable, reliable fix. Confirming a vulnerability can be a far fucking cry from having a successful patch implemented and released, if the fix for the vulnerability is not trivial. For example, a mere buffer-overflow vulnerability in a piece of C code is typically a trivial fix. Revamping DHCP is not necessarily.

            Does Carrel's advisory offer a code fix to the Darwin Core? NO it doesn't. Has the potential issue of rogue evil Netinfo servers been around for a while? YES IT HAS.

            Some geeks should consider getting laid [fleshlight.com] once in a while and resist the amazing trepidations of unleashing a juicy piece of information that'll quench a lifetime's worth karma-whoring lust.

    • "Smitty"...damn, that sounds familiar from the far, far reaches of memory. Google doesn't turn anything up, but did you do an interview with a journalist as a security expert years ago in which you discussed packet sniffing on the Macintosh?

  • Watch out Bill (Score:3, Funny)

    by bodin ( 2097 ) on Wednesday November 26, 2003 @03:43PM (#7572313) Homepage
    Apple are about to catch up on Microsoft!

  • Damn (Score:5, Insightful)

    by JHromadka ( 88188 ) on Wednesday November 26, 2003 @03:44PM (#7572318) Homepage
    It seems pretty irresponsible to release details on an exploit when the vendor has already acknowledged the issue and has a date planned on when to release the fix. Now if Apple was ignoring them, that would have been a different story.

    • Re:Damn (Score:3, Insightful)

      by MrPink2U ( 633607 )

      It seems pretty irresponsible not to release a timely patch to a know root exploit. Would you people please make up your minds on the standards by which you judge a software company.

  • Making rounds (Score:4, Interesting)

    by somethinghollow ( 530478 ) on Wednesday November 26, 2003 @03:45PM (#7572325) Homepage Journal
    Looks like this guy is making the rounds. A more detailed post is at MacSlash [macslash.org]. The highlight of conversation there is "Root is disabled by default, and SSH is off by default. Therefore the default settings don't make you vulnerable."

    Apparently, it took 48 days from the time he informed Apple until now. Looks like he was itching to post something. There's his 15 minutes of fame.

  • What is telling (Score:4, Informative)

    by Space cowboy ( 13680 ) on Wednesday November 26, 2003 @03:45PM (#7572331) Journal
    is that this is news. Ok, it's not a vanilla BSD, but it is based on BSD, which has a fantastic record on security. What will be interesting to find out is where the bug came from - Apple or some third party ...

    I'm pretty sure it was Apple that could boast of no exploits against them (this was OS9 days). Sad to see that go, if it's true. Any unix-os is a friend of mine :-)

    Simon

  • Nothing is infallible (Score:5, Insightful)

    by Coryoth ( 254751 ) on Wednesday November 26, 2003 @03:49PM (#7572369) Homepage Journal
    So, we have yet another security hole. No surprises there - they will come up eventually. It sounds as if the patching is reasonably prompt (though next month doesn't sounds that fast - hopefully that means it is well tested and it won't break anything like MS patches can). Ultimately though, we don't see many holes for MacOS X. Yes, I'm sure they exist, but they are a lot less frequent than some.

    For instance, there's still this [theregister.co.uk] unpatched hole in IE that MS doesn't seem inclined to do much about right now. So much for their "on average a patch in 24 hours" policy they were claiming. Looks like they'll get their patch out around the same time Apple does. I guess we hope that means that they've tested it this time...

    Jedidiah

  • What is the fix? (Score:5, Insightful)

    by stefanb ( 21140 ) * on Wednesday November 26, 2003 @03:50PM (#7572383) Homepage
    I'm not sure I fully understand the problem, but it appears to me that the defaults of just accepting information from DHCP for authentication and authorization are wong; not necessarily any piece of software. (It is debateble whether the very possibility of obtaining such information from DHCP is such a bad idea that the option should not be offered at all.)

    Obviously, the fix is not quite so easy: instead of just updating a binary or two, Apple needs to devise a program/an advisory that will alert users to the problem, and that also makes sure people don't shoot themselves in the foot (turn option off, suddently you can't log in anymore).

    Devising such a thing, and testing it in a wide variety of environments will take time, so I wouldn't blame Apple for "reacting slowly" just yet.

    • Re:What is the fix? (Score:5, Informative)

      by Glock27 ( 446276 ) on Wednesday November 26, 2003 @05:19PM (#7573131)
      They're not fixes, but there are some fairly easy workarounds:

      Workarounds
      There are a variety of avenues to avoiding this vulnerability...

      1. Disable any network authorization services from obtaining settings from DHCP:

      * in Directory Access, select LDAPv3 in the Services tab, click "Configure...", uncheck "Use DHCP-supplied LDAP Server"

      * in Directory Access, select NetInfo in the Services tab, click "Configure...", uncheck "Attempt to connect using broadcast protocol" and "Attempt to connect using DHCP protocol"

      * in Directory Access, uncheck LDAPv3 and NetInfo in the Services tab, if you don't intend to use them

      2. Turning off DHCP on all interfaces on your affected Mac OS X machine can also keep you from being affected.

      For added security, be sure to disable any unused network ports:

      * turn the AirPort card off or remove it, if it is not being used.

  • Comment removed (Score:4, Interesting)

    by account_deleted ( 4530225 ) on Wednesday November 26, 2003 @03:51PM (#7572385)
    Comment removed based on user account deletion

  • Not exploitable in the default configuration, at l (Score:5, Interesting)

    by Onan ( 25162 ) on Wednesday November 26, 2003 @03:51PM (#7572386)
    Apple has essentially made the design choice to default to a system which trusts the local dhcp server. Which is problematic much of the time, but convenient if you'd like to just unbox a new shipment of macs for your lab and plug them in, without needing any further client-side config.

    This means that the dhcp server can provide authoritative information about anything ldap handles, including user accounts. So Mallory can use a rogue dhcp server to give herself a root account on your system.

    But unless I'm mistaken, the default configuration still doesn't allow her to do anything with it. sshd and afpd are turned off by default, so even having a root account doesn't get you anything unless you physically sit down at the box and log in locally.

    I think I'd prefer that the system defaulted to not trusting other hosts for anything beyond network numbers, but I don't think that issue will lead immediately to a rash of rooted osx machines.

    • Mallory can configure her LDAP server to not only give her root on you box, but also to remotely mount filesystems on your box. Mallory mounts her trojans over your bin directory and waits for you to start one, or also mounts a root crontab that starts a trojan automaticly. No your box IS running services, and Mallory owns it.

    • ... well ... what people are saying is that they could use the exploit to mount a malicious file sytem and execute some eeeveeehl piece of code that would enable sshd and afpd ... or something ....

      what boggles my mind is that this exploit is labeled as a "remote" exploit. while it is technically true, i'd like people to start qualifying the concept of "remote": an offending machine would need to live within a fairly close geographical location to exploit this vulnerability as it would need to be plugged

  • Slashdotting to the rescue! (Score:5, Funny)

    by SuperBanana ( 662181 ) on Wednesday November 26, 2003 @03:55PM (#7572435)
    It is unclear why an exploit was made public before Apple resolved the problem

    Slashdotting to the rescue! Apple has at least a few more hours now.

  • Good News? (Score:3, Insightful)

    by KrizDog ( 95871 ) on Wednesday November 26, 2003 @03:56PM (#7572441)
    Now I can finally login as root on OSX. Considering all my friends running OsX have no idea what their root password is, or for that matter what root is, this seems like a blessing.

    • Re:Good News? (Score:5, Insightful)

      by Jesrad ( 716567 ) on Wednesday November 26, 2003 @04:09PM (#7572531) Journal
      Root account is disabled by default. Apple has chosen to make the users do all administrative tasks via sudo instead, which makes sense in the case of your clueless friends.

      • Re:Good News? (Score:3, Informative)

        by debrain ( 29228 )
        Apple has chosen to make the users do all administrative tasks via sudo instead, which makes sense in the case of your clueless friends.

        You mean like:
        $ sudo bash

        What is the difference, if any, between having an enabled root account and a user account with sudo access to every command (ie. bash)?

        Cheers

        • Re:Good News? (Score:4, Insightful)

          by brianosaurus ( 48471 ) on Wednesday November 26, 2003 @05:45PM (#7573331) Homepage
          Subtle difference:

          if you log in as root, no one knows who you really are. if you "sudo bash", that command gets logged, and its still possible to determine who you really are.

          personally I try to avoid using "sudo bash", because its too easy to screw something up when you're root. but sometimes I get lazy.

  • bigger problem (Score:3, Insightful)

    by kaan ( 88626 ) on Wednesday November 26, 2003 @03:57PM (#7572447)
    Let's assume that somebody is sitting outside of my apartment with all of this wireless hijacking configured, and we'll further assume that I've got all of the exact configurations required for my machine to be vulnerable. One would presume that this person is after the data in my machine, or wants to cause problems for me. Why else would they be trying to break in and gain root access? (btw, don't I need to have enabled the root account for this person to get root access, since root is not enabled on OS X by default?)

    I might be going out on a limb here, but I would venture to say that there's a much bigger threat because the dude could just kick my door down and take my entire computer away with him. Then he can have all my data, and all of my applications, and my hardware too. Meanwhile, some other loser nerd is still mucking around trying to get this "hack" to work, but the guy who jacked me is walking away with my machine.

    I understand this security issue is a threat and all, but I just don't see why anyone should be overly concerned. People seem to come up with scary stories like this about all kinds of things, hyping the facts up to make it seem like everyone who owns a Mac today is going to have a nerd take over their machine and steal all of their stuff. It reminds me of the pains people will go to in order to "secure" their machines, but then do something completely insecure like walk away from their desk for 10 minutes without password-protecting their machine.

    • Re:bigger problem (Score:4, Insightful)

      by freeweed ( 309734 ) on Wednesday November 26, 2003 @04:06PM (#7572516)
      I might be going out on a limb here, but I would venture to say that there's a much bigger threat because the dude could just kick my door down and take my entire computer away with him.

      Person breaks into your place, steals your computer. You know about it, you can call the cops. You can also change bank account info, credit cards, passwords, or any other information you might keep on your computer (they're used for more than just porn, ya know :).

      Someone hacks in remotely, you have no clue it happened. They can do what they want, when they want, and there's absolutely nothing you can do about it.

    • Re:bigger problem (Score:3, Insightful)

      by venom600 ( 527627 )
      Have you considered the possibility that an attacker may not be interested in any of the data you have on your computer. Instead, he or she may just root it, leave a back door and come back later to use your box as a launch platform for a DOS? Who's liable then?.....you. What if the person places child pornography on your computer and joins it to a P2P network?

      I think there is a common mis-conception out there about the intentions of crackers. You don't have to have valuable data on your computer to ha

  • why? (Score:5, Funny)

    by silicongodcom ( 241132 ) on Wednesday November 26, 2003 @04:00PM (#7572473)
    "It is unclear why an exploit was made public before Apple resolved the problem."

    no SCO news!

  • Here's a mirror (Score:3, Informative)

    by EvilStein ( 414640 ) <spam@BALDWINpbp.net minus author> on Wednesday November 26, 2003 @04:06PM (#7572514)
    http://www.pbp.net/~jnichols/dhcp-vuln.html

    Link for the extra-lazy: here

  • Reason for release of info (Score:4, Insightful)

    by Todd Knarr ( 15451 ) on Wednesday November 26, 2003 @04:19PM (#7572609) Homepage

    I suspect the reason why this info was released was simple: Apple went and released the 10.3 upgrade with a known remote-root vulnerability in it after having acknowledged the existence of the vulnerability.

    To me, knowing that this vulnerability exists would be critical. I don't run a Mac, but I attach to possibly hostile networks routinely. Normally I can firewall my machine to block attacks, but I can't firewall off DHCP and still use the network. Were I using a Mac and OSX, I'd very much want to know that I needed to take immediate steps to avoid giving someone the keys to my machine just by plugging in at the local coffee house.

    Release of this information may constitute a problem for Apple, and may mean a lot of fast work for OSX users. Not releasing it, though, would mean a lot more work for OSX users who get their machines rooted, and a lot more work for the rest of us who have to fend off attacks and other crud routed through those rooted boxes.

  • Background info (Score:5, Insightful)

    by krisbrowne42 ( 549049 ) on Wednesday November 26, 2003 @04:21PM (#7572627)
    This is hardly a vulnerability, it's an ease of access feature that NeXT people have known about for almost a decade. The idea of this is, you take a computer out of the box, put it on your network, and it's working. Everything configured, users setup, etc. That should probably be shipped off by default, but I can understand the way they've done it in the past. It should also be noted that unless you've got a OS X server floating around, physical access to the network and management access to the existing DHCP server, this would be awefully hard to exploit.
    • It's quite possible to override a DHCP server, even without intending to; the request is broadcast, and if multiple machines send a response back, the first one received wins.

      I've been bitten by this myself: I have cable at home, and someone on the same subnet has (presumably) set up their NAT box backwards, so when I request a DHCP address, I get one of their internal addresses (192.168.100.x) as well as one from the ISP. Because they're on the same subnet and the ISP's DHCP server is elsewhere on the net

  • Why it was made public (Score:4, Insightful)

    by siphoncolder ( 533004 ) on Wednesday November 26, 2003 @04:23PM (#7572647) Homepage

    "It is unclear why an exploit was made public before Apple resolved the problem. Apple's fix is apparently scheduled for a December release."

    • Because I hate [company] for making software that allows this to happen, they need to be taught a lesson.
    • Because they're not releasing it quickly enough - Open Source software is superior, because it would be released ASAP, usually same day, and [company] doesn't.
    • Because I hate [company], period, they sux.

  • Bastille Linux works on Mac OS X (Score:4, Interesting)

    by jjb ( 250135 ) <jay@NoSpam.bastille-linux.org> on Wednesday November 26, 2003 @04:32PM (#7572716) Homepage
    We've got Bastille Linux [bastille-linux.org] working on OS X 10.2.x. Within a couple weeks, we'll have 10.3.x support. We could prevent exploitation of this vulnerability (on systems running sshd) by disabling network authentication systems from getting data by DHCP.

    If this is interesting to you, please join our mailing list and/or e-mail me via jay AT bastille HYPHEN linux DOT org.

  • why? (Score:3, Insightful)

    by fudgefactor7 ( 581449 ) on Wednesday November 26, 2003 @04:49PM (#7572888)
    "It is unclear why an exploit was made public before Apple resolved the problem.

    Dude this happens almost every time. It doesn't matter the vendor, if it's MS, Oracle, RedHat, or Apple...no matter. Exploit warnings always preceed the patch. It's how it is.

  • Is this a quick fix? (Score:3, Interesting)

    by braines ( 723956 ) on Wednesday November 26, 2003 @04:58PM (#7572973) Homepage Journal
    If I set Directory Access (located in the Utilities folder) to authenticate against 'local directory' rather than 'Automatic' then I am safe right? If this really is the case, could someone please make this work around explicitly clear so that all the iMac Users of the world can do it (and yes I know they don't have ssh up and running anyways but, just incase...)

  • Show-boating, grand-standing (Score:5, Insightful)

    by macdaddy ( 38372 ) on Wednesday November 26, 2003 @05:00PM (#7572985) Homepage Journal
    IMHO this guy is show-boating. It is not unreasonable for an operating system company to take a non-critical but serious bug and spend 1.5 months developing and testing a fix. How many times have we seen a vendor rush to fix something only to seriously break things by not testing the fix thoroughly? Do we really want them to break something else? This isn't a minor piece of software like an FTP server where a security hole can be fixed in a morning, tested in an afternoon, and release the next day. I contend that even a piece of software as complex as Sendmail can be fixed and tested in a small amount of time and is really a minor piece of the puzzle when you're talking about an entire operating system.

    This exploit means nothing to very little the average user simply because no remote services are enabled by default. I'm using a 10.2.8 box right this minute and I had to enable Remote Login and Personal File Sharing.

    I really don't know where to start talking when it comes to the idiocy of releasing an exploit, not just a proof of concept, prior to the vendor releasing a fix. Apple wasn't dragging their heels. The whole timeframe is under 1.5 months. It is certainly not unreasonable to expect their programmers to spend time working on a bug fix. Hell the development cycle alone is more than a month if not two. So they didn't make the November 3 date. That's less than a month from the date the bug was reported. That's no surprise. I'd hate to rush a fix out that fast too. So the 10.3 Security Update and 10.3.1 Security Updates didn't fix it. Does he not realize that they were in the pipeline for testing back at the beginning of October? They aren't going to insert another code change in the middle of testing.

    IMHO this guy is show-boating, grand-standing, and showing that he has unreasonable expectations. The security vulnerability isn't that great. It's a hole, yes. It's not nearly as serious as a security hole in IE in which ALL IE installations are affected by "default." I think this guy should seriously be flogged for releasing an exploit at the same time as the advisory. That's just plain ridiculous. IMHO that alone speaks wonders about this guy. It's idiotic acts like this that seriously make me wonder about full disclosure. Anyhow, I've said my piece. Move along.

    • "This exploit means nothing to very little the average user simply because no remote services are enabled by default. I'm using a 10.2.8 box right this minute and I had to enable Remote Login and Personal File Sharing."

      This exploit means a ton to the average user; the directory server you authenticate too can dictate what mount points you have.. allowing me to have target machines mount all sorts of interesting things. Bad, bad scene.

      As far as the timeline for releasing the vulnerability goes, it appear
      • First, the average user 1) doesn't have a directory server to authenticate to and 2) doesn't mount anything that's not connected by either USB or Firewire. The average Macintosh user doesn't have Remote Login enabled, and lots of average Macintosh users don't have Personal File Sharing enabled (neither is enabled in the installation, by default).

        As far as your understanding of the timeline goes, you should RTFA. He notified Apple, and they did respond. He is just unjustifiably impatient.

  • AUTHOR: FAQs answered (Score:5, Informative)

    by Cysgod ( 21531 ) on Wednesday November 26, 2003 @05:16PM (#7573109) Homepage
    Thought I'd field some of the more mentioned questions and misconceptions here...

    Is my machine safe if I have the root account "turned off"?
    No. The account attacking can be uid 0 and have any other name in the universe that is a valid account name.

    Is my machine safe if I have all remote access services "turned off"?
    *NO*, and please quit saying it is. This exploit allows malicious people full control of where things are mounting on your system. They can mount malware anywhere. Including places that can virtually guarantee executiong of their target code. For example, an attacker could cause their evil data to be mounted in place of crontabs and have their fake root's crontab point to an evil executable mounted there or somewhere else.

    Why did you release this when you did?
    This was an exploitable remote root vulnerability. After Apple reneged on the Nov. 3rd release date I gave them 2-3 weeks. After the 2-3 weeks were up, I asked for the status and they said "December". Meanwhile, users are left exposed and independent rediscovery seemed fairly likely. And maybe by someone less scrupulous than myself. I felt I was being strung along and that the issue may never get properly addressed so I set a hard deadline at that point. They didn't meet it, and I issued my advisory.

    It would not be fair of me to let Mac users hang out in the breeze for more than 2 months on an issue of this magnitude. You may disagree, but I have no regrets about my actions and feel that I was more than fair to Apple Computer and its users.

    (As I mentioned in a previous post, I was out horseback riding by the time /. got around to finally posting the article. Sorry it has taken me so long to respond.)

    • Re:AUTHOR: FAQs answered (Score:5, Informative)

      by Wanker ( 17907 ) * on Wednesday November 26, 2003 @07:35PM (#7574064)
      Kudos to you for handling this very responsibly. Despite the attention-grabbing comment by pudge [pudge.net], you followed the policy he linked to [wiretrip.net] quite nicely.

      It doesn't seem to me at all unclear "why an exploit was made public before Apple resolved the problem". In fact this seems very clear in what you wrote:

      After Apple reneged on the Nov. 3rd release date I gave them 2-3 weeks. After the 2-3 weeks were up, I asked for the status and they said "December". Meanwhile, users are left exposed and independent rediscovery seemed fairly likely.


      The wiretrip policy linked above is quite clear on how long to give a vendor ("maintainer") to come up with a fix:

      B. The MAINTAINER has 5 work days respond. Note that all times of work days are relative to the ORIGINATOR, not the MAINTAINER. Suggestion to the MAINTAINER: sooner is better than later--just because you have 5 days does not mean you need to take them all. The ORIGINATOR is technically free to do whatever they want to do after 5 work days--however, they should be fair and wait if the MAINTAINER shows adequate initiative to fix the ISSUE.


      This is clarified a bit on what it means to "respond" in the FAQ section:

      Q. I'm a software maintainer, and I can't possibly fix the problem in 5 days....
      A. You don't have to. If you (re)read the above, you have 5 days to establish communication. Provided you cooperate with the researcher and keep them 'in the loop', they should provide you with whatever time necessary to resolve the ISSUE (within fair reason).

      Q. I'm a software maintainer, and I want more than 5 days!
      A. Well, considering that, in general, you don't have *anything* technically, this document hopes to provide you with at least 5. Be on your best behavior, cooperate with the ORIGINATOR, and you should get more. :)


      According to policy, you would have been OK (if somewhat rude) releasing this after 5 work days from initial contact. Extending it through 48 calendar days and several patch cycles seems extraordinarily generous.

      I wouldn't feel at all bad about the timeline followed. If anything it shows remarkable restraint.

  • subnet exploit ?! (Score:4, Informative)

    by didiken ( 93521 ) on Wednesday November 26, 2003 @05:21PM (#7573142) Homepage
    Remote exploit ? Can you say subnet exploit ?! Victim gotta have DHCP and SSH turned on. So not a default client installation exploit.

    You MAY say MacOS X Server got SSH turned on so will be vulnerable, but you must enter a static IP address at the system setup, that means you've no DHCP options unless you manually change it to DHCP later at "System Preference". By the way, if you do use DHCP to hand out server IP address you deserve to get rooted.

    Anyway I get enough laugh out of some amateur security people today. Movie at 11.

  • No panic, just reconfigure (Score:5, Informative)

    by ApocryphX ( 554288 ) on Wednesday November 26, 2003 @06:19PM (#7573595)
    Just in case anybody missed it: the solution is easy!
    Just open the Directory Access tool and deselect:

    LDAPv3, NetInfo, SLP

    done!

    I.M.H.O., Apple made the same mistake as MS in this case: Enable everything in case someone might need it. And don't worry about the bad guys ......

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close