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!
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.
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.
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.
Slashdotting to the rescue! Apple has at least a few more hours now.
Please help metamoderate.
He's a friend of SCO! Burn him!
"It is unclear why an exploit was made public before Apple resolved the problem."
no SCO news!
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.
Maybe we deserve this world ?
If you have physical access to a machine, security is compromised anyway. You can rip out the hard drive and take/modify the bits by force if you want. If the machine is locked in a box, then you can't reboot it without being root, so the exploit doesn't work and you're still safe.
Communism was just a red herring.
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.
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.
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.
The solution is documented in /etc/ttys, simply change the secure of the console to a insecure:
I.e. The lines you want to edit is/are (with sudo viconsole "/usr/libexec/getty std.9600" vt100 on insecure
console "/System/Library/CoreServices/loginwindow.app/Cont ents/MacOS/loginwindow" vt100 on insecure onoption="/usr/libexec/getty std.9600"
Given that you propably still want to be able to log in if you have to - you propably also want to do:
netinfo or other default passwd: sudo passwd root
default passwd file used during early boot stages sudo passwd -i file root
Note that in most cases you want to change both.
Dw
Once set, you cannot boot from anything but the default startup disk. Also you need to enter the root password to enter single-user. (If root is enabled.)
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.
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.
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
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.