Slashdot Mirror
New Remote Root in Mac OS X
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.
Looks like this guy is making the rounds. A more detailed post is at MacSlash. 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.
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)
world was created 5 seconds before this post as it is.
..then why are we posting a link to it and making it even more public?
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.
Yeah, on a day with 5 new IE holes (most of which are the same magnitude), I'll have to agree with you.
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
You're in as root, no login required, and it even tells you how to mount local filesystems writable.
snip...
I love my Mac, but Mac OS X is not a secure OS.
All of the *BSD assume that if you have local physical access to the machine, that you should be able to reset the root password.
You can fight this by encrypting portions of your file-system - at boot time, you unlock the encrypted filessystem with a pass-phrase. If somone reboots your computer, of turns off the power - they would have to get you to unlock the file-system, and even if they set themselves up as root, they woulden't have access.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
If this is interesting to you, please join our mailing list and/or e-mail me via jay AT bastille HYPHEN linux DOT org.
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...)
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.
"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?
May we never see th
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 network, they consistently return a response faster, too.
I worked around that by configuring my DHCP client daemon to ignore all responses from the 192.168.100 subnet, but that's not an option if your DHCP client isn't configurable.
On Linux, some folks set up loopback encrypted filesystems. A loopback encrypted filesystem cannot be accessed by simply taking a hard drive.
If you can get repeated undected physical access to the machine, you can probably eventually trojan your way to root, though it might involve things as intricate as trojaning the bootloader and whatever utility you're using to decrypt the filesystem.
May we never see th
Uh, lookup how "Automatic Proxy Configuration" works before you get too relaxed. It's a "hey you untrustworty slime out on the network, do you want me to run something" sort of thing, just like this.
Not quite. Automatic proxy configuration (APC) only tells the browser to download a javascript file (admittedly, on IE, that could cause serious trouble if there is no filetype checking, etc.). And IE runs as the user, not as the operating system (unless you're logged on as the admin, of course).
APC doesn't tell the computer "here, trust this server for login names, passwords and network shares/mounts" the way Apple DHCP does.
It sounds like simple bad design by Apple.
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 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.
Extraordinary Vacations. Exceptional Prices
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.
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 to a network port plugged to some small or large hub, with machines belonging to a similar subnet. Or it would have to be a machine that lives within 802.11 b/g range, which is *also* fairly local. Both scenarios should allow a fairly educated network admin to trace the attacker and hang'em by the balls.
Extraordinary Vacations. Exceptional Prices
Give me a break. That is anything but a true statement, and one born of prejudice. Apple, Microsoft, those hardworking folks making Linux better all recognize that flaws exist in software and work hard to do something about it. Software by nature is large and complex, the product of human efforts. And as such, it will not be perfect. For all the hard work of programmers throughout the world, mistakes will happen. But companies like Apple work hard to correct them quickly. If you develop software like I do, you will understand that you can't just issue a patch and expect the problem to stop. You have to test the patch thoroughly to make sure that it does not create unintended problems of its own. To say that Apple sweeps security flaws under the rug is an insult, not only to Apple, but to any developer that has to correct the problems of an exploit. Save your venom instead for the jerks and script kiddies who are the real problem, not Apple.
Administrator can grant himself "Act as part of the operating system", and then he does have kernel level access.
The only advantage to this situation is that you may get a security log event telling you that administrator promoted himself. It doesn't provide better security.