Certificates aren't really great in IT either, whether they're vendor specific or more generic. My own experience has been that people in both low level and advanced IT roles with certs tend to perform very unfavorably when compared to people with nearly the exact same resume, but no certificates.
However when the school repeatedly engages in shenanigans like this, it makes the tech community and well place alumni a *lot* less likely to give money to the school. Instead donations from alumni are being targeted at the department itself and related student activities since it appears the school doesn't have the best interests of the CS department at heart.
It has been pretty obvious from the communication coming from the Provost at WWU that she hasn't the foggiest idea what Computer Science is or how students apply what they learn when they leave.
Top tier employers and startups don't really want vocational school IT folks. Some of the best system administrators I know have Computer Science degrees and use the knowledge that came with those degrees to kick ass, take names, and automate the crap out of systems they manage. They're over an order of magnitude more productive than the kind of system administrator that thinks that "big O" is Oprah's magazine. I've also seen SAs with no degree pick up these skills over time because they see that it makes them more productive.
A bachelor's in computer science, when it's done right, is something that teaches you the theory that allows you pick up most any tool in the field and find your way through to using it and realize it's strengths and shortcomings. IT on specific products or software engineering with specific tools is to Computer Science as the pipes and fittings are to Fluid Dynamics.
Apparently Verizon has a single point of failure for much of its FiOS for the metro areas of Western Washington state in this building as well so the FiOS customers are offline as well right now.
Clownshoes: Have no failover plan and be singly homed.
Meh: Have a failover plan.
Good: Have a failover plan that requires humans and exercise it regularly.
Better: Have a failover plan that is automated and exercise it regularly.
Best: Eliminate single points of failure so failover is turning off the flake or fail and going back to drinking a beer.
Hot/Hot is always a more ideal solution than Hot/Warm or Hot/Cold for disaster recovery (and increasing equipment utilization/ROI), and this event demonstrates why.
What kind of software patches increase screen resolution?
How dare you question him!?! Can't you see that his UID is less than half yours? He clearly knows more about this stuff than you.
Clearly. Through empirical evidence we can see that the cutoff is not half your UID, but an order of magnitude less. _..-* The More You Know
Slightly more seriously, who puts something like a phone up for sale without testing with some engineering prototypes first? And then still has not tested with prototypes before going to manufacture?
Presuming gross ignorance rather than malice as the culprit here seems to stretch credibility some. Does Australia have class-action lawsuits? If so, several lawyers will probably make some money on this.
Well, one obvious example would be that it's now N days into February and only one of the MoAB bugs has a patch, and there is (as usual per Apple policy) no communication about what's being done with respect to the other bugs. Will they ever get fixed? Are they working on them? Who knows? Certainly not the user community and (again per policy) usually not the person that reported the problem either.
My own experience (DHCP remote root a couple years ago) was that it took 2 1/2 months for a fix during which communications was not insanely great, to put it mildly. Even your own examples (9 days, a few weeks) are more than "a few days" which was the original point being refuted here.
Don't get me wrong, it's good that Apple has stepped up their game, from your examples, and are fixing some things in short order. My own experiences lead me to think this is still the exception rather than the rule. It's hard to make an objective judgement though since the data is generally unavailable outside Apple unless you submit things yourself on a regular basis.
However long they're taking, it's not "a few days" and it may make sense for some people to take action to protect themselves in the interim rather than be hanging in the breeze for an indeterminate period of time.
quiet night tonight... not one mac fan boy or anti-mac troll has popped up yet, though im sure its just a matter of time Reversing the broken code that people find and figuring out how to patch it can be a great, fun mental exercise if it's something you're interested in. The personal satisfaction from doing that is sometimes offset by all this seemingly inevitable rabblerousing between fanbois and, their complementary particle, anti-fanbois.
When fanbois and anti-fanbois come into contact they emit a special radiation that causes a temporal shift, known informally as "a colossal total waste of time", for anyone who happens to be reading or listening. For example, you're reading a technical thread, then two of these subsentient particles come into contact. They insist on threadjacking your discussion into an us versus them discussion that only tangentially involves the subject at hand and is logically irritating since it represents a false dilemma. As you skip past the messages looking for some meaningful discussion and swearing about the state of technical discourse, you suddenly discover two hours have passed due to the temporal-moronic radiation.
Maybe people could study training Bayesian filters to delete those messages (or just delete the authors).
It's more risky running "zero day patches" than it is waiting a few days for any bugs with said patch to be flushed out. Given that Apple's not exactly famous for being Johnny-on-the-spot with security fixes, I don't quite get where you get "a few days" from.
When days become weeks and weeks become months waiting for the official patch to arrive, the risk equation (such as it is) may very well be worth it for some groups of users. Maybe not you, but it's no use foreclosing everyone who might be interested from that possibility. And even beyond that there's the whole Freedom to Tinker thing. I personally found working on some of the MoAB fixes to be fun mental exercise.
If you read the article, he says that it's the former, and not the latter.
Specifically, his employer (who would have paid him to do the work, and thus owns the exploit code in question) has said that they won't release the exploit until Apple has had a chance to release a fix.
The "apple lawyer" crap is pure ungrounded speculation.
I did, in fact, read the article. We agree on the first point, whether it his him or his employer making a call on releasing the details is not particularly relevant (except to his employment status). And they may not be able to release details because they may have been under contract to Apple to find the problems.
Upon reviewing the quote in question again, I'm going to have to disagree with you about "ungrounded speculation". From both the article and the mailing list post (see the article above for the links):
Secureworks absolutely insists on being exceedingly responsible and doesn't want to release any details about anything until Apple issues a patch. Whether or not this position was taken after a special ops team of lawyers parachuted in out of a black helicopter is up for speculation.
There is no reason to include the comment about special ops lawyers parachuting out of black helicopters except to drive speculation about Apple Legal (or Secureworks Legal). In either case, it is a device to fuel speculation that lawyers have intervened to force the "exceedingly responsible" "position was taken" absolving him of the burden of disclosing further details.
Again, the "exceeding responsibility" of this position on full disclosure can be fairly debated, but inserting a sentence to try and deflect blame through insinuating you were forced into the position is disingenuous. Either you provide evidence that your hand was forced or take responsibility for your actions. You don't say you're being responsible, and then when people disagree point at someone else and say "it's her fault."
Further, "doesn't want to release any details about anything until Apple issues a patch" could turn out to be inconsistent with the actions taken later on in that same email. He gives specific detail on how to try and trigger a timing attack on the Centrino driver. If it's a related attack that is the posited Apple security hole, then it would appear to be some details about something. On top of what we already know about the posited problem, which is a lot more than nothing.
And lastly, there is the debatable point on full disclosure. Waiting until Apple issues a patch is not exceedingly responsible. It is exceedingly irresponsible. It leaves users hanging in the breeze, potentially vulnerable to a remote root for as long as the vendor cares to take to correct the issue, which could be several months. For instance, your Ford truck may explode, but we're not going to tell you how or why until Ford issues a service bulletin and recall.
When I published my OS X remote root (link-local remote root for the pedantic), a poorly chosen use for DHCP, Apple had advance notice of when I was going to release it, numerous avenues to attempt contact and I didn't hear one peep from Apple Legal. That this guy was suddenly chilled and can't produce evidence of it other than making vague insinuations just sounds hoakey to me.
If he doesn't feel okay about releasing details until they've patched the driver that's one thing. But insinuating that the big bad lawyers have silenced you is quite another. The only circumstance I can think of where they could actually be legitimately silenced is: they are/were being paid to do pen testing for Apple, they submitted this bug, they blabbed about it at a conference when they were under a contractual NDA, they're now claiming they didn't say enough violate the NDA and are remaining mum until the rest of the details go public.
Given the nature of this scenario (i.e. that they'd have to have violated an NDA to wind up where they are insinuating they are now), I'm not overwhelmed with trust for the researchers who are positing this security hole's existence. On the other hand, I was led on and on by Apple waiting for them to release a patch for my earlier security issue that had a similar attack vector and security impact to this posited new security hole. If these researchers are actually waiting, we may all have to sit around for a good long while before the proof is actually shown.
This dilemma is more evidence of why full disclosure is a good idea.
I should note, that he did have a disclaimer on his own site's review of the book that he got a free review copy. Why this wasn't in the slashdot review... well, only slashdot's editors can answer that.
I'm still curious why he gets lots of free advance copies of books. (Where do I sign up...)
The book isn't even available yet (see the link from bn.com). One must presume the reviewer got an advance copy from the publisher, who may have given it away expecting a favorable review.
What reason do we have to to believe that this review isn't complete astroturf? What is his relation that caused him to get an advance copy?
It may well be an honest review, but I'm inclined to be a lot more skeptical. Especially since there is no mention in the review of the fact that he got an advance copy.
I have to admit, I find slashdot's schizophrenic reactions to these Mac security issues quite interesting. When I gave Apple 2 months that wasn't enough time and I was an awful evil person for informing people how to workaround the problem.
But when people 0-day this stuff then it is suddenly okay and we don't mind it's protecting the users, yay for community!
Good for these folks for working towards the bottom of all this stuff though. Yet another case of automagically changing settings to make life "easier" for the users turning around and causing trouble...
dynamic_pager has NO UPPER BOUND on how much disk it will eat. One nice thing about swap partitions is that you can at least set a hard limit. Once you get a certain distance into swap, disk contention ramps up very, very quickly and you wind up disk-bound for all activities and performance suffers badly as a result.
You can mitigate it with the ulimits to some degree, but it would also be useful to have more fine-grained control of swap usage. "Swapiness" indeed.
How about max-swap-bytes-per-process or max-cache-demand-swap-bytes?
I've seen several OS X applications run away into swap in my time. The whole machine is rendered pretty much unusable until it either exhausts the disk or its address space. For interactivities sake, I think it could be suggested that they are not taking the right approach or there is more work to be done and the status quo severely hurts the user experience.
A separate issue is that OS X does (or at least did in historical versions) bad bad things when it ran out of disk. And dynamic_pager's behavior tended to have the result of eating the whole disk if anything went wrong, leading to even larger problems. Serious bad mojo time.
You could probably capture KUOW's MP3 stream of their live programming and make yourself an MP3 of the week's Car Talk show (or anything else they have for that matter).
Between Clear Channel and Infinity there isn't much else left in Seattle. KPLU, KUOW and a stack of CD's. Although I'm getting a bit annoyed that the NPR's Morning Edition is running the same "news of the weird" blurbs that the morning zoo shows talk about on length and that I saw on Fark 2 days ago.
Can't even dream of picking up KEXP way out in the county, the commercial FM stations around Seattle bleed all over everything.
The signal takes around 0.107ms to get there, so about 0.214ms round trip + processing time to handle the packet and send a response. I see roundtrip delays (ping) on the order of 0.4 ms on my switched network and 2.5 ms on my wireless network. I think the odds are above zero that you could beat the DHCP server to reply in this scenario, and so long as they are, there is an issue that needs to be dealt with.
In the end, people are just making excuses about why the attack might be kind of hard to pull off. And I don't disagree, it is kind of hard to pull off generally speaking, and most people, they probably won't be attacked anyway. But just because most people don't get their cars stolen and their homes robbed doesn't mean we leave them unlocked.
The goal for me is to help people protect themselves, so the risk that is there, however small it may be according to some, can be reduced to zero.
Malicious user sits 2 miles away with laptop and WiFi card and a good antenna pointed at your house. Waits for DHCP requests to come across the network, sends responses, and if lucky, gets one your clients to recieve its response before your base station's. That's all there is to it.
While I haven't tested this, I don't think that most base stations capture broadcast packets that look like DHCP requests and filter them out of the packet stream that they are sharing with the rest of the network. If this is the case, hurrah for the vendors that do this with their wireless AP's.
Mac OS X cannot be configured to only accept DHCP responses from one specific server. If it did have this ability it would be another way to mitigate the risks of this vulnerability.
Given the description you provide, your network can be had. Better to be safe than sorry and disable the settings that allow this vulnerability to exist.
...if they get on my wireless network, what are the chances that my wireless machine will leave an already established lease to jump ship
The chances are that if you read the original advisory the main vulnerability identified required a reboot. At reboot, your Mac will associate with the first DHCP server it hears from. This may or may not be a malicious one. The chances are, of course, not 100%, but they are above zero, and thus something for people to know about, so they can protect themselves.
And lets not forget the whole problem of "ssh" is not on by default.... Out of the box, you are safe.
BZZT! Out of the box you are vulnerable. A malicious person can use the mount maps to mount files into your filesystem in places that guarantee execution as root. Then you are running sshd, even if you thought you weren't. This also, is covered in the advisory.
You trust the network (and DHCP) to tell you how to talk to the network. (IP address, netmask, gateway, DNS, etc.) And then you use things like SSL and SSH host keys to make sure you are really talking to who you think you are. You don't trust it with root access to your machine to do whatever it wants to.
The argument I make in the "philosophical details" section of the advisory is that realistically you should not trust a network for user authentication information without at least *some* user interaction so the user is aware of what is going on. To do otherwise is irresponsible and puts end users at risk.
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.
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.)
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....
Slashdot Mirror
Certificates aren't really great in IT either, whether they're vendor specific or more generic. My own experience has been that people in both low level and advanced IT roles with certs tend to perform very unfavorably when compared to people with nearly the exact same resume, but no certificates.
However when the school repeatedly engages in shenanigans like this, it makes the tech community and well place alumni a *lot* less likely to give money to the school. Instead donations from alumni are being targeted at the department itself and related student activities since it appears the school doesn't have the best interests of the CS department at heart.
It has been pretty obvious from the communication coming from the Provost at WWU that she hasn't the foggiest idea what Computer Science is or how students apply what they learn when they leave.
Top tier employers and startups don't really want vocational school IT folks. Some of the best system administrators I know have Computer Science degrees and use the knowledge that came with those degrees to kick ass, take names, and automate the crap out of systems they manage. They're over an order of magnitude more productive than the kind of system administrator that thinks that "big O" is Oprah's magazine. I've also seen SAs with no degree pick up these skills over time because they see that it makes them more productive.
A bachelor's in computer science, when it's done right, is something that teaches you the theory that allows you pick up most any tool in the field and find your way through to using it and realize it's strengths and shortcomings. IT on specific products or software engineering with specific tools is to Computer Science as the pipes and fittings are to Fluid Dynamics.
They do. It sounds like the involves-humans failover process failed somehow.
Looks like from twitter comments that Verizon finished their failover since people's FiOS is coming back now.
Apparently Verizon has a single point of failure for much of its FiOS for the metro areas of Western Washington state in this building as well so the FiOS customers are offline as well right now.
Hot/Hot is always a more ideal solution than Hot/Warm or Hot/Cold for disaster recovery (and increasing equipment utilization/ROI), and this event demonstrates why.
Clearly. Through empirical evidence we can see that the cutoff is not half your UID, but an order of magnitude less.
_..-* The More You Know
Wait a second. Are we saying that Taco is omniscient?!? *shudder*
Unfortunately for him, the counter can overflow.
What kind of software patches increase screen resolution?
How dare you question him!?! Can't you see that his UID is less than half yours? He clearly knows more about this stuff than you.
Clearly. Through empirical evidence we can see that the cutoff is not half your UID, but an order of magnitude less.
_..-* The More You Know
Slightly more seriously, who puts something like a phone up for sale without testing with some engineering prototypes first? And then still has not tested with prototypes before going to manufacture?
Presuming gross ignorance rather than malice as the culprit here seems to stretch credibility some. Does Australia have class-action lawsuits? If so, several lawyers will probably make some money on this.
Well, one obvious example would be that it's now N days into February and only one of the MoAB bugs has a patch, and there is (as usual per Apple policy) no communication about what's being done with respect to the other bugs. Will they ever get fixed? Are they working on them? Who knows? Certainly not the user community and (again per policy) usually not the person that reported the problem either.
My own experience (DHCP remote root a couple years ago) was that it took 2 1/2 months for a fix during which communications was not insanely great, to put it mildly. Even your own examples (9 days, a few weeks) are more than "a few days" which was the original point being refuted here.
Don't get me wrong, it's good that Apple has stepped up their game, from your examples, and are fixing some things in short order. My own experiences lead me to think this is still the exception rather than the rule. It's hard to make an objective judgement though since the data is generally unavailable outside Apple unless you submit things yourself on a regular basis.
However long they're taking, it's not "a few days" and it may make sense for some people to take action to protect themselves in the interim rather than be hanging in the breeze for an indeterminate period of time.
When fanbois and anti-fanbois come into contact they emit a special radiation that causes a temporal shift, known informally as "a colossal total waste of time", for anyone who happens to be reading or listening. For example, you're reading a technical thread, then two of these subsentient particles come into contact. They insist on threadjacking your discussion into an us versus them discussion that only tangentially involves the subject at hand and is logically irritating since it represents a false dilemma. As you skip past the messages looking for some meaningful discussion and swearing about the state of technical discourse, you suddenly discover two hours have passed due to the temporal-moronic radiation.
Maybe people could study training Bayesian filters to delete those messages (or just delete the authors).
When days become weeks and weeks become months waiting for the official patch to arrive, the risk equation (such as it is) may very well be worth it for some groups of users. Maybe not you, but it's no use foreclosing everyone who might be interested from that possibility. And even beyond that there's the whole Freedom to Tinker thing. I personally found working on some of the MoAB fixes to be fun mental exercise.
I did, in fact, read the article. We agree on the first point, whether it his him or his employer making a call on releasing the details is not particularly relevant (except to his employment status). And they may not be able to release details because they may have been under contract to Apple to find the problems.
Upon reviewing the quote in question again, I'm going to have to disagree with you about "ungrounded speculation". From both the article and the mailing list post (see the article above for the links):
There is no reason to include the comment about special ops lawyers parachuting out of black helicopters except to drive speculation about Apple Legal (or Secureworks Legal). In either case, it is a device to fuel speculation that lawyers have intervened to force the "exceedingly responsible" "position was taken" absolving him of the burden of disclosing further details.
Again, the "exceeding responsibility" of this position on full disclosure can be fairly debated, but inserting a sentence to try and deflect blame through insinuating you were forced into the position is disingenuous. Either you provide evidence that your hand was forced or take responsibility for your actions. You don't say you're being responsible, and then when people disagree point at someone else and say "it's her fault."
Further, "doesn't want to release any details about anything until Apple issues a patch" could turn out to be inconsistent with the actions taken later on in that same email. He gives specific detail on how to try and trigger a timing attack on the Centrino driver. If it's a related attack that is the posited Apple security hole, then it would appear to be some details about something. On top of what we already know about the posited problem, which is a lot more than nothing.
And lastly, there is the debatable point on full disclosure. Waiting until Apple issues a patch is not exceedingly responsible. It is exceedingly irresponsible. It leaves users hanging in the breeze, potentially vulnerable to a remote root for as long as the vendor cares to take to correct the issue, which could be several months. For instance, your Ford truck may explode, but we're not going to tell you how or why until Ford issues a service bulletin and recall.
When I published my OS X remote root (link-local remote root for the pedantic), a poorly chosen use for DHCP, Apple had advance notice of when I was going to release it, numerous avenues to attempt contact and I didn't hear one peep from Apple Legal. That this guy was suddenly chilled and can't produce evidence of it other than making vague insinuations just sounds hoakey to me.
If he doesn't feel okay about releasing details until they've patched the driver that's one thing. But insinuating that the big bad lawyers have silenced you is quite another. The only circumstance I can think of where they could actually be legitimately silenced is: they are/were being paid to do pen testing for Apple, they submitted this bug, they blabbed about it at a conference when they were under a contractual NDA, they're now claiming they didn't say enough violate the NDA and are remaining mum until the rest of the details go public.
Given the nature of this scenario (i.e. that they'd have to have violated an NDA to wind up where they are insinuating they are now), I'm not overwhelmed with trust for the researchers who are positing this security hole's existence. On the other hand, I was led on and on by Apple waiting for them to release a patch for my earlier security issue that had a similar attack vector and security impact to this posited new security hole. If these researchers are actually waiting, we may all have to sit around for a good long while before the proof is actually shown.
This dilemma is more evidence of why full disclosure is a good idea.
I should note, that he did have a disclaimer on his own site's review of the book that he got a free review copy. Why this wasn't in the slashdot review... well, only slashdot's editors can answer that.
I'm still curious why he gets lots of free advance copies of books. (Where do I sign up...)
The book isn't even available yet (see the link from bn.com). One must presume the reviewer got an advance copy from the publisher, who may have given it away expecting a favorable review.
What reason do we have to to believe that this review isn't complete astroturf? What is his relation that caused him to get an advance copy?
It may well be an honest review, but I'm inclined to be a lot more skeptical. Especially since there is no mention in the review of the fact that he got an advance copy.
I have to admit, I find slashdot's schizophrenic reactions to these Mac security issues quite interesting. When I gave Apple 2 months that wasn't enough time and I was an awful evil person for informing people how to workaround the problem.
But when people 0-day this stuff then it is suddenly okay and we don't mind it's protecting the users, yay for community!
Good for these folks for working towards the bottom of all this stuff though. Yet another case of automagically changing settings to make life "easier" for the users turning around and causing trouble...
You can mitigate it with the ulimits to some degree, but it would also be useful to have more fine-grained control of swap usage. "Swapiness" indeed.
How about max-swap-bytes-per-process or max-cache-demand-swap-bytes?
I've seen several OS X applications run away into swap in my time. The whole machine is rendered pretty much unusable until it either exhausts the disk or its address space. For interactivities sake, I think it could be suggested that they are not taking the right approach or there is more work to be done and the status quo severely hurts the user experience.
A separate issue is that OS X does (or at least did in historical versions) bad bad things when it ran out of disk. And dynamic_pager's behavior tended to have the result of eating the whole disk if anything went wrong, leading to even larger problems. Serious bad mojo time.
You could probably capture KUOW's MP3 stream of their live programming and make yourself an MP3 of the week's Car Talk show (or anything else they have for that matter).
Between Clear Channel and Infinity there isn't much else left in Seattle. KPLU, KUOW and a stack of CD's. Although I'm getting a bit annoyed that the NPR's Morning Edition is running the same "news of the weird" blurbs that the morning zoo shows talk about on length and that I saw on Fark 2 days ago.
Can't even dream of picking up KEXP way out in the county, the commercial FM stations around Seattle bleed all over everything.
The signal takes around 0.107ms to get there, so about 0.214ms round trip + processing time to handle the packet and send a response. I see roundtrip delays (ping) on the order of 0.4 ms on my switched network and 2.5 ms on my wireless network. I think the odds are above zero that you could beat the DHCP server to reply in this scenario, and so long as they are, there is an issue that needs to be dealt with.
In the end, people are just making excuses about why the attack might be kind of hard to pull off. And I don't disagree, it is kind of hard to pull off generally speaking, and most people, they probably won't be attacked anyway. But just because most people don't get their cars stolen and their homes robbed doesn't mean we leave them unlocked.
The goal for me is to help people protect themselves, so the risk that is there, however small it may be according to some, can be reduced to zero.
Malicious user sits 2 miles away with laptop and WiFi card and a good antenna pointed at your house. Waits for DHCP requests to come across the network, sends responses, and if lucky, gets one your clients to recieve its response before your base station's. That's all there is to it.
While I haven't tested this, I don't think that most base stations capture broadcast packets that look like DHCP requests and filter them out of the packet stream that they are sharing with the rest of the network. If this is the case, hurrah for the vendors that do this with their wireless AP's.
Mac OS X cannot be configured to only accept DHCP responses from one specific server. If it did have this ability it would be another way to mitigate the risks of this vulnerability.
Given the description you provide, your network can be had. Better to be safe than sorry and disable the settings that allow this vulnerability to exist.
...if they get on my wireless network, what are the chances that my wireless machine will leave an already established lease to jump ship
... Out of the box, you are safe.
The chances are that if you read the original advisory the main vulnerability identified required a reboot. At reboot, your Mac will associate with the first DHCP server it hears from. This may or may not be a malicious one. The chances are, of course, not 100%, but they are above zero, and thus something for people to know about, so they can protect themselves.
And lets not forget the whole problem of "ssh" is not on by default.
BZZT! Out of the box you are vulnerable. A malicious person can use the mount maps to mount files into your filesystem in places that guarantee execution as root. Then you are running sshd, even if you thought you weren't. This also, is covered in the advisory.
You trust the network (and DHCP) to tell you how to talk to the network. (IP address, netmask, gateway, DNS, etc.) And then you use things like SSL and SSH host keys to make sure you are really talking to who you think you are. You don't trust it with root access to your machine to do whatever it wants to.
The argument I make in the "philosophical details" section of the advisory is that realistically you should not trust a network for user authentication information without at least *some* user interaction so the user is aware of what is going on. To do otherwise is irresponsible and puts end users at risk.
I've been pretty low-key about this until today, so I'm not sure what you're talking about. I'd be very interested to see links to the comments you refer to.
:-) Thanks for writing.
I may have reason to believe that the seeded copies of 10.3.2 are, in fact, still vulnerable to this bug by default. But I can't say for sure because if I did know for sure, that would mean that someone violated their NDA and that would be bad news for someone. Live in fear of Apple Legal.
It's not a real happy conundrum. I found out one week ago that Apple was planning to release in December after having previously agreed in principle to a date sometime in November. I felt that I was being strung along like a ball of yarn, but I didn't want to be unreasonable so I gave them 1 more week. They never replied and cut off all contact with me. And here we are.
And FWIW, since it's been mentioned, I'm not an Apple hater, I love my PowerBook.
Thought I'd field some of the more mentioned questions and misconceptions here...
/. got around to finally posting the article. Sorry it has taken me so long to respond.)
Is my machine safe if I have the root account "turned off"?
No. The account attacking can be uid 0 and have any other name in the universe that is a valid account name.
Is my machine safe if I have all remote access services "turned off"?
*NO*, and please quit saying it is. This exploit allows malicious people full control of where things are mounting on your system. They can mount malware anywhere. Including places that can virtually guarantee executiong of their target code. For example, an attacker could cause their evil data to be mounted in place of crontabs and have their fake root's crontab point to an evil executable mounted there or somewhere else.
Why did you release this when you did?
This was an exploitable remote root vulnerability. After Apple reneged on the Nov. 3rd release date I gave them 2-3 weeks. After the 2-3 weeks were up, I asked for the status and they said "December". Meanwhile, users are left exposed and independent rediscovery seemed fairly likely. And maybe by someone less scrupulous than myself. I felt I was being strung along and that the issue may never get properly addressed so I set a hard deadline at that point. They didn't meet it, and I issued my advisory.
It would not be fair of me to let Mac users hang out in the breeze for more than 2 months on an issue of this magnitude. You may disagree, but I have no regrets about my actions and feel that I was more than fair to Apple Computer and its users.
(As I mentioned in a previous post, I was out horseback riding by the time
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....