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.

Comments

i thought i would never say this

[Anonymous Coward]

thank goodness iam running Windows

Re:i thought i would never say this

[toastmaster]

because windows never had any security issues...

Re:i thought i would never say this

[ePhil_One]

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.

Re:i thought i would never say this

[helzerr]

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

[Anonymous Coward]

thank you for moding this as funny

Re:i thought i would never say this

[wo1verin3]

NO! It's because we are safe, windows doesn't have a root user. :0

Re:i thought i would never say this

[zrk]

Uh, Administrator?

So, in the past month, that's Apple: 1, Microsoft: how many????

Re:i thought i would never say this

[RustyTaco]

Uh, lookup how "Automatic Proxy Configuration" works before you get too relaxed. It's a "hey you untrustworty slime out on the network, do you want me to run something" sort of thing, just like this. Both are on by default, which is bad. Apple is accepting account information and passwords without cross-checking, MS is running a random script an injected packet told it to run.

Bad Fruit on Apple though. Since they probably don't want to remove the automagical "Just Works" functionality I have a feeling they're change it so that it "Just Works" only for unpriliaged users and requires some statement of trust to allow prilieged users.

- RustyTaco

Re:i thought i would never say this

[Anonymous Coward]

This is not the first vulnerability to ever afflict an Apple product. Plus, Administrator is not the same as root as you don't have kernel level access.

Re:i thought i would never say this

[Anonymous Coward]

Uh, lookup how "Automatic Proxy Configuration" works before you get too relaxed. It's a "hey you untrustworty slime out on the network, do you want me to run something" sort of thing, just like this.

Not quite. Automatic proxy configuration (APC) only tells the browser to download a javascript file (admittedly, on IE, that could cause serious trouble if there is no filetype checking, etc.). And IE runs as the user, not as the operating system (unless you're logged on as the admin, of course).

APC doesn't tell the computer "here, trust this server for login names, passwords and network shares/mounts" the way Apple DHCP does.

It sounds like simple bad design by Apple.

Re:i thought i would never say this

[netsharc]

Wow, what about wild proxies that can log every http transaction you're making? They can also configure to be the https and become the man-in-the-middle. Here come the login names and passwords!

Re:i thought i would never say this

[Hoser McMoose]

Actually that brings MS and Apple even for the past month at 1 a piece (Microsoft had a buffer overrun in the Workstation service).

Ohh, and both MS and Apple have had a security vulnerbility for their browser this month on top of the OS vulnerbilities listed above.

Linux doesn't seem to have had any new security vulnerbilities announced this month, though a few security fixes are filtering through for vulnerbilities announced in October. Both WinXP and OS X also had some similar fixes for earlier bugs.

Long story short, it doesn't matter what OS you run, you WILL have security vulnerbilities. Patch your OS and use a firewall already!

Re:i thought i would never say this

[mad flyer]

And won't be the last, but fairly obscure, with no exploit yet...

"Administrator is not the same as root as you don't have kernel level access."
Ever used windows for anything else than BF1942 do you ?

Re:i thought i would never say this

[JeffTL]

Well, actually, on most Windows boxen, EVERYONE is root.

Re:i thought i would never say this

[jjhlk]

I don't understand what you meant, but Administrator does not have kernel level access, like your parent said. This is obvious when you try to kill certain processes as Administrator, but are not allowed. Of course, Administrator access is enough to still do anything you want on the computer, so the distinction is almost moot.

Re:i thought i would never say this

[Anonymous Coward]

Administrator can grant himself "Act as part of the operating system", and then he does have kernel level access.

The only advantage to this situation is that you may get a security log event telling you that administrator promoted himself. It doesn't provide better security.

Re:i thought i would never say this

[Anonymous Coward]

I think apple is planning to take a lot longer to fix it. Plus, the phrasing "future release" implies to me that the fix will have to be purchased.

Re:i thought i would never say this

[steeviant]

What an amazing idiot you are, I realize most people don't even bother to read the article for most of these articles, but even the original post states that it's intended for release in December. Perhaps you should have a look on dictionary.com at the meaning of the word release.

Given that Apple just released a paid upgrade in October, it's not even remotely likely that they'd release one in December. For all the amazing bullshit spouted by one-eyed pro-apple people, there's an equal and opposite amount spouted by anti-apple morons like you.

Re:i thought i would never say this

[Anonymous Coward]

And you're a bigger idiot if you even begin to think that the comment was said after the post was changed. Yes, the slashdork editors added that last bit in.. Now stop jerking off to Applesoft, and go jump of a skyscraper.

Re:i thought i would never say this

[Pius II.]

Administrator may not have SYSTEM level access, but he has the privilege to promote himself to it. Process Explorer, for example, promotes itself to system level access, and can subsequently kill everything. Try killing LSASS.EXE, it's fun.

Re:i thought i would never say this

[Barlo_Mung_42]

Not true. There is a difference between unix style root and ms style admin. There is only one root. There can be many admins and you can prevent other admins from accessing your files, even if you are not an admin. This is a good thing because it allows the admin to have a separation. An admin can gain access by taking ownership but this is a very overt act. They can not sneak in an look around if they don't have access. Same goes for any files run in their name BTW.

Re:i thought i would never say this

[JeffTL]

Note that I said most Windows machines. Few actually use limited accounts, and even among servers, there's probably usually only one admin account.

Re:i thought i would never say this

[JeffTL]

Sorry to doublepost, but I forgot to mention: When there ARE multiple admins on a server, there are usually so many that there's probably one with a bad password.

Re:i thought i would never say this

[neuroticia]

Actually, when there are multiple admins on a server, there are usually so many that at least one admin has enough brains to put security policies in place that disallow weak passwords.

In fact, it's the one thing drilled into your brain during MCSE training and exams. Security policies. Mandating them for everyone on the system--admin or no admin.

-Sara

Re:i thought i would never say this

[Barlo_Mung_42]

I did see that you said 'most' and I still disagree. In corporate environments especially, most people are not running as admin. They are set up as part of the user's group.
This is really just a side track though because you were originally equating the power of root (aka god of the system) to MS style admin (who is not a god). I just wanted to point out that the two are quite different.
And I think from your posts, we agree on that.

Exploitability Questionable

[marsipan]

"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

[gl4ss]

how about public wlans? is it exploitable in a scenario like that?

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

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

Re:Exploitability Questionable

[Darth Troll]

Actually someone could wreak major havok inside of a Starbucks here in NYC. A cursory glance inside of any coffee joint shows at least one or two Titanium notebooks on the wireless LAN.

I tend not to use my laptop in public spaces so I'm not affected by this.

Re:Exploitability Questionable

[Vandil X]

In most cases, the Mac will need to be booted into the malicious environment to be exploitable by this flaw.

In the Windows world, we call this malicious environment "Internet Explorer".

Re:Exploitability Questionable

[moof1138]

Static automounts from directory services (which are what you need to exploit this) only get mounted at boot, if if certain directory services related processes get restarted that never get restarted in a normal setup, so you really need to boot a machine in a hostile environment for this to affect you. Dynamic automounts will get mouted at each login, but will not be mounted in a dangerous way.

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

Re:Exploitability Questionable

[Anonymous Coward]

Im looking at my Directory services utility. I see a list of services notably two are checked: active directory BSD flat Files and NIS notably net info and ldap are unchecked. I'm not quite sure what active directory is but I assume from the name its some windows perversion of ldap over the network and that I dont want it on by default. so that leaves NIS. is that a network based authentication. if so then there's no way to turn it off and leave the DSD flat files on. any tips?

Re:Exploitability Questionable

[Anonymous Coward]

Are LDAP and NetInfo enabled by default?

Re:Exploitability Questionable

[Anonymous Coward]

LDAP service is running on OS X by default. NetInfo service is not.

I imagine NetInfo is always on with OS X Server. But that's just a guess.

Re:Exploitability Questionable

[neillewis]

I found it quite disturbing when Mail on my new Powerbook started auto-filling account names from my SuSE box when I was addressing emails. Sometimes ease of use is just too opaque.

Re:Exploitability Questionable

[Anonymous Coward]

Ha, you people are all ignorant.

If you were a Mac person, you would know that Mac people never shut their laptops down, only put them to sleep. Why go though a slow boot on your iBook when it wakes up as soon as the lid is up?

As many moderated up quotes from the article tell us, this problem is only a problem when the services are started, which is on boot. Which is not on wake-from-sleep.

I do not mean to trivialize this hole. To me, it seems obvious why it is there. Apple wants LDAP-enabled, OSX Server managed networks to work out of the box. This includes the ability to mount shares anywhere on the client system, which is insanely powerful and useful in a trusted setup.

Trusted is, of course, the operative term there. Apple needs to fix this or disable the services by default. People who need it can enable it themselves.

Re:Exploitability Questionable

[sharkey]

In the Windows world, we call this malicious environment "Internet Explorer".

Actually, it's just called "explorer". Go ahead and check, I bet you've got this malware running on your Windows PC right now.

Re:Exploitability Questionable

[tgibbs]

NetInfo is the standard method used with OSX Server to associate a user with a home folder on a server. However, one does not necessarily have to use DHCP to locate the server. It is also possible to specify a particular server by IP address.

Re:Exploitability Questionable

[bash_jeremy]

I just checked in Directory Access (OS X 10.3.1) and NetInfo is unchecked, buy LDAP is not.

Re:Exploitability Questionable

[Anonymous Coward]

If you don't know what NIS is you almost certainly don't need it. It is a network authentication and name resolution database, like netinfo but even suckier. It is a god forsaken Sunism which nobody should have to contend with.

Re:Exploitability Questionable

[gl4ss]

i asked if it is exploitable in such a scenario and nobody is denying? so it is an issue.

and mac people DO as well boot their machines occasionally(for unpredictable reasons, like finder fucking up ftp?), though it doesn't take that long to do even that.

Re:Exploitability Questionable

[thoughtcrime]

Actually with Panther, my machine boots fast now in addition to also waking up fast. Though sometimes Civ 3 crashes if I've put it to sleep mid-turn.

Re:Exploitability Questionable

[steeviant]

The fire in the firewire wire burns up all the evil before it can reach your computer.

Whereas, all the evil in the universe gets to eat a hearty breakfast that will help keep them regular, on the bus ride to your CPU when you use the other one.

Hope that clears things up.

Default?

[Phroggy]

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?

[Darth_Foo]

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?

[Anonymous Coward]

Ummm...yeah it is. Dumbass.

Re:Default?

[Cysgod]

Hi there.

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

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

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

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

Re:Default?

[dcocos]

and most servers aren't going to be using DHCP

Re:Default?

[nehril]

your OSX server is vulnerable only if it uses DHCP on an untrusted lan. if you're using dhcp for *servers* on an unsecured network.... well then you have more problems than this.

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

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

Re:Default?

[IM6100]

Security holes are often 'features' of a sort.

The swiss-cheese security of default Linux five years ago is what got me involved in home networking. Back in the day you could just throw samba on an old Slackware box and do cool things out-of-the-box with Windows 95, WFW, and even LanMan client systems. There were loose 'default on' Sendmail configs on out-of-the-box Linux distros.

In one sense this taught 'lazy admin' habits and a resulting lack of security, in another sense, things just worked without a lot of the hairpulling these days. Linux tightened up, Microsoft tightened up (to deliberately break Samba, some claim), and things got 'better' but truth be told, it's not as welcoming to a beginner messing around on an isolated home subnet anymore.

I used to do amazing geek-out things with older hardware (back when a skinflint geek couldn't afford to have five or six 386 or better boxes around running Linux) like the time I had a boot floppy with just DOS and the MS Lanman TCP/IP client on it for a floppy-only system, that mounted a Samba share 'C:' drive that I was able to then install Windows 3.1 on without the Windows Software ever knowing it was a network drive. You know, cool things that bored geeks do with junk hardware. It was an 8 MHz 286 system, what can I say?

Last time I tried to casually just install Samba by building from the NetBSD pkgsrc system, it was a big mess and I've not bothered to get it to work.

Re:Default?

[Anonymous Coward]

> was able to then install Windows 3.1 on without the Windows Software ever knowing it was a network drive

Not so amazing. Running applications off a file server with a "dickless workstation" was a pretty standard configuration when Win3 shipped. Problem is that it doesn't work so well (swap file, shared config files).

Re:Default?

[bash_jeremy]

Nope, that's incorrect. When you're setting up the server, you specifically have to say that you want it on. It's not on by default.

Re:Default?

[Anonymous Coward]

I'm curious to know if your "dickless workstation" was intentional or just a typo (freudian?). Sadly, it is now 5 days later, and the world will likely never know.

Call me an Apple Apologist, but..

[grub]

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

[Anonymous Coward]

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

Re:Call me an Apple Apologist, but..

[FredFnord]

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

[freeweed]

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

Re:Call me an Apple Apologist, but..

[Evil Adrian]

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

[Anonymous Coward]

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

[feepness]

You are an Apple Apologist.

Re:Call me an Apple Apologist, but..

[Maserati]

Funny, I just installed the latest Omega drivers for my Ti4600. During the install process, ZoneAlarm said that ScriptingHost 6.0 (maybe VisBasic 6, not 100% sure) wanted to access the Internet. I'm glad I didn't let it.

I'm also glad that the only machine at the office that ever has remote login turned on is on a static IP address and isn't running dhcpd at all (and it doesn't have it turned on now anyway). And we aren't using directory services on the desktop for any authentication at all, so even the DHCP machines shouldn't be at all vulnerable. Having an email out to the group as soon as I'm back from vaaction will be a nice feather in my cap.

Incidentally, a fresh install of 10.3 does have some of these services turned on by default, and they aren't really necessary unless you have a specific reason for them - corporate IT environments for example. This is usually a Microsoft boobo, Apple usually leaves things off - remote login for one - by default. And hasn't ever done anything like share your C$ automatically.

Re:Call me an Apple Apologist, but..

[HeghmoH]

Which category is it in if they can take over the machine, but only if they're on the same unswitched subnet, only if things are set up just so, and only if they're very lucky?

Re:Call me an Apple Apologist, but..

[bunhed]

It's true. Even if you are sitting at the machine, you don't have complete access to a windows box. The only way to get complete access is with a virus. Now that IS security.

Re:Call me an Apple Apologist, but..

[maniac1860]

Let's be serious. A bug in active script that "may allow access to a users files" is no where near the same magnitude of a remote root exploit.

Re:Call me an Apple Apologist, but..

[DeltaSigma]

Seriously, Liu Die Yu has once again torn IE a new one. He's a very talented vulnerability researcher. I wish I had the money to help him get a computer, but I don't.

People can donate via paypal here, if they want.

He's very good, very responsible. Doesn't bash on Microsoft in his reports. It all appears to be acedemic with him. Help him out if you can.

Re:Call me an Apple Apologist, but..

[Anonymous Coward]

Can't you read? He told you to call him an Apple apologist, not a whore.

Re:Call me an Apple Apologist, but..

[freeweed]

Sorry, I linked to the wrong page.

Yu said the redirection feature could also be exploited to download and execute a malicious file on a user's system.

You're right, it needs the browser to work. Still pretty damn close to a remote root exploit, in a Windows environment anyway. Visit a malicious webpage, and bang! you're rooted.

Re:Call me an Apple Apologist, but..

[Anonymous Coward]

what, the, hell, are, you, talking, about?

Re:Call me an Apple Apologist, but..

[destroyingworld]

mmm...
I <3 mozilla firebird 0.7.

Tabbed Browsing, a fraction of the exploits of IE, and just as fast. Not to mention it is open source

Re:Call me an Apple Apologist, but..

[ScottKin]

Hmmmm...

*NIX root = ring[0]

Windows Admin != ring[0]

Ergo, Windows exploits that give someone Admin rights on Windows boxen will *never* enable kernel-level access - whereas *NIX root exploits will *ALWAYS* enable "Open Source" access to the kernel and all kernel-level processes.

Do the math, moron.

ScottKin

Re:Call me an Apple Apologist, but..

[IM6100]

You only have to root a box once if you know what you're doing. Then it's yours forever, or until the next OS install, anyway. So don't pooh-pooh 'only if they're very lucky'. This sounds like 'cool stuff' for University computer labs and bored students with 'cracker' tendencies.

Re:Call me an Apple Apologist, but..

[Bob Davis, Retired]

In all seriousness, this is the SAME as a remote root exploit. Users run Windows NT+ as Administrator. If access is allowed to their (remember, they are the Administrator) files, magical Root exploits could happen.

Re:Call me an Apple Apologist, but..

[Anonymous Coward]

It is my understanding that Apple gets these problems fairly often. Just look at Apple's "updates". Most of them fix buffer overflows.

OpenBSD is not relevant. Mac OS X is not OpenBSD. It has parts of FreeBSD, but it is not FreeBSD either. Mac OS X is, first and foremost, its own thing.

Before I get some twat replying, trying to tell me it's FreeBSD, pointing at all the FreeBSD code in Mac OS X, etc., let me point out in advance that said twat should research a few things. First look at the parts of FreeBSD that are in Mac OS X. Then research NeXT. You will find that FreeBSD is merely used to provide a foundation for NeXT libraries. Then look at the Darwin kernel. You may notice that it is not Unixy at all. Then look at the source code of some Mac OS X program. Then maybe look at a Unix program. And try and tell me Mac OS X is FreeBSD.

</tirade>

Re:Call me an Apple Apologist, but..

[mr100percent]

Oh come on, 100+ software releases by Apple in the past few years and you say that two cases, on a non-standard setup (yeah, i know, 2 hard drives), is grounds to be suspicious of all Apple software. Give me a break.

Re:Call me an Apple Apologist, but..

[Anonymous Coward]

root != ring[0]

Programs runned as root do not run with the CPU in kernel mode if this is what you are assuming. It makes a big difference if you are trying to execute a CPU privilege instruction.

Though, I do agree that root has full access to the file system and may have access to the kernel memory via some /proc file, though not sure of that last point. Also, root access means that you can install a new kernel with your own system calls to play with kernel stuff.

Re:Call me an Apple Apologist, but..

[anthonyrcalgary]

Remote root. Period.

Re:Call me an Apple Apologist, but..

[Evil Adrian]

Oooh, you have a low user number! You get to call me a moron while you point out semantic differences!

Hey, can I watch you using FrontPage to generate the rest of your shitty, unoriginal website over the ScottCam?

Re:Call me an Apple Apologist, but..

[stux]

Hehe, that's not a low user number ;)

Re:Call me an Apple Apologist, but..

[steeviant]

Heh, remember two worms in quick succession got the entire world riled enough to mumble bad words and consider switching away from Microsoft for a few days.

It's right to be suspicious of all Apple software -it's right to be suspicious of everything you didn't write yourself, and downright paranoid about stuff you did write yourself. :)

If Apple's security and QA stumbles of late have got people thinking about these issues then that's a Good Thing(TM).

Clearly, I *AM* an Apple apologist, but I know nobody and nothing is perfect.

Re:Call me an Apple Apologist, but..

[Anonymous Coward]

> but only if they're on the same unswitched subnet,
Wrong. DHCP discovery packets are broadcast and pass through
switches; in fact, they even pass through appropriately-configured
routers.

> only if things are set up just so,
Wrong. This exploits a hole in the default configuration.

> and only if they're very lucky?
No luck required. It's a simple race condition, so all that's needed
is to slow down the DHCP server that would respond (piece of cake -
since you're on the network, you can suck up all the leases, or hammer
it with discover packets) so that your packet can beat it.

Jeez, I can't get over you Apple zealots. Go ahead and discount the
issue, but don't spread lies to make it seem less serious.

Re:Call me an Apple Apologist, but..

[HeghmoH]

> but only if they're on the same unswitched subnet,
Wrong. DHCP discovery packets are broadcast and pass through
switches; in fact, they even pass through appropriately-configured
routers.

You're right, my bad. I shouldn't have said 'unswitched'. But you still have to be on the same subnet, or at least on a network where DHCP packets from the target machine can be recieved and sent.

> only if things are set up just so,
Wrong. This exploits a hole in the default configuration.

No, that's not correct. It is true that you can set up a root account on the machine with the default configuration, but then you can't actually do anything with that account, because ssh is not turned on by default, nor is any other service you could use. You either need physical access to the machine or a service like ssh turned on. Either one counts as "set up just so".

> and only if they're very lucky?
No luck required. It's a simple race condition, so all that's needed
is to slow down the DHCP server that would respond (piece of cake -
since you're on the network, you can suck up all the leases, or hammer
it with discover packets) so that your packet can beat it.

You need luck. First you need to be in a position to grab and resond to the DHCP requests. Second, you need to have access to the target machine, either via ssh or physically. Third, you have to actually be there and ready when the machine does a DHCP request, which isn't all that often.

You could probably compromise a machine or two in a lab full of Macs, since the combination of machines will be sending DHCP lease renewal requests reasonably often. Then you get to hunt through the room and figure out which machine you got root on. And somehow this has to make more sense than just showing up with an OS install CD and using that to reset the administrator password.

No, you do need luck.

Jeez, I can't get over you Apple zealots. Go ahead and discount the
issue, but don't spread lies to make it seem less serious.


Yeah, it's not like the same thing ever happens with Linux fans whenever a Linux vulnerability comes out, or with Windows fans (if we have any on slashdot...) when Windows vulnerabilities show up. The fact of the matter is that for most users, this vulnerability is impossible to exploit. In the cases where you can exploit the vulnerability, most of the time you'll have physical access to the machine and you will therefore have easier ways to gain unauthorized root. Not to say that this isn't a problem, it is, but it's not an enormous problem.

Re:Call me an Apple Apologist, but..

[Anonymous Coward]

Sha na na na, sha na na na na,
Sha na na na, sha na na na na,
Sha na na na, sha na na na na,
Sha na na na, sha na na na na,
Yip yip yip yip yip yip yip yip
Mum mum mum mum mum mum
Get a job
Sha na na na, sha na na na na
Every morning about this time
she get me out of my bed
a-crying get a job.
After breakfast, everyday,
she throws the want ads right my way
And never fails to say,
Get a job
Sha na na na, sha na na na na
Sha na na na, sha na na na na,
Sha na na na, sha na na na na,
Sha na na na, sha na na na na,
Yip yip yip yip yip yip yip yip
Mum mum mum mum mum mum
Get a job
Sha na na na, sha na na na na
And when I get the paper
I read it through and through
And my girl never fails to say
If there is any work for me,
And when I go back to the house
I hear the woman's mouth
Preaching and a crying,
Tell me that I'm lying 'bout a job
That I never could find.
Sha na na na, sha na na na na,
Sha na na na, sha na na na na,
Sha na na na, sha na na na na,
Sha na na na, sha na na na na,
Yip yip yip yip yip yip yip yip
Mum mum mum mum mum mum
Get a job
Sha na na na, sha na na na na

Re:Call me an Apple Apologist, but..

[Anonymous Coward]

If you're such a goddamn genius, how come you haven't mastered basic HTML to the point where anyone not running IE can use your friggin web site?

Not that I want to see it that bad, just curious.

What does this mean to the average home user?

[Anonymous Coward]

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?

[falcon5768]

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?

[TheCrazyFinn]

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?

[venom600]

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.

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

[Anonymous Coward]

Routers connect subnets. Routers do not forward broadcasts. If you use VLANs and have multiple logical subnets on one physical network, you still won't see broadcasts from one VLAN passed to the others.

So if you're on the same physical/logical subnet with no routing required between machines, the exploit is possible.

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

[homesteader]

Routers connect subnets. Routers do not forward broadcasts. If you use VLANs and have multiple logical subnets on one physical network, you still won't see broadcasts from one VLAN passed to the others.

So if you're on the same physical/logical subnet with no routing required between machines, the exploit is possible.

Didn't to post AC

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

[jcr]

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

If, and only if, they've also allowed incoming ssh, or a similar service.

Out of the box, Mac OS X has *no* services turned on.

-jcr

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

[HTH NE1]

But if you thought that a Mac was inherently secure (with its track record and species immunity) for administrating a LAN party....

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

[EverLurking]

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

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

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

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

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

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

DaveC

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

[IM6100]

'Every' geek who runs a Unix/Freenix has uses for ssh and is likely running it. Hell, some people see running ssh as 'security enhancing' since the classic alternative is telnet. So yes, there are probably people who like to be able to 'reach into' their Powerbook from their desktop from time to time for various tasks, who have the ssh daemon enabled. Likely there are a bunch of them.

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

[jmcneill]

So if you're on the same physical/logical subnet with no routing required between machines, the exploit is possible.

It is, however, possible for a router to forward DHCP requests to a server on a completely different subnet...

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

[Anonymous Coward]

From Apple's Knowledgebase:

http://docs.info.apple.com/article.html?artnum=3 24 78

Article ID: 32478

Created: 11/26/03

Modified: 11/26/03

Mac OS X: Directory Access Configuration In the Presence of a Malicious DHCP Response

Please note that the exploit requires the malicious DHCP server to be located on your local subnet. For typical home network configurations with a broadband (DSL or cable service) modem and a NAT (Network Address Translation) device, such as Apple's Airport, this exploit is not possible.

If there is a chance that a malicious DHCP server has been injected into your subnet or you are operating on an untrusted network there are two solutions to the potential vulnerability depending on if you are using a directory service.

No directory service: For users that do not use a directory service you can go into the Directory Access utility and uncheck the "Use DCHP-supplied LDAP Server" option (Figure 1). You are no longer susceptible to this exploit.

Directory service: If your Mac is configured to use a directory service consult with your IT administrator before changing any settings. Your IT administrator will need to change the default setting from "automatic" to "custom" search policy in the Directory Access authentication tab and specify the correct LDAP server.

The Reason the exploit was made public..

[Smitty825]

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

[abde]

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

[robochan]

"Full-Disclosure - We believe in it."

Re:The Reason the exploit was made public..

[GigsVT]

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

[TopShelf]

Why is this situation any different from new Windows exploits, which are shouted from the rooftops at the earliest opportunity?

I'm not trolling here, just genuinely wondering...

Re:The Reason the exploit was made public..

[Greedo]

I have to say, I looked down that timeline as well and thought "Well, at least Apple is looking into the problem and has given a timeframe for an update (December)."

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

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

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

Re:The Reason the exploit was made public..

[ZxCv]

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

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

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

Re:The Reason the exploit was made public..

[Anonymous Coward]

is it, now? they released what, at least 3 security updates without a fix, trailed the fix release by almost a month now by their own deadline setting (3 Nov., "2-3 weeks", now Dec., who knows the date) ... this is when MS is bashed for fixing patches within 2 weeks or so (oh well, assuming 'fixing' ideally doesn't 'unfix' other things).

48 friggin' days, man, is not unreasonable. I'd say the guy was too patient with them. all he got was "we're ... umm ... workin' on it or somethin' " and 3 security updates with nada about this problem.

looks like there's a big jam on the looooong Apple bugfixing pipeline

Re:The Reason the exploit was made public..

[Anonymous Coward]

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

Linux and MS developers have root exploits fixed within a day after they're discovered.

Re:The Reason the exploit was made public..

[druske]

If he'd waited until Apple released the fix, he wouldn't have generated any publicity for himself. Apple had already made it clear they were fixing the problem, it seems like nothing more than self-promotion to release an advisory right now. Add to that the fact that this is publicized just before a holiday (U.S. Thanksgiving) --- when sysadmins and Apple programmers might be taking some time off, but script kiddies have time to play --- and you've got the potential for some mischief. Ending the advisory with "Happy Holidays" suggests that this wasn't altogether coincidental, either.

Re:The Reason the exploit was made public..

[mkettler]

In general, I'd agree it's quite questionable to include exploit details... However, in general I don't think he was unreasonable to Apple in releasing his advisory early.

Apple was notified of the intended release 7 days ago on the 19th. There's nowhere in the log showing that apple ever replied requesting more time.

Admittedly it's speculation, because who knows if Carrel would have honored such a request, but the fact that Apple doesn't appear to ever have made one is a very shameful showing indeed.

Sorry, but if the vendor can't even respond to notices, then they can and should be considered unresponsive. Apple's history in this log of releasing incomplete fixes is extrordinarily shameful as well.

RFPolicy requires a 5-day response time between the originator and maintainer.. Carrel was quite reasonable in giving them 7 days to respond before deciding to consider them unresponsive to the issue.

48 days total time without a fix, 7 days with no response to the last notice sent... anyone home?

Re:The Reason the exploit was made public..

[arkanes]

Well, if you read rather than skim the timeline, you'll note that Apple confimed the exploit quite early on in the process. They've shipped 2 security updates since it was reported. They've missed two ship dates.

It may seem unreasonable and arrogant to demand deadlines. On the other hand, it's unreasonable and arrogant of Apple (or any company, of course) to demand that people not release exploits unless they're going to work with researchers and honor thier security responsibilites.

That said, I wouldn't have released the details in the initial advisory.

Re:The Reason the exploit was made public..

[burns210]

but ssh and all services are turned off by default, so even if you get an IP from a malicious DHCP server, and they use the exploit, they can't login remotely to do anything. So unless the services have been turned on by the user, the security whole is, to an extent, moot. and should be fixed, but not panicked about.

Re:The Reason the exploit was made public..

[0x0d0a]

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

Re:The Reason the exploit was made public..

[OECD]

I'm not trolling here, just genuinely wondering...

Oh, sure you are--only in a good way. This is why /. needs a +1 Troll modifier.

(And because it also lacks a +1 Offtopic mod, I'll answer your other question. Most people here hate Microsoft. Even the Windows users. It's just that simple.)

Re:The Reason the exploit was made public..

[valmont]

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

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

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

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

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

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

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

Re:The Reason the exploit was made public..

[valmont]

i don't know why you got modded down, i do think you do have a very valid point. that thing reeks of self-promotion and he went as far as releasing the exploit in a first advisory, which is completely unethical.

Apple clearly confirmed the vulnerability and chances are they started working on it right away but my guess is fixing the vulnerability isn't exactly a trivial patch such as mere buffer overflows in daemons. Otherwise the open-source Darwin community would have written and released a patch to the public a long-assed time ago. It looks like Apple is guna have to rethink the way DHCP hand-shaking is being handled and this needs careful thought and consideration.

Way to fucking botch some poor engineer's Thanks Giving holiday. And i can fucking relate.

Re:The Reason the exploit was made public..

[IM6100]

Yes, yes. And the Pentium division bug only had a slight and obscure error that only signifcantly impacted a few programs and a few computer users.

That doesn't mean that a lot of people, particularly Mac Zealots, didn't crow and crow and crow, and cheer on the demand that Intel replace each and every Pentium chip.

Re:The Reason the exploit was made public..

[mkoz]

In all fairness to some of these dates [specifically 10.3 for example]. I would imagine that many of these updates go GM well before the actual date of release.

In addition it would strike me that it is more important to Apple that the fix work well, than have it break lots of things... especially given the difficulty of actually doing anything with the exploit

Re:The Reason the exploit was made public..

[groomed]

You're assuming that the black hats don't already know of the exploit.

Re:The Reason the exploit was made public..

[moof1138]

The thing is is that this particular thing is a 'feature' to some sites. So if Apple releases a 'security' update that turns it off, and they are breaking some customer's configurations, and large customers at that. Because of this, there is no obvious fix. To expect Apple to release a fix in a few weeks is ridiculous on your part, and on the part of the guy who submitted this.

BTW - even if you used DHCP all you would need to do is click a few checkboxes in Directory Access to protect yourself from this issue. If Apple wrote a knowledge base article recommending people turn off unneeded directory services, that would be an adequate vendor response as far as I am concerned.

Finally, this is not like a remote hole in a service that can be exploited by any script kiddie out there on the internet. This is a hole that can only be exploited by an attacker on the same subnet as the victim, requires that the attacker be running a DHCP server that wins in a race condition against a legitimate DHCP server, and requires the victim reboot while the attacker is up on the network. Since rogue DHCP server are usually investigated pretty quickly, this is not a trivial set of conditions.

It is still theoretically exploitable, and I would recommend to all to go into Directory Access and disable any directory services they are not using (I always do), but it is not as dire a security risk as something like a root exploit in a remote service enabled by default, and people treating it like that need to think more clearly.

Re:The Reason the exploit was made public..

[Anonymous Coward]

Short memory, must have a shoooooort memory (nod to Midnight Oil).
It was the PC press and consumer advocate groups who were the driving force. Talk of court action and stuff... remember... Where do you source you allegation about Mac Zealots (nice to see that Zealots is capitalised).

Re:The Reason the exploit was made public..

[Anonymous Coward]

except that a rogue LDAP server can dictate your mount points for you and thereby inject pretty much whatever nastiness it wants to (as noted above by the reporter himself)

Re:The Reason the exploit was made public..

[anthonyrcalgary]

It's a user space problem. The kernel has nothing to do with it.

Re:The Reason the exploit was made public..

[Anonymous Coward]

Did the poster say that was a good idea either?

I think we need a new logical fallacy: argument ad slashdotem = Assuming homogenity of opinion among members of a group where none exists.

Re:The Reason the exploit was made public..

[Anonymous Coward]

if he'd waited until Apple released the fix, he wouldn't have generated any publicity for himself. Apple had already made it clear they were fixing the problem, it seems like nothing more than self-promotion to release an advisory right now.

Right. And Microsoft always fix their problems... eventually, after six months... so by the same argument we should never ever release any advisories but trust the vendors.

Apple doesn't get any free ride in this game. They had about a month to fix it, but choose not to. Tough luck.

Watch out Bill

[bodin]

Apple are about to catch up on Microsoft!

Re:Watch out Bill

[Anonymous Coward]

Actual, MS is far better than other vendors such as Apple, Red Hat, et al. Most people such as yourself are simply blinded by your hatred.

Re:Watch out Bill

[Trejkaz]

Yeah, whatever Bill. Get an account instead of posting anonymous.

Re:Watch out Bill

[sharkey]

Apple are about to catch up on Microsoft!

Yeah, right. Apple is only up to 'X', and MS is up to 'XP'.

Damn

[JHromadka]

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

[mrsev]

Not when they dont fix it!

Re:Damn

[Anonymous Coward]

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

Re:Damn

[MrPink2U]

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

[Anonymous Coward]

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

Apple is dragging their feet.

Re:Damn

[Anonymous Coward]

mod down parent as troll!

Re:Damn

[MrPink2U]

Instead, it got an "insightful".

ROFL

Re:Damn

[venom600]

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.

Re:Damn

[dema]

It's not at all irresponsible. In fact it's very responible of Apple to do its best to test and make sure the patch takes care of the problem and doesn't cause more problems. The problem isn't entirely serious anyway seeing as how both the root account and ssh are disabled OOB. So must users who don't know there way around NetInfo don't even need to be concerned.

Re:Damn

[Steve Cowan]

"Hundreds of Macs"? Um, troll much?

Anyway, somebody has to be plugged into your LAN before they can take advantage of this security hole, i.e. they must be on your subnet. If you are behind a NAT device you are safe, unless somebody can get in via wireless or by plugging in.

I'm not worried.

Re:Damn

[Anonymous Coward]

Minds are already made up, and it's very simple:

If it's Apple that does it, they are ALWAYS in the right, regardless of what/how they do things.

If it's Microsoft, they are ALWAYS in the wrong, regardless of what/how they do things.

See? Real simple and easy standard to judge a software company. Maybe not a very intelligent one, but hey, this is /.

Re:Damn

[Anonymous Coward]

"Hundreds of Macs"? Um, troll much?

Wow, you don't miss much do you?

Re:Damn

[valmont]

i agree with Dema, if this was a trivial fix such as fixing a stupid buffer overflow vulnerability in one line of C code of some daemon, then you would have a point, Apple could, and should have released a fix early.

but this is not the case.

upon reading the karma-whoring advisory it would appear that fixing this vulnerability will NOT be a trivial matter, in which case it is reasonable to expect and anticipate a reasonable amount of time to release a stable, reliable patch involving a re-think of the DHCP protocol implementation.

Re:Damn

[Anonymous Coward]

It's doubtful that a company like Apple would be ignoring this. Consider another post that listed the history of communications between the author and Apple. And consider another post that pointed out that this is not a trivial fix, not that it is not solvable (it is), but rather, it requires some solid testing to make sure that the fix does not cause other problems. If you are in software development like I am, you will understand. As it is, a rumor site pointed out that 10.3.2, the next update of OS-X, is very far along in testing with developers. I have a hunch that the necessary patch for this is contained in this latest update. I may be an optimist, but I think this matter will be rendered moot quite soon.

Re:Damn

[Anonymous Coward]

it is reasonable to expect and anticipate a reasonable amount of time to release a stable, reliable patch

Sure. However, for a company that releases a completely new version of their OS every 12 months and has hundreds of programmers, many of which are working on the unix parts, one month should have been more than enough.

What most people here don't understand is that this is all about priorities. If Apple (or any other company) _really_ wanted they could fix things like this within 48 hours. By putting deadlines after which advisories are made public we want to force companies to respond better to security issues.

Apple doesn't get to select these deadlines. Sorry, I don't find it acceptable to wait two months for possibly critical security patches (any remote root hole is critical). If that is Apple's policy, my policy will be not to use OS X on critical servers.

Re:Damn

[valmont]

please, sit down for a second, and take the time to think long and hard about the scope of the concept of a remote exploit. While it is true that someone who is not "at the machine" could potentially own it, this exploit can asbolutely NOT be leveraged by just anyone on the internet. For example, there is absolutely no fucking way in the world, this exploit could be leveraged to write a self-spreading worm that could wreac havoc all over the internet? Why? because the exploit has to happen within a local network. The author of the advisory could have very easily waited another 30 days without anyone ever being affected. Hell even now that the exploit is out and can be copied verbatim by lower-lifeforms, there is still no way anyone will be infected.

i'm tempted to qualify this hole/exploit as "extended local".

Making rounds

[somethinghollow]

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.

Re:Making rounds

[marsipan]

"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

[Onan]

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

[Kunta Kinte]

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.

Re:Making rounds

[mentatchris]

I agree. I think this guy has shown some patience...

If you can't get a patch ready in a month and a half, you aren't trying very hard.

If something like this were to come out on linux, I'd like to know immediately so I can shut the damn service off. I sure as hell wouldn't want this sitting on my box for two months while a vendor twiddles their thumbs.

Re:Making rounds

[arkanes]

Except that (as (he?) posted in this thread), the LDAP server can also specify mountpoints for you, (apparently) including things like replacing your crontab with a remote one that WILL start all those services.

Re:Making rounds

[ziggyboy]

Know your facts first. READ THE TOPIC LINKS. The security advisory says EXPLICITLY:

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.

Re:Making rounds

[Anonymous Coward]

No, you cannot do that. Not just any directory goes for static (or dynamic) automounts as supplied by a directory server (be it LDAP, NetInfo, Nis, or whatever). The system directories cannot be affected that way.

Re:Making rounds

[Daniel_Staal]

I'll agree he should have posted something. I think he could have waited on the working exploit code until Apple's stated fix release date passed. Posting that he had (without giving it out) exploit code would have been reasonable, given that he knew Apple was working on a fix.

Re:Making rounds

[Anonymous Coward]

Very responsible to blackhats, yes. They would definitely want to have the exploit to themselves for 48 days, before admins and users around the world got the advisory.

Listen, this is not about Apple, or their reputation, no matter how much they try to make it look that way. It is about the owners of all those machines that may have been attacked in those 48 days, because this moron wanted Apple to look like they fixed the problem quickly.

That's why full disclosure is important. To help users and admins protect their systems, in the time from the exploit becomes known, until the vendor gets around to fixing the problem.

As this hole was easy to workaround (don't use DHCP until it's fixed), waiting 48 days had the only effect of deliberately putting other peoples computers at risk.

Re:Making rounds

[Anonymous Coward]

I'll agree he should have posted something. I think he could have waited on the working exploit code until Apple's stated fix release date passed. Posting that he had (without giving it out) exploit code would have been reasonable, given that he knew Apple was working on a fix.

Yes, but Apple already knew that but apparently didn't bother fixing it for a month and a half.

The advisories have a dual function: in the long run I think it's pretty powerful that vendors learn "if you don't fix your critical bugs within a month or two we'll publish them and all your customers will see you with your pants down".

My turn to karma-whore

[McDutchie]

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

Vulnerability Text (Already running slow)

[Anonymous Coward]

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 se

What is telling

[Space cowboy]

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

[GigsVT]

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

[Boing]

Any unix-os is a friend of mine

He's a friend of SCO! Burn him!

Re:What is telling

[Anonymous Coward]

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.

Re:What is telling

[Anonymous Coward]

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

Obviously Apple. They've configured the DCHP client to trust whatever info the DHCP server provides. Any idiot can run a DCHP server.

And it's OpenBSD that has the fantastic security record :)

Re:What is telling

[redJag]

No no no, let's not be rash. SCO is a friend of his not vice-a-versa.. Burn him!

Re:What is telling

[Anonymous Coward]

Does he weigh as much as a duck?

Re:What is telling

[Anonymous Coward]

We'll have to burn them both and weigh the remains!

Re:What is telling

[IANAL(BIAILS)]

Wait! First, we have to see if he weighs the same as a duck!

Re:What is telling

[Anonymous Coward]

It's more like it has BSD utilities / daemons rather that being based on BSD. It does not have a BSD kernel, installation system, filesystem, etc.

In any case, from the article it looks more that a configuration issue or how things are done rather than a flaw in the DCHP software.

Its like the improper file permissions of /Applications (some directory world writable). A Unix system not properly configured is not secure.

So there are a few things that still need fixes.

Re:What is telling

[anthonyrcalgary]

Free and Net are pretty good.

Re:And now the question of support...

[johnpaul191]

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

[falcon5768]

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

Re:And now the question of support...

[llf4nlp]

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.

Nothing is infallible

[Coryoth]

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

Re:Nothing is infallible

[mobby_6kl]

>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!'

Re:And now the question of support...

[tgibbs]

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.

What is the fix?

[stefanb]

I'm not sure I fully understand the problem, but it appears to me that the defaults of just accepting information from DHCP for authentication and authorization are wong; not necessarily any piece of software. (It is debateble whether the very possibility of obtaining such information from DHCP is such a bad idea that the option should not be offered at all.)

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

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

Re:What is the fix?

[burns210]

the other half of the problem is that ssh, etc. are turned off by default, so even if you can use this rogue DHCP server to create a root account(which is also removed, by default) how are you going to login remotely?

And if you get physical access to a machine, your security is compromised anyway. It is albut impossible to secure a machine if a hacker has physical access to it. regardless of OS flavor.

Re:What is the fix?

[Glock27]

They're not fixes, but there are some fairly easy workarounds:

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

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

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

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

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

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

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

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

Re:What is the fix?

[YOU LIKEWISE FAIL IT]

This is an excellent post. Thank you.

I don't understand why these directory services are on by default ( I just checked, and they certainly are on this 2 day old panther install ) - I don't think the average home Mac user will ever be deploying Netinfo or LDAP login account servers...

YLFI

Re:What is the fix?

[brianosaurus]

ya know, if you read the article, all of those same fixes are listed.

while it was perhpas irresponsible of him to detail the exploit (especially right before a holiday), it was nice that he gave the workaround.

Re:What is the fix?

[YOU LIKEWISE FAIL IT]

Yeah, I read the advisory too. But most people reading Slashdot won't. Several people in this room with me won't read advisories for their platform because they're "too technical" for them to understand. But this is a nice soundbyte with just the good stuff ( and I do concede, this advisory was a bit of a shining star for putting the Workaround in plain language at the top ), and that's the type of post I'd like to encourage. Certainly a better use of space than a failed first post.

YLFI

Re:What is the fix?

[Anonymous Coward]

The fix on a default Panther configuration is very simple. Go to Applications -> Utilities and start Directory Access. Configure LDAP v3, and uncheck Use DHCP-supplied LDAP server. Done.

NetInfo appears to be off by default. It's off on my system anyways, and I've never touched Directory Access. If it is on, configure it and uncheck Attempt to connect using DHCP protocol. You can also, like people have suggested, disable NetInfo and LDAP completely if you want, but those two checkboxes are all you need to deal with to fix this "exploit."

Dang, that sure is easy.

Re:What is the fix?

[Cecil]

Weird. NetInfo was decidedly off on my 3 week old Panther install (I did an archive and install, which might have harvested my settings from Jaguar, as unlikely as I believe that to be)

If you are unsure why it was made public...

[bdigit]

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

[Anonymous Coward]

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!

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

[NaugaHunter]

Probably in the hopes that the slashdot effect(TM) would remove the information from the general public.

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

[dubiousmike]

Because this is a news site and not a tin-foil-hat site.

If it was made public, many who frequent this site might have been made aware of it and thus could try to take appropriate measures to protect themselves.

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

[lucas teh geek]

Because this is a news site and not a tin-foil-hat site.

I resent that comment, I wear my tinfoil hat as a fashion statement, nothing to do with paranioa

Not exploitable in the default configuration, at l

[Onan]

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

[DaveCBio]

Why should it be any different for Macs?

Re:People post Windows exploits immediatley

[Anonymous Coward]

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

Re:People post Windows exploits immediatley

[r3dx0r]

um, you shouldn't do that either. i must admit it's quite tempting though.

Re:People post Windows exploits immediatley

[WegianWarrior]

Because a more than a fair bit of the mac-users are semi-relgious about their OS of choice* and would rather walk on fire than to publicly admit that there is a problem with it?

Seriously thought, I strongly believe that the correct way to handle any exploit you find - no matter what OS or app - is to first contact the people who wrote the software. If they fail to fo somethign about it, then go tell the world, thus shaming them into doing something. And if they still wont fix it.. well, then it says somethign about their priorities, right?

*) Fair is fair; you'll find these kind of people among the users of Linux, FreeBDS, Windows and every other OS too.

Re:People post Windows exploits immediatley

[Anonymous Coward]

Windows is an OS.
Mac is some kind of hardware from Apple.

Mac OS X is one of the possible operating system running on Mac hardware.

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

[Anonymous Coward]

os 9 has no vulnerabilities that need patching you retard.

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

Slashdotting to the rescue!

[SuperBanana]

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.

Re:Slashdotting to the rescue!

[thebatlab]

Well when they've had 48 days already I don't know how much a slashdotting can help

Re:Slashdotting to the rescue!

[Anonymous Coward]

redundant:

Re:Slashdotting to the rescue!

[YOU LIKEWISE FAIL IT]

The problem is, it's a config problem, not an application problem. How do we patch it? Simply turn off this trust setting on any machine accepting the patch? That's going to be great when it thrashes your 30 Mac design lab that you specifically setup this way.

However, I guess they're just going to have to bite the bullet and do it, and set the default for 10.4 to not use any sort of directory services, let alone directory services received from DHCP.

YLFI

Good News?

[KrizDog]

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?

[Jesrad]

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?

[pi radians]

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?

[hondo77]

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?

[kwerle]

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

Re:Good News?

[AKnightCowboy]

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

As opposed to my Windows 2000 box where the first thing I have to do is go in and put my user account in the admin group or certain stuff doesn't run and I can't install any software. :-) I wonder if they fixed the requirement for that in certain games and such with XP. Alas I'll never know since I don't plan on buying any shit that needs to be "activated" before it works. Serial numbers are bad enough, but tying the OS to my hardware with a unique activation key is pushing it way beyond my tolerance level. Too bad Apple has crappy game support (this means no Counter-Strike or Battlefield 1942 for you Mac fanatics who say 'Well sure it has The Sims and Warcraft 3 though') or I'd just get a new Mac instead.

Re:Good News?

[debrain]

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

You mean like:
$ sudo bash

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

Cheers

Re:Good News?

[kwerle]

Yeah, it is pretty thin pickin's game-wise. It SEEMS like it's getting better, but that may just be me wishing it so...

Re:Good News?

[WildBill1941]

It's trivial to login to an OS X box as root - unlike other posts, with this one you can do it from the GUI so you could wipe out your whole box from Finder.

1) From your user account with "admin" privileges, do a "sudo passwd root". It will ask you for your password, then it'll ask you for root's password (and a confirmation). At this point root is enabled.

2) Logout.

3) From the Login Window, hit "down arrow" to highlight the 1st user. Then hit "Option+Enter" and the login box will morph into a traditional UNIX username/password login.

4) Login as root with the root password you specified in step 1. That's it - you now have root on your box. It's kinda handy to have it here, in case you b0rk your regular user. But it's not visible from the login window - which is also nice.

Re:Good News?

[brianosaurus]

Subtle difference:

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

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

Re:Good News?

[Anonymous Coward]

If he's a troll, you're a big stupid fish flipping around in the bottom of his boat now, dude.

har har

Re:Good News?

[Anonymous Coward]

I used to work at an isp that used macs exclusively. Instead of using sudo over and over again, we would simply type "sudo su". Even better was "sudo passwd root". This was a while ago, Mac OS X version 10.1, this issue may have been fixed by then.

Re:Good News?

[Anonymous Coward]

The best thing to do with sudo:

Mac users who are your friends, will normally give you admin, cause you can't touch 'their files' cause the mac os x gui won't let you do it(cause even as admin they have restrictions). Especially if you are a unix person, cause they wanna, ahm, "learn the cool terminal tricks". Well, one night i decided to have some fun with him. I had him enable ssh, and told him i was just gonna teach him something. Logged in and typed kill 1. After doing it three or four times he got wise and stopped letting me login :-D

bigger problem

[kaan]

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

[freeweed]

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

[Anonymous Coward]

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

[ChiperSoft]

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

[venom600]

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.

Re:bigger problem

[Exiler]

Are you kidding? Tack "Over the internet" or "using a computer" to any crime and suddenly the penalty becomes the same as if he had been sacrificing children to $EVIL_DIETY.

Re:bigger problem

[jmike]

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.

Are you kidding? You're thinking he's more likely to uncurl his claw-shaped hands from his keyboard and mouse, put down his Mt. Dew and Fritos, get up from his butt-shaped chair, go outside (and thereby risk exposure to sunlight) wheeze over to your door, kick it down and take your Mac?

Ha. The PPC Linux distros may be cool but hell, we're talking physical exertion here!

:-)

Re:bigger problem

[glorf]

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?

I wouldn't presume that. An attacker could be after your computer to use it as a spam proxy, part of a distributed child porn archive, zombie for DoS attacks, or even just another link in the chain to further cover tracks of some other nefarious activity (e.g. ordering goods with a stolen credit card is something they probably wouldn't want to do from their own connection).

Then of course there is the fact that some people break in to others' computers because they find it an interesting thing to do to amuse themselves and they consider it more of an intellectual exercise than a crime. And why should I settle for your hardware when I can keylog your access to your banking site and empty your entire account? The risk vs reward ratio for compter crime is much better than that of traditional B&E type stuff.

And are you sure the assumption that it is a wireless attack in your immediate vicinity valid? When cable internet access fist came out a lot of people didn't realize they were on the same network as everyone else in their neighborhood and had open shares that anyone could access.

Re:bigger problem

[Anonymous Coward]

Why is this Flamebait? It seems like a valid point, to me. Alas, I have no Mod Points today....

Re:bigger problem

[Anonymous Coward]

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.

True, the threat is greater, but for him as well as myself. If he is rooting my machine from his car and I notice I'm going to run out there and put a brick through his windshield. If on the other hand, he breaks into my apartment, I'm going to shoot him in the head. Since I am much more likely to notice the latter, as are my neighbors, I'd put it in a completely different risk catagory.

Re:bigger problem

[Anonymous Coward]

No, root doesn't have to be enabled for them to get root. All "enabling root" does is set a password for the root user. Go into netinfo and set your uid equal to 0 and it'll work fine. If LDAP authenticates them and tells them the machine's uid is 0, their uid is 0 :)

Re:bigger problem

[Anonymous Coward]

If you don't notice people mounting over your home directory, then you probably wont notice your computer missing.

RFP policy

[Anonymous Coward]

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.

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

[tomhudson]

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, the original OS9. No exploits there, and links to versions running on dif. platforms, etc., that you can download.

why?

[silicongodcom]

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

no SCO news!

Local insecurity

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:Local insecurity

[Commykilla]

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

[Anonymous Coward]

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

Re:Local insecurity

[supertsaar]

Peanutbutter is terribly insecure! It washes right off with some detergent! Personally, I prefer superglue (also used to glue the S _and_ the command button)

Re:Local insecurity

[Jesrad]

IIRC there IS now a login prompt before accessing single-user mode. And there is a free utility that lets you password-protect the OpenFirmware, which prevents you from booting from a CD or in single-user mode.

But in any case, having physical access to any machine WILL give you admin access anyway. If you really want the data, just crack the case open and pick the hard drive up.

The real issue is REMOTE security, and MacOS X has a wonderful track record on that. The flaw mentionned in the article is hardly exploitable even when all the (numerous) conditions are met.

Re:Local insecurity

[Anonymous Coward]

And what a surprise, if you sit down at a typical WinXP Home or Win2K Pro, you are running as a user with administrator privliges. What a fucking surprise, people want control over their computers without having to prove who they are.

Re:Local insecurity

[zulux]

You're in as root, no login required, and it even tells you how to mount local filesystems writable.

snip...

I love my Mac, but Mac OS X is not a secure OS.

All of the *BSD assume that if you have local physical access to the machine, that you should be able to reset the root password.

You can fight this by encrypting portions of your file-system - at boot time, you unlock the encrypted filessystem with a pass-phrase. If somone reboots your computer, of turns off the power - they would have to get you to unlock the file-system, and even if they set themselves up as root, they woulden't have access.

Re:Local insecurity

[Maserati]

And any intruder short of the MiB or NSA is going to have a lot of fun with an encrypted home directory (now that they fixed that little glitch in 10.3.0).

Now we just need an OpenFirmware option to password protect a Mac when it's booted in Target Disk mode (firewire connection to another Mac and booted with cmd-T down - Mac boots up as an external hard drive, very handy) to secure a Mac from anything short of having its drive(s) pulled and decrypted.

Re:Local insecurity

[dirkx]

This seems to only affect machines which did not come through an upgrade path from 10.1 or before; but had Panther instaleld on them cleanly.

The solution is documented in /etc/ttys, simply change the secure of the console to a insecure:

If the console is marked insecure, single-user requires the root password. Since DirectoryServices is not running by the time we enter single-user mode, init will ask for the non-shadow crypt password stored for root in /etc/master.passwd. If no such password exists, it will not be possible to enter single-user mode from a console marked insecure.

I.e. The lines you want to edit is/are (with sudo vi /etc/ttys):

console "/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

Re:Local insecurity

[Jesrad]

FileVault is the correct answer, password-protecting the OpenFirmware can be bypassed by removing / rearranging some of the RAM.

Re:Local insecurity

[stefanb]

Hold down Command-S while starting up the machine.

Open Firmware Password is a little utility that will set up the password for Open Firmware, which you could also do from the Open Firmware prompt (Cmd-Opt-O-F).

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

Re:Local insecurity

[Anonymous Coward]

Bravo. Give that man a coconut. Are you that desperate for points and the respect of your little friends that you had to share this with the world? I've been trying to keep this dirty little secret quiet but I guess the jig is up now!

Re:Local insecurity

[mlyle]

If you're root, and a filevault protected user logs in, the encryption key can be captured and the information stolen. So it's not bulletproof in these kinds of scenarios.

Re:Local insecurity

[dr.badass]

You can also "physically sit down to any machine running any OS and perform a denial of service attack" by doing this :

1) Get some explosives
2) Place explosives near target machine
3) Get to safe distance (optional)
4) Detonate explosives

I've reported this to Apple, Microsoft, Sun, and all the open source OS guys. They all say they see it as a non-issue! Except the OpenBSD guys who said "We're working on it. Patches welcome."

Re:Local insecurity

[Anonymous Coward]

There is one other point you forgot. Once the DHCP lease has expired it might be possible to have the bad information sent to the machine.

Re:Local insecurity

[Anonymous Coward]

If the machine has a self contained nuclear power supply, maybe, otherwise just find the power cable, unplug it, cut it and patch it, flip the circuit breaker...

Re:Local insecurity

[IM6100]

If you have physical access to a machine, security is compromised anyway.

Yes, but it's so convenient to not need an external boot device, or to open the box or anything at all.

Granted you can single-user boot any freenix system as well.

Re:Local insecurity

[IM6100]

And there is a free utility that lets you password-protect the OpenFirmware, which prevents you from booting from a CD or in single-user mode.

Oh coolness! So there isn't any default protection built in, but anybody who has physical access to the box can install a patch that locks any and everybody else out of the box to undo whatever fun tricks they've installed.

This is the kind of stuff that makes malevolent freshmen in College computer labs smile.

(not advocating the above, but let's be real here- easily installable add-on lockout features aren't that great an idea. That level of security should be thought of 'inside the box' before it's produced)

Re:Local insecurity

[gerardrj]

The issues you mention have absoloutly nothing to do with Mac OS, and everything to do with a machine not being secure if a malicious person has physical access to the it.

Unless your bios/firmware/hardware is encrypting data on the drive there is no machine that will not yield data or control to a local hacker. You can always boot to an alternate volume (or remove a volume and access it via another machine).

With a Mac that you have physical access to, you could reboot it in to FireWire target mode and access anything you like (that isn't filevaulted) from a laptop.

Re:Local insecurity

[netsrek]

Let's be real here.

If you'd read how the damn system worked you wouldn't look like such an ass.

(ie, the physical owner of the machine can easily remove the password)

Re:Local insecurity

[placeclicker]

And, unless im mistaken, all you have to do is drop in a floppy or a cd thats bootable, and you have complete access to the entire system as root.

Here's a mirror

[EvilStein]

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

Link for the extra-lazy: here

Whoops

[EvilStein]

here is the clicky-link

x-queeze me, but...

[airdrummer]

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

source

[Dave_bsr]

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

Re:source

[llf4nlp]

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.

Re:source

[Anonymous Coward]

Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?

When I first started reading slashdot, I wondered how anyone could be so stupid, and hold such contradictory views.

Blasted City Folks!

[GussT]

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:Blasted City Folks!

[Anonymous Coward]

Reminds me of the old joke....

Whats worse than finding a worm in your apple?
Only finding half a worm in your apple!

I say we take off and..

[cutecub]

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

Re:I say we take off and..

[anzha]

You can only be mostly sure. Mostly.

Reason for release of info

[Todd Knarr]

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.

Re:Reason for release of info

[thebatlab]

"Apple went and released the 10.3 upgrade with a known remote-root vulnerability in it after having acknowledged the existence of the vulnerability."

That does seem to be the case however it's not a good reason in my eyes. They are on a monthly patch time cycle. This patch wasn't ready for the monthly patch so got delayed to next months. Seems simple and reasonable to me. If you can't fix something right, don't push it out in a half-fixed state.

Re:Reason for release of info

[Todd Knarr]

Apple wouldn't even have had to release a patch. Just change the default settings and/or include a prominent notice about the problem so users knew what they had to do based on their situation. On a vulnerability like this, response time should be a week tops, a few days preferably. A month without at least a workaround for users is completely unacceptable to anyone who cares at all whether their machine gets rooted.

Re:Reason for release of info

[Espen]

Normally I can firewall my machine to block attacks, but I can't firewall off DHCP and still use the network

DHCP is only an enabling device in this attack. The real attack comes from the LDAP or Netinfo server's creation of rouge mounts, which can be blocked.

Re:Reason for release of info

[TiggsPanther]

I've been trying to stay out of this, as I don't know a great deal about Macs or BSD. (And /. gets enough clueless comments without me adding to them)

But the timeline given does seem to put Apple in a less-than-favourable light.
- They knew about the exploit, and intended to fix it. Good.
- They missed their first deadline. No-one's perfect.
- They released 10.3 (I assume this is a version upgrade) with the known vulnerability still in it. ::DANGER:: ::DANGER::

The upgrade would have been a common-sense time/place to address the issue. Most people either install upgrades, or at least read up on what gets changed. (Alerting them to known issues with the current version)
OK, some don't. But people who don't keep up to date with upgrades probably don't really pay attention to patches either.

From what I've read, the vulnerability might not be the most dangerous around. But it still seems like a hole that should be closed PDQ.

Tiggs

Unreasonable?

[mindstrm]

How many times does a vendor need to promise a fix, then delay it, before it's time to release it?

Background info

[krisbrowne42]

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.

Re:Background info

[Anonymous Coward]

You can have more than one DHCP server on a network, dumbass.

Re:Background info

[lieven_dekeyser]

you could've said it in a nice way too, you know...

Re:Background info

[Anonymous Coward]

This is a vulnerability because Windows clients do some authentication on the Directory Server and have since 1993. Otherwise they'd be vulnerable to DHCP and WINS spoofing.

Just because NeXT thought it was smart to trust DHCP servers back in the low-security 1980s doesn't make it a smart idea in 2003.

Re:Background info

[Anonymous Coward]

If you can't trust DHCPs servers on your local network, you are screwed already. You shouldn't be attaching to unsecured networks and if you are, you deserve whatever happens to you.

Why it was made public

[siphoncolder]

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

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

Re:Why it was made public

[merdark]

When the next Linux worm comes out you can be sure you'll here me say:

• Because I hate OSS folk for being so arrogant and stuck up and *still* letting this happen.
• Because I don't want an untested patch that could break my mission critical server, and I don't want to risk recompiling parts of a very complex system myself. There is *no evidence* that open source software is at all better than propietary software in real world applications.
• Because I hate OSS zealots, period, they suck (and don't know basic grammar either).

Don't think it'll happen to Linux? Just wait till Linux gets the features of OSs like Windows and OS X. It's easy to secure a system with few features, but much much harder to secure a complex but flexible system with many many features.

It's people like you that give the OSS community a bad image, namely that of a snotty 15 year old brat.

Re:Why it was made public

[siphoncolder]

You'll have to excuse my earlier post - it was tongue-in-cheek sarcasm. I was merely echoing typical responses that would be heard from such a snotty OSSer.

As it is, I hate Linux, and the zealotry that lingers in that community (as you might notice from my other posts). I hate the design of the product itself, I hate the Microsoft bashing, and I hate the hype around it, and I hate the constant socialist overtones that fan the flames of such hatred.

At least NOW you can judge me for what I really am.

Re:Why it was made public

[merdark]

Ah, sarcasm is hard to determine with just text. :)

I'm glad there are others who see the OSS community for what it really is.

Re:Why it was made public

[Anonymous Coward]

I agree with the first part, that of the zealots and MS bashing. However, both of you seem to be the same mentality and for the record rather hateful as well. Back in reality, we know the value of OSS (and Linux) as well as Windows and that implies we spy out zealots and "Anti-" folk no matter what hat they claim to wear.

good day

Mac zealots

[Anonymous Coward]

Modded down twice? Zealots...

Re:Ummm, no it isn't, fuckface....N/T

[Anonymous Coward]

Ummmm.... ssh is enabled. sshd isn't. (by default). What were you saying about my face again? You're a dumass. N/T

Bastille Linux works on Mac OS X

[jjb]

We've got Bastille Linux working on OS X 10.2.x. Within a couple weeks, we'll have 10.3.x support. We could prevent exploitation of this vulnerability (on systems running sshd) by disabling network authentication systems from getting data by DHCP.

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

Re:Bastille Linux works on Mac OS X

[mentatchris]

Bastille is awesome... I have installed it on every linux box I've ever adminned. If you haven't used it, you should.

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

[zulux]

Microware's OS-9 Kicked ass....

For those who don't know anything about it:

Imagine a windowed UNIX-like, pre-emptive multitasking OS with all the goodies: swap files, networking, hot-swap devices, assembler, shell scripting, a pcode language.

Running in 1982....

On a $500 computer.....

I'll let that sink in. OS-9 really was cool.

Re:Ummm, no it isn't, fuckface....N/T

[WiseWeasel]

Who's the one who writes N/T after their text? Huh? Who's the dumbass now? :p I mean, in any version of OS X client (I don't know about Server), SSH is definitely off. If you go to your 'Sharing' system pref, services tab, "Remote Login" is unchecked by default. This checkbox turns on the SSH daemon (aka SSHD). Dumbass.

Just use an Open Firmware password.

[netsrek]

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

Re:Just use an Open Firmware password.

[valkraider]

No worries, after a couple hours rendering things in PhotoShop - my Powerbook's RAM is melted to the motherboard... No changing possible.

Re:Just use an Open Firmware password.

[IM6100]

Waah. My Powerbook is a 165c and only has 4 megs of RAM. It's jealous of yours. I guess there's probably a version of Photoshop out there somewhere that would run on it. There's Pagemaker, afterall...

Re:Just use an Open Firmware password.

[valkraider]

Fill up the 80MB hard disk yet? For people who don't know, the 165c was the first color Powerbook. Warning - that link crashes my Safari every time... But works fine in OmniWeb and Camino. YMMV.

Is the 165c vulnerable to this root exploit?

Re:Just use an Open Firmware password.

[IM6100]

It's running OS 7.5.5 and I don't think is vulnerable to this root exploit.

It's a sweet machine for retro-ness. Sometimes when you're writing you just want a simple machine to get away from it all.

Why suprised?

[Anonymous Coward]

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

Didn't you know that corporations like Microsoft and Apple do not act responsibly when confronted with these security issues. Given the fact that Apple doesn't fix the vulnurabilities in the earlier versions of its OS, it is very natural to release this vulnurability to protect the users.

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

[tomhudson]

And not just multitasking, but multitasking on 64k, or graphical environment + multitasking on 128k (that's kilobytes, not megabytes). Also multiple terminal screens, etc.

Also had a C compiler for $60.00 (2 disks - bought it along w. the 2-disk pascal compiler - same price).

I remember using one of these while Gates was saying that you would need "at least 1.5 meg" to multitask.

why?

[fudgefactor7]

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

One race Apple as already lost!!!

[Anonymous Coward]

Kind of like a car race with the finish line at the edge of a cliff.

Re:And now the question of support...

[green pizza]

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

There is no way this splot can affect Mac OS 9 users. There is no command-line for Mac OS 9, nor is it even a true multi-user system. Remote access in Mac OS 9 is minimal and disabled in the first place. If you want an insanely secure server, get a box with Mac OS 9 and run WebStar, Rumpus, FileMakerServer, and/or QuickDNSPro.

Comparing Mac OS 9 to Mac OS X is like comparing DOS to NT.

Why the exploit was released

[greygent]

It is unclear why an exploit was made public before Apple resolved the problem. [Link to RFP's policy]

Probably because the person who released the exploit wasn't RFP, maybe? Just a guess.

CNET article

[green pizza]

http://news.com.com/2100-1002-5109969.html

Is this a quick fix?

[braines]

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

Re:Is this a quick fix?

[Anonymous Coward]

I wanna know too!!!

No one's addressed this! If parent is right, I imagine Apple will just change that default setting.

MOD PARENT UP!!!

Show-boating, grand-standing

[macdaddy]

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

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

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

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

Re:Show-boating, grand-standing

[holoway]

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

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

As far as the timeline for releasing the vulnerability goes, it appears he told Apple he was planning on publishing the vulnerability.. and got no response. I imagine that, had they responded with something along the lines of "Sorry, it has to go through our testing pipelines first, and the absolute earliest we can do it is December" things might have gone differently.

Re:Show-boating, grand-standing

[Anonymous Coward]

Let us replace "Apple" with "Microsoft" and see if you still wax poetic about "grand-standing" and the guy's "idiocy" and poor company being in the middle of "testing". No? Thought so.

I can't believe this piece of apologetic mac zealotry can get modded up. Oh wait, I can.

Re:Show-boating, grand-standing

[Quixotic Raindrop]

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

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

Re:Show-boating, grand-standing

[Anonymous Coward]

You obviously don't understand the issue. Don't comment if you don't understand.

It's called "automount" because it is a u t o m a t i c. The user doesn't have to do anything. You can automatically mount a file system at /var/cron/tabs and then execute sshd (That's "Remote Login" for you Mac People).

Re:Show-boating, grand-standing

[Quixotic Raindrop]

Here's the problem that shows that you don't understand. It's not enabled by default, there is nothing auto-mounted via LDAP. In order for a remote user to modify your crontab or your fstab, they'd have to already have access. The method detailed in the advisory requires that the client using DHCP have already enabled LDAP; this is not enabled by default in the non-Server versions of Mac OS X 10.2 or earlier. It might be by default on OS 10.3, but I don't have 10.3 yet. Approximately 99% of all non-Server versions of Mac OS X 10.2 and earlier are not vulnerable out of the box.

Re:Show-boating, grand-standing

[IM6100]

First, the average user 1) doesn't have a directory server to authenticate to

No problem. No problem at all. I'm sure Joe Cracker will provide a directory server post-haste.

Re:Show-boating, grand-standing

[Anonymous Coward]

And you, sir, are the reason people hate Mac fan-boys. Anyone who dares to say something bad about Macs is evil incarnate according to you idiots...

Re:Show-boating, grand-standing

[Anonymous Coward]

It is not unreasonable for an operating system company to take a non-critical but serious bug and spend 1.5 months developing and testing a fix.

First, I would DEFINITELY say it is unreasonable to have to wait 1.5 months and two intermediate releases (10.3 & 10.3.1) without having a fix for a remote root exploit the vendor was aware of. They are not "working hard to fix it" - they apparently thought it wasn't important enough to delay their releases.

Second, the guy already waited MORE than 1.5 months (48 days). Apple wanted 2.5 months.

You can motivate the delay all you want, but in the end it comes down to this: If Apple needs 2 months to fix a remote root exploit in their software they are not a serious alternative for critical servers.

Re:Show-boating, grand-standing

[Anonymous Coward]

WRONG! I just pulled a 10.2.6 Powerbook fresh outta' the box, opened Directory Access, and LDAPv3's setting is configured to "Use DHCP-supplied LDP Server" .

YOU don't understand!

panther fixed this for me

[Other1]

it completely hosed ssh services for me.

Root may not be enabled by default, but...

[MyDixieWrecked]

OSX doesn't have the root password SET by default. You can say that it's not enabled, but it exists, although you can't log in to it.

With this exploit, the compromised system gets and uses a root password which would then allow logging in, I believe.

Luckily OSX doesn't have any network services (sshd, ftpd, afpd, smbd, etc) turned on by default, so the only way to gain access would be to have physical access to it for the general home-user, unless they have file sharing turned on, which would allow for a user to gain access to any file on any one of the computer's drives.

The way I see it, the most significant target would be schools and offices where the users want root access.

Yeah but..

[Paradox]

Even were they to use the specified procedure to change your machine's auth info, they couldn't log in unless you have SSH enabled.

There are very few reasons to have sshd enabled on a portable machine. Can you name some?

Re:Yeah but..

[Todd Knarr]

Logins are the least of the problems. Once they can change the authorization information on your machine, they can gain access to anything you have accessible but protected by authorization. Many people have their machines set up so that certain things like file shares are accessible but require a valid username and password to gain access to them, to make it easier to copy things around between multiple machines. Normally this would be safe, but this vulnerability allows an attacker to gain access by his control of the passwords.

And I can think of at least 2 reasons off-hand to have sshd enabled on a laptop. The same reasons I'd have it enabled on a desktop, in fact.

Re:Yeah but..

[Todd Knarr]

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.

Re:Yeah but..

[IM6100]

There are very few reasons to have sshd enabled on a portable machine. Can you name some?

Laptops have smaller, less comfortable displays and keyboards. It's nice to be able to put the thing on the corner of the desk plugged into the network and access it to do various things from your desktop with the big display and the friendly keyboard and mouse. For me, it's a very good reason to have sshd enabled on my portable machines, and it would be for anybody else technically inclined who works regularly across a personal network all the time.

Tech TV

[wangotango]

Anyone giving odds on the Tech TV Mac lovers saying absolutely nothing about this tomarrow, much less today.....? My guess is they can't do a story on this one without at least pointing to something Microsoft.

Re:Tech TV

[wangotango]

Damn, I nailed that one...... Not a word about a "huge hole" in OSX. Only a slightly smaller hole (sarah lane) talking some shit about a hole in IE and another browser..... If they ain't anything else at TTV, they are damn sure predictable.

Does it not require directory access turned on?

[goombah99]

Perhaps Someone can explain. As I understand macs dont by default go beyond the local netinfo/passwd file to authenticate unless instructed to do so. You can turn on directory access and enable authentication by ldap or remote net-info, but I dont beleive this on by default is it?

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

what am I missing here. or is this thing on by default?

Re:Does it not require directory access turned on?

[DF5JT]

"what am I missing here. or is this thing on by default?"

RTFA

Re:Does it not require directory access turned on?

[Anonymous Coward]

asshat. I did read the fucking answer. its not clear if directory access for ldap and remote net info has to be truned on or if its a default attack,

Re:Does it not require directory access turned on?

[Goldfinger7400]

Yeah, these services are apparently running by default, as I've just had to turn them off. Also, the way Apple set up the network control panels is confusing to the user who wants to make his computer more secure. In the Sharing tab, there's all the services there which you know you should turn off if you didn't need them. I didn't realize that NetInfo was running additional services, controlled by an additional application/terminal command.

Re:Does it not require directory access turned on?

[steeviant]

It was turned on by default in my (upgraded from Jaguar) install of Panther. The real problem here is that Apple had all this crap turned on by default, as the article mentions.

Basically, we can all avoid exploits of this ilk by turning off all of the remote authentication protocols in Directory Access.

This is pretty much the same kind of blunder that MS made with XP and the windows file and messaging services, and RedHat (5) used to make with Telnet and Finger and other worthless services.

They thought they were doing their users a favour by shipping with all this junk on by default even though most people don't need it.

Re:Does it not require directory access turned on?

[hayne]

Yes - the Apple knowledge base article (that was posted this evening) says to turn off LDAP if not needed.

BWA HA HA HA HA HA! what a caboosh

[Anonymous Coward]

ROFL You retard, SSHD is the SSH daemon, as in the service that enables SSH. I think he said something about fucking your face. Fuckwad! BTW, N/T means No Text.

Re:BWA HA HA HA HA HA! what a caboosh

[Anonymous Coward]

off-topic 8 year old? the ssh client has nothing to do with this discussion. I fail to see the point of your original comment other than you were intentionally hitting upon some ambiguity between the binary naming scheme and the discussion. When someone say "Is ssh enabled", I don't think anybody looks at their client.

Re:BWA HA HA HA HA HA! what a caboosh

[Anonymous Coward]

Silly goose! MacOS X CLIENT (the OS, not the SSH client) has an SSH SERVER that is apparently vulnerable to a root exploit. This SSH server is off by default. SSHD is the daemon that runs the SSH server.

AUTHOR: FAQs answered

[Cysgod]

Thought I'd field some of the more mentioned questions and misconceptions here...

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

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

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

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

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

Re:AUTHOR: FAQs answered

[Anonymous Coward]

Give me a break please... Get off your High Horse that you were out riding and please give someone else your demands - news. Exploit - no sorry, taking over my subnet are you? Try it. You've shown your ignorance here - move along.

Re:AUTHOR: FAQs answered

[ziggyboy]

Why should we, you people post without reading the links provided with the topic. It explicitly says you're vulnerable even with root disabled.

_Normally_, you hover your mouse over some text that's usually underlined (see dictionary if you don't know what this means). If your cursor chances to something which invites you to click, then go ahead. It then leads you to another page which _you're supposed to read_ before posting comments.

Well, that's normally what regular Slashdotters do, but then again, you're Mac users. You "think different," don't you?

Re:AUTHOR: FAQs answered

[Anonymous Coward]

So, you've actually sucsessfully automounted a malicious /etc directory, or you're just throwing more fuel onto the fire?

Re:AUTHOR: FAQs answered

[Wanker]

Kudos to you for handling this very responsibly. Despite the attention-grabbing comment by pudge, you followed the policy he linked to quite nicely.

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

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

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

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

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

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

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

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

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

Re:AUTHOR: FAQs answered

[MacTroll]

automount adamantly refuses to mount a remote share into something that already exists. So /private/var/cron/tab is out. /etc/ is out. /Library and /System are out.

So we are left with:

1. You didn't actually try to automount any malicious sharepoints. Certainly not the cron tab that you speak of.

2. We don't have a remote hole in the default install.

Now, I'm open to the concept of automounting in something malicious, but I'm at a loss of what that would be.

Certainly you could automount a Fonts folder into /Network/Library/Fonts and mess with a user. Perhaps a bad preference file into /Network/Library/Preferences? Although the home folder preferences should take precedence over that.

But no remotely starting ssh that I can think of.

Re:AUTHOR: FAQs answered

[mzs]

Now, I'm open to the concept of automounting in something malicious, but I'm at a loss of what that would be.

I have not tried this so I do not know if it would work. StartupItems are directories. What would happen if you added a /System/Library/StartupItems/evil directory. I hope that by the time /System/Library/StartupItems/NFS loads (which starts the automounter), the system had already looked at all of the startup items to determine the dependencies so this new one would not be picked-up on.

In MacOS X Aqua apps are bundles (really directories). So someone could add a program to your per user startup items. The problem is that this outside party does not know any of the user names on your system so this could be used to plant a trojan that curious user might run in /Applications.

Here is something I have not tried. I believe that whenever a user logs in the programs into Aqua /Library/CFMSupport are run automatically. If this is true, then all an attecker needs to do is mount an /Library/CFMSupport/evil.app directory with a suitible application. Most likely this alone could not be used for a root exploit though. The app would be running with the uid of the login user and so even if an sshd was started on a non-priviledged port, a login for a user with uid 0 should still fail.

Still seems far fetched of how to make this a root remote exploit without something like sshd enabled.

Re:AUTHOR: FAQs answered

[Anonymous Coward]

It could just makes it more work, not necessarily far fetched.

An interesting question would be can OS X automount mount individual files, because the BSD nfsd certainly supports sharing them out...

Re:AUTHOR: FAQs answered

[Anonymous Coward]

what about automounting an application bundle (or a /Library/CFMSupport/evil.app) which happened to have the main executable suid root?

Re:AUTHOR: FAQs answered

[MochaMan]

It then leads you to another page which _you're supposed to read_ before posting comments.
Well, that's normally what regular Slashdotters do [...]

*snicker snicker* You must be new here... When you're done with the sermon, please pass the paper towels... I'm not sure when the last time I blew that much chocolate milk out my nose was.

Re:AUTHOR: FAQs answered

[Cecil]

Well, that's normally what regular Slashdotters do, but then again, you're Mac users.

Well, I was with you until that point. If anything, Mac section of Slashdot typically has a slightly higher signal-to-noise ratio than normal posts. Where slightly higher is still smaller than can be represented by a double.

Really. This site is full of illiterate zealots. Every part of it, not just the Mac section. If you think the people on other stories have mostly read the articles and are posting informed opinions, hahaha, I feel sorry for you man (and please stay away from any article regarding copyright law, for your own legal wellbeing).

Re:AUTHOR: FAQs answered

[Ed_Moyse]

He would be more than "somewhat rude" if he released after 5 days. If you re-read what you posted, you'll see that the policy is that 5 days is an okay length of time to open communication. It explicitly states however, that 5 days is not the time given for a fix:

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

I don't own anything made by Apple, so I'm hardly an Apple zealot, it might be a tricky problem to resolve, and to test thoroughly, in which case 48 days is not excessive. I'd guess it's still apple's fault though ... if they had explained to Cysgod that they were a) actively working on it and took it very seriously but b) it was a hard problem and could they have more time. ... he'd probably have said yes.

(of course this may have happened - we only have one side of the story ;-)

subnet exploit ?!

[didiken]

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.

Re:subnet exploit ?!

[Anonymous Coward]

...speaking of amateur...

DHCP is on by default, that's all that is needed to attack a default client installation.

Subnet == remote. Subnet != local.

Thanks for calling.

Re:subnet exploit ?!

[didiken]

>DHCP is on by default, that's all that is needed
>to attack a default client installation.

Oh hold on young grasshopper.... if you don't get SSH on how can get you get into the machine to write some graffiti ? AFP and FTP don't allow you to get into other home user directory...

Look like DHCP isn't the thing you need

Re:subnet exploit ?!

[Anonymous Coward]

Remote exploit ? Can you say subnet exploit ?! Victim gotta have DHCP and SSH turned on. So not a default client installation exploit.

Listen up, you idiot. The default configuration IS vulnerable. All you need is the DHCP client turned on with the default options. To exploit this vulnerability, all a bad guy needs is a DHCP server in your broadcast domain. The rest is a simple unix break-in. If you don't see that, you're an idiot.

By the way, if you do use DHCP to hand out server IP address you deserve to get rooted.

Do you have any idea what you're talking about? Have you ever configured 400 servers?

Wholly unacceptable

[jjeffrey]

Apple are actually being slower to patch than Microsoft. For a hole this serious - and this is about as serious as security holes get - this is unforgivable. It was a stupid design decision in the first place.

Re:Wholly unacceptable

[Anonymous Coward]

How many 8 billion computer companies have you run? Really? Then, please, have nice hot cup of STFU.

Damn

[Anonymous Coward]

Can you imagine what will happen when the hundreds of Macs on the Internet get hacked? No, me either.

I think Microsoft owns a part of Apple

[Fighting.Cephalopod]

Not to be contrary, but I'm sure the Microsoft investors do buy stock in Apple on occassion, especially when they can turn around and sell that stock for profit later.

Ummm

[Paradox]

That means that they can mount their startup directories over top of yours, and theirs have things configured to start sshd.

Hmm. Indeed. However, my startup share is also my primary partition. I don't play with this much, but wouldn't this imply that I'd notice this, because I'm no longer using the same startup? Would my account even exist, and be using the same picutre and background (last is special case, most users do not do this).

Moreover, they could record my password I suppose, but wouldn't I know something is up and reboot? If I'm suspicious, I'll just change my passwords.

I'm curious here, wouldn't you know?

And in most cases, I never reboot my machine. I move it from network to network in sleep mode. Again, I have never played with this kind of scenario, but it is my thought I'd have to reboot for this to work.

Care to answer this stuff, Todd Knarr?

Re:Ummm

[Todd Knarr]

/ isn't /etc. Basic Unix, and OSX is Unix. Your account would be fine, you wouldn't notice a thing. And you can change your password all day, won't make a difference because in the vulnerable configuration it's the password in my LDAP server that would be checked, not the one you set locally. That's what makes this vulnerability so vicious.

Sleep mode would require some more work, I'd have to play games with mountpoints to get one of root's cron jobs to execute one of my programs, but it can be done once you can control mountpoints.

Re:Ummm

[smcv]

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.

Alternatively, if they knew your OS version, they could replace /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.

Re:Ummm

[Paradox]

Well, okay.

But by changing my etc, overriding my database of users, do you not obliterate my login? Unless you knew my password, of course, in which case I am screwed.

You would need to do this to get sshd running on my machine, would you not? Without my account settings to log in, I can't log in, and immediatly detect the problem. Without overriding my /etc directory, you can't get ssh going.

As for the sleep mode and playing with cron jobs, that would be of a heroic level of difficulty to get that to go off without alerting a user who is actively using their machine.

In any event, I'm confused as to why this is being hyped up so much. It's really a rather odd condition, which a exploitability rating of "difficult and unautomatable" at best.

Re:Ummm

[Todd Knarr]

I wouldn't have to overwrite /etc/passwd, setting an LDAP authentication server via the DHCP parameters would cause that LDAP server to take precedence. If I put an entry in it for "root", your local password file wouldn't ever be checked when checking root's password while your own account would be unaffected (no entry for it in LDAP, so automatic fallback to the local password file).

As for cron, hardly heroic. Trivial in fact. cron reads known files for it's scripts, and it runs known scripts. Mount a directory on top of cron.hourly with a malicious script in it and wait for the turn of the hour. There's usually no scripts in there, so the overwrite wouldn't be noticeable.

I'd rate the exploitability of this as "trivial to exploit, easily automatable", especially considering that it's the default configuration and few people change it without being told to.

Reboot Alternative

[sEEKz]

Just pull the plug if it is locked.

*book: remove battery

You can override a DHCP server, even by mistake

[smcv]

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.

What Apple did Wrong

[0x0d0a]

Are any among us innocent of wanting our 15 minutes?

The problem is that software companies do damned little to reward people that do a good job of turning up and reporting bugs properly. Frankly, if he releases before Apple, then he gets to be quoted all over the place, including mainstream media. He might get to be interviewed. If he instead sits on the problem and waits and he's lucky, he might get a brief note at the bottom of the advisory.

Microsoft and Apple should lay in a big store of T-shirts and mugs, and put a "special thanks" section somewhere in their OS to people that report crucial security holes but don't run out and release them to the public if they don't want a public release. It costs them *far*, *far* less to hand out a "MacGuardian" or somesuch T-shirt and mug and add a mention than it does to deal with the aftermath of a publically available remote root exploit without a fix. Actually, I would have given him a free pass to the next MacWorld or whatnot convention. Have incentives to favor the outcome you want, not discourage it.

On the other hand, Linux is pretty much always full disclosure, since describing problems generally happens in public forums anyway...

Not true

[0x0d0a]

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.

No panic, just reconfigure

[ApocryphX]

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

not true, just turn off ldap

[Anonymous Coward]

As I read it, as long as Ldap, Net info, and other remote directory access services are off this cant harm you.

Mod +1 Informative

[Fighting.Cephalopod]

Thats about it, really.

I had no idea this crap was turned on -

[marcmac]

why isn't it in the system preferences?

I've got a mac laptop, which I use almost exclusively from the command line. ssh in, ssh out, nobody gets hurt. NIS, SMB, ldap all enabled by default, and not in the obvious way (under the preferences window) but via a utility buried in my applications folder.

I normally work on my own network, via dhcp, so it's not a big deal - but I do occasionally take it on the road and use public networks.

damn.

what's unclear?

[KalvinB]

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

Is Apple supposedly exempt from hackers (crackers for the symantically inclined) finding exploits and making them known publically before notifying the company?

Let's try to name another company that never got outted on an exploit before a patch was available. Besides the fact that the workaround IS publically available which will work just as well as a patch.

And how much crap did MS get for a root exploit that DID HAVE a patch available over a month in advance?

Maybe the editor thought it would be better to just pretend Apple was secure so users could just magically have their machines screw up with no way to know how to fix it.

Fortunatly the security advisors had more sense. Word got out and a bandaid is available so they did the smart thing and told everyone how to apply the bandaid while Apple worked on healing the wound.

There is nothing unclear about it.

Ben

Ahh, that's the piece I was missing.

[Paradox]

I was unaware that you could overwrite specific files with nodes that would work as actual files. That's worse than just being able to replace directories.

But it's important to keep things in perspective. This makes it bad for YOU. The vast majority of mac users will never run into a scenario in which this attack is feasible.

Thus I can see Apple's low priority for it.

Further, what exactly is the "right" thing to do here? Simply change the default? What do other OSs do that's better?

Re:Ahh, that's the piece I was missing.

[Todd Knarr]

cron.hourly is a directory. Thus how I could mount a volume over it.

Vast majority? Home users on fully-wired networks, perhaps, but home users with a wireless access point or laptop users who plug into networks they don't control are wide-open to exploits.

The right thing to do is configure it to only trust specific known DHCP servers, or to only trust specific known LDAP and netinfo servers and refuse to talk to any others regardless of what DHCP says. The information on the vulnerability pretty much covered everything you can do.

Re:Ahh, that's the piece I was missing.

[IM6100]

Thus I can see Apple's low priority for it.

Intel shouldn't have had to replace all those Pentium chips with the FDIV bug in them, either. It actually impacted very few people's ordinary usage of their computers.

The question is wether the flames on this one will be flamed or not.

Re:Ahh, that's the piece I was missing.

[IM6100]

correction:

"The question is wether the flames on this one will be fanned or not."

Blaming the messenger...

[Androgynous Coward]

Bad, Mac fanboi, bad!

Someone stick his nose in it...

Uh....-1, Uninformed

[Anonymous Coward]

Post above you explains that you *do not* have to have SSHD on as a service.

Example:

Replace /etc mountpoint to my exported one containing bogus crontab

*/15 * * * * root /path/to/sshd/startup
*/15 * * * * root /path/to/email/ip_addr

If DHCP is enabled on an unswitched subnet (many of those around) then you have just been 0wned by "mr. amateur security person". News at 11.

Re:Uh....-1, Uninformed

[didiken]

Wow, now you've to attack by adding some crap to crontab huh ! ;)

Now you've to be 0wn3d before 0wn3d by a dhcp, LOL

Re:Uh....-1, Uninformed

[Anonymous Coward]

didiken how bout you read the article before you shot off your stupid ass mouth?

I'm not sure you read all the material either

[AnEmbodiedMind]

Exploiting this vulnerability requires that you set up a rogue DHCP server/LDAP server on someone's sub-net. From what I can gather, a well administered network will block unauthorised DHCP traffic at the switch - and the author of the post you are replying to seems to be claiming that they do have their sub-net under control. Obviously many people connect to unsecured sub-nets (e.g. WiFi) so this is a real concern for some users - but not for this person.

Re:I'm not sure you read all the material either

[homesteader]

I've never heard of a way to block DHCP requests at a switch. Really, I'm all ears if there is a way to do it. I once had a trainer bring down a whole region of several hundred users, just by bringing a DHCP server online in a training lab. These were NT servers with NT clients. I don't think it was until Active Directory that DHCP was brought into the fold.

How is DHCP authorized in the Unix world.

Re:Not exploitable in the default configuration, a

[Zan Zu from Eridu]

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.

It Maybe the Least of Their Problems!

[rocker_wannabe]

I don't think a person with root access to my computer would do as much harm as turning FileVault on in OS 10.3 did. It wiped out my old email messages and iTunes library, changed my dock setup, erased a registration file for some software I have so I have to re-enter the registration code, and who knows what else. I'm certainly not going to be on the bleeding edge of Apples OS X releases anymore. "How was I supposed to know that my boss wasn't being literal when he said 'Cut out the middleman!'. Will I be going to jail now?"

Re:Not exploitable in the default configuration, a

[valmont]

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

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

Oh please, spare us your generalizations!

[Anonymous Coward]

You said: "Maybe so it wouldn't be swept under the carpt, like ALL other Apple security problems."

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.

Re:Oh please, spare us your generalizations!

[t0ny]

My point is that non-MS software doesnt get 1% of the publicity that MS software does, especially on Slashdot where it would be of more interest.

If I were a linux user, I would be more interested in reading about potential security flaws in linux than reading about every single flaw in Windows. WTF does somebody who doesnt use Windows care? What I am saying is it is a total bias on the part of non-MS users to pretend that their software is so much more secure, when its not. Its just as bad, and has just as many flaws; all one needs to do is look at security websites to find this out. Instead, they would rather mod my posts down as a troll because Im saying something that, while true, isnt what they want to hear.

From your response, I gather this knee-jerk reaction is effecting over there as well. Security doesnt improve by sticking your head in the sand, guys.

Re:Oh please, spare us your generalizations!

[Anonymous Coward]

After your first post, I though, "There's no way this guy could be any stupider." Yet, here we are.

Re:Oh please, spare us your generalizations!

[Anonymous Coward]

Instead, they would rather mod my posts down as a troll because Im saying something that, while true, isnt what they want to hear.

The truth will set your karma free.

Re:Oh please, spare us your generalizations!

[Anonymous Coward]

At first, I thought anonymous cowards couldnt get any gayer. And yet, there you are...

Re:Oh please, spare us your generalizations!

[Anonymous Coward]

I believe the article's focus was that this is a NEW tactice by Apple. Basically, that Apple had in the past done a good job of focusing on the fix (which of course includes the regression issues as you mentioned).

However, as I am sure you are not implying that any organization that has developers would of course never stonewall and delay (as opposed to just taking a bit too long in honest testing), then I think the real issue you have with the previous poster was his saying that this method of delaying they are accused of is normal for Apple. If I had a nickle for every "developer" that really didn't give a crap about the quality of their work, much less how it effected the end user, and resorted to slimey coverups and "hush" sessions then you can bet I would be able to buy most of those companies top positions.

Yeah, Happy Holidays, asshole.

[Enahs]

This is just the thing I like to read just as I'm about to leave for the next 48 hours. Gee, hope nobody roots the fileserver!

Thanks a million.

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

[IM6100]

I remember using one of these while Gates was saying that you would need "at least 1.5 meg" to multitask.

Correction: in 1982 Gates' company Microsoft produced a product called Xenix. Microsoft Xenix ran, with support for five users plugged into serial ports on dumb terminals, on an 8086 box with 512K of RAM. That was a hell of a lot of memory back in 1982, but the fact that Altos made the Altos 586 box, and Microsoft produced the OS for it, contradicts your claim.

Re: Releasing the information

[Anonymous Coward]

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.

No, if they had released an exploit and said "Crack everything you can before it gets fixed!!!1!", then that would be irresponsible. The responsible procedure after finding a security bug is to immediately post the details to both the author and all relevant security mailing lists, along with a patch if possible, or with workarounds if not (ways to avoid the attack or at least a statement to disable the service entirely until the problem is fixed). I would much rather disable and/or replace a service than find my machine cracked into by the second person to discover the problem.

DON'T READ IF YOU HATE FLAMES ...

[Anonymous Coward]

Suggest you read the following article: The Reality of Bugs as to some insight why the bug in question has not been fixed. The article references Safari, but it is equally valid for any complex software. Yes, you're right - it's a serious bug, but in my opinion (not that it matters) you have managed to make yourself look like an asshole by giving the appearance of demanding certain release dates.

Even I have the good sense to realize that things move on a different timetable in a large organization, and action cannot be taken on every concern immediately. Shuffling people around to deal with a single issue may ultimately delay many issues that are just as pressing.

Sorry, mate. You tried to cast yourself as concerned user and I think you came off as an arrogant ass. Especially considering the timing.

Responsibility

[Anonymous Coward]

Its also pretty irresponsible to post an opinion about a page you obviously haven't read.

Nearly 2 months and two security updates were released since Apple confirmed the bug.

Re:what fud

[Anonymous Coward]

Modding parent post as Flamebait is not "facing it"

It's more like you're in denial.

I remember this guy.

[ITR81]

He had a so call friend running around all the Mac forum sites making comments about his friend was going to blow the lid of this remote access exploit and made very big deal but most folks (macrumors.com) blew it off because I and everyone else knows Apple will fix issues when they arise. Apple has already seeded a copy of 10.3.2 to developers twice in the last two weeks which included new security updates. What I need to ask if he knew Apple had this planned why release it when you know the actual fix is being seeded to developers as of two weeks ago? Dec will be the release date of 10.3.2.

Re:I remember this guy.

[Cysgod]

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.

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. :-) Thanks for writing.

10.3.2 update thus far is only Panther update.

[ITR81]

I would say Apple will probably update Jag. as well but at a later date. Most Mac users have switched or will be switching over the holiday season.

Re:Ummm, no it isn't, fuckface....N/T

[Bob Davis, Retired]

N/T isn't funny.

Security company puts publicity ahead of security.

[inimcus]

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.

moderators -- parent is a troll

[Anonymous Coward]

he didn't even read the article and is spouting off like he knows what he is talking about the issue is that OSX defaults use DHCP to mount, and by mounting a remote /etc or /usr/bin, for example, you can install a trogan without having ssh or root. I wish people would read the damn article before they spread nonsense like the parent post.

RTFA

[Anonymous Coward]

you did not read the article or the explanation of the exploit, and when confronted on this you talk about irrelevant subjects... like graffiti -- it is not about graffiti

say you take your portable into a coffee house that has been exploited (or has someone outside with a stronger wireless signal that is malicious), you "turn on" your computer, it asks via DHCP for the IP address, and also asks for remote mounts. the malicious box returns trogan programs to some mount point, say the directory that contains safari... then when you launch your browser you now have local user access... perhaps not root yet; but good enough. If you are clever you can schedule things to run as root via cron, etc.

in any case, read the fucking article next time before you make yourself look stupid

workarounds don't make it any less of an exploit

[Anonymous Coward]

it is an explot beacuse this isn't the default settings; just beacuse you have a good work-around doesn't make it any less of an exploit.

free utility to protect Openfirmware? Why bother?

[pr0ntab]

Hardening your Mac at boot time.

just enter OpenFirmware and setenv security-mode command. Then setenv security-password "passwd" (or use the "password" command).

Works on Suns too.

About the delay

[Anonymous Coward]

As far as the delay before the fix is concerned, that may be related to whether they think this hole is actually a feature for convenience of setting up new machines.

If so, and if they want to retain the convenience while preventing misuse, then patching becomes more complicated. It might involve creating a UI for getting user approval for the process (via the keyboard/mouse) so that it doesn't connect to an unauthorized directory.

Developing and testing that could take a bit longer than fixing a simple coding problem, or changing some default config files.

Re:Not exploitable in the default configuration, a

[Anonymous Coward]

This remedy will only work if it is a guy who is trying the exploit.

The KnowledgeBase article is up.

[tgibbs]

Apple should have had a fix for this sooner or at least issued a Knowledgebase article

Looks like Apple didn't want to publicize it themselves, since they waited until the exploit was published to issue a
KnowledgeBase advisory. (Basically, it just says to turn off LDAP in Directory Access if you are on an untrusted network).

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

[tomhudson]

correction to your correction (and relevant to today's news)

1. microsoft did not produce xenix - xenix was licensed from SCO
2. microsoft bought a 25% interest in SCO and handled the marketing
3. microsoft later sold its' interest
4. the facts are not contradictory in the sense that Gates has always been prone to lie (just look at his latest stupidity about code quality). Multi-tasking OSs were available w. a gui that ran in 128k - just not made by microsloth.

Newsflash: Networks are non-secure. Sky is falling

[pelorus]

This isn't a "remote root exploit vulnerability" as much as it is a "stupidly turned on by default" and fixed by ... ...turning the service off.

This sort of thing has been an issue in a network running NFS for years, is an issue in any network running DHCP (just how much configuration do you permit to be dynamic?)..

I mean, if you came onto my network, nabbed your DHCP address and my DNS servers forwarded every request of yours to whitehouse.gov...then is it your fault or the vendors fault? Like so many "explots", it requires non-trustworthy infrastructure.

Then Macs Will Always Be Toys

[Vagary]

Thank god crackers are on a monthly crack cycle!

Seriously: if Apple wants their candy-coated machines to be taken seriously, they need to take their customers seriously, and serious customers aren't going to sit there with a hole open until the Apple engineers release patches on tradition. If you can't patch as fast as open source, you have no business selling software.

William Carrell

[Alexander]

Doesn't he work with Infospace? I wonder what a google search for Infospace and Microsoft turns up?

LDAP and Netinfo binding via Airport.

[dmdimon]

Look at this link:
http://macslash.org/comments.pl?sid=4019&ci d=59290 ... just tested LDAP and Netinfo binding via Airport. As I had suspected, it does not work (the AirPort interface is not brought up early enough in boot). ...

Apple KBase article

[Anonymous Coward]

http://docs.info.apple.com/article.html?artnum=324 78

Re:Apple KBase article

[llf4nlp]

Mod this UP!!! It answers the issue.... 'On topic'

Why did it take so long??

[stry_cat]

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

The real question is why did it take 45 days for the public to be informed! When one finds a vulnerability one has a duty to inform the public so that immediate steps can be taken to secure the machine. Just notifying the vendor leaves my machines insecure until the vedor gets around to patching it.

Re:Ummm, no it isn't, fuckface....N/T

[steeviant]

No, that's N/F for not funny.

Much like this post.

Apple's response

[stefanb]

Looks like Apple finally put up an article at http://docs.info.apple.com/article.html?artnum=324 78

Salient quote:

Learn how to configure the Directory Access feature to protect your Mac from a malicious DHCP server.

DISCUSSION

Please note that the exploit requires the malicious DHCP server to be located on your local subnet. For typical home network configurations with a broadband (DSL or cable service) modem and a NAT (Network Address Translation) device, such as Apple's Airport, this exploit is not possible.

[...]

If your Mac is configured to use a directory service consult with your IT administrator before changing any settings.

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

[IM6100]

'The Santa Cruz Operation' was a part of Microsoft.

And really, SCO didn't 'produce' Xenix in the first place. They ported the AT&T UNIX code to the 8086.

Not a true remote exploit

[homesteader]

I just realized this, looking at another poster calling this a subnet exploit. This really isn't a remote root. Maybe 10 years ago you'd call this a remote root. But in today's world of MS 90% market dominance with a whole product line of OS's that a few months ago could each and every one of them could be remotely dazed and controlled through rpc, we really should KNOW what remote exploit really means.

Home users will not be hacked, unless it's by their ISP.

LANs are safe unless you've got some disgruntled worker out there, but that's always the case.

I know security purists will scoff. I'd be one if I wasn't working under an MS loving boss.

Bollocks

[Anonymous Coward]

This has been a feature of NS since the beginning.

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

[tomhudson]

poster wrote:

'The Santa Cruz Operation' was a part of Microsoft.

Thanks for identifying yourself as a troll. IWNBT HAARD

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

[Anonymous Coward]

tomhudson411@yahoo.com
tomhudson@fuckmicrosoft.co m

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

[IM6100]

Hey big dummy:

In 1979, Microsoft licensed UNIX directly from AT&T, but couldn't license the UNIX name, so it called its UNIX variant Microsoft XENIX.

XENIX was originally developed on a DEC Virtual Address Extension (VAX) running the Virtual Memory System (VMS) and a PDP-11 running UNIX V7, albeit now using Microsoft's own in-house minicomputers, and then converted into assembly language specific to the new 16-bit Motorola 68000 and Intel 8086 microprocessors. This put XENIX at the high end of the microcomputer market, which was still dominated by 8-bit machines, but well below the lowest end of the minicomputer market.

In 1979, brothers Doug and Larry Michels founded the Santa Cruz Operation (SCO) as a UNIX porting and consulting company using venture capital from Microsoft, which handed over all further development of Microsoft XENIX to SCO.

To read it at the source,
click hyar, cowboy.

Mod parent up

[Anonymous Coward]

Disagree or not, he isn't trolling.

Are Apple users so thin-skinned that they can't handle any dissent at all?

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

[tomhudson]

... but microsoft only received 25% of the shares in exchange. This is not ownership in the real world.

Workaround.

[ITR81]

1) Disable network authorisation services from obtaining settings from DHCP via "Directory Access". 2) Turn off DHCP support on all interfaces.

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

[IM6100]

Read the text more closely.

Microsoft developed Xenix in-house.

Microsoft handed off development to a third party called SCO.

I was wrong in saying 'SCO was part of Microsoft'. I was not wrong in saying Microsoft produced the first version of Xenix (which they handed off to SCO).

I used to own an Altos 8086 box that ran Microsoft Xenix. It had (C)Microsoft all over the place in bootup messages, etc.

One man's "blackmail"...

[Zhe Mappel]

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

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

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?

Unclear?

[rixstep]

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

Oh really? The 'originator' explains this in full under 'Why did you release this when you did?', and the wiretrip link only confirms this was correct.

And after the fact, it would seem it prompted Apple to act faster.

He's not the only one sitting on an advisory; in general, the experience can be quite similar: they do tend to 'string you along'.

I worry this affects me, please help me verify

[Anonymous Coward]

I am:

1. Heterosexual
2. Do not own a cat
3. Married
4. own a house (not a condo)
5. said house does NOT smell like cat urine and feces
6. do not own a single Anime DVD nor have I a pirated version of the same
7. self made and personally responsible for my actions
8. never follow political party group-think and YES that would also include being a Naderite
9. I very rarely change the default Gnome background and I do NOT have sound themes
10. as above, I look for efficiency and effectiveness, not pretty trinkets
11. I actually liked the Matrix but then it ended there
12. I like neither the current police action in Iraq or the 30 something police actions that preceeded it in the last decade
13. I didn't vote for Bush but am not stupid enough to believe he "stole" the votes
14. I wear what I think is comfortable and do not dress to impress others (and YES that means dressing in the "official individual's uniform" of the time and clique)
15. I actually enjoyed playing around with a earlier OSX build, but since I could not customize the actions, relationships, etc to what I am most effective with I still use 'lunix'
16. I remember what the previous point is referring to, and I remember when BBS was still fun.

So, can someone help me figure out if this is relevant to me and I should get that specialized piece of Sun equipment... errr, that specialized piece of Apple equipment and fire up MAC OSX?