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.
thank goodness iam running Windows
"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...
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.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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.
Trolling is a art,
Assuming two scenarios:
/. reader, is this vulnerability something to be seriously concerned about?
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
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!
Doh!
Apple are about to catch up on Microsoft!
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.
"The objective of securing the safety of Americans from crime and terror has been achieved." -- John Ashcroft
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.
It's already slow and it may get slashdotted soon, so here it is:
[blank.gif] [1]Carrel.ORG > Important Mac OS X Security Advisory
Mac OS X Security Advisory
Vulnerability:
Malicious DHCP response can grant root access
Affected Software
Mac OS X 10.3 (all versions through at least 26-Nov-2003)
Mac OS X Server 10.3 (all versions through at least 26-Nov-2003)
Mac OS X 10.2 (all versions through at least 26-Nov-2003)
Mac OS X Server 10.2 (all versions through at least 26-Nov-2003)
Probably earlier versions of Mac OS X and Mac OS X Server
Possibly developer seeded copies of future versions of Mac OS X
Abstract
A series of seemingly innocuous default settings can cause an affected
Mac OS X machine to trust a malicious machine on a network for user,
group, and volume mounting settings.
What does this mean to the average user
Anyone who can gain access to your network can gain administrator
(root) access to your computer and therefore steal your data or launch
attacks upon others as soon as you reboot your machine. System
administrators and users of affected software should read the section
"Workarounds" for immediate actions to protect their machines. It is
important to note that WEP security in 802.11b/g (AirPort/AirPort
Extreme) wireless networks is generally not sufficient to protect your
network from access by an attacker.
Vendor Patch
Apple Computer has been notified of this issue and may be working a
fix at this time. At the time of this writing, a fix is not available
from Apple.
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.
Configuration Awareness
If a user should need any of these settings turned on due to the
network and authorization system they are currently using, they should
be aware that they could fall prey to a malicious individual using the
techniques outlined in this advisory. Steps to mitigate this concern
could be as simple as manually configuring the directory server
settings on the affected machine.
Technical Details
By default, the affected versions of Mac OS X attempt to negotiate
DHCP on all available interfaces. In the event that an Airport card is
installed but there is no network nearby, they also default to
associate with any network that might appear and then use DHCP to
obtain an address. The system will also use DHCP provided fields, if
available, to connect to an LDAP or NetInfo server on the network.
The default settings in "Directory Access" on affected systems will
cause the system to place the network LDAP or NetInfo server ahead of
the local user info for any given account, and will implicitly trust
the LDAP or NetInfo server to provide correct information.
Furthermore, nothing in the system prevents a login as a user with uid
0 (zero) with any login name. For example, an LDAP or NetInfo source
with an account username "bluemeanie", uid 0, would be perfectly valid
and usable for login at the login window and on any network provided
service, includi
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
Physicists get Hadrons!
Apple is on record saying they will provide security fixes for all versions of OS X. In some cases, the press has not caught up with this fact.
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 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
Craft Beer Programming T-shirts
Yes, all we have to go on is Apple's past record of continuing to provide security fixes for previous versions of OS X and OS 9.
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.
..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.
Why should it be any different for Macs?
Slashdotting to the rescue! Apple has at least a few more hours now.
Please help metamoderate.
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.
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.
"It is unclear why an exploit was made public before Apple resolved the problem."
no SCO news!
You can "physically sit down to any Mac OS X machine and log in as root locally" by doing this:
1. Shut down machine, or power it off if you can't shut down.
2. Hold down Command-S while starting up the machine.
You're in as root, no login required, and it even tells you how to mount local filesystems writable.
You can also reset the password by booting from a Jaguar or Panther installation CD with the "C" key down, and resetting the password from the Installer menu.
I love my Mac, but Mac OS X is not a secure OS.
I've reported this bug before, and Apple sees it as a feature.
http://www.pbp.net/~jnichols/dhcp-vuln.html
Link for the extra-lazy: here
here is the clicky-link
Everybody knows in the sticks that when you get a worm in your apple it just means you are getting a little extra protein in your snack.
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.
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 is unclear why an exploit was made public before Apple resolved the problem. Apple's fix is apparently scheduled for a December release."
i'm amazed that i survived - an airbag saved my life.
Source: CNET: http://news.com.com/2100-1002-5109969.html Apple has come under fire from some in the security community who feared that it was not planning to patch the Jaguar flaws and that it would instead force people to upgrade. However, the Cupertino, Calif.-based company said it would patch the holes in earlier Mac OS X versions, as it had done in the past.
If this is interesting to you, please join our mailing list and/or e-mail me via jay AT bastille HYPHEN linux DOT org.
Set an Open Firmware password on your machine.
You will then need to enter this password to enter single user mode or boot from a CD.
Note that this still doesn't fully secure your machine unless it's physically secured, as someone can simply reset the OF password by changing the amount of RAM in the machine, then zapping the PRAM.
Makes securing a powerbook pretty much impossible, but otherwise...
i don't read slashdot anymore.
"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.
http://news.com.com/2100-1002-5109969.html
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...)
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.
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 provide bogus authentication regardless of the dhcp status.
what am I missing here. or is this thing on by default?
Some drink at the fountain of knowledge. Others just gargle.
Thought I'd field some of the more mentioned questions and misconceptions here...
/. got around to finally posting the article. Sorry it has taken me so long to respond.)
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
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.
Can you imagine what will happen when the hundreds of Macs on the Internet get hacked? No, me either.
Oh, forgot the most important one: it doesn't matter whether you've enabled sshd or not. Remember that this vulnerability allows them to control network mounts on your machine via the relevant DHCP parameters. That means that they can mount their startup directories over top of yours, and theirs have things configured to start sshd. Presto, your machine now has sshd running and ready to accept logins even if you've disabled it, because your configuration no longer applies.
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
An attacker could override arbitrary directories, if they could control the mount table. As another poster pointed out, if they mounted a network share containing a malicious script over the top of, say, /etc/cron.daily, you'd never know, and it'd execute at midnight.
/lib with a nearly-identical version, except that the standard C library (libc) contained some sort of malicious code which executed once (the first time fork() was called, say), and it'd get loaded the first time you ran any dynamically-linked program. Again, unless you habitually mess with the contents of /lib (not advisable), you'd never know - the only symptom would be a slight slowdown when starting new programs, and it could even be coded to be self-removing so it only triggered once, while quietly opening up remote access in the background.
Alternatively, if they knew your OS version, they could replace
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
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.
I've been pretty low-key about this until today, so I'm not sure what you're talking about. I'd be very interested to see links to the comments you refer to.
:-) Thanks for writing.
I may have reason to believe that the seeded copies of 10.3.2 are, in fact, still vulnerable to this bug by default. But I can't say for sure because if I did know for sure, that would mean that someone violated their NDA and that would be bad news for someone. Live in fear of Apple Legal.
It's not a real happy conundrum. I found out one week ago that Apple was planning to release in December after having previously agreed in principle to a date sometime in November. I felt that I was being strung along like a ball of yarn, but I didn't want to be unreasonable so I gave them 1 more week. They never replied and cut off all contact with me. And here we are.
And FWIW, since it's been mentioned, I'm not an Apple hater, I love my PowerBook.
I can see the reason for some of the advisory, but not the part where they tell people how to exploit it. If I were Apple, I would be furious about this. Apple told them when they would have a patch. Sure they should have given a general overview of the exploit, and how to defend against it, but to post how to do it is irresponsible.
Salient quote:
If we followed that kind of standard, then we would always be waiting for corporations to decide when they're good and ready to fix problems that put the public at risk. That is a curiously supine view of manufacturer responsibility!
And it's precisely what Microsoft says when lobbying for federal punishment for those who reveal its vulnerabilities: only the corporation shall be an arbiter of public safety where its products are concerned. It shouldn't be hard to work out why that is practically an invitation for manufacturer caprice, negligence, and laziness.
Look again at Carrel's timeline. What happened on Oct. 24? What big commercial product unveiling did Apple choose not to interrupt or cloud with acknowledgement of this untimely news about the famously iron-clad OS X?