The Story of a Simple and Dangerous OS X Kernel Bug

RazvanM writes "At the beginning of this month the Mac OS X 10.5.8 closed a kernel vulnerability that lasted more than 4 years, covering all the 10.4 and (almost all) 10.5 Mac OS X releases. This article presents some twitter-size programs that trigger the bug. The mechanics are so simple that can be easily explained to anybody possessing some minimal knowledge about how operating systems works. Beside being a good educational example this is also a scary proof that very mature code can still be vulnerable in rather unsophisticated ways."

Comments

1?

[bennomatic]

frist psot?

Re:1?

[geoffrobinson]

You have the first psot I've ever seen.

Re:1?

[bennomatic]

Yeah, I'm kind of ashamed, but it's so rare to get here before anyone else, and I had nothing useful to say.

Re:1?

[Anonymous Coward]

Please read this guide on appropriate first post content.

4 fscking years

[should_be_linear]

no wonder for sotware lonely nerds living in parents basement are doing in their free time... oh wait...

Re:4 fscking years

[Anonymous Coward]

Oh look, I think it's trying to communicate, perhaps we can find a translator. Does anyone speak yiddiotish?

Age is irrelevant, resistance is futile.

[girlintraining]

"Beside being a good educational example this is also a scary proof that very mature code can still be vulnerable in rather unsophisticated ways."

Since when did the age of code become a metric for evaluating its trustworthiness? Code should only be trusted after undergoing in-depth analysis by people with training and experience in information security. Code should also be written with security in mind from the beginning. The story of this kernel bug is simple and goes like this: "I was in a hurry."

Re:Age is irrelevant, resistance is futile.

[Idiot with a gun]

I believe the implied meaning of this is "in the absence of exhaustive security analysis, a code's age/maturity is one of the better indicators of its security". While I'm not particularly sold on this notion myself, it does bear a lot of semblance to the idea that code can be proven "secure" if it stands after a multitude of random attacks, which is basically one of the tenets of OSS.

A million monkeys with typewriters....

Re:Age is irrelevant, resistance is futile.

[Secret Rabbit]

Well, assuming that the code is actively (and properly) maintained, then that isn't a bad metric. Essentially, it's because any security flaw is the result of a bug. It's just a bug that can be exploited. So, if the code is maintained properly, then bug fixes will be continuous and as such, reduce the number of exploitable bugs.

Good metric, yes. Absolute metric, no.

"""... which is basically one of the tenets of OSS."""

And where did you hear that? Because, I never have and I've been around for a while.

Re:Age is irrelevant, resistance is futile.

[Kjella]

Well... I think that depends a lot on the reason why it's old code. I've met my share of code with the warning "There be dragons!".

Re:Age is irrelevant, resistance is futile.

[_Sprocket_]

While I'm not particularly sold on this notion myself, it does bear a lot of semblance to the idea that code can be proven "secure" if it stands after a multitude of random attacks, which is basically one of the tenets of OSS.

I'm pretty sure that's not a tenet of OSS. If someone is pushing that as a tenet, then they really need to pay closer attention to history. A history of resilience is a nice metric - but it's not "proof" that code is bug-free rather just that nobody has found a given bug or made it public. People who get caught up in vulnerability counts forget that the real metric is response to a given vulnerability.

One tenet you hear bandied about is "given enough eyeballs, all bugs are shallow." Criticism tends to revolve around whether enough eyeballs have been put to any particular piece of code. Although one could argue that it's not just the number of eyeballs - but whether said eyeballs have the training to look for particular kinds of bugs that might not show up in normal use of the given code. None of that has anything to do with the frequency of attack.

Re:Age is irrelevant, resistance is futile.

[johanatan]

Essentially, it's because any security flaw is the result of a bug. It's just a bug that can be exploited. So, if the code is maintained properly, then bug fixes will be continuous and as such, reduce the number of exploitable bugs.

It depends on your scope of consideration. Design flaws are not 'bugs' in the traditional sense of the word (i.e., implementation-related). However, if you expand your scope to include design specs then your statement is true. There do exist though exploits of perfectly-implemented but imperfectly-designed code.

Re:Age is irrelevant, resistance is futile.

[Anonymous Coward]

The prison niggers appreciate those crackers in Apple be making iphones. Now we know we have whitey looking after iphones and we look to take white chicks up the ass. It be the best thing to run a train on a chubby low self esteem white chick, fucking her pussy and asshole all night long. It is almost as good as tapping some puerto rican ass, but that shit is tighter and when that bitch get violent (PR chicks always do) we just duct tape that mouth shut while we take turns cumming in that ass over and over. Mexican bitches be the best cause you can run up on a bitch with a fat ass in broad daylight and run a pimp train on that bitch in her anus and that immigrant husband won't do shit. When we got some gay ass niggers who want to fuck some male asshole, we just run up on a mexican man, who they gonna report. Sometimes we just abduct the bitch to our projects apartment for the week and fuck the shit out of her, until we get tired of that bitch. White bitches are more fun though, sometimes when the bitch is chubby and horny enough we just fuck her through for 2 weeks and come back in another week cause her fat ass is ready for more. Smack bitches with a 10 inch cock. I once raped this indian chick, she was mad weak, so i got my boys to run a train on her that lasted 3 days. She looked like frosty the snowman after we all got done with cumming on her. She got that shit so hard she must of spit cum for a month. I recently visted her and punched her in the face before I got inside that ass again. We be abnormal.

Re:Age is irrelevant, resistance is futile.

[ClosedSource]

You're right and it's worth remembering that some bugs will cause incorrect behavior on a cycle that is so long that our Sun will go nova before it shows up.

Re:Age is irrelevant, resistance is futile.

[Jurily]

There are also cases where this just isn't true. See malloc.

Re:Age is irrelevant, resistance is futile.

[Jurily]

I've met my share of code with the warning "There be dragons!".

The word "fuck" in the comments is a much better metric. If it's more than one for the same function, it's time to pay attention.

Re:Age is irrelevant, resistance is futile.

[Anonymous Coward]

...appreciate those crackers in Apple be making iphones....

I noticed you used the word "crackers" instead of "hackers". Interesting.

Re:Age is irrelevant, resistance is futile.

[Hognoxious]

Since when are age and maturity synonyms?

Re:Age is irrelevant, resistance is futile.

[TheRaven64]

The general assumption is that code that is old has been run a lot (meaning it has been tested) and has been inspected for bugs periodically. Of course, this doesn't apply to code that's been sitting in a cupboard for a long time, but all other things being equal a part of a program that is two years old is likely to contain fewer bugs than a brand new part, because they will have contained approximately the same number on release, but the older part will have had some fixed.

Re:Age is irrelevant, resistance is futile.

[hairyfeet]

Just look at the WMF bug for an example, which affects everything from Win3.0 up. I've always wondered how much truly old and crufty crap is "brewing in the bowels" of the big three OSes just waiting to fall apart. I'm guessing it isn't as bad a problem in OSX and Linux though as backwards compatibility isn't such a big selling point with them.

After all nobody really expects programs written for 10.0 on OSX or for whatever version Debian was out in 01 to actually work now, but considering the fact that I still run some of my Win9X games in WinXP32/64 now means they have to have some seriously old code brewing in the bowels to run code that damned old. Of course without all that backwards compatibility then their wouldn't be any reason to buy the latest and greatest (see how bad Vista boned BC) but why they didn't go with a Parallels for Mac approach instead of the Virtual PC "XP Mode" is beyond me.

Re:Age is irrelevant, resistance is futile.

[LO0G]

In my experience, a code's age/maturity is one of the better indicators of it's INsecurity.

We've learned a LOT about security (and more importantly about writing secure code) over the past 10 years.

10 years ago, nobody knew about arithmetic overflow vulnerabilities or heap overflow vulnerabilities. Now every coder needs to worry about them. And all that old code was written non knowing about those vulnerabilities so it's highly likely to contain issues.

Re:Age is irrelevant, resistance is futile.

[Idiot with a gun]

"""... which is basically one of the tenets of OSS."""

And where did you hear that? Because, I never have and I've been around for a while.

It's implied, in my opinion. Because OSS stuff rarely gets the benefit of expensive and time consuming security analysis. Mostly because often nobody has the money/time/skill set, or because the code moves so damned fast. Admittedly, this setup appears to work quite nicely (I'm a *nix user myself).

Re:Age is irrelevant, resistance is futile.

[PC and Sony Fanboy]

I think he meant "White folk who think they're cool". Not cracking-hackers. Crackers.

Re:Age is irrelevant, resistance is futile.

[Anonymous Coward]

Newsflash: code maturity has always been and probably always will be one of the most important metrics of code reliability. Mainly because it can be objectively determined. I will trust a piece of code that has been run billions of times by millions of users in many thousands of setups over some code that has "undergone in depth analysis" any time.

Re:Age is irrelevant, resistance is futile.

[Anonymous Coward]

Wasn't one of the selling points that it was based on UNIX which had a long history of security compared to another OS?
And how did they manage to make a deBaSeD UNIX that cannot multitask when downloading updates?

Re:Age is irrelevant, resistance is futile.

[M. Baranczak]

Really now... what percentage of non-free, commercial software do you think gets subjected to "expensive and time consuming security analysis"?

Re:Age is irrelevant, resistance is futile.

[pclminion]

One tenet you hear bandied about is "given enough eyeballs, all bugs are shallow."

Given just a little thought it's easy to see that this axiom is untrue. Were it true, any organization (company or OSS leadership) could produce bug-free code by using a huge number of developers. And being able to claim that one's software is 100% bug free is a great marketing cookie, so if it were possible, you would expect many companies to be doing it, and many companies to be claiming 100% correct code. Yet we do not see this in software engineering. There is no perfect code, nobody claims it, and -- we do NOT throw a huge number of developers at a piece of code. The problem is that the communication overhead between developers becomes so large that the task becomes unmanageable. Anybody who doesn't get this needs to read Brooks' "The Mythical Man Month".

Given enough eyeballs, a group of people becomes incapable of making directed progress on an engineering task. That is a far more accurate axiom.

Re:Age is irrelevant, resistance is futile.

[Thinboy00]

Essentially, it's because any security flaw is the result of a bug. It's just a bug that can be exploited. So, if the code is maintained properly, then bug fixes will be continuous and as such, reduce the number of exploitable bugs.

It depends on your scope of consideration. Design flaws are not 'bugs' in the traditional sense of the word (i.e., implementation-related). However, if you expand your scope to include design specs then your statement is true. There do exist though exploits of perfectly-implemented but imperfectly-designed code.

Bug == Something that bugzilla tracks and is not:

• A feature request
• Marked INVALID or similar
• FIXED

Re:Age is irrelevant, resistance is futile.

[Thinboy00]

How about this: As the number of developers approaches infinity, the number of nontrivial bugs approaches zero, but the total number of bugs approaches infinity (not necessarily at the same rate as the developers).

Re:Age is irrelevant, resistance is futile.

[_Sprocket_]

"The Mythical Man Month" deals with keeping software projects on schedule. It notes that adding developers to a project will not speed up development and, in fact, will slow it down. I'm not sure this is the same thing.

The "...all bugs are shallow" phrase comes from The Cathedral and the Bazaar and is an informal summery of the following:

8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

It's not necessarily saying one puts large numbers of developers on bug hunts and implementing fixes. Simply auditing code could be part of this process (or pen-testing, beta-testing, etc.).

As for why companies don't do this? Because being "bug free" isn't as important as other considerations. Heck, some companies ship code with known bugs. Schedules (development, marketing, sales, etc.), development costs, feature sets, etc. tend to push software release as much, if not more, than bug counts. Even OSS pundits preach "release early, release often"; from the very same document that claims we can achieve a point where "all bugs are shallow."

Re:Age is irrelevant, resistance is futile.

[Anonymous Coward]

Remember how Something Awful/Anonymous/ED liked to claim that the reason there were so few trojans and viruses on Macs was because "nobody used them"? I guess they are flat out wrong now days, as more people are using Macs, more vulnerabilities are being found.

Re:Age is irrelevant, resistance is futile.

[corrie]

All true, but the important thing about OSS is really this: The actual possibility for many eyeballs exists.

No assumptions or predictions about the quality of the hypothetical eyeballs need to be entertained.

Re:Age is irrelevant, resistance is futile.

[_Sprocket_]

All true, but the important thing about OSS is really this: The actual possibility for many eyeballs exists.

No assumptions or predictions about the quality of the hypothetical eyeballs need to be entertained.

Depends on the context. If you're talking about theory, then I'd agree. If you're using this as a practical concept, then you've got to start digging in to the details.

Of course - I sort of meandered off topic with that phrase. I had intended to match up something that would go with the OP's claim of an OSS tenant. But now that I think about it, I really should have pointed out that the "multitude of random attacks" thing is usually in counter to claims that OSS hasn't been tested like it's proprietary counterparts.

Re:Age is irrelevant, resistance is futile.

[WinterSolstice]

Actually, you might be surprised how many "current" versions of unix end up having to install ancient backwards-compatible libraries for some stupid program or other. Sometimes this is even for the newest version of the app.

SAP comes to mind... (Java 1.4.2, old C libs, etc)

Steve Jobs here

[Anonymous Coward]

Listen, Jack! I will make my it my morning ritual to poop in your cereal and piss in your OJ you lying sack of worthless doorknobs! My OS is the best OS there is and nothing you say can change that!

Yours,
Steve "Got Me My Liver from a Chinese Convict" Jobs

But it's not Windows!

[ynososiduts]

I call fake. It's OS X! It's bullet proof! Steve Jobs would not let this happen! Macs are immune to crashes! Et cetera!

Re:But it's not Windows!

[davmoo]

Dammit, I was going to post that!!

Re:But it's not Windows!

[BikeHelmet]

Macs have a history of having far less vulnerabilities than Windows.

But now they're catching up with Microsoft in that, as well as average patch time! :D

Re:But it's not Windows!

[bonch]

Same could be said for Linux! Right? Right? Being open source makes it invulnerable?

Re:But it's not Windows!

[Anonymous Coward]

Queue cries of all the butt-hurt Microsoft fanbois.

Re:But it's not Windows!

[Daniel Dvorkin]

You know, at this point there are probably about a thousand times as many people whining about this supposed attitude on the part of Mac users than there are Mac users actually displaying it.

Re:But it's not Windows!

[e2d2]

They're an easy target because they stress this in their advertising thus bringing it on themselves. Why have pity for them? Their ads are smarmy so getting a little in return is all in good fun. It's ridiculous to think that any computer is perfect, that's why we point and laugh.

Re:But it's not Windows!

[tagno25]

Same could be said for Linux! Right? Right? Being open source makes it invulnerable?

No, it being open source means that the vulnerabilities can be fixed quicker than 2+ years.

Linux has had more known vulnerabilities than Windows, but that is because people can see the source and find the vulnerabilities. It has also had more fixed vulnerabilities and currently has less valid vulnerabilities than Windows.

Re:But it's not Windows!

[Bromskloss]

You know, at this point there are probably about a thousand times as many people whining about this supposed attitude on the part of Mac users than there are Mac users actually displaying it.

But that's perfectly in order, isn't it? There have been many more people complaining that Hitler was a bad guy than there has been Hitlers.

(*knock, knock*
- Who's there?
- Godwin.)

Re:But it's not Windows!

[Architect_sasyr]

Yes because even we manage to fix our kernel bugs faster than 2+ years

Re:But it's not Windows!

[Anonymous Coward]

Isn't Darwin the open source OSX kernel?

Re:But it's not Windows!

[JustinRLynn]

Yes, but the issue in this case isn't in the amount of time the bug is exploitable -- it's all about the amount of time it goes from known to fixed. In the bug you cite's case that patch time was zero since the patch was announced with the bug. You just can't do that with closed source software unless you're the original developer. DNDTR.

Re:But it's not Windows!

[Anonymous Coward]

What's an invalid vulnerability?

Re:But it's not Windows!

[arbiter1]

With windows having most the market flaw's get found quick, with mac not having no where near as much and fact most people will go after the OS they have most chance to infect as many as possible, this is what will happen. There is probably a lot more nasty flaw's like this hidden in the Mac OS that are still not known. Kinda nice to knock these mac nut's down a peg.

Re:But it's not Windows!

[TrancePhreak]

Because the first thing someone does when they find a vulnerability is to report it. They wouldn't want to sell it for $100K or so to the top bidder.

Re:But it's not Windows!

[Anonymous Coward]

one that is a designed bug, but looks line a vulnerability (AKA a back door)

Re:But it's not Windows!

[characterZer0]

With Windows, there are two groups of people looking for bugs: Microsoft employees who do not want to admit to the bug and who will hide the fix in a service pack who knows how many months later, and those looking to exploit.

In Linux, in addition to those being paid to work on it such as RedHat employees and those hoping to exploit it, you have volunteer kernel hackers and users as well, to whom it is beneficial to release a patch immediately.

Re:But it's not Windows!

[JustinRLynn]

Thank you, this is exactly the argument I would've posed. Please also note that the moment it starts appearing in the wild everyone with access to that source code is going to be on a witch hunt for the bug. The number of people with the source code is much greater and those people are more motivated since they're actually the ones experiencing its affect.

Re:But it's not Windows!

[Anonymous Coward]

With windows having most the market flaw's get found quick, with mac not having no where near as much and fact most people will go after the OS they have most chance to infect as many as possible, this is what will happen. There is probably a lot more nasty flaw's like this hidden in the Mac OS that are still not known. Kinda nice to knock these mac nut's down a peg.

How can you read a bunch of other people's posts that use simple terms like mac nuts and flaws - then go ahead and repeat those terms in your own post complete with the liberal application of completely unnecessary apostrophes?

What exactly is going on in your head when you do this? Enquiring minds want to know!

Re:But it's not Windows!

[TheRaven64]

This bug was in one of the open source parts of the XNU kernel. A third party did find the flaw and, once it was demonstrated to be dangerous, Apple released a fix quickly. I object slightly to the fact that they ignored it for about a year when they thought it was 'only' able to crash the kernel, but maybe they had more pressing issues that they needed to fix. Given that the source is available, under a license which permits both recompilation and distribution of modified versions, this isn't an open versus closed debate, it's a question of how many people bother to look and fix bugs. Last numbers I saw said there were 78 people actively working on the Linux kernel, and not all of these full-time; I expect Apple devotes a similar number of man-hours to XNU, but divided among fewer people.

Re:But it's not Windows!

[TheRaven64]

Godwin's law talks about the probability of a discussion involving someone being compared to Hitler. You didn't compare someone to Hitler, you compared comparing someone to someone to comparing someone to Hitler. This is not a Godwin, it's a meta-Godwin.

Re:But it's not Windows!

[Anonymous Coward]

No shit, Sherlock. Macs also have a history of being used 10 times less often than Windows.

Re:But it's not Windows!

[Anonymous Coward]

Same could be said for Linux! Right? Right? Being open source makes it invulnerable?

No, it being open source means that the vulnerabilities can be fixed quicker than 2+ years.

But the Drawin kernel IS open source. Sounds like a case of the community failing Apple!

Re:But it's not Windows!

[je ne sais quoi]

You know, the OS X kernel is open source, right? It's released right here. 10.0 beta through 10.6. The package you want is XNU. 10.6 doesn't seem to be up yet, but 10.5.8 is right there.

The parent said:

Linux has had more known vulnerabilities than Windows, but that is because people can see the source and find the vulnerabilities. It has also had more fixed vulnerabilities and currently has less valid vulnerabilities than Windows.

All of this applies to the Apple kernel as well because it's open source. In fact, if you read TFA, this particular bug was found was somebody mistyping something and then using a kernel debugging kit to determine the problem. That sounds precisely like the way open source software works.

Re:But it's not Windows!

[donaggie03]

Why can't you let us have our Godwin fun, you Hitler!

Re:But it's not Windows!

[Anonymous Coward]

"No, it being open source means that the vulnerabilities can be fixed quicker than 2+ years."

Bullshit.

SAMBA had a vulnerability around that was in the code from the late 1990s. I believe it was fixed around 2 years ago. It was discovered when one of the main programmers was sniffing his own network traffic and noticed some traffic hacking into his own machine. You've had code used in most Linux distros that was over half a decade old that was vulnerable to exploit.

The Apple bug in question from the links seem to have been in the wild since at least June 2008. It's the end of August 2009, so that's 1 year 2-3 months, not 2+ years as you state. Frankly, this error alone makes you incompetent and shows your bias since you didn't even bother to RTFAs.

Furthermore, Apple seems to have known this at the start of August according to the security releases dating largely around August 5, 2009, again in the links of the article. So they fixed it in under a month, much faster than several XP exploits and faster than Adobe. You make it sound like Apple sat around for "2+ years" doing nothing, when they fixed it in well under a month.

btw, I'm not attacking that something in the code took a small while to fix. I'm attacking this damn consistent blinders of certain ignorant Linux fanboys to their own practices in direct comparison to other OSs. I use several OSs myself, and I know Ubuntu comes out with a security fix nearly every week, usually several. OpenBSD, pretty much one of the best out there if not the best, has had vulnerabilities in the code that were around for years as well; when they are known, they are fixed immediately as well.

Quite frankly, this /. story actually took a more correct tone and attitude that usual: that this was a longstanding bug that was recently found and rather simplistic in nature. With slight glossing over the real details that Apple patched it accordingly and within reasonable time limits. What the Linux crowd again has done is gone off the deep end and attacked, while their own code base has been shown repeatedly to have similar issues. I believe such people are usually called hypocrites.

Re:But it's not Windows!

[Anonymous Coward]

Linux has had more known vulnerabilities than Windows, but that is because people can see the source and find the vulnerabilities. It has also had more fixed vulnerabilities and currently has less valid vulnerabilities than Windows.

I call bullshit twice. Without citations your opinion is noted but not necessarily relevant. Can you throw us a bone and define "Linux" and "valid"?

Because I don't know the basis of your statements, if you compare Windows Vista to Ubuntu 9.04 you'll see that Vista has 63 advisories and 113 vulnerabilities over three years. Ubuntu has 58 advisories and 147 vulnerabilities over four months. Vista's aren't all patched. Yawn. Microsoft does fix urgent issues out of band.

Re:But it's not Windows!

[Anonymous Coward]

Using that "logic" Microsoft would be the same sort of target. But the ads are not your issue with Apple are they? Nooo

Re:But it's not Windows!

[Anonymous Coward]

So was I! But my Mac crashed in the middle of my post so someone else beat me to it while I waited for Windows to boot!

Re:But it's not Windows!

[Anonymous Coward]

That's right brother... Microsoft gets off lightly on this site, don't they. You tell 'em.. maybe Steve's reading and he'll grace us by downloading our unworthy bytes.

Re:But it's not Windows!

[SanityInAnarchy]

With Windows and OS X, those are the only two choices.

With Linux, there's a third option: Fix it myself.

Now, granted, you're still going to have all kinds of people who go with option #1 and option #2. But if I had the skills to find and debug kernel exploits, for instance, I'd probably want to fix them at least to secure my own systems.

Also worth mentioning -- with Windows and OS X, developers can know about a bug and ignore it, hoping no one notices. This is an obvious example:

To make this disclosure full: I discovered the kernel panic in August 2008. I wrote to Apple but the only reply I got was indicating that they are investigating the problem. In July 2009 I finally spent some time and debug the problem. After I found that it could be used to write arbitrary data in memory I wrote again to Apple. This time they wrote back asking me if I want to be credited in the Security Update. They kept their promise. :-)

And, looking at that page:

About the security content of Security Update 2009-003.... Last Modified: August 05, 2009

So it was at least four or five months, and it looks like a year, between the initial report and the fix. This can only really happen with closed software -- open source tends to fix security issues within days, if not hours, of being reported.

And again, despite this being a very knowledgeable guy who knows how to step through the kernel with a debugger, the proprietary nature of it means that he couldn't even fix it on his own machine until Apple finally got off their asses and released a patch.

Re:But it's not Windows!

[Simetrical]

Last numbers I saw said there were 78 people actively working on the Linux kernel, and not all of these full-time

Where did you get that? LWN's development statistics for 2.6.31 (subscriber-only for the next few days) say that there were 1,146 distinct developers whose patches got accepted into this particular minor release (i.e., over the last three months or so). The stats for 2.6.30 (publicly viewable) show 1,125. Granted, most of these are probably touching only a tiny portion of the code and might only get a few changesets accepted, but they could still fairly be described as "actively working on the Linux kernel" (even if far from full-time). Also, there are an untold number of people who "actively work on the Linux kernel" but don't submit their patches, or submit them but don't get them accepted.

So maybe there are 78 people working on the Linux kernel according to some very specific, narrow definition, but you should really provide the definition if you're going to throw around such small numbers.

For what it's worth, I doubt that either Apple of Microsoft devotes anywhere near the man-hours to their kernels as get devoted to the Linux kernel. But a lot of the extra man-hours that Linux get contribute to extreme specialization, like dozens of supported CPU architectures (Windows: 3, Mac: 1), dozens of supported filesystems (Windows, Mac: But I'm not a kernel hacker or anything close to one, so take this post with a grain of salt.

Re:But it's not Windows!

[Joe Jay Bee]

Company advertises product as perfect and hassle free - OMG!

Hint: Apple, Microsoft, Red Hat, Novell, Canonical et al all advertise their respective OSes as being secure and trouble free (and, really, Linux zealots can be about twelve times smarmier than Mac fanboys when they try). Picking on just one of them as a result is a tad unfair.

Re:But it's not Windows!

[Anonymous Coward]

No, it is not.

Darwin is the XNU operating system + compiler and few other tools.

The XNU is open source operating system what Apple use. It is designed from studies from Linux when Apple tried to make it microkernel based OS.

The OSX kernel is the Mach. What is microkernel.

Mach = microkernel
XNU = microkernel-based operating system
Darwin = Apple's XNU development platform
Mac OS X = software system including Darwin.

The article speaks how the bug is on the kernel. So it is not on the XNU (darwin) OS. It is located to Mach microkernel.

Re:But it's not Windows!

[e2d2]

But they are the same sort of target. So what is your point? It's not my fault people feel it's a personal insult when I laugh at their high and mighty computer.

Re:But it's not Windows!

[e2d2]

Fair? Do we need an equal opportunity insult council? All of those you mentioned get plenty of crap.

Re:But it's not Windows!

[Lars T.]

So was I! But my Mac crashed in the middle of my post so someone else beat me to it while I waited for Windows to boot!

So it took Windows over 10 hours to boot?

Re:But it's not Windows!

[Lars T.]

With Windows and OS X, those are the only two choices.

With Linux, there's a third option: Fix it myself.

How likely is it you will introduce at least one new, probably worse bug while trying to fix this bug in code you have never seen before - unlike the guy who originally added it, and all those who checked the code since?

Re:But it's not Windows!

[Lars T.]

No it's not - why don't you actually RTFA you claim to be quoting?

Re:But it's not Windows!

[SanityInAnarchy]

How likely is it you will introduce at least one new, probably worse bug while trying to fix this bug in code you have never seen before - unlike the guy who originally added it, and all those who checked the code since?

Considering I'll submit it to be checked, chances are small that such a bug would survive.

Also, what are the chances that this code is so insanely complex and fragile that this is likely?

Re:But it's not Windows!

[Anonymous Coward]

well i could agree with your argument if there were actual damages... but there werent other than a little humbling ... ill take that over 100000+ viruses...etc and a bloated spaghetti mess of code. touche

Re:But it's not Windows!

[Anonymous Coward]

Well by Quirk's exception (ok, interpreted a bit wider) this is also not a valid Godwin ;)

Re:But it's not Windows!

[Anonymous Coward]

And yet, linux STILL can't support USB 1 (or 2) to the extent that even the most primitive of Mac os Windows OSes can...

Doesn't cause panic on 10.3.9

[noidentity]

Sadly I couldn't get my Mac OS X 10.3.9 (PowerPC) machine to panic with the C code.

Re:Doesn't cause panic on 10.3.9

[Anonymous Coward]

RTFI

covering all the 10.4 and (almost all) 10.5 Mac OS X releases.

Re:Doesn't cause panic on 10.3.9

[noidentity]

I did read the blog posting, and it says "The oldest kernel I was able to test the problem was Darwin 8.0.1 which corresponds to Mac OS X 10.4 'Tiger'." I figured I'd post a result on an earlier one, so shove it.

Re:Doesn't cause panic on 10.3.9

[Anonymous Coward]

Sadly you're a cunt.

Re:Doesn't cause panic on 10.3.9

[noidentity]

Perhaps, but I did read something first. True, I could have read the official Apple version that listed the affected versions. The blog author could have updated his post as well, considering that he did update it to note that Apple credited him in the security fix (ego takes priority I guess, heh).

Re:Doesn't cause panic on 10.3.9

[Anonymous Coward]

I can remember finding something very similar to this in SunOS 4.1.x. A certain invalid parameter to fcntl() would always lead to a panic, but the panic wasn't immediate, it would always occur about 10 minutes after making the call.

Re:Doesn't cause panic on 10.3.9

[Anonymous Coward]

Yeah, but did you actually compile the C code, or did you just chmod and execute it directly? :)

(Sorry, couldn't resist.)

Re:Doesn't cause panic on 10.3.9

[FatdogHaiku]

Sadly I couldn't get my Mac OS X 10.3.9 (PowerPC) machine to panic with the C code.

Try letting it see you use an Android phone while simultaneously unwrapping a new Zune media player...

Sorry, I should probably let my meds kick in before I post in the mornings...

MACFAGS TOLD...

[Anonymous Coward]

...in two lines of Python.

Re:MACFAGS TOLD...

[Anonymous Coward]

lol, butthurt TOLD mods.

I read

[Runaway1956]

Alright, I read TFA. I read the earlier slashdot article. I even googled around a little bit. What I find is, an obscure little bug, if exploited locally, enables a user to crash his machine. What I don't find is an exploit that makes use of this bug.

Am I missing something?

I suppose that I could accomplish something similar on my current Ubuntu installation. If I thought it made a difference, I could install a few other flavors of Linux and try doing something like that. But, why?

MS astroturfer's posts above are noted. And, I also note that MS bugs are routinely exploited, locally and remotely. The unwarranted superiority complex looks pretty pathetic, doesn't it?

Re:I read

[Thantik]

It's not the fact that it is local exploit code, it's the fact that local and remote exploits and the line between them are being blurred every day. TFA mentioned being able to write memory in 8-bit pieces, ANYWHERE in kernel memory. That's pretty dangerous if you ask me.

Re:I read

[Architect_sasyr]

Am I missing something?

Possibly. An active exploit might not be available, it may still be in the underground, or we may be dealing with a series of code flaws that resemble the old tenets of CISCO fame - "We're unexploitable, all you can do is cause DoS". It might just be we have to wait for someone to turn around and go "oh really" before an active exploit can be retrieved from a crash.

Re:I read

[emurphy42]

The relevant part is:

The problem is the data in the buggy case is whatever we give as a third parameter in the fcntl code. Considering that the 8 bytes are controlled by the user it means he can write that amount of information anywhere in the kernel memory!

followed by an example of actually doing it and proving that it worked (not a particularly malicious example, but it seems enough proof of concept to me).

Re:I read

[Overunderrated]

So your argument is that even though the bug exists, it's okay because no one took the time to massively exploit it? you do realize that if OSX had anywhere near the market share of windows, this would've been exploited years ago, right? i accept that 'security through obscurity' is perfectly valid, but you need to recognize it for what it is.

Re:I read

[Runaway1956]

Yeah, I've read this "market share" argument used as a defense for shoddy MS code time and time again. That just doesn't cut it.

Mac has a presence in the business world. If it were as buggy as MS, crackers would be launching fishing expeditions for vulnerable Macs, so that they could gain access to company networks.

What I asked for were examples of exploits, or reasons why this bug were really dangerous. Posts before yours are attempting to put things into perspective. Please, no more lame defenses of from MS astroturfers - there are enough of those even before you arrive at my question.

Market share, indeed. Remind me that the next time I want a cheap padlock, I should purchase a no-name lock. Since it has no market share, burglars won't try to pick it or break it.

Re:I read

[Anonymous Coward]

The market share thing is always dragged up in these instances... Given that Microsoft (and the rest of the non-Apple world) seem to drag out how Macs are more expensive, wouldn't it make sense to attempt to write something that goes after these so-called well-off users? They must have plenty of cash lying around if they so frivolously throw their money away on Macs....

Re:I read

[nmb3000]

Mac has a relatively tiny presence in the business world.

Fixed that for you.

What I asked for were examples of exploits, or reasons why this bug were really dangerous.

And a bunch of people already pointed out that this bug gives you write-access to the kernel's memory. That's bad, privilege escalation bad.

Market share, indeed. Remind me that the next time I want a cheap padlock, I should purchase a no-name lock. Since it has no market share, burglars won't try to pick it or break it.

That's funny, because I recall seeing all sorts of instructions on how you can open MasterLock(TM)(R) and (ALL THAT) combination locks. They were so detailed, they would even specify which serial numbers of which models were vulnerable to which cracking techniques. And yet, I never saw any instructions for opening the Wal-Mart special RandomBrand of padlock.

Market share does matter when it comes to investing time and money into exploiting flaws in a product. To say it is the only factor in operating system security is false, but saying it doesn't matter at all is just as wrong.

Re:I read

[Anonymous Coward]

The unwarranted superiority complex looks pretty pathetic, doesn't it?

OSX: 4% (5 out of 132) are marked as unpatched
http://secunia.com/advisories/product/96/?task=advisories

Windows 2008 Server: Currently, 0% (0 out of 40) are marked as unpatched.
http://secunia.com/advisories/product/18255/?task=advisories

Unwarranted astroturfing? Wake up from your dream land.

Re:I read

[Sir_Lewk]

local and remote exploits and the line between them are being blurred every day

Citation please? The line between local and remote seems to be pretty concrete and fine to me.

Re:I read

[TapeCutter]

"The line between local and remote seems to be pretty concrete and fine to me."

Indeed, for those having trouble spotting it, it's the line with the flashing green light next to it.

Re:I read

[beuges]

The bug is really dangerous because it allows userspace to write anywhere to kernelspace. Yes, it's a local-only exploit, so the attack surface isn't that large. Or is it? How many pieces of software do you have running on your system right now that may contain vulnerabilities? It would be trivial for a skilled hacker to find an exploit in some arb application, with the payload being an exploit of this particular issue. So your local-only exploit has a remote entry-point from any other piece of software thats running on your system.

Local-only exploits are only less dangerous than remote exploits if your system has no contact with other systems. When you expose your system to others, all of your local exploits become remote exploits the moment any piece of software that you run has a remote exploit. Recently there have been a number of reports of vulnerabilities in common applications like Firefox, and Adobe doesn't have a particularly great security track record either. Ideally, a vulnerability in one of these applications would only be able to run code as the user, or attack the user's home directory. Except since you can now modify any address in kernel space, you can craft code that tells the kernel your userid actually has root permissions, in which case you now have complete control over the whole system.

Every kernel-level exploit is *really dangerous*. Marketing people will try to play it down by saying that since its local-only, it's not that bad, so that they can carry on making dumb 'im a pc, im a mac' adverts and patting themselves on the back. But all they're doing is lulling their userbase into a false sense of security.

Re:I read

[Alef]

From Apple's summary of the bug:

Description: An implementation issue exists in the kernel's handling of fcntl system calls. A local user may overwrite kernel memory and execute arbitrary code with system privileges. This update addresses the issue through improved handling of fcntl system calls. Credit to Razvan Musaloiu-E. of Johns Hopkins University, HiNRG for reporting this issue. [Emphasis mine]

If you have the ability to alter kernel memory at an arbitrary place, you can accomplish pretty much anything. An exploit could for instance modify some critical kernel data structure, or replace a function pointer or return address, thus allowing the exploiter to inject code and make the kernel run it in privileged mode.

Re:I read

[palegray.net]

You're missing the point. The line between local and remote vulnerabilities is indeed being blurred these days, given the rise in network services running on workstations (instead of just servers). Add in the fact that even on servers application-level vulnerabilities can be greatly exacerbated by the potential for kernel exploits. This was neatly illustrated with the recent Linux kernel vulnerability, which essentially turned every remote exploit that allowed arbitrary code execution into a kernel exploit. I happen to work for a company that has an extremely large Linux deployment across several datacenters; while not a cause for panic, these issues are becoming harder to concretely classify as the difference between workstation and server becomes blurred and people deploy increasingly complex application setups on servers.

Re:I read

[Anonymous Coward]

The only difference is that to take control with a local exploit you need a bug in another program that the user is running. On servers this could services like apache. On desktops this could be the browser, a media player or a instant messenger.

If you feel safe because it is only a local exploit you are a moron. As soon as you have any interaction with unknown systems a local exploit isn't any less dangerous.

Re:I read

[Anonymous Coward]

Snow Leopard could level security playing field

OS X vulnerabilities vs Vista (IBM Research via /.)

Re:I read

[benjymouse]

Yeah, I've read this "market share" argument used as a defense for shoddy MS code time and time again. That just doesn't cut it.

So you think that an attacker thinks he must exploit each platform proportional to the market share?

Or do you believe that each attacker randomly chooses a platform to specialize in proportional to market share. Or do they keep a list with number of slots according to each OS's market share?

Consider this:

1. Imagine you were on a shooting range. You can shoot for two different targets, one labelled "OS X" and the other one "Windows"
2. One "OS X" target is 3 times larger than the other (OS X has 3 times the vulnerabilities compared to Windows) and is thus easier to hit.
3. Each time you hit "OS X" you get $10.
4. Each time you hit "Windows" you get $200.
5. You have 12 shots.

Now, if the targets were 10 ft in front of you and both easily hit, how would you spend your 12 shots? Would you aim 3 shots that the smaller target and 9 shots at the larger target because that seems the fair thing to do? Or would you just shoot all 12 shots at the smaller target and go home with $2400? I know what the typical person would do.

Only when you move both targets so far back that both of them gets pretty hard to hit would any sane person consider spending any rounds on "OS X".

Attackers chose target platform based this simple economics. As long as Windows has 15 - 20 times (worldwide) the market share of OSX and as long as the limiting factor of attacks is time (the actual creation of an exploit), the attackers are going to target Windows each and every time. Only if they cannot find any exploitable vulnerabilities in Windows will they invest in another platform.

Oh, and what about Apache you say? Apache has 2 times the market share of IIS (roughly). Why isn't Apache attacked exclusively for the same reason. The difference here is that these targets are pretty distant; both Apache and IIS are pretty tight. Neither Apache nor IIS5, 6 and 7 has seen successful widespread attacks directly at the server. Neither Linux nor Windows are vulnerable at the network level anymore, especially not when behind a firewall as *all* webservers are nowadays.

The shooters have simply given up (for the time being) and went to another shooting range with better odds. BothApache and IIS has seen widespread attacks against vulnerable applications running on top of the servers. Here you could certainly argue that attackers has a preference for PHP and ASP.Ancient.

Re:I read

[pv2b]

From my understanding of the blog post, the hole described by the blog post allows you to write a data structure containing the window size into any arbitrary kernel memory location.

The information about terminal window size etcetera comes from the teletype. I'm sure that it wouldn't be too difficult to write an exploit which basically implemented a "stub" teletype which had most features unimplemented except one that returns a fake window size - allowing you to write arbitrary data to kernel memory.

Now, I'm no kernel hacker, I frighten easilly at the sight of X86 assembler, but I'm sure that - once you can actually write arbitrary data to kernel memory - you can get root in pretty short order. I don't know - the most straightforward way to me would sound like just munging the process table.

Re:I read

[node 3]

Market share does matter when it comes to investing time and money into exploiting flaws in a product. To say it is the only factor in operating system security is false, but saying it doesn't matter at all is just as wrong.

No one is saying that it's not a factor. On the other hand, there are countless people who make the reverse mistake and state that Macs don't have exploits solely due to market share.

This is easily debunked by:

1. IIS exploits.
2. Linux exploits (Linux market share is to Macs as Mac market share is to Windows)
3. Mac apps. People still write apps for the Mac, why not viruses?
4. There are plenty of viruses for the classic Mac OS.
5. There are tens of millions of Mac users. Even though Windows has hundreds of millions, tens of millions is still a large and lucrative group to attack.

The key isn't that Mac OS X is flawless or too low of a market share, it's that Windows is so easy to exploit. Design decisions made decades ago are still impacting Windows today. If you look at the typical Mac OS X bug and the typical Windows bug, you'll see that the Mac bugs tend to be very Unix-like in nature, that they are some part of the system can be tricked into crashing by being passed data in a specific way. Many a Windows bug is not due to getting something to crash, but by using some feature in a way that tricks it to allow unwanted things to happen.

Re:I read

[Anonymous Coward]

I'd argue that most malware for windows doesn't really use exploits. It is installed with some pirated software, codec, screen safer or other garbage.

Re:I read

[Anonymous Coward]

" Linux exploits (Linux market share is to Macs as Mac market share is to Windows"

Eh?!?

Linux has up to 20% market share while there are NO MACS used a public servers.
Name onle ONE Linux exploid which was open fore 4 years.

Re:I read

[Macthorpe]

How about 7? I didn't even have to leave this story to find the link.

A tip for the future - try not to get so worked up that someone may be attacking your precious Linux that you can't even spell 'for'.

Re:I read

[Anonymous Coward]

Proof by analogy is fraud.

Re:I read

[snemarch]

Think for a few seconds.

An OS with a high marketshare is interesting to auto-exploit because you can build yourself a botnet that way. For lower marketshare OSes, you'll only be able to grab a "handful" of boxes by auto-exploiting; on the other hand, there might be some "really interesting" systems you can break into.

Anybody with half a clue knows what this means: you keep your 0-day exploit code to yourself, because the value of breaking into those interesting systems is vastly higher than penis-enlargement from getting your name out with a 0-day exploit. Think industrial espionage, blackmailing, etc.

Just because there's no known exploit code out in the wild doesn't mean people aren't exploiting systems.

Re:I read

[Anonymous Coward]

Huh!?!

Just read the lonk you have posted...

Re:I read

[LurkerXXX]

Some problems with your arguments.

#1 IIS is a web server. That is a juicy target. It's much jucier than a lot more home OSX machines.

#2 Linux is used very often as a server. Once again, a much much jucier target than some OSX desktop.

#3 They do, just much less of them, as with apps. Less written, less looking, less discovered.

#5 Modern *nixes have pretty much all implemented this feature which OSX has neglected to implement. What else haven't they done right as the other *nixes have?

Re:I read

[rekoil]

By itself, a local exploit, say, a privilege escalation exploit, is only dangerous if you don't trust your local users.

The real danger of a local exploit is that it allows a remote exploit, which normally can be contained by server process permissions, chroot jails, etc. to become more dangerous - if you can get a remotely-exploitable process to run local exploit code, you can own the box no matter what privilege restrictions the server with the remote attack vector is running with.

In other words, via a local exploit, "0wning apache" becomes "0wning the box" very easily.

Re:I read

[Anonymous Coward]

Many a Windows bug is not due to getting something to crash, but by using some feature in a way that tricks it to allow unwanted things to happen.

Except in most cases there's not even any trickery involved. For example, Active X was designed to break the security model; it relies heavily on Security through hoping the other guy will play nice.

Re:I read

[Anonymous Coward]

TL;DR = If your machine is exploited, this bug means your machine is exploited. Scary stuff.

Yeah, local escalation exploits should be fixed, but they're much much less dangerous than the vulnerabilities that allow unauthorized access.

And drop the mac vs PC bullshit, Windows escalations are extremely common, as are linux escalations. If an attacker gets unauthorized access you have to assume they were able to escalate and reinstall. Trying to "hunt down and clean" an attack is a losing proposition.

Root access lets them do a few additional things they can't do as a user, but generally not anything they care about doing anyway. Botnets don't require root access, just listen on a port > 1024. Malware, keyloggers, etc. don't require root access. Corporate espionage doesn't require root access. The Half Life 2 source code was stolen without root access.

Local escalations are just not that bad.

Re:I read

[Anonymous Coward]

Security through obscurity is a myth and is used by Windows lusers to explain away the wide open barn door nature of Windows which Microsoft doesn't have the interest or ability to fix. Pre-OS X Macs had plenty of viruses. Malware writers live for attention and if they could get a successful pice of malware on the mac they would do so. But any script kiddy can write some new pice of trash for Windows and its not at all easy on the Mac due to its Unix underpinning. Thats why the only two known types of malware for the Mac that are in the wild depend on the user doing stupid things to infect the machine.

As a security architect I wold be out of a job pretty quick if I thought security through obscurity was real.

Re:I read

[washu_k]

You want an example of security by obscurity? Or maybe it should be security by no one cares?

MacOS

Not OSX, the OLD MacOS. It was used in the business world just like OSX is today. But it was different in one critical way: It had NO SECURITY AT ALL!

It had no security, no memory protection, nothing. By your logic it should have been overrun by viruses. Or at least have a proportional amount compared to its market-share.

Just before OSX came out in 2001 MacOS should have had between 500 to 3000 viruses if it was proportional to the windows market-share and number of viruses (depends on which numbers you use). It had 40. Forty.

No one cared, security by obscurity.

Re:I read

[Runaway1956]

"It had NO SECURITY AT ALL!"

MacOS was based on BSD, right? By extension, does BSD have no security at all? Or, are we to assume that Mac stripped out BSD's inherent security? Remember, Unix like operating systems are inherently modeled on security.

This site, among others, suggests that Mac OS users might have been security conscious: http://homepage.mac.com/macbuddy/SecurityGuide.html

Re:I read

[chefmonkey]

Am I missing something?

Yes, you are.

The exploit allows users to choose an arbitrary location in memory -- including kernel space -- and write 8 bytes to it at a time. The 8 bytes are chosen by the terminal program attached to the TTY that the system call is made on. So, if a local program attaches to a TTY in the same way that a terminal does, and then makes this system call, it can load executable code into the kernel (or anywhere else, for that matter).

In other words, it makes it ridiculously simple to run any code you want as root.

Re:I read

[washu_k]

No, OSX has some BSD in it.

MacOS 9 and lower have no BSD in them at all. It is basically DOS with a GUI and very crude multitasking. No security at all.

Re:I read

[malevolentjelly]

And, I also note that MS bugs are routinely exploited, locally and remotely. The unwarranted superiority complex looks pretty pathetic, doesn't it?

Would you like to cite how you can remotely exploit NT 6? I would be fascinated to hear that. Unless you're just saying that local exploits are distributed and then run locally by users.

So no, it doesn't. NT 6 is the most secure desktop operating system, followed by maybe Red Hat or SuSE linux and somewhere down the line perhaps Mac OS X. That's the security situation we're looking at, like it or not.

Microsoft exploits get huge press-- Microsoft has lots of enterprise customers and needs to be very clear when something has gone wrong. Linux exploits show up constantly and are swept under the rug with quick hackish "fixes" to the kernel that often only address part of the issue, and Mac OS X exploits are casually ignored and smarmed away as Apple doesn't like to draw attention to them. Cultural differences between systems are a big deal in security issues, where part of the exploit system is human.

Many people here are fans of elegant simplicity, so it would suffice to say that the NT 6 kernel is much much smaller than the Linux or XNU kernel and is designed using advanced modern security practices and architecture. This is a kernel that is commonly re-architected. The kernels on Linux and Mac are architecturally stagnant in comparison.

Re:I read

[Anonymous Coward]

If all one needs is access to a local account for the exploit, than a vulnerability in a networked program may be all it takes to be exploited. In other words, think of it as using a remote exploit to interface with the local exploit. This is why local exploits that can be carried out through a local account are still serious.

Re:I read

[Runaway1956]

"NT 6 is the most secure desktop operating system,"

So, what you seem to be saying is, you have faith that over the next several months, as NT6 is adopted by more and more people, we will see an end to Windows exploits.

Ohhhh-kay. Good luck with that. I remember similar expectations when Win9.x was finally dropped in favor of NT.

I will grant that the security model seems to be improved over NT5.x I'll readily admit that security defaults are much improved over NT5.x But, I honestly believe that NT6.x will be exploited soon. Am I the only person to notice that MS strongly encourages you to find and install an antivirus immediately after installation? Could that warning be prompted by MS knowledge that some, or many, or even all of the old viruses and trojans can be modified to use the same old exploits on NT6 that they have taken advantage of on NT5?

Give it 12 to 24 months, then come back and tell me that NT6 security is superior to Linux, or Mac, or whatever.

Meanwhile, you might browse these pesky articles.

Re:I read

[malevolentjelly]

Am I the only person to notice that MS strongly encourages you to find and install an antivirus immediately after installation?

Linux and Mac OS X are fully vulnerable to viruses, also. On a Windows or Mac computer you run far more third party untrusted code than on Linux, which endemically lacks third party support. It's both a strength and weakness of the platform. Mostly, Linux avoids viruses in the same way it avoids commercial software, by being an inconsistent platform. It's security through incompatibility.

Meanwhile, you might browse these pesky articles. [google.com]

I see old exploits. On the Microsoft security page, there's some stuff relating to Office and IE, but nothing regarding a remote platform exploit. Windows isn't like Mac or Linux where an attacker can casually step in through poorly written network services or even audio drivers and become root through one of the thousands of undiscovered exploits GCC optimizes into the kernel.

Admittedly, these are desktop systems. They constantly do risky things and the security is often reduced for convenience. Among desktop systems, Vista/7 are comfortably more secure. If a user runs with a limited account and follows proper security procedures (uses an anti-virus, doesn't grant arbitrary applications admin privileges, etc.) then they will find themselves far less vulnerable than users on platforms with more archaic security models, such as Linux. UAC may be annoying, but at least it's not like Linux where you don't even need the user's permission to privilege escalate. There are decades-old holes for that. Thanks, SUID.

So, what you seem to be saying is, you have faith that over the next several months, as NT6 is adopted by more and more people, we will see an end to Windows exploits.

No, there will always be exploits as long as open systems are used. I simply believe that if Mac gains more users, it will have dangerously more security holes than Windows, given the reduced security resources and vast architectural deficiencies. Linux exploits popularly are saved for servers, the only place where it's really used from a broad perspective. If anyone wants something on a linux server and has the expertise, it's an open door.

Give it 12 to 24 months, then come back and tell me that NT6 security is superior to Linux, or Mac, or whatever.

Given the wide gulf in security practices between the platforms, I would say I'm quite confident that that will be the case.

Re:I read

[Simetrical]

2. Linux exploits (Linux market share is to Macs as Mac market share is to Windows)

What are some examples of widely-exploited Linux bugs? (Of course there are isolated exploits, but the same is true for Mac. And of course there are very severe security vulnerabilities all the time, but that doesn't mean they're exploited in practice. And of course Linux machines are compromised on a regular basis, but that might be due to weak passwords and such.)

3. Mac apps. People still write apps for the Mac, why not viruses?

Apps have to compete with each other. If a particular niche is filled on Windows but not Mac, then a new Windows-only app will have to compete with the existing apps. A new Mac app won't, so it will get a much larger slice of a smaller pie. On the other hand, twenty different viruses can recruit your computer into twenty different botnets with no problem, as any Windows user should be able to attest. (How often does a virus scan on an infested computer turn up only one virus?)

Besides, the number of apps for Mac is tiny compared to Windows.

4. There are plenty of viruses for the classic Mac OS.

Such as? I'm not doubting you, but I've never heard that claimed before.

5. There are tens of millions of Mac users. Even though Windows has hundreds of millions, tens of millions is still a large and lucrative group to attack.

It's a matter of cost and benefit. If it's three times the effort to write Windows exploits and you get twenty times the victims, there's just no reason to write viruses for Macs. Hackers are usually motivated by money, pure and simple.

Anyway, I don't have any credentials in hacking. So I'll rely on Charlie Miller, who's a professional hacker (security expert). He demonstrated that he knows something about Mac exploits by cracking a Mac in two minutes flat a while back and winning pwn2own. In an interview, he said (emphasis added):

Between Mac and PC, I'd say that Macs are less secure for the reasons we've discussed here (lack of anti-exploitation technologies) but are more safe because there simply isn't much malware out there. For now, I'd still recommend Macs for typical users as the odds of something targeting them are so low that they might go years without seeing any malware, even though if an attacker cared to target them it would be easier for them.

He's far from a Microsoft shill; he works for a security consulting firm and uses a Mac himself.

Re:I read

[shmlco]

"... lack of anti-exploitation technologies..."

Uh, you mean like firewalls? Sandboxing? Library Randomization? Protected memory and Execute Disable? Encrypted virtual memory? System heap library checksums? The ability to actually run user accounts as non-admins? FileVault? Disabling root by default? Download screening? Antiphishing technology? Browser page isolation? Minimal outward facing ports and services? Parental Controls?

Those anti-exploitation technologies?

"...he works for a security consulting firm and uses a Mac himself."

And not Windows and not Linux. Guess that says it all.

Re:I read

[shmlco]

Except OS X has library and address-space randomization, which makes changing an arbitrary bit of RAM just that: arbitrary.

Which pretty much makes this, at worst, a DoS/crash issue, and not an exploit.

Re:I read

[Sir_Lewk]

All I said was that remote and local were very clearly defined. Clearly you agree because you had no problem saying exactly what a local exploit was.

Re:I read

[RyuuzakiTetsuya]

I would say that 100% of the money making malware market is Windows machines. breaking into a new market would be good business.

Re:I read

[Simetrical]

"... lack of anti-exploitation technologies..."

Uh, you mean like firewalls? Sandboxing? Library Randomization? Protected memory and Execute Disable? Encrypted virtual memory? System heap library checksums? The ability to actually run user accounts as non-admins? FileVault? Disabling root by default? Download screening? Antiphishing technology? Browser page isolation? Minimal outward facing ports and services? Parental Controls?

Those anti-exploitation technologies?

If you read the interview, you would see that he specifically refers to ASLR and the NX bit, at least. OS X apparently only has a very limited version of those, at least compared to Vista (and some Linux builds). Quote:

For the record, Leopard has neither of these features, at least implemented effectively. In the exploit I won Pwn2Own with, I knew right where my shellcode was located and I knew it would execute on the heap for me.

But hey, if you want to believe lists of features rather than the opinion of a professional security expert who was demonstrably able to hack an OS X machine in two minutes and win a high-profile hacking contest, then go ahead.

"...he works for a security consulting firm and uses a Mac himself."

And not Windows and not Linux. Guess that says it all.

Yes, it does, because he said Mac was safer. Less secure — much easier to hack — but safer, because nobody bothers to hack it. Which is exactly my point. I was responding to the great-grandparent, who claimed Windows is easier to hack than Mac, and that obscurity isn't the major reason Macs are safer. The security expert I cited believes exactly the opposite to be the case, that Macs are easier to hack and obscurity is the major reason they're safer. No one disputes that they're safer.

Re:I read

[GaryPatterson]

MacOS was nothing at all like "DOS with a GUI."

It was always graphical, and never had a command line. It's the exact opposite.

That's not to say your point is completely invalid - it had nothing to do with BSD, there was no real security (apart from some anti-virus apps and some simple memory protection), and the multi-tasking was cooperative instead of preemptive.

It's just that calling it "DOS with a GUI" staggers me.

Re:I read

[Anonymous Coward]

You missed the point about IIS.

IIS has a much smaller share of the web server market than Apache, but is exploited much more often.

So pretty much the exact opposite of Windows/OSX desktops, except in the part where the Microsoft product is full of holes...

Re:I read

[washu_k]

I meant "DOS with a GUI" to show how primitive an OS MacOS was on a technical level. It had no memory protection, no security, primitive memory management and poorly done cooperative multitasking. Other than the multitasking it was on the same technical level as DOS, just with a GUI instead of a command line. Windows 3.1 ran circles around MacOS on a technical level, even if it's GUI wasn't as pretty.

Re:I read

[Anonymous Coward]

Oh brother. This is the worst strawman argument ever. There are many reasons why OS attack frequency might be proportional to marketshare which are simply not captured in this silly "shooting gallery" argument. Consider for example that there is more than one attacker "shooting" simultaneously, or that stealth matters.

Folks, coming up with a simplified metaphor for a concept is not an explanation of that concept, much less an analysis of that concept. Really.

"It's like a balloon and then... something bad happens!"

Re:I read

[Anonymous Coward]

blurred as in, you can remotely exploit a known local priv. escalation or other vuln by first exploiting remote services (mysql/apache/php/etc.) then leveraging that to exploit a local vuln.

Re:I read

[Anonymous Coward]

Except that Mac OS X only runs 2 remote services (ZeroConf, mDNSresponder) by default, and its been a while since there were exploitable holes in that.

Just because linux blurs those lines and windows runs a bajillion services, don't assume everyone tossed a blind eye to memory boundaries...

Wow

[Anonymous Coward]

WoW! a vulnerability in an OS, now thta is news worthy

Mature code?

[Casandro]

I'm sorry, but what has MacOSX to do with mature code? Code is mature when it has lasted for _decades_ and no significant bug has been found. MacOSX is just your average kernel. OK, there are _much_ worse around, but that doesn't make OSX any better.

What _really_ is a shame that it took them 4 years to fix it.

Re:Mature code?

[blackraven14250]

By your definition, there is hardly any mature code out in userland. Adding features means you will create bugs, and since users crave features, there won't ever be a full set of software (app, os, daemon, etc) labeled mature by your definition, and only a small number of code segments that would be unchanged over a decade, let alone multiple decades.

Re:Mature code?

[Casandro]

Yes precisely, there is very little mature code. That's why you still have buffer overruns and other security critical bugs.

New features don't have to mean that old code will be changed or made more insecure. There are many attempts at making computer systems modular so adding one piece of code will add a lot of new features to unchanged programmes. The oldest concept incorporating it is the UNIX concept where you have lots of small single-purpose programs which you can connect via pipes to serve any more complex purpose. Each of those programs can easily be made mature. So you reduce the problem to a bit of managable code to string those programs together.

Other concepts are found on object oriented operating systems (even in MacOSX) where Applications typically are just connections between stock objects. If those stock objects are made out of mature code, you get stable software.

Re:Mature code?

[treat]

By your definition, there is hardly any mature code out in userland.

Of course not.

Name a nontrivial example of mature code in wide use anywhere today.

Not a single legacy system. Not a few lines of code in a huge application or OS. An actual complete mature application in use today. Name one.

It doesn't take quibbling over the definition of mature for this to be readily apparent. If you're finding bugs in it yourself, if bugs aren't fixed because there are higher priority bugs to fix - it isn't mature!

Re:Mature code?

[TheRaven64]

Well, it has lasted for decades, although bugs have been found (which is rather the point, and how something achieves maturity; code doesn't become mature by sitting untested). Mac OS X is a linear descendent of NeXTSTEP. Development is now 25 years old, and some bits of the kernel date back to earlier BSD and CMU Mach projects. Last bits of the kernel I read had comments date-stamped 1997 and these were commenting on modifications to older code.

Re:Mature code?

[drinkypoo]

At the same time, there's been big hunks grafted on recently, not just to the kernel but all the big pieces which were heavily revised, e.g. DPS to DPDF. When you change mature code, it's not mature any more. If they actually made use of the microkernel design of OSX (and used the microkernel as anything other than a HAL, which is literally all it does there) then maybe this situation would be different... but it's not.

Re:Mature code?

[hondo77]

When you change mature code, it's not mature any more.

So by your really interesting way of thinking, Apple shouldn't patch the bug at all because modifying the code would make it not mature and mature (i.e. old) code is always better than immature code. Which is great if you're working on VMS every day, I suppose.

Re:Mature code?

[drinkypoo]

When you change mature code, it's not mature any more.

So by your really interesting way of thinking, Apple shouldn't patch the bug at all

If this is what you got from my comment, you're stupid. What I said is that you can't call it mature code once someone has been grafting new functionality onto it, especially when they ARE throwing away big chunks of code that you could actually call mature. Bug fixes make code more mature; adding features makes it less so. This should not be a complicated concept. Maturity does not, of course, automatically lend quality; that only happens in responsible hands.

Re:Mature code?

[hondo77]

What I said is that you can't call it mature code once someone has been grafting new functionality onto it...

No, what you said was, "When you change mature code, it's not mature any more." I see neither "graft" nor "functionality" there. Sorry for not divining your true intentions with my mystic powers. Garbage in, garbage out.

I don't think you understood

[pathological liar]

What are you, a Linux kernel dev? ;)

The bug lets you write arbitrary, user-controlled bytes into kernel space. The first thing that comes to mind is that you could change the current process' priv structure in memory. Now you're root. Or why not use it to hook syscalls, or do really whatever you want? You're in ring0, go nuts.

It's far more than just a DoS.

Re:I don't think you understood

[Anonymous Coward]

It's a local escalation, right? It requires the user to run the code to be exploited? In which case the application can already take complete control of the user its running under and its data.

It's an exploit that makes a compromised machine slightly more compromised. Certainly the exploit should be fixed, but unfortunately local escalations are a dime a dozen and not all that scary.

Re:I don't think you understood

[pathological liar]

OSX is a multi-user OS. This turns any local account compromise, even an unprivileged account (sshd privsep user? nobody?) into a full compromise of the machine.

Local escalations are always scary on a multi-user machine.

More precisely

[Casandro]

...no significant bug has been found, but the code has regularly been reviewed.

I'm a Mac

[Overunderrated]

So this means we can take those idiotic commercials off the air, right?

Re:I'm a Mac

[Daniel Dvorkin]

So this means we can take those idiotic commercials off the air, right?

When there's as much malware for OS X as there is for Windows, sure.

Okay, I'll make it easy. When there is a tenth as much malware for OS X as there is for Windows, sure.

Hmmm, this isn't working. When there's a hundredth as much ... um, no, that doesn't work either.

A thousandth -- no, damn.

You get the idea. Or maybe you don't.

Re:I'm a Mac

[mwvdlee]

http://www.google.nl/search?q=malware+mac says it all. Now get those ads off the air.

Re:I'm a Mac

[Anonymous Coward]

No, it doesn't "say it all".

I can use Google to search for alien abduction, doesn't mean it's some sort of widespread occurrence.

Re:I'm a Mac

[ceoyoyo]

OMG! A Google search for two words shows up some hits! Most of which appear to say that there are one or two bits of malware for the Mac.

If you watch Apple's ads carefully, they don't claim there is no malware for the Mac. They only imply that it doesn't affect your user experience the same way it does on Windows. I think one of the actual statements goes something like "there aren't hundreds of thousands of viruses." Which is absolutely true.

You may find the commercials annoying (don't you find all commercials annoying?), and they are arguably misleading on other points, but that's not one of them.

Re:I'm a Mac

[Rewind]

http://www.google.nl/search?q=malware+mac says it all. Now get those ads off the air.

Why? Because that brings up some "Malware on the Rise" and "Malware proof your system" articles? http://www.google.com/#hl=en&source=hp&q=linux+malware Brings up some articles just like that. Should we then assume that Linux is a growing haven of security holes and seedy malware? I don't think so and I don't know why you got modded informative.

Re:I'm a Mac

[rat_herder]

ha. the top hit is from 2007, the next is from 2004. Really drove that point home, eh?

you faiL 1t

[Anonymous Coward]

and piss cocktail. Is wiped oof and

summary

[Trepidity]

Despite its relative obviousness, it took me a bit of reading there to figure out what the cause of the bug was, since I was rusty on my Unix system calls, so here's a short summary.

ioctl(2) is essentially a way of specifying system calls for drivers without actually making a system call API, so drivers can register their own calls in a more decentralized way. A call to ioctl(fd, cmd, args, ...) on a special/device file 'fd' gets routed to the driver that owns 'fd', which handles the command. The arguments might be values, or might be pointers to locations in which to return data.

fcntl(2) provides a way to perform operations on open (normal) files, like locking/unlocking them. It has the same parameters as ioctl(), except that there's always a single integer argument.

One way of implementing fcntl is essentially like ioctl -- find who owns the fd, and pass the cmd along to the relevant driver. But, Apple's code did this even for the operations on special devices normally manipulated via ioctl, so you could basically do an ioctl via fcntl. But, this bypasses some of the arg-checking that ioctl does, since fcntl always has one integer argument. So an easy exploit arises: call an ioctl that normally takes one pointer argument to assign something to. ioctl would normally check that the pointer is valid (something the caller is allowed to write to) before writing to it in kernel mode. But you can pass in any memory location at all as an integer via fcntl's argument. Voila, you get data written to arbitrary locations in memory. As an added bonus, some calls let you manipulate what data gets written--- the example exploit uses a "get terminal size" ioctl, so you can vary what gets written by changing your terminal size.

Re:summary

[FearForWings]

A good summary of the exploit.

Admittedly I don't have experience with either function but..
What I don't understand is why TIOCGWINSZ, or almost any TTY call, can be used from fcntl(2)?
Also, why didn't OS X throw an exception when fcntl(2) tired write outside the program's memory?

Re:summary

[weicco]

Also, why didn't OS X throw an exception when fcntl(2) tired write outside the program's memory?

I understood that the actual writing happened in kernel, not in userland. In kernel you can do some nasty things like write stuff to almost anywhere you like.

Make summaries more informative

[Bromskloss]

The mechanics are so simple that can be easily explained to anybody possessing some minimal knowledge about how operating systems works.

So then do so in the summary!

Re:Make summaries more informative

[jellomizer]

While the concept is simple. The example given really isn't that good to prove it.

1. Including of Uncommon (in terms of everyday use) libraries and headers.
2. The function calls and enumerations/global variables really have horrible names.

So unless you use these uncommon features in your work and even if you do have a good understanding of Operating Systems, that example isn't really that good.
So in really the post is just the guy see how 7337 I am. I found a way to hack a computer in a twitter line.

Re:Make summaries more informative

[Anonymous Coward]

"I have discovered a truly remarkable summary of the problem, but it is too small to get past the lameness filter."

Oh god

[clarkkent09]

This article presents some twitter-size programs that trigger the bug.

Ok, I get libraries of congress and olympic-sized swimming pools, but twitter is a new one. Is it used for measuring how long a program is or how pointless it is?

Re:Oh god

[e2d2]

A twitter-size program is defined as .00001 football fields or .00002 747s, which of course can be converted to Hiroshima bombs as .00000000001

Re:Oh god

[Anonymous Coward]

You forgot 'or how dangerous it is?'.

Re:Oh god

[Anonymous Coward]

The comparison was simply to (successfully) annoy those of us who are /still/ ignoring everything we can about twitter. I briefly considered checking wikipedia to see how small that was, but there were some kids on my lawn.

Re:Oh god

[Trepidity]

if u no abt txt its the same

Re:Oh god

[jack2000]

Twitter? What twitter? Who is this twitter you speak off.
You strange kids, an hour ago they were asking for a book of faces.

AND DON'T STEP ON THE GRASS!

Re:Oh god

[PearsSoap]

Seeing as Twitter uses UTF-8 encoded messages 140 characters long, you could put 560 bytes worth in a single tweet. Of course, if you're posting source code rather than an executable, then you don't have as much space.

Re:Oh god

[ceoyoyo]

My girlfriend asked me what Twitter was the other day (after some news agency mentioned following their Twitter feed, I think). So I told her that it's kind of like a Facebook wall, except that your messages are limited to 140 characters of text. Her response? "That seems kind of useless."

Re:Oh god

[hondo77]

But she knew what a "Facebook wall" was so she's not completely above it all, is she?

Re:Oh god

[gyrogeerloose]

How many Libraries of Congress is that?

Hahhah... kernel bug... LOL

[Anonymous Coward]

The author might be correct about bug exist. But he is totally lost about operating systems and kernels.

Calls Darwin as the kernel and Mac OSX as OS. Can someone explain then what is the Mach microkernel on the XNU?

Darwin is OS development version. XNU + Apples own compililation tools and configurations. The XNU is the OS of the Mac OS X. It is the OS what is microkernel-based. (Marketed as so called "hybrid kernel").

The XNU OS microkernel is the Mach. The XNU is not kernel, it is the OS. Darwin is not the kernel, it is the XNU OS Apples compiliment tool.

When author talked about kernel, I really tought "here is wiseman" but then he started talking about Darwin as kernel, what would be the Mach in the Darwin (XNU).

Re:Hahhah... kernel bug... LOL

[Anonymous Coward]

"Darwin" is actually the word used for describing all of OSX's kernel space, which actually is not at all a microkernel - they basically took mach and added all the other stuff to make it into a monolithic kernel, calling it XNU.

XNU plus drivers is Darwin.

Re:Hahhah... kernel bug... LOL

[TheRaven64]

No, XNU plus userland is Darwin. Darwin does not contain a number of proprietary drivers including, unfortunately, the entire sound stack.

For GNU types, XNU is equivalent to Linux, Darwin is equivalent to GNU/Linux, OS X is equivalent to Ubuntu (in terms of bundling nomenclature, I make no claims about feature equivalence). Darwin includes the libc, the loader, the init system (Launhcd), the toolchain and so on. XNU is just the kernel, which incorporates a Mach microkernel used as a hardware-abstraction layer and handles the VM subsystem and thread creation, a BSD subsystem which handles providing a POSIX interface to the Mach stuff and all of the other OS services, and IOKit drivers, which provide access to devices.

Still get the kernel panic on Tiger

[ygslash]

Even after the recent security update on Tiger, I still get a kernel panic with the Python code supplied in TFA:

import termios, fcntl
fcntl.fcntl(0, termios.TIOCGWINSZ)

Yeah, I'm planning to upgrade to Snow Leopard soon, after having skipped Leopard. But has Tiger already been abandoned to this extent?

Re:Still get the kernel panic on Tiger

[Bananenrepublik]

Think of it as a feature: it's faster than pulling the plug.

Re:Still get the kernel panic on Tiger

[Anonymous Coward]

It appears so. The Apple doc on Security Update 2009-003 only shows this as 'affecting' 10.5. Meaning, they didn't fix it in 10.4. I guess this is standard Apple practice when they release a newer toy than the previous one. That would mean 10.5 may now be in this category of abandoned toy now that Apple Toy 10.6 is out.

Re:Still get the kernel panic on Tiger

[foo fighter]

I'd say yes, Tiger has been as good as abandoned for quite some time. Various places were reporting 80% Leopard adoption across the Mac platforms waaay back in late 2007 to early 2008. Especially after the 10.5.2 service packs fixed many of the most glaring issues with the initial Leopard release.

Why did you hold of for so long? I'm genuinely curious. Not knowing anything else, if I were you I would have upgraded as soon as the Leopard/iWord/iLife boxed set were released at the absolute latest.

Re:Still get the kernel panic on Tiger

[ygslash]

Why did you hold of for so long? I'm genuinely curious. Not knowing anything else, if I were you I would have upgraded as soon as the Leopard/iWord/iLife boxed set were released at the absolute latest.

This is my first Mac, I'm really a Linux guy. So I was naive enough to look at the feature list and reviews for Leopard, and decide that it wasn't worth $120 for an upgrade I just didn't need. Why slow down my machine and fill up my hard disk for upgrades to apps I don't use, and a shiner GUI than one that is already far shinier than what I need? And after all, Tiger is still officially supported.

Ha. Silly me.

Real Mac users just upgrade when told to and don't ask any questions.

Re:Still get the kernel panic on Tiger

[n0nsensical]

Hahahahaha. Yeah and by 6 mos after the upgrade every new version of user apps will need function DoSomethingUselessAndShiny out of it. Welcome to the Apple's ecosystem.

Well then

[Anonymous Coward]

Just buy a PC already.

mo8d do3n

[Anonymous Coward]

we don't sux0r as fucking confirmed: t*he deal with you words, donj't get

Less vulnerabilities? Yeah, right!

[benjymouse]

Macs have a history of having far less vulnerabilities than Windows.

From IBM research: IBM Internet Security Systems X-Force® 2008 Trend & Risk Report

Look under "most vulnerable operating system". Yes, right at the top, for several years going sits OS X. It actually consistently experiences 3 times the number of vulnerabilities compared to Vista.

You can also do some secunia digging yourself. It shows the same tendency even in the raw data.

OS X may be less exploited but it has far more vulnerabilities. On top of that OS X lacks many of the anti-exploit mechanisms found in both common Linux distros and in Windows Vista.

Vulnerabilities does not have much to do with exploits. A single vulnerability may leads to several independant exploits. Many vulnerabilities will pass unexploited. The difference is incentive. And if pwn2own has showed us anything it certainly confirms this. Macs have consistently been the first to fall, literally within seconds.

Re:Less vulnerabilities? Yeah, right!

[TheRaven64]

While I agree that there are a lot more security holes in OS X than there ought to be (and you only need one to win pwn2own), I seem to recall reading that study when it came out and being less than impressed with their methodology. They did not weight the types of vulnerability in a sensible way, and they included a number of bugs in components of OS X that have no equivalent bundled with Windows (and several of the most vulnerable ones are not enabled by default), but doesn't include exploit counts for Windows equivalents.

On top of that OS X lacks many of the anti-exploit mechanisms found in both common Linux distros and in Windows Vista.

Not sure about that. OS X has a very advanced sandboxing system, and has since OS X 10.5. This is why the mDNSResponder bug last year was a remote root hole on Linux, Windows, and OS X 10.4 and a DoS on OS X 10.5 and above.

Re:Less vulnerabilities? Yeah, right!

[walt-sjc]

All studies analyzing security vulnerability reports or released patch sets as a measure of OS security simply prove that the researcher is a fucking idiot. It's IMPOSSIBLE to measure security in this way because you are comparing lawn tractors to jet skis. The reasons are basic: everyone that releases an OS has their own way of dealing with reports and patches. The raw data is MEANINGLESS.

It doesn't matter what anti-exploit technology is in the OS because it has been proven time and time again that no matter WHAT the warning, Users hit OK anyway. In fact, studies have shown that even when presented with a dialog that says something like "If you click OK, your computer will be infected by a virus," users STILL click OK 50% of the time. Windows is particularly bad in this regard because it is CONSTANTLY asking permission to do this, that, or the other thing. A typical work day for me I get 100-1000 requests for permission. It's no wonder users click OK all the time.

Due to "OS conditioned" user behavior, NONE of the anti-malware software out there is actually effective at preventing infection. Most can clean it up after the fact (with the drive pulled and scanned from another machine.)

Users also continue to use stupid passwords like "password", "1234", etc. no matter how much training given. Forcing complex passwords just ensures that there will be a postit on the monitor with the password, and a 100x increase in calls to the help desk to reset passwords.

The ONLY measure we REALLY have is subjective, and based on my experience, the reality is that windows users are probably 1000 times more likely to have malware on their systems.

I don't have any good solutions to this problem other than to suggest that we need security technology that actually analyzes a program's behavior, possibly simulating it by running in a mini-secure sandbox before talking to the user about it. Maybe apps could be be checked against a reputation database... Known good could be passed with no prompting thus reducing the amount of warning dialogs to the user. The current situation has proven dire however.

Re:Less vulnerabilities? Yeah, right!

[Anonymous Coward]

In the report (page 40, or rather; page 44. Was it really that hard to refer to a page?) it talks about number of disclosed vulnerabilities. There a re few things wrong with that list:
1) IBM's own OS is at the bottom. As they built the report, one should start questioning that. I'm ignoring "Others.".
2) It's the number of DISCLOSED vulnerabilities. I wouldn't be surprised if most of those fully-closed OSes (really just 1 of them) fixes a lot of stuff they don't disclose
3) It's the NUMBER of vulnerabilities. Actual severity of these vulnerabilities is completely ignored. Proper vulnerability analysis also takes into account the chances of these vulnerabilities actually being exploited and their impact.

My privately built OS has tons of vulnerabilities but I don't disclose them. Can I be on the bottom of that list too please? My friends OS has tons of glitches in it and he's disclosing them (like when a dinosaur logs in, and is positively authenticated, one can take over the entire system! ohnoes that's a vulnerability...... if dinosaurs still roamed the earth, that is). His OS should be on top, because clearly any dinosaur can exploit it, so it must be insecure.

Re:Less vulnerabilities? Yeah, right!

[ColdWetDog]

I'm not entirely sure I want to know the answer to this but:

A typical work day for me I get 100-1000 requests for permission.

Makes me wonder just what the hell you're doing all day. Feel free not to answer....

Re:Less vulnerabilities? Yeah, right!

[Anonymous Coward]

LOL. Parsing the post above reveals the following summary:

1. If you try to examine the problem from a quantitative point of view, you're obviously an idiot.

2. Instead, listening to MY gut feeling, and believe that Windows is far more vulnerable. This makes you less of an idiot.

It's this kind of informed debate at /. that truly blows my mind.

Re:Less vulnerabilities? Yeah, right!

[benjymouse]

All studies analyzing security vulnerability reports or released patch sets as a measure of OS security simply prove that the researcher is a fucking idiot. It's IMPOSSIBLE to measure security in this way because you are comparing lawn tractors to jet skis.

That is right. It is much better to rely on Apple adds to get the "real picture". Because we all just "know" that OS X is secure by design, that it is immune to viruses and stupid users.

Instead of any form of metric let's just vote who's secure and who's not. Better yet - let's leave it to the blogosphere and biased forums.

Or maybe you should read the IBM report on "the economics of exploits".

Re:Less vulnerabilities? Yeah, right!

[Lars T.]

Could that have something to do with the fact that the vulnerability reports for OS X include tons of third party stuff (including Java or things that aren't used by default), that those for Windows don't?

Re:Less vulnerabilities? Yeah, right!

[stewbacca]

Yes, the severity of the exploits is what matters. I didn't read TFA, but a lot of people keep bringing this up in this thread. If the IBM study doesn't properly address the "magnitude of effect" (i.e. the seriousness of any differences between means or other comparative or inferential statistics), then it is ripe for biased-respresentation. People can pick and choose what they want to say without an accurate discussion of the findings. Raw numbers don't mean crap.

Re:Less vulnerabilities? Yeah, right!

[mvdwege]

That is right. It is much better to rely on Apple adds to get the "real picture".

Care to point out just where the OP wrote that? Or even suggested it?

Mart

Re:Less vulnerabilities? Yeah, right!

[walt-sjc]

I'll gladly answer. I'm actively using my computer doing everyday tasks, browsing web sites, reading and responding to email, writing documents, working in spreadsheets, moving files around, etc., all day long. Probably 10 hours at least. 100 pop ups would only be one every few minutes. In reality, it's much more, and they come in spurts.

Tell ya what. You keep a little pad next to your mouse, and make a check mark for each pop up you get when doing something normal, like deleting a file, or copying a directory over another (a task which can easily generate a dozen dialog boxes alone) that requires a Yes, OK , or Continue answer. See how many you get after a 10 hour day. Apparently, from your comment, you will be stunned. And you should be.

Re:Less vulnerabilities? Yeah, right!

[assassinator42]

"browsing web sites, reading and responding to email, writing documents, working in spreadsheets":
Are you talking about UAC prompts? You don't need admin privileges for any of that. You also shouldn't need admin privileges for moving your personal files around. If you need to do a lot of copying of files in the program files or windows directories, it may be easier to just start an elevated command prompt.
Although I guess you're talking about all kinds of dialog boxes. Only thing I can really see is deleting files and doing a save as on an office document.

Re:Less vulnerabilities? Yeah, right!

[walt-sjc]

Yes, I'm talking about all the confirmation dialogs of all types... UAC, browser plugins, file deletion, etc. It's the "conditioning to press OK" that I was talking about. I thought I was pretty clear about that and had not mentioned UAC at all.

Re:Less vulnerabilities? Yeah, right!

[arminw]

...I don't have any good solutions to this problem ...

Apple does have a solution to this problem for the iPhone. They have to give permission to load any given program on the phone by approving it to be in the app store. Apple could extend this to OSX which many people would appreciate. They could also allow loading other normal nonapproved applications, but these would give the user a draconian security warning about the possibility that the program they are about to approve on their computer is likely to be malicious. For anybody who is willing to restrict themselves to only the applications available in the apps store, and it would did return given the ironclad guarantee, that they could never get a virus, Trojan or other nasty program installed on their computer. No program of any kind would be allowed to execute on the computer, unless it had a signature from Apple, or was specifically approved by the user, who was amply warned of possible dire consequences. It would be kind of like it is done today on jail-broken iPhones.

Re:Less vulnerabilities? Yeah, right!

[Thinboy00]

You explicitly used the term "requests for permission", which, while not a ridiculous term for modal dialog boxes, sounds a lot like UAC prompts (commas inserted for clarity, not because they're needed).

Re:Less vulnerabilities? Yeah, right!

[Thinboy00]

That involves security audits of things like MS Office for OS X. How, exactly, will Apple convince MS to allow such a thing, especially given current legal circumstances (i4i v. Microsoft). Furthermore, that involves a lot of security audits of a lot of things, and right now we're in the middle of the great recession, so...

Re:Less vulnerabilities? Yeah, right!

[arminw]

.....and right now we're in the middle of the great recession,....

What does the recession have to do with this? After all,it works great for the iPhone. People would have a choice to install guaranteed secure applications from the App store, or they could install applications as they do now, except they would get a warning that such applications may not be secure and be malicious. If Microsoft chose not to include their office application in the app store, that would be fine. All it means is that when a user installs Microsoft office or any other program outside from the App store, they get a security warning. Obviously, if I as a user choose to install a well-known applications such as Microsoft Office, I would likely be pretty confident that it is also clean. This would not necessarily be the case for a random download from the Internet.

Re:Less vulnerabilities? Yeah, right!

[bmckeever]

Not sure about that.

GP is probably referring to things like address randomization, which make many types of vulnerabilities harder to exploit. I think Matasano Chargen has a good writeup if you're interested in more.

Re:Less vulnerabilities? Yeah, right!

[TheRaven64]

OS X has had loader address randomization since 10.5 and increased the number of places where it's used with 10.6 (you need to compile a position-independent executable for it to be enabled). The Mach-O loader relocates individual symbols independently, while many ELF loaders relocate a segment at a time, which increases the utility of this. OS X has also supported stack canaries for a while. 10.4 shipped with a non-executable stack by default (which caused lots of people to complain that nested functions broke). Swap has been encrypted on OS X since 10.4., 10.5 added W^X protection.

Using the sandbox-exec command, you can run any program, trivially, in a sandbox, either with a policy you define, or one of the standard ones (e.g. no write access to disk except in a temporary folder, no Internet, and so on). This is a simple UI on top of the SEDarwin stuff, which is based on TrustedBSD (a full MAC framework for BSD).

The code signing framework on OS X is used by things like the keychain and firewall, so if an application is trojaned then suddenly the keychain won't allow it access to your passwords and the firewall won't allow it access to the network.

Saying that OS X lacks anti-exploit mechanisms is just ignorant.

Re:Less vulnerabilities? Yeah, right!

[0ld_d0g]

The operating system functionality has overshadowed its theoretical computer science definition. If Apple isn't confident of all the bits it ships to its users, maybe it shouldn't ship them?

Hunt the Link

[mike260]

This article presents some twitter-size programs that trigger the bug.

Out of interest, what's the justification for linking to the article on "programs that trigger the bug" and not in the blindingly obvious place ("This article")?
I ask because it seems to be in-line with some kind of brain-dead in-house Slashdot linking style, and I'm curious to know the reasoning behind it.

Re:Hunt the Link

[Phurd Phlegm]

Out of interest, what's the justification for linking to the article on "programs that trigger the bug" and not in the blindingly obvious place ("This article")? I ask because it seems to be in-line with some kind of brain-dead in-house Slashdot linking style, and I'm curious to know the reasoning behind it.

I gave up long ago trying to determine what, if anything, a given link in an article summary had to do with anything. Either determining where to put a link in a sentence is a lot harder than I think, or no one cares very much.

Re:Hunt the Link

[6Yankee]

Usability guidelines - the link text should be meaningful on its own. IIRC, some browsers will present you with a list of links, complete with text. I'm sure Slashdot used to do this at the top of articles, too.

"This article" tells you only that there's an article.
"Programs that trigger the bug" is a clearer description of what you'll find.

That said, I'd have re-written the submission to avoid using "This article" if I wasn't going to link on it.

Re:I read, therefore I am

[Anonymous Coward]

And yet, I never saw any instructions for opening the Wal-Mart special RandomBrand of padlock.

Those locks can be opened by sneezing. Only the person who buys them would need instructions.

mature code ? ah!

[Anonymous Coward]

mature code ? MacOS ? give me a break. it's not mature with respect to security, it's always features, features, features.

Re:mature code ? ah!

[Anonymous Coward]

From the way OS X is designed, I imagine two groups at Apple that work on OS X and its design. The first are the classic BSD crowd who add and enhance the already notable BSD foundation for security. For example, the way passwords have been stored went from the old crypt() way to storing a salt and a SHA1 hash. I haven't purchased OS 10.6 yet, but 10.5 has a lot of solid security features, such as SELinux-like MAC lists (like the one that prevents writes to a Time Machine drive by even root processes).

One ingenious thing Apple developed was the concept of sparse bundles. Encrypted data can be stored in its own container, and if there is a 1 byte change, instead of the backup program having to back up the whole container, only 1 8 meg band has to be copied. Of course, this may give an attacker knowledge of what is in an encrypted container over time, but for a lot of purposes, this is an excellent thing to have for security.

The other group at Apple is the one values usability above all else. They want the user experience to take precedence over everything else, even if it means a cut corner or two in the security department. So there is a lot of stuff that either runs SUID or runs at root. For example, the decision to make the Applications directory writable by "blessed" users with su to root admin access, rather than root only. This is stupid because malware can infect one of the files in there, which will affect all users, just like in the old UNIX variants where critical files were owned by the bin user and not by root.

Both groups are needed. Fire the BSD guys in sandals, and OS X ends up like OS 9 and previous with numerous, unfixable security issues and apps which take down the whole box. Fire the guys with the UI tastes, and you get an OS that the Mac users will find difficult to work with, similar to why a lot of people left Macs in the early 1990s.

Love the editing

[Pedrito]

or lack thereof:

"The mechanics are so simple that can be easily explained to anybody possessing some minimal knowledge about how operating systems works."

"...so simple that it can be easily..."

The choice of "some minimal" is a bit questionable too. "some" or "minimal" alone would have been sufficient to convey the meaning. Together, it sounds almost redundant.

"Beside being a good educational example this is also a scary proof that very mature code can still be vulnerable in rather unsophisticated ways."

"Beside" means "next to". "Besides" means "other than".

Not that it really matters. The mainstream news sites can't seem to compose articulate sentences either. Grammar has really gone to crap and it really bugs me that English based news providers can't be bothered to produce fluent English stories.

Re:Love the editing

[Megane]

"Mechanics" is plural, and yet you want to use "it" as a pronoun for a plural word? Grammar really has gone to crap. (Also, how operating systems work, another case of mis-matched plurality.)

Re:Love the editing

[StormReaver]

or lack thereof:

"The mechanics are so simple that can be easily explained to anybody possessing some minimal knowledge about how operating systems works."

"...so simple that it can be easily..."

Since we're being grammar Nazis:

"...so simple that they can be easily..."

Re:Love the editing

[Anonymous Coward]

Not to be pedantic, but if you're going to call the kettle black:

"...so simple that they can be easily..." (The pronoun should agree with its antecedant "mechanics" in number.)

The choice of "some minimal" is a bit questionable too. "some" or "minimal" alone would have been sufficient to convey the meaning. Together, they sound almost redundant. (Again, an error in number agreement between the pronoun and its referent.)

"Beside" means "next to." "Besides" means "other than." (Small punctuation marks like periods and commas are properly placed before end quotation marks, unless you're British.)

Not that it really matters. The mainstream news sites can't seem to compose articulate sentences either. Grammar has really gone to crap, and it really bugs me that English-based news providers can't be bothered to produce fluent English stories. (Compound sentences require a comma before the conjunction. Compound adjectives should generally be hyphenated.)

Yeah, grammar sucks--especially because no matter how many times you revise, there's always some smartass who can come along and find a mistake you overlooked.

Not available for 10.4?

[Anonymous Coward]

It looks like there is no patch for 10.4.

That sucks.

" Kernel

            CVE-ID: CVE-2009-1235

            Available for: Mac OS X v10.5 through v10.5.7, Mac OS X Server v10.5 through v10.5.7

            Impact: A local user may obtain system privileges

            Description: An implementation issue exists in the kernel's handling of fcntl system calls. A local user may overwrite kernel memory and execute arbitrary code with system privileges. This update addresses the issue through improved handling of fcntl system calls. Credit to Razvan Musaloiu-E. of Johns Hopkins University, HiNRG for reporting this issue."

Re:Mature code? vs Robust code

[Anonymous Coward]

It seems to me that is the distinction that should be made in this side argument over semantics. I would think "mature" would be more applicable to code that has been around for a "while" without modifications for purpose (for adding function) versus modifications to enhance robustness (for fixing incorrect function/crashing and security exposures). The need to fix security exposures could be driven by new exploits of quite "mature", but not "robust" code.

Does that make sense?

RO

Re:Hahhah... kernel bug... Origins?

[Anonymous Coward]

I am curious. Did this vulnerability originate in the Mach microkernal, or one of those other parts listed above? In something Apple added or modified? My first thought upon reading this discussion was that the BSD "base" (as I had understood to be the origins of MacOS X, having forgotten about the Mach part), was to wonder if any of the BSD's shared the flaw (although I doubt that OpenBSD would be likely to ;-)

Just trying to get a clearer understanding.

TIA,
RO

Finder

[Weezul]

You can find a major privilege escalation hole in Finder quite easily :
http://ask.metafilter.com/131473/Does-this-create-a-local-root-exploit-for-Mac-OS-X-using-Finder
Finder isn't setgid but may access any gid!

And

[AnAdventurer]

I RTFA, but it lacked an example of the bugs use in the wild for reals and/or by accident. I am an Apple user and maybe I am the only one to admit it, but my Mac hangs and parts crash sometimes. Is this a likely and occasional culprit?

twitter, Erris, gnutoo, inTheLoo

[tepples]

Who is this twitter you speak off.

A notorious sockpuppet troll on Slashdot.

Re:Hahhah... kernel bug... Origins?

[TheRaven64]

Without looking at the code, I can't tell you for certain, but looking at the traces that were in TFA it looks like the code is part of the bottom of the BSD stack responsible for handing over control to the device driver layer. This is almost certainly Apple code, because it contains interfaces to Mach and IOKit.

Given that the bug is in tty handling, I wouldn't be surprised if some of this code dates back to 4BSD or even earlier (take a look at the change log for the firs OpenBSD release to get an idea of how buggy the original BSD releases were).

rara

[Anonymous Coward]

hmmm, this bug was one of several kernel bugs presented at Cansec'09, if memory serves me right, an exploit for this bug was written in June 2008.

Perspective

[Anonymous Coward]

So you can crash a OS X server with a small program if you can get it on there. How does this affect anyone?

- Web Server
-- anyone who can publish code to the web server can crash it. But why would they want to? They just paid to use it!

- Home computer
-- If you install a malware program- it could crash your computer without your permission. It could do worse...like delete your files. Don't worry about this one.

- Data center servers
-- If someone hacks into the system, they could write a program to take down the server. Hmm, that is not what most hackers want to do...they want to get into data. So your biggest concern is the data. But hacking into OS X isn't like hacking into Windows, so again, not something you should lose sleep over.

I guess I'm at a loss to say why this is really a problem. It requires someone to willingly put a bad program on the machine, or for another hack to get you onto the system in question....which to me is far worse than shutting down the machine!! If a hacker shuts down your box, they're doing you a favor.

os upgrade cycle - hardware upgrade cycle

[bill_mcgonigle]

Sadly I couldn't get my Mac OS X 10.3.9 (PowerPC) machine to panic with the C code.

That's OK, there are bound to be other exploits for a 10.3 machine available for you.

This one gets by for the PowerPC users (if you can somehow ignore Leopard being so spotty, right, that's why they did an entire no-feature release). But there are tons (literally) of Macs belonging to owners with fine, workable machines, who have to chose to be vulnerable, ditch their machines, or switch OS's. Ubuntu 8 LTS seems to have a PPC version at least.

Heck, there are probably some folks who bought the quad-core, liquid cooled G5 towers at EOL with machines still under AppleCare who cannot upgrade to the current OS. STBT, I guess.

PPC to Intel was one such painful inflection point - I'm not sure if CPU to GPU or Macintosh to iPhone Platform will be the next. Not a problem for Apple, the wealthy, or people who can actually get a computer properly recycled, though.

And they broke WiFi Internet sharing...

[Anonymous Coward]

And they broke WiFi Internet sharing - Doesn't work any more. Comes up, works for about 3 minutes and then 100% failure.

I wonder if they will even bother fixing it, or if they hope to force us all to buy Snow Leopard?

Re:And they broke WiFi Internet sharing...

[Archeopteryx]

And they broke WiFi Internet sharing - Doesn't work any more. Comes up, works for about 3 minutes and then 100% failure.

I wonder if they will even bother fixing it, or if they hope to force us all to buy Snow Leopard?

I can confirm this.

I spent about 6 hours trying to find a good workaround over the weekend, but could not.

Re:And they broke WiFi Internet sharing...

[Archeopteryx]

OK, here is a workaround;

http://blog.hep-cat.de/?p=4760#Mac

Basically it rolls the Airport firmware back to 10.5.7

It's a terminal-based solution.

Tried it and it works.