Linux X.org Critical Security Flaw Silently Patched

eldavojohn writes "On June 17th, the X.org team was notified by Invisible Things Lab of a critical security flaw (PDF) that affected both x86_32 and x86_64 platforms. The flaw deals with escalated privileges of a user process that has access to the X server. The founder of ITL said of the flaw, 'The attack allows a (unpriviliged) user process that has access to the X server (so, any GUI application) to unconditionally escalate to root (but again, it doesn't take advantage of any bug in the X server!). In other words: any GUI application (think e.g. sandboxed PDF viewer), if compromised (e.g. via malicious PDF document) can bypass all the Linux fancy security mechanisms, and escalate to root, and compromise the whole system.' This has apparently been a security flaw since kernel 2.6 was released. From the article, 'On 13 August, Linus Torvalds committed an initial fix, but several patches were added afterward for various reasons. The problem has been addressed in versions 2.6.27.52, 2.6.32.19, 2.6.34.4 and 2.6.35.2 of the kernel.'"

Comments

Convenient

[rotide]

So, I'm supposed to click a link to read a PDF about a PDF flaw. You sly boots!

Re:Convenient

[Asmodaie]

Ah, you beat me to it.

Re:Convenient

[odies]

So, I'm supposed to click a link to read a PDF about a PDF flaw. You sly boots!

It's not a PDF flaw, it's a flaw in Linux kernel. The malicious PDF file was just an example for an attack vector. You know, the same way it works in Windows. No system is immune to these kind of attacks, the only reason Linux and Macs see them less is because most of the users are on Windows (especially the "stupid" or casual ones). Not even the walled gardens like iPhone, where PDF attack was used to root and jailbreak the system just recently.

Re:Convenient

[Nadaka]

Another reason Linux is safer is that these problems get due attention when reported, but for the windows team puts effort to fix most problems, it has to be a source of embarrassment for the company.

Re:Convenient

[odies]

Do you honestly think that Microsoft would do nothing if there was a non-patched privilege escalation exploit in Windows?

Also, note that this was silently patched with no announcement of the problem. It has been there since kernel version 2.6. That is a long, long time.

Re:Convenient

[machxor]

It's not a PDF flaw, it's a flaw in Linux kernel. The malicious PDF file was just an example for an attack vector. You know, the same way it works in Windows. No system is immune to these kind of attacks, the only reason Linux and Macs see them less is because most of the users are on Windows (especially the "stupid" or casual ones). Not even the walled gardens like iPhone, where PDF attack was used to root and jailbreak the system just recently.

You got it spot on. Although in my personal experience I've had more Linux servers compromised than Windows ones. Could be the fact that in general my Linux servers are exposing services to the internet where as my Windows servers are not. Or it could be the fact that at times questionable users (ie: customers) have had access to my Linux boxes. Oh and then there was one time my MS-DOS server was compromised (lol).

In general it's not the OS keeping you secure it's how valuable of a target you are and how vigilant you are at security.

Re:Convenient

[NNKK]

Do you honestly think that Microsoft would do nothing if there was a non-patched privilege escalation exploit in Windows?

What rock have you been living under?

Re:Convenient

[Peach Rings]

They patched it, I don't know what you expect them to do beyond that. "Silently" just means that slashdot didn't pick up on it or something.

Also,

Do you honestly think that Microsoft would do nothing if there was a non-patched privilege escalation exploit in Windows?

Are you kidding?

Re:Convenient

[Anonymous Coward]

What are you on about? There a full changelog for the patched code. Do you have any idea how much changes in the linux tree each week? One bugfix is not going to make news other than from a pro-Windows news outlet attempting to make it appear there's a cover up. Try reading LKML if you're stupid enough to think there's a conspiracy going on.

Re:Convenient

[Anonymous Coward]

You got it spot on. Although in my personal experience I've had more Linux servers compromised than Windows ones.

Reference please? Which Linux servers? Red-hat? Debian? SELinux enabled?

Sounds like you know a lot about the subject..

Re:Convenient

[erroneus]

Yes.... yes I do. We have seen it with the process messaging flaw.

Microsoft is a for-profit company. To make a profit, they have to control costs and increase sales. By paying people to patch vulnerabilities, they are increasing costs. This has the effect of lowering profit. On the other hand, their reputation has impact on their ability to make sales (though admittedly, not as much when you are not a monopoly). So if the flaw is well known (which in this case, became the headline of a great many news stories) they might be pushed in the direction of spending the money to fix it, but since they are a monopoly, it takes a much bigger push to get a flaw like that fixed than if they were in competition with other OS makers. And I am sure they work under some sort of formula that says "If cost of fix x 10 loss of sales then ignore it" or something like that.

So yes, if they felt that the threat to their profits is large enough they will take action... else they will not. Lately, Microsoft is facing a lot of competition so yeah, they are more likely to take action now than ever before. But that has not always been the case, especially during their golden years of "embrace and extend" and other standards-trampling behaviors. They could pretty much do whatever they wanted... and did.

Re:Convenient

[Anonymous Coward]

er...woosh?

Re:Convenient

[morgan_greywolf]

Do you honestly think that Microsoft would do nothing if there was a non-patched privilege escalation exploit in Windows?

Yes. Microsoft's track record certainly speaks for itself. There have been plenty of instances where known non-patched privelege escalation exploits in Windows went unpatched by Microsoft for years. (One I'm thinking of in particular affected GDI).

Re:Convenient

[Anonymous Coward]

Came here to post the same!
Can't wait to be Adobe's PR dept.

Re:Convenient

[Lunix Nutcase]

There have been plenty of instances where known non-patched privelege escalation exploits in Windows went unpatched by Microsoft for years. (One I'm thinking of in particular affected GDI).

Your case might be more persuasive if you actually linked to them rather than a vague claim of "plenty of instances". If there were so many, you could link to at least a couple, no?

Re:Convenient

[betterunixthanunix]

Also, note that this was silently patched with no announcement of the problem.

It was not "silently patched." It would be pretty hard to "silently patch" the Linux kernel, unless you could come up with some other explanation of your changes to the kernel developer. The patch was noted in the changelog like any other patch. No attempt was made to hide it.

Or did you think that the developers should have been screaming about the patch from the rooftops? This is not the first security bug to patch in this way.

Re:Convenient

[blair1q]

Just click the popup telling you that your PC is infected. That'll fix it.

Re:Convenient

[Anonymous Coward]

How shitty an admin do you have to be to have so many compromised machines? I can see how you've come to your conclusion however I think you've got it all wrong, the weak link in the chain seems to be you, not how valuable you are.

Re:Convenient

[machxor]

Reference please? Which Linux servers? Red-hat? Debian? SELinux enabled?

Sounds like you know a lot about the subject..

This was between 1999 and 2003 when a partner and myself were running a small web hosting/shell company Mach Nine Internet Services, http://www.mach-nine.com/ (under construction now?), http://www.lomag.net/information/news.php

Always Redhat... started with 6 (which was the 2.2 kernel...) and think we ended at 7.1.

In any case this small period of time was the only time I've had Linux servers publicly available on the internet and two of three machines were rooted due to a (2.4?) kernel flaw that made it trivial to escalate privileges if you had a shell (which being a shell provider...). Since then I've had several Windows servers publicly servicing the internet but the difference is that they are for my personal use and not high profile (in relation to my old Linux servers) targets.

My statement was not one about the inherent security of one OS over the other. There is more I could have done to prevent the root attacks on the Linux machines and I don't deny that. I'm repeating myself here but my point was:

In general it's not the OS keeping you secure it's how valuable of a target you are and how vigilant you are at security.

Re:Convenient

[Anonymous Coward]

The only issue with your logic is that the cost of repairing bugs is infinitesimally small when compared to the revenue that Microsoft generates. The cost of bad press is far more than fixing the OS.

I think the problem with MS is that they are a leviathan, and slow.

Re:Convenient

[digitalunity]

Oh god they're countless. Sure, the publicly known privilege escalations are patched now, but there are a few that were around for many many years.

The old NT login bug was there for a long time before MS fixed it.

Re:Convenient

[Abstrackt]

Came here to post the same!

Came here to post something completely different! (I just like the attention)

Re:Convenient

[tolan-b]

Privilege escalation by any non-privileged GUI app you say? No they'd just say it's not a bug and that they have no intention of fixing it.

http://www.pretentiousname.com/misc/win7_uac_whitelist2.html

Re:Convenient

[drsmithy]

Oh god they're countless.

List 10.

Re:Convenient

[drsmithy]

So yes, if they felt that the threat to their profits is large enough they will take action... else they will not.

Yet regularly and frequently they release bugfixes for problems that are neither high profile, nor "embarrassing". Strange.

Re:Convenient

[blueg3]

Xorg is part of the Linux kernel?

Re:Convenient

[gorzek]

Sure, fixing a bug might take a line or two of code.

But the time required to fully test it and make sure it doesn't break anything else? That's where all the real costs are. It's why Microsoft doesn't generally have a fast turnaround on Windows security fixes.

Re:Convenient

[VGPowerlord]

Interesting article. It's a shame the author hasn't updated it since Windows 7 RC1. As far as we know, some or all of the bugs it mentions have been fixed... or that none of them have been.

Re:Convenient

[Ant P.]

This exploit works on OpenBSD?

Re:Convenient

[digitalunity]

I don't have that kind of time. Here's one.

http://www.microsoft.com/technet/security/Bulletin/MS10-054.mspx

Microsoft acknowledges that it affects Windows all the way back to XP SP3 but I'd bet my lunch money it affects SP1 also.

Re:Convenient

[drsmithy]

Your support of an assertion claiming "countless" unpatched privilege escalation bugs is a single, already patched, bug ?

Re:Convenient

[drsmithy]

No they'd just say it's not a bug and that they have no intention of fixing it.

That's because it isn't. From that very web page:

All of this only affects the default account type and UAC level of Windows 7 (builds 7000 & 7022, but probably also the retail given Microsoft's stance so far). If you go against the defaults and run as a non-admin user or turn UAC up to the Always Prompt level, so it behaves like it did in Vista, then it is no longer possible for code-injection from unelevated processes to bypass UAC prompts.

Not to mention it requires the end user to manually run untrusted code.

At _worst_ it's a configuration issue. It's as much of a "bug" as the default timeout for sudo.

Re:Convenient

[Anonymous Coward]

And I am sure they work under some sort of formula that says "If cost of fix x 10 loss of sales then ignore it" or something like that.

It's not the cost of lost sales that drives bug fixes in most cases, but the cost of repeatedly triaging field failures that eventually come down to "oh, that's that same stupid bug that we didn't fix last time."

Re:Convenient

[Anonymous Coward]

Not to mention it requires the end user to manually run untrusted code.

Phew! Thank goodness that users never do that!

Re:Convenient

[Score Whore]

Contrary to the headline written by an idiot, this isn't an Xorg bug. It's a kernel bug that can be exploited through Xorg.

Re:Convenient

[cynyr]

All bugs are the same in the kernel devs eyes. "crashes when the user touches their nose on days that end in X, and while mars is behind the sun relative to the earth" as well as "Press the 'y' key to become root" both get the same mention, a line in the kernel changelog.

Re:Convenient

[Anonymous Coward]

1) http://blogs.pcmag.com/securitywatch/2010/08/unpatched_vulnerability_in_all.php
2) http://www.zdnet.com/blog/security/microsoft-warns-of-serious-unpatched-windows-7-flaw/6474
3) http://blogs.pcmag.com/securitywatch/2010/08/unpatched_vulnerability_in_all.php
4) http://www.computerworld.com/s/article/9176944/Microsoft_warns_of_bug_in_64_bit_Windows_7?source=rss_security
5) http://isc.sans.edu/diary.html?storyid=8023
6) http://news.cnet.com/8301-1009_3-10170962-83.html
7) http://www.geek.com/articles/chips/17-year-old-unpatched-windows-vulnerability-discovered-20100120/
8) http://arstechnica.com/microsoft/news/2010/03/exploits-of-unpatched-ie6-ie7-flaw-on-the-rise.ars
9) http://www.h-online.com/security/news/item/Several-known-vulnerabilities-to-remain-unpatched-on-forthcoming-Microsoft-patch-day-947191.html
10) http://www.myce.com/news/microsoft-confirms-windows-shortcut-zero-day-exploit-32107/?utm_source=myce&utm_medium=frontpage&utm_campaign=related_posts

There, 10 vulnerabilities, which either took Microsoft months after visibility to patch, or still aren't patched.

Now, STFU.

Re:Convenient

[machxor]

I wonder why did you make such an omission. Perhaps to create an appearance of support for your completely invalid claims?

First I fail to see how my claim is invalid. It's popular belief that software X is more secure than software Y simply because it is less desirable for someone to attack.

So how do you compare exploits seen by a Linux shell provider with exploits you have seen being a Windows shell provider?

Ummm because my point was that machines with higher value (ie: ones customers use/have access to) are of more likely to be attacked...

And you conveniently did not mention that you counted exploits on a poorly run shell server vs. Windows "server" that never runs anything you didn't put on it (and they apparently still were copromised, just less often than your shell servers).

I mentioned my compromised MS-DOS machine more as a joke (I was probably 12, running a BBS gave the wrong person sysop...)

I think the Linux servers were maintained pretty well actually but what do I know? Oh and I clearly mentioned the difference between users having access to my Linux servers and not my Windows Servers.

If it's too hard for you guys to see my point because I mentioned Linux and Windows in the same post and got your panties in a bunch then think about this...

My console is connected to the internet. To an attacker it's a lower value target than say a PC on the same network that I do my online banking on. Just because my console is lower value to an attacker doesn't inherently doesn't make it any more or less secure than my PC.

Re:Convenient

[Alex Belits]

1. All compromises of a Linux shell servers ARE privilege elevation -- because every intruder starts from having a valid local an account on it.

2. A privilege elevation on a Windows server would not even be an exploit because Windows server does not run untrusted content -- if you have an account on hosted Windows server that can install things, you are its administrator already, so there is nothing to exploit.

3. Windows desktops suffer from privilege escalation exploits all the time. So would any system that would provide remotely accessible shell accounts on Windows server.

4. You are still pretending that anything you have observed has something to do with remote exploits, quality of maintenance, and other irrelevant and stupid statements that you made and I have ignored.

Re:Convenient

[machxor]

1. All compromises of a Linux shell servers ARE privilege elevation -- because every intruder starts from having a valid local an account on it.

Are you for real? A non-customer would not have a local account.

2. A privilege elevation on a Windows server would not even be an exploit because Windows server does not run untrusted content -- if you have an account on hosted Windows server that can install things, you are its administrator already, so there is nothing to exploit.

Why are you still arguing Linux vs. Windows? My post has never had anything specific to Windows vs. Linux and you'd know that if you bothered to read before responding.

3. Windows desktops suffer from privilege escalation exploits all the time. So would any system that would provide remotely accessible shell accounts on Windows server.

Sigh...

4. You are still pretending that anything you have observed has something to do with remote exploits, quality of maintenance, and other irrelevant and stupid statements that you made and I have ignored.

Again if you'd read my posts you'd know what my point is. I'll give you a hint, it has nothing to do with anything you wrote there.

Re:Convenient

[Alex Belits]

Are you for real? A non-customer would not have a local account.

Have you ever seen a shell server compromised by a non-customer? You are talkling about your shitty little ISP experience, not some theoretical possibility, right?

Why are you still arguing Linux vs. Windows? My post has never had anything specific to Windows vs. Linux and you'd know that if you bothered to read before responding.

Don't even try that shit. Your most prominent statement was the claim that you have observed that Linux servers were compromised more often than Windows server. You backed it with fallacies, spin and your experience that -- if it was true or relevant in the first place -- is in no way applicable for any comparison.

If you want to discuss your most idiotic (though less prominent) claim that one has to be "vigilant" to run Linux servers in a secure manner (as opposed to merely implementing well-known sane policies and apply updates when they are released), you are welcome to do it after renouncing your claims of having demonstrated it with your shitty experience running shell servers.

Re:Convenient

[machxor]

Have you ever seen a shell server compromised by a non-customer? You are talkling about your shitty little ISP experience, not some theoretical possibility, right?

Yes I have. Must be nice to live in a world where the only possibilities are the ones you believe.

Don't even try that shit. Your most prominent statement was the claim that you have observed that Linux servers were compromised more often than Windows server. You backed it with fallacies, spin and your experience that -- if it was true or relevant in the first place -- is in no way applicable for any comparison.

No my most prominent statement was "in my experience" and then I went on to convey that experience. Sorry my experience is that of the Linux/Windows servers I've had on the internet and the Linux servers being compromised more than my Windows servers. I know my personal real world experience is really upsetting you but I even gave very clear reasons as to why my experience was such. You want to ignore all that and pretend that I said "Windows is more secure than Linux" or "Windows is easier to maintain than Linux"

If you want to discuss your most idiotic (though less prominent) claim that one has to be "vigilant" to run Linux servers in a secure manner (as opposed to merely implementing well-known sane policies and apply updates when they are released), you are welcome to do it after renouncing your claims of having demonstrated it with your shitty experience running shell servers.

If you want to twist my words into something I didn't say then go right ahead. My point was that unless you are vigilant on security under ANY operating system then you will be less secure than someone else who is.

PS: "...to merely implementing well-known sane policies and apply updates when they are released..." is being vigilant about security. A home user that ignores updates is not being "vigilant" about security.

Re:Convenient

[Alex Belits]

Yes I have.

Describe one.

Must be nice to live in a world where the only possibilities are the ones you believe.

Extraordinary claims are supposed to be supported by something other than "you are not open-minded enough".

No my most prominent statement was "in my experience" and then I went on to convey that experience.

Your "experience" how you described it, contradicts your own claims. The rest is irrelevant.

You want to ignore all that and pretend that I said "Windows is more secure than Linux" or "Windows is easier to maintain than Linux"

No, you claimed that all operating systems are equally insecure. This is false.

PS: "...to merely implementing well-known sane policies and apply updates when they are released..." is being vigilant about security. A home user that ignores updates is not being "vigilant" about security.

"Vigilant" means actively and constantly applying some nontrivial effort. Not calling root shell with input from CGI, or running an auto-update procedure every day is not "vigilant". Backing up all data from VMWare hosts, sifting for exploits, reimaging compromised VMWare instances of Windows and restoring sanitized data back to them is "vigilant".

Re:Convenient

[Anonymous Coward]

Really, the kernel mailing list only ever gets about 330 messages per day, and thats for only about two or three thousand lines of code (per day). Thats it. The kernel growth rate is starting to level out, its just that code is replacing older code. The problem with Linux is that the refining process never ends. People are always picking nits and replacing code with code thats cleaner and faster. With companies (eg microsoft), they stop the process when its either economically not viable to fix problems, or when no one is complaining, or when there is something else more serious to deal with (or when there is a shipping date, at which point its considered 'good enough' and after which bugfixes stop, and product is shipped to eager paying customers).

Re:Convenient

[drsmithy]

There, 10 vulnerabilities, which either took Microsoft months after visibility to patch, or still aren't patched.

Actually, there were about 6 unique vulnerabilities listed, only 2 of which remain unpatched.

Congratulations. Only 8 more to go. I'm surprised it's so hard, given how "countless" they are - I was expecting to get at least 25 listed by various posters within an hour.

Re:Convenient

[drsmithy]

Phew! Thank goodness that users never do that!

No security system in the world can help you when you're ready and willing to turn it off and invite the robbers inside.

Re:Convenient

[Anonymous Coward]

It would be of great interest (to me at least) if the Gods who administer this website could give us a summary of how many people came to this page and followed the link. It would also be of some interest to see the system/browser stats of those that did click through. If only the PTB cared about the hopes and desires of ACs my life would be complete(ish).

Re:Convenient

[TheSeaCucumber]

...Don't feed the troll. Does it not worry you that there are 2 unpatched and documented vulnerabilities? At least the linux team didn't know about this vulnerability. Besides, only a small percentage of the user base actually know exactly what everything in the kernel does, let alone pick vulnerabilities in it. In a working distro, there should be NO documented vulnerabilities without a patch. In any case, when the Linux team got tipped off, the patch was fixed. For that, I am proud to belong to such a community.

Re:Convenient

[TheSeaCucumber]

Yeah, why was that modded as a troll? OP's comment is a perfect criticism to pick out from an ignorant media company. Maybe humourless mod missed sarcasm?

Re:Convenient

[Anonymous Coward]

I'm sure I read the same reply as you and I came away thinking he had experianced more linux breakins because he had looked after mainly linux servers. He was in no way trying to start an argument.

So please pipe down.

Re:Convenient

[IrquiM]

I came here to avoid posting, but now you ruined that!

Will have to spend my mod-points elsewhere!

Re:Convenient

[NeverVotedBush]

Alex Belits says: "If you want to discuss your most idiotic (though less prominent) claim that one has to be "vigilant" to run Linux servers in a secure manner (as opposed to merely implementing well-known sane policies and apply updates when they are released)..."

Alex, you have to be vigilant to run any server or desktop in a secure manner. Many times there are reconnaissance efforts before an actual exploit. If all you do is set something up and keep it patched, but never inspect logs or other activity on and around the system, you will miss a lot of clues to malicious activity that in many cases predate the actual exploit.

That is computer security 101.

Re:Convenient

[Anonymous Coward]

You are deliberately ignoring the "or took MS a long time to patch" part of this discussion. We're not talking about current, live vulnerabilities. We're talking about a history of a long turn around time for patches of extreme security holes.

And you're sticking your fingers in your ears and ignoring it because it hurts your stance.

But the fact is, there are two that some random guy on the internet found. Any sane person will therefore admit that the bad guys seriously looking at this have found more. And there are probably more known vulnerabilities we're not discussing.

Re:Convenient

[Fri13]

Run Windows and Adobe Reader and you are safe to open it....

Re:Convenient

[drsmithy]

You are deliberately ignoring the "or took MS a long time to patch" part of this discussion.

Yes, because it's not relevant to the discussion *I'm* having.

We're not talking about current, live vulnerabilities. We're talking about a history of a long turn around time for patches of extreme security holes.

This thread, starting here, is most certainly only talking about "current, live vulnerabilities". In particular, the "countless" ones that digitalunity claims knowledge of (yet, unsurprisingly, is "too busy" to even hint at - I guess he must be heading to the gym in 26 minutes).

And you're sticking your fingers in your ears and ignoring it because it hurts your stance.

No, I'm ignoring it because it's not relevant to the discussion I'm in. Even going back another 4 posts up the hierarchy, it's still only about "current, live vulnerabilities".

But the fact is, there are two that some random guy on the internet found. Any sane person will therefore admit that the bad guys seriously looking at this have found more. And there are probably more known vulnerabilities we're not discussing.

I'm sure. The points are, a) if there are "countless" (the other AC's Lawyer-like answer notwithstanding) such vulnerabilities, why is it a list of 10 is so hard to generate (especially on one of the internet's premier anti-Microsoft sites), and, b) if it really is that hard then, hey, maybe things aren't quite so bad after all ?

Re:Convenient

[drsmithy]

Don't feed the troll. Does it not worry you that there are 2 unpatched and documented vulnerabilities?

Sure, but that's not really relevant to a discussion about "countless" unpatched vulnerabilities.

At least the linux team didn't know about this vulnerability.

They knew about it for at least 2 months. How long does it have to be before it's "too long" ? Note also that just because it's been fixed in the raw kernel release, doesn't mean it's been rolled into distributions, which could take anything from days to months.

Besides, only a small percentage of the user base actually know exactly what everything in the kernel does, let alone pick vulnerabilities in it. In a working distro, there should be NO documented vulnerabilities without a patch. In any case, when the Linux team got tipped off, the patch was fixed. For that, I am proud to belong to such a community.

And when Microsoft gets "tipped off", bugs in Windows get fixed. What's the difference ?

Re:Convenient

[epine]

But the time required to fully test it and make sure it doesn't break anything else? That's where all the real costs are. It's why Microsoft doesn't generally have a fast turnaround on Windows security fixes.

That's what you get when you design an architecture rife with knock-on effects. The usual case where fixed a bug breaks an existing application is where the existing application was coded badly in the first place. In free market economics failure of weak institutions is praised. Why should badly coding software not fail? If it breaks when the OS patches a bug, maybe you should have done better due diligence in the first place. We'd have a market which rewards a track record of responsible coding practices, and far greater triage rate on software which didn't deserve to see release in the first place.

I don't shed half so many tears for companies that invest heavily in badly coded software.

I'd be very much in favour of Microsoft releasing the first cheap and quick fix (sans expensive breakage testing) and letting the end user decide where security or pandering to some ridiculous broken application is more immediately important. Later they can also release the regression-proof gold-plated fix, if they feel like investing the extra resources.

Oh, we didn't release that patch promptly because some abortion coded in VB6 failed in our regression test compatibility suite. Thanks, glad to know you're looking out for my interests there.

Of course there would be the case there the simple fix breaks half the applications out there because misuse of a bad API is endemic in the Windows ecosystem. That doesn't speak well of the ecosystem.

Re:Convenient

[tolan-b]

Oh come on, it's the default behaviour so most installs are going to be affected.

> Not to mention it requires the end user to manually run untrusted code.

As does the kernel flaw. A compromised or deliberately malevolent app will suffice in either case.

Re:Convenient

[Alex Belits]

Many times there are reconnaissance efforts before an actual exploit.

And the only valid response to them is to never react in any manner unless you are specifically researching attackers and potential attackers' behavior. Security of a system should never be assumed to be dependent on anything but secure design of that system.

That is computer security 101.

Reaction to threats is an idiotic practice that makes absolutely no sense. There are billions of hosts on the Internet, large percentage of them is compromised by botnets, and at any moment any of them can happen to be attacking your system. If you are vulnerable to a remote exploit, you will never have time, leave alone chance, to react -- your only defense is to eliminate vulnerabilities before they are attacked. Fortunately remote exploits (what the article describes is not a remote exploit) are taken very seriously by software/distributions maintainers other than Microsoft and Adobe.

This is why security research and bug fixing is so important, however there is absolutely nothing end user can do about it unless he is in the position to investigate a new, previously unknown vulnerability. This happens what statistically can be described as "approximately never".

Local exploits don't require "vigilance" either -- if you really have large amounts of untrusted things running on potentially vulnerable systems, you have to have reasonable policies, access/authentication system and backup procedures. None of them involve red-eyed peering at the monitor looking for the signs of enemies coming.

Re:What I suggest to people

[DarkKnightRadick]

You do realize that Mac is built on a FreeBSD kernel?

Blame Xorg

[betterunixthanunix]

Xorg is a mess. Fedora had to craft a special SELinux policy, which exempted Xorg from a number of restrictions that apply to other applications (for example, the ability to unset the NX bit on a region of memory), because not only does Xorg do so many questionable things, but there is no good way to fix it. That, and the fact that Xorg runs as root, make it a particularly weak link in the chain.

Re:Blame Xorg

[Anonymous Coward]

I run Nvidia cards, so I switched as fast as I could to a KVM-enabled driver, which allows me to run Xorg as a user, not as root. As I recall, the FOSS drivers for both ATI and Nvida allow this currently.

Re:Blame Xorg

[vadim_t]

That should be fixed eventually. With the switch to kernel modesetting (already happening) there shouldn't be any need for X to mess directly with hardware anymore, and without that it should run just fine without root privileges.

Re:Blame Xorg

[Anonymous Coward]

What the heck. I meant KMS, not KVM.

Re:Blame Xorg

[ultranova]

Is that the only thing still running in userspace? I was under the impression that you still need device-specific drivers in the X server. Or are we finally approaching the point where the kernel exposes a framebuffer console with standard accelerated features (OpenGL, preferably), and X or any other program can simply run on top of that?

Re:Blame Xorg

[gzipped_tar]

Hopefully, Wayland could be able to fix most of these kind of mess in Xorg (assuming it ever comes out).

Re:Blame Xorg

[Anonymous Coward]

There is no real need to run as root anymore. MeeGo X does not do that, as an example.

Re:Blame Xorg

[Cyberax]

Yep.

On Linux input devices are now moved into the kernel. The only complex thing remaining is modesetting and hardware acceleration. But they are being fixed as well.

In fact, you can run 'rootless X' on Fedora ( http://lwn.net/Articles/341033/ ) and soon on Ubuntu ( https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-rootless-x ). Here 'rootless' means that the server doesn't require root privileges to work.

Re:Blame Xorg

[LingNoi]

So for anyone else wanting to know what the hell Wayland is here is the link that I spent 20 minutes googling... http://groups.google.com/group/wayland-display-server

Re:Blame Xorg

[Anonymous Coward]

Actually, if you read the paper, this is not an Xorg bug.

if i understand it correctly, the problem is that X allows direct access to some parts of its memory to user processes.
this is done to allow writing to pixmaps, and is safe in itself.

the problem is, that the linux kernel allows creation of such a mapping just above the stack; then the stack grows a little and hits the user-controlled memory, and then the user can write directly to the xorg-stack - and overwrite return adresses of functions.

the problem here is insufficient protection offered by linux - the stack should NEVER grow into shared memory areas!

Re:Blame Xorg

[Anonymous Coward]

(same AC here)

For the record: i agree that xorg is somewhat too big and complicated to run as root. it isnt the culprit here, though...

Re:Blame Xorg

[pizzach]

:-/ Can someone tell me what running startx does as a normal user? Is it still running as root?

Re:Blame Xorg

[Andy Dodd]

startx or one of the programs it calls has the SUID flag set. (Meaning that the process will run with the privileges of the executable file's owner, not the privileges of the user who executed it.)

Re:Blame Xorg

[Cyberax]

Yes, it starts as root, but then it immediately drops privileges upon initialization.

Re:Blame Xorg

[Anonymous Coward]

I discovered the hard way that the fbcon based console drivers fail on my hardware.

It took a lot of probing to determine the working drivers. There were Xvesa and vgacon.

Anybody want to make KMS from/to vgacon?

Re:Blame Xorg

[Anonymous Coward]

No, the kernel doesn't expose your video card as "standard accelerated features". That would involve bolting several complete OpenGL drivers (at least) inside the kernel, which would make things worse, not better.

The kernel exposes the video card as a custom device, which still requires custom drivers, but these new userspace drivers can run unprivileged once given an fd for the device. The safety checks (e.g. to protect the OS from a badly programmed card) are to be in the kernel, but correctness is a userspace problem. So in this bold future X.org can crash if the userspace driver is bad, but it no longer has any special privileges, whereas before it could crash, overwrite the kernel, install malware and a root kit.

Userspace drivers are a common design pattern. That's how a GPS works (it appears as a mundane serial device, the userspace drivers get the GPS data out of it). Or fancy multi-touch controls. Even a lot of Bluetooth. Once you don't need interrupt context you can move the driver into userspace unless raw performance is critical (e.g. with GigE network cards, hard disks)

X really is one of the last things that wanted setuid. Network programs like ping haven't need setuid for a year or two now because Linux added donated capabilities, allowing you to give 'ping' just the network privileges it needs, not root access. I guess that leaves 'sudo' and a few other administrative commands.

Re:Blame Xorg

[Alex Belits]

It does nothing. No one used startx for many years by now.

However yes, startx started as user would run X server as root, thank to setuid bit. And that was one of the reasons why it is deprecated in favor of display managers (xdm/kdm/gdm/...) that are started from system startup scripts and do not have setuid components.

Re:Blame Xorg

[cynyr]

Could you link me to KMS driver for my Nvidia Geforce 8600GT with full 3d support and support for decoding h264 and the rest? I need to play tuxracer and bzflag.

The problem for me is i have need of the 3d accel parts of my video card, and none of the FOSS drivers support that yet.

Re:Blame Xorg

[cynyr]

I'll still need my binary nvidia driver until i can get 3d accel, and hardware decoding for nvidia cards from OSS, making wayland a long distant pipe dream.

Re:Blame Xorg

[Shikaku]

It does nothing. No one used startx for many years by now.

I run arch linux you insensitive clod! Also I still use ed.

?

Re:Blame Xorg

[Anonymous Coward]

And no-one can use startx since ConsoleKit, else ConsoleKit will get confused with all its keeping track of displays, sessions, seats and fuck knows what else (ConsoleKit being yet another useless background daemon solution to a non-problem, namely how to fail to determine that there is one user sitting in front of this computer), and no hardware will work properly since you don't have permissions on the files in /dev/ .

So, you get to enjoy gdm. I hope you enjoy the dumbed down date (well, just day name now), and probably the wrong time format, and enjoy the simplicity of having no way to configure anything like that.

Re:Blame Xorg

[shutdown -p now]

It does nothing. No one used startx for many years by now.

Actually, quite a few people running "hacker" distros (Gentoo, Arch etc) prefer to boot into console and do startx from there when (and if) needed.

Re:Blame Xorg

[MostAwesomeDude]

Xorg's exemption comes from libGL, which needs to have text relocations because of the way DRI works. (Long version: DRI has a way to load on older X servers with newer GL versions by dynamically rewriting the API entry point table. Requires text relocations since the data for the entry points needs to be marked executable after the library's already in memory.) It's not going to be fixed because it's not a problem; if you really didn't want people doing questionable things on your system, you would already have disabled DRI. (Yes, this is actual policy. Letting people submit commands directly to your GPU is *always* unsafe.)

Xorg doesn't need to run as root; Moblin already has made the switch, and other distros are getting ready to follow. Running as root is only necessary with input drivers (or some rare video drivers) that don't have the ability to talk to the HW through a normal kernel interface as non-root.

Re:Blame Xorg

[MostAwesomeDude]

Nouveau has working Gallium code for your GPU, but it's not officially supported by the project because it's not stable enough. Fedora and Ubuntu have special experimental DRI packages available that enable nouveau's 3D acceleration.

For h.264 acceleration, you will have to wait for somebody to write it, which likely means waiting until the patents on it run out.

How much more 'silent' was than other bugs?

[master_p]

Do the Linux developers put a news announcement out every time there is a bug and they forgot about it this time?

Isn't it a little sensational to imply that Linus and the other people didn't want this bug to be known because they fear Linux will be characterized as buggy?

Re:How much more 'silent' was than other bugs?

[stagg]

I'd rather hear about a flaw like this after the fact frankly. I don't think an unpatched exploit needs the kind of publicity that /. would get it.

Re:How much more 'silent' was than other bugs?

[psbrogna]

Isn't that what "New Media" means; sensational?

Re:How much more 'silent' was than other bugs?

[stagg]

Isn't that what "New Media" means; sensational?

We require more Google hits!

Re:How much more 'silent' was than other bugs?

[Rogerborg]

Isn't that what "New Media" means; sensational?

Sure, because Legacy Media was so focussed on telling people what was important, rather than just what they wanted to... ooooh, OK! magazine have offered Linsday Lohan $1m for an exclusive - must read now!

Re:How much more 'silent' was than other bugs?

[pclminion]

Do the Linux developers put a news announcement out every time there is a bug

No, but all changes to the kernel are documented in the changelog. And security-related bugs are treated the same as any other bugs. They are not explicitly called out as being security related. Linus has been pretty clear on this in the past. A bug is a bug, period. The fact that it's security related is uninteresting (to him, at least).

I think that's a weird attitude but that's what we've got.

Re:How much more 'silent' was than other bugs?

[Anonymous Coward]

Do the Linux developers put a news announcement out every time there is a bug

No, but all changes to the kernel are documented in the changelog. And security-related bugs are treated the same as any other bugs. They are not explicitly called out as being security related. Linus has been pretty clear on this in the past. A bug is a bug, period. The fact that it's security related is uninteresting (to him, at least).

I think that's a weird attitude but that's what we've got.

My interpretation is that it's a middle ground between "HEY EVERYONE LOOK AT THIS SECURITY FLAW" and "Nothing to see here, move along".

Anyone wanting to put a number on the amount of security flaws in Linux that have been found/updated can do so by looking through changelogs (and doing a tiny bit of research), but at the same time they don't make them publicly known until the fix is already available (as long as the distros package the new kernel quickly).

Re:How much more 'silent' was than other bugs?

[Securityemo]

As long as it reaches the security mailing lists, it has all the publicity it needs in terms of reaching "the wrong sort of people". Slashdot isn't exactly a timely or accurate source for whitepapers and public exploits. It would be like a criminal reading the NYT for information about illegal happenings and arrests.

Re:How much more 'silent' was than other bugs?

[tuffy]

I don't think it's all that weird. For example, is a bug that corrupts one's filesystem less critical than a bug that allows unauthorized access? Is a root escalation bug more important than a bug that prevents one's video card from working? They all need to be fixed, but I don't think security implications entitle such bugs to special treatment.

Re:How much more 'silent' was than other bugs?

[m50d]

With a security bug, there are benefits to keeping it secret until it's fixed, which is why many organizations will treat them differently.

Re:How much more 'silent' was than other bugs?

[Beelzebud]

Oh the humanity!

Re:How much more 'silent' was than other bugs?

[ultranova]

For example, is a bug that corrupts one's filesystem less critical than a bug that allows unauthorized access?

More importantly, is there a difference? Red Hat 9 had - and perhaps distros still have - this nice system where cron would, once a day, run programs dropped into a directory in /etc with root privileges. Very useful for various packages that required periodical maintenance; but if a filesystem corruption bug would allow one to link an arbitrary file to those directories...

A bug means that a system behaves in a way it shouldn't. There's always the chance that such unplanned behaviour can be used by an attacker to do nasty things. There is no difference between security critical and other bugs, there's only bugs with known exploits and bugs without. Every bug is a chink in the armor, and every kernel bug should be considered security-critical.

Re:How much more 'silent' was than other bugs?

[spitzak]

A filesystem corruption bug that allows one to link an arbitrary file somewhere would allow a much quicker root exploit than relying on cron!

I think you are thinking about extremely old bugs where cron itself could be convinced to run a program without root privledges as root (or really as the cron job). That is from about 1980 or earlier I think.

Re:How much more 'silent' was than other bugs?

[VGPowerlord]

More importantly, is there a difference? Red Hat 9 had - and perhaps distros still have - this nice system where cron would, once a day, run programs dropped into a directory in /etc with root privileges. Very useful for various packages that required periodical maintenance; but if a filesystem corruption bug would allow one to link an arbitrary file to those directories...

I assume you mean /etc/cron.daily which is still around, along with its hourly, weekly, and monthly counter-parts.

Re:How much more 'silent' was than other bugs?

[Anonymous Coward]

With a security bug, there are benefits to keeping it secret so it doesn't have to be fixed, which is why many organizations will treat them differently.

FTFY.

Also it's not like progress on security bugs in the kernel is being hindered by work on other types of bugs is it? Or are you purposing that the video card developers should stop work to fix a bug in one of the file system drivers (way out of their field of expertise)?

There's not a lot of benefit in a large distributed development environment to prioritize one bug type because the bug isn't being held back by other work. More likely if a patch is held up its being held up by the merits of the patch itself.

Re:How much more 'silent' was than other bugs?

[mr_mischief]

In the end, almost any bug is security related anyway. A denial of service by crashing my system is security related. A denial of service by tying up my ports is security related. Gaining unauthorized access is security related. Gaining more than authorized access is security related. Any bug more serious than a color or a pixel alignment being off in a UI is pretty much security-related, because security means the system is available to authorized, authenticated users and not to anyone else.

Re:How much more 'silent' was than other bugs?

[psbrogna]

Hilarious. Truly. But back to reality- are you saying that the bar hasn't changed with the advent of the Web and the removal of virtually all costs and barriers to publishing to a global audience? Because that hasn't been my experience. I've observed a marked change in the signal-to-noise ratio since the web went mainstream.

Re:How much more 'silent' was than other bugs?

[pclminion]

So, giving system administrators a decent opportunity to triage and sequence their patches and updates in a way that causes less disruption to their users while minimizing actual risk, is something you just don't give a crap about? Is it cold up there on your mountain top?

Re:How much more 'silent' was than other bugs?

[Anonymous Coward]

Whereas they should be reading the Wall Street Journal.

Re:How much more 'silent' was than other bugs?

[Rogerborg]

Sorry, I've been too busy proactively leveraging synergies in win win Web 2.0 meta scenarios to pay attention to that.

Re:How much more 'silent' was than other bugs?

[Anonymous Coward]

A bug is a bug, period. The fact that it's security related is uninteresting (to him, at least).

Even Linus hides?

Re:How much more 'silent' was than other bugs?

[epine]

There is no difference between security critical and other bugs, there's only bugs with known exploits and bugs without. Every bug is a chink in the armor, and every kernel bug should be considered security-critical.

Wow. Peculiar assertion. Take your favorite recent Linux distribution. Construct the set of all possible bugs. Construct the set of all possible realizations (basically, the powerset of all possible bugs). Within the set of all possible realizations, determine the exploitable subset. Now construct the minimal cover of the exploitable subset (the smallest subset of all possible bugs, such that if the realization contains none of these, it is non-exploitable).

Bugs in the minimal cover are certainly distinct from bugs outside the minimal cover. For example, some application program is supposed to open port 4343 so that gdb can connect, but fails to open the port due to some bug. Essentially, the bug subsets specified functionality (it doesn't add a quirky behaviour, but eliminates a function you would otherwise expect to have). Such a bug is almost certainly not a member of the minimal cover. I would eat my cable modem if someone determines otherwise.

Yes, every bug is a chink in the armour, but not all chinks are created equal.

Re:What I suggest to people

[stagg]

You do realize that Mac is built on a FreeBSD kernel?

Macs can't be exploited. That's why people paid to get into the walled garden, it's safe in there. LA LA LA LA LA LA I CAN'T HEAR YOU.

Re:What I suggest to people

[Anonymous Coward]

FreeBSD userland, mach kernel

I'm not affected...

[Anonymous Coward]

Because I run Windows as user SYSTEM.

Re:I'm not affected...

[Thinboy00]

Because I run Windows as user SYSTEM.

To people who have no Windows familiarity (i.e. all sane people *ducks*): SYSTEM is roughly the same thing as root.

Is this news?

[mspohr]

Isn't this the way it's supposed to work?

1. Bug found, responsible parties notified

2. Bug fixed and software updated

3. We are protected from potential future attacks. (Profit!)

Was there an actual attack? No.

Re:Is this news?

[jpapon]

Must be a slow day. Conspiracy articles about HAARP causing Moscow to burn, and an article about a security flaw that has been fixed. Fascinating stuff... What's next?

Re:Is this news?

[Nerdfest]

Yes, and quickly in this case too, I think, with a fast fix, and then more solid changes later. You can never really tell whether there was an attack or not. There may have been something targeted at a very specific company, site, or person.

Re:Is this news?

[Anonymous Coward]

Quickly? This flaw has existed for 7 years.

Re:Is this news?

[dragin33]

Why is it that for every Microsoft vulnerability the many in the slashdot community has this "See? Microsoft.. Insecure." attitude but for every Linux vulnerability the same community will say There's no problem here.. It was patched. Move along. Linux is still secure. And my favorite "Linux doesn't have viruses." Sometimes those in the Linux community need a taste of reality.. mspohr; Yes this is news.. Just as much as Patch Tuesday is news.

Re:Is this news?

[dragin33]

Microsoft vulnerability.. *there are many* .. in the slashdot community that have* Sorry for the bad editing

Re:Is this news?

[mspohr]

Although this article was about a Linux potential vulnerability and not about Microsoft, you seem to think that Microsoft is treated unfairly with too much publicity. I guess the difference is that Microsoft, unlike Mac and Linux, does actually have thousands of virus infection vectors in the wild and they have been slow to patch their buggy software. It isn't particularly newsworthy when Linux patches a potential vulnerability (with no known exploit) promptly but it is news when Microsoft patches an old bug that has already led to thousands (? millions) of infected machines.

Re:Is this news?

[marcello_dl]

It could be there since linux 0.1, so what? all that it matters is that holes are patched when discovered or in the worst case when the first 0days exploits are detected.

Also thanks to the fact that there probably is no guy in business suit that decides when and if to disclose the vulnerability, I tend to think that this xorg problem was managed well enough.

Re:Is this news?

[Anonymous Coward]

Quickly? This flaw has existed for 7 years.

If you get your 2 gram brain to work you will notice that this flaw, while present for long time, it is only known for a very short time. So, from the time it was known to the fix, it was indeed quick.

Now, lets go back to your spyware pop-n-close routine.

Re:Is this news?

[Anonymous Coward]

From Time of detection? Yes. I concede I would have liked "Even More Quickly" given the scope of the vulnerability, but we've seen Microsoft vulnerabilities be reported and lie in their inbox for *years* before Microsoft was finally forced to do something about it because the researchers finally said "I've had it" and published.

So, yeah "Quickly".

Pug

Re:Is this news?

[Monkeedude1212]

Was there an actual attack? No.

Woah now junior, you don't know that.

There have been no reported attacks.

But now that its out there - it's up to people to update their kernel.

Re:Is this news?

[the_bard17]

Probably since we're not Microsoft. Really.

Who's got access to the Linux kernel's source code? Anyone. Compare that to who's got access to Windows' source code. Who can submit a patch for the Linux kernel? Again, anyone. Compare that to who can submit a patch for Windows.

So if there's an exploit in the Linux kernel, it's our fault... because the only thing holding any of us back from fixing it is our own lack of knowledge, ability, and/or time.

For those Windows exploits, however, we're left at Microsoft's mercy, assuming there's no other way to prevent the exploit than to fix the source code. The same is true for any other closed third party software.

Re:Is this news?

[mspohr]

I think that if there was a reported attack then this would really be NEWS. As it is, this is just a bug fix, not news.

Re:Is this news?

[xiong.chiamiov]

Sure, but you can't fix a bug until you know about it, and once it was found out, it was fixed, quickly.

Re:Is this news?

[mr_mischief]

FROSTY PISS!

Re:Is this news?

[Anonymous Coward]

Don't forget to mention that the fixed 2.6.35.2 and the other "stable" releases from the same time are all broken (on x86_32 anyway), with the next stable versions being prepared now. Check the stable review summary lkml messages.

Re:Is this news?

[Anonymous Coward]

I have been the finder of (kernel) bugs, and notifier on LKML. I've been contacted by Intel senior systems engineer, asked to (and did) run test software to highlight the nature of the bug, then ran patch and built new kernel to test performance and accuracy of patch (with success). It was nice because a new kernel was released, more than 10,000 people had problems, patch was already in, and Linus only found out 2 days later. I got a lot of email from people I don't know in many parts of the world, sending thanks. Sometimes its not a bad thing to roll up your sleeves and get a bit dirty.

Re:Is this news?

[Ungrounded Lightning]

Was there an actual attack? No.

Make that "Not as far as we know." and I'll agree with you. Or "Not that was detected and publicized."

I hear the security community on the Windows side of the world is of the opinion that it takes a couple years for an exploit to trickle down to where the signature-based antimalware people find out about it.

  - First it gets used for spearphishing some high-value target - typically for whomever commissioned its creation.
  - Once that customer has gotten his data (or performed his attack), its author gets more money from it by selling it to his five or so top-tier regular customers.
  - Repeat for lower tier customers until interest is exhausted or it gets detected (often enough) and the defenders start to become aware of it. Then:
  - Wring the last money out of it by selling it broadly to the driftnet malware users, who get a phishing season until signatures are written and propagate to the security vendors' clients. (Once it hits general availability it will immediately hit some honeypots, so if the defenders weren't aware at the previous stage they are now.)

I don't see any reason why an exploit of a broad vulnerability in *x systems running X.org servers should not have a similar latency in detection. (Perhaps longer, since some of the targets are higher value and harder to break into, so the payoff for maintaining stealth could be higher.)

Re:Is this news?

[cynyr]

why didn't you report it 7 years ago then? huh? huh?, right it was recently discovered, and recently fixed. so quickly.

Re:Is this news?

[Anonymous Coward]

It's not so clear cut, read Wojtczuks paper. The exploit was discovered in 2005 by Gaël Delalleau, he even pointed out linux as a vulnerable platform. The information didn't reach the kernel security guys though, and we have no idea if it reached any interested black hats.

Re:What I suggest to people

[l2718]

You do realize that Mac is built on a FreeBSD kernel?

Actually, MacOS uses the Mach microkernel in a BSD system; some code was taken from FreeBSD -- but not the kernel.

Re:What I suggest to people

[DarkKnightRadick]

lol

Though I wonder how I'm off-topic, considering this is about a Linux vulnerability.

Oh wait, this is /., nvm

Microsoft bugs

[Anonymous Coward]

So they had a whole month to patch their bug, whereas Microsoft had only a week (albeit from the Google researcher)?

Re:Microsoft bugs

[Anonymous Coward]

The researcher simply wanted a timeline to how MS would address it in a week.

Thanks for playing.

Re:What I suggest to people

[DarkKnightRadick]

http://en.wikipedia.org/wiki/Mach_(kernel)

Neither Mac OS X nor FreeBSD maintain the microkernel structure pioneered in Mach, although Mac OS X continues to offer microkernel Inter-Process Communication and control primitives for use directly by applications.

Re:What I suggest to people

[Third Position]

You do realize that Mac is built on a FreeBSD kernel?

Well, more accurately it's a mach based os that presents both a BSD and a Mac OS personality. /pendant

Re:What I suggest to people

[Thinboy00]

Actually, MacOS uses the Mach microkernel in a BSD system; some code was taken from FreeBSD -- but not the kernel.

Really? I thought they used Darwin...?

How fancy can you get?

[gzipped_tar]

can bypass all the Linux fancy security mechanisms, and escalate to root, and compromise the whole system.

The author who wrote this certainly didn't count SELinux as one of the "fancy" security mechanisms...

Re:How fancy can you get?

[betterunixthanunix]

Actually, he did:

The attack allows even to escape from the SELinux's "sandbox -X" jail.

(From the announcement of the attack)

Re:How fancy can you get?

[gzipped_tar]

I wasn't referring to the jailbreaking from the Xephyr server in the sandbox. I meant to say that SELinux was exactly one of the fancy stuff that were supposed to protect the system from unknown vulnerabilities.

Yes, the attacker is able to break out of the sandbox and further escalate to root by attacking the Xorg server; but under a well-secured SELinux system the actual damage can be nullified by the SELinux mechanism because the attacker cannot escape from the security context even if he has root privileges. The attacker will be unable to access the resources that are not supposed to be accessed (e.g. making the stack executable) so the scope of the damage can be greatly limited.

Admittedly total lock-down of a system with SELinux is very difficult, but theoretically this is not impossible.

Re:How fancy can you get?

[betterunixthanunix]

Xorg throws a wrench into SELinux; just ask the Fedora SELinux policy maintainers. I still remember the days when my Fedora system would pop up SELinux warnings left and right because Xorg was trying to do something stupid and suspicious. These days, Xorg just gets exempted from SELinux policies in Fedora.

Re:What I suggest to people

[bsDaemon]

Darwin is their codename for what is the open source bits of MacOS X. The kernel is largely based on Mach. Since its a Microkernel, it can have "servers" for different subsystems, including BSD, which aren't really "kernel modules" in the Linux or BSD sense. A lot of the userland and C libraries are derived from FreeBSD, with some GNU stuff, and custom changes to both. They did hire a bunch of big-name FreeBSD people though, like Jordan Hubbard, which just contributes extra confusion to a confusing situation.

Re:What I suggest to people

[DarkKnightRadick]

http://en.wikipedia.org/wiki/Mac_OS_X

http://en.wikipedia.org/wiki/Mach_(kernel)

Neither Mac OS X nor FreeBSD maintain the microkernel structure pioneered in Mach, although Mac OS X continues to offer microkernel Inter-Process Communication and control primitives for use directly by applications.

Running X.org on a server?

[Anonymous Coward]

I dunno about a lot of admins, but running X.org on a server seems fraught with problems aside from this recent issue. Running things that are not necessary means less of an attack surface. Didn't microsoft finally get this with its latest server products?

Re:What I suggest to people

[DarkKnightRadick]

pedant*

Unless you are actually a piece of jewelery.

PDF flaw?

[hackwrench]

I'm missing something here. A PDF reader shouldn't let a PDF file anywhere near executable code, should it?

Re:PDF flaw?

[betterunixthanunix]

Depends on whether or not the reader can be compromised. Adobe's PDF reader is known to allow the execution of arbitrary programs and code on the target system if you send someone a specially crafted PDF.

Of course, plenty of other PDF readers do not, and on a number of desktop Linux distros, packages are compiled with stack and heap smashing protection enabled, so finding a PDF exploit would be pretty tough. Of course, a lot of people wind up installing Acrobat Reader on their systems despite the available of libre PDF readers in the repositories, so perhaps the point is moot.

Re:PDF flaw?

[vtcodger]

**I'm missing something here. A PDF reader shouldn't let a PDF file anywhere near executable code, should it?***

Not a stupid question although it'll probably get treated as such. My understanding is that PDF is sort of an partial encapsulation of Postscript and therefore can include some kinds of executable code. Personally, I've never much cared for pdf/postscript which have always seemed to me to be a maximal grief approach to getting a document (possibly) printed ... if the stars are right and the force is with you.

Re:PDF flaw?

[digitalunity]

The PDF specification includes a lot of active content features that most linux readers don't even support.

One in particular comes to mind and that is javascript. Although javascript isn't directly executed by the host machine(it's interpreted), that makes it a really attractive attack vector.

Re:PDF flaw?

[spitzak]

It sounds like if the PDF file can get the PDF reader to overflow the stack (possibly by triggering a bug that causes infinite recursion) then it will write over memory belonging to the X server which the X server will later jump to with root privileges.

I would think the most likely effect is the X server will crash but it seems there is already an example PDF that manages to write the correct data there to get the X server to execute something desired by the hacker, such as running a shell. This is NOT good.

Also it might not be too hard to convince a user to just run a program that is explicitly written to exploit this bug. I doubt it would be much trouble for that to do anything it wanted. Though if the user runs an unknown program that program could write all over his home directory and cause just as much grief, even without this bug.
 

Re:PDF flaw?

[mr_mischief]

Anything that can overrun a buffer or smash the stack can execute arbitrary code if you play around with your delivery package enough. Lots of code out there has stack or buffer issues. Some web browsers used to be exploitable just by overrunning the address bar's buffer, no executable code at all until the buffer overruns and you overwrite a JMP instruction to jump into part of what you wrote to the unchecked buffer.

Security is hard. It's even harder when you're not using a language or libraries that check for proper array and buffer bounds.

Re:PDF flaw?

[TheRaven64]

The point is that vulnerabilities stack. By itself, this is a local root exploit (unless you do xhost + in your shell). Combine it with a vulnerability in an app like a PDF reader or a web browser, it becomes a remote root hole. Because this bypasses things like chroot(), SELinux, and so on, it means that even a hole in an app that is run in a completely unprivileged sandbox can lead to system compromise.

Re:What I suggest to people

[tuxgeek]

You're wrong
All systems have bugs, even MACs.
You're being naive if you think you are completely secure in your sandbox.

There will always be exploits and/or proof of concept exploits for MAC as well as Linux platforms, but are usually patched immediately without damage or fanfare.

Nothing to see here, move along .. SSDD

What about distros?

[Anonymous Coward]

So how many distros have so far packaged this fix up and released a new kernel package?

Good thing that Google Guy didn't find it

[Anonymous Coward]

Wow, it is a good thing that Google researcher didn't find it. Since it took two months to patch the flaw, he would have posted it. So would a bunch of these other "wah, you are taking too long" grey hat zealots. According to the group think it is never supposed to take 2 months to patch Linux and other FOSS. It's actually too bad that they didn't just do the full disclosure method after a few days like the Google guy.

Re:Good thing that Google Guy didn't find it

[Anonymous Coward]

You really should be modded redundant since someone posted the exact same thing futher up and someone else already replied..

The researcher simply wanted a timeline to how MS would address it in a week.

Thanks for playing.

Re:What I suggest to people

[hazah]

It was an obvious troll.

Hmm interesting.

[Beelzebud]

Let me just open up my PDF reader and see what thi

Re:What I suggest to people

[abigor]

From your first link: "Mac OS X is based upon the Mach kernel."

2 Months is Acceptable?

[Arainach]

Just a few months ago we were blasting Microsoft for taking five weeks to prepare the Ormandy patch. Now we discover that Linux has had a root-privledge exploit for years, was notified, and took two months to fix it, and we get comments like "Must be a slow day." Stay classy (and unbiased), Slashdot.

Re:2 Months is Acceptable?

[Anonymous Coward]

So you obviously didn't see the two other people before you that said the exact same thing.. here it is again..

The researcher simply wanted a timeline to how MS would address it in a week.

So yeah, it's not at all similar, however many times you say it over and over in the thread.

Re:2 Months is Acceptable?

[valeo.de]

Ha.

Re:2 Months is Acceptable?

[drsmithy]

You're either with us or with them, eh ?

Who would have thought George W posted on Slashdot ?

Re:2 Months is Acceptable?

[dch24]

Whatever. He's calling Slashdot biased. Pot, meet kettle.

Re:2 Months is Acceptable?

[drsmithy]

Whatever. He's calling Slashdot biased. Pot, meet kettle.

But Slashdot *is* biased, quite heavily, towards Linux and Open Source (and against anything not anti-Microsoft). Your previous post is, indeed, an excellent example of that bias.

Re:2 Months is Acceptable?

[Anonymous Coward]

Now we discover that Linux [...] took two months to fix it

I'd be impressed if Linux managed to fix bugs in itself no matter how long it took.

Re:2 Months is Acceptable?

[Blakey Rat]

But, judging [slashdot.org] by [slashdot.org] your [slashdot.org] comment [slashdot.org] history [slashdot.org] you [slashdot.org] (Arainach) [slashdot.org] are a Microsoft [slashdot.org] shill [slashdot.org] and [slashdot.org] probably [slashdot.org] an employee.

Your Comments in the Past Year:
Anti-GPL w/o mentioning Microsoft: 2
Pro-Microsoft arguments: 9
Pro-Microsoft information: 1
One rant about WA-520 [google.com]: 1

Seriously? We've lowered ourselves to this level? "OMG you're familiar with a highway in the same half of the same state as Microsoft! YOU MUST BE AN EMPLOYEE!!!" This is what you want Slashdot to be?

Dude, even if he was a Microsoft employee-- SO FUCKING WHAT!? His opinion is as valid as yours. More valid to me, in fact, since he's not nearly as pathetic and petty as you. Isn't it even theoretically possible that he genuinely likes Microsoft products and is expressing his opinion?

This is a new low for Slashdot commenting.

Of course, you won't pay attention to this post after you do your extensive background research on me and find out I live only 45 miles from Microsoft headquarters!! I MUST BE A SHILL!!!

Re:2 Months is Acceptable?

[mr_mischief]

Now THAT's what I call self-healing software!

Re:2 Months is Acceptable?

[Anonymous Coward]

10 years ago the Slashdot readership may have shown a large bias as you say, but not so much anymore.

-someone who loathes Microsoft

Re:2 Months is Acceptable?

[techno-vampire]

Microsoft has thousands of programmers working full-time; Linux is maintained by volunteers, working in their spare time. That means that Microsoft can easily allocate more resources to fixing a security bug than Linux can. This being true, you'd expect Microsoft to get bug patches out quicker than Linux, but it's almost always the opposite. And, of course, with rare exceptions, the Microsoft patches come out only on Patch Tuesday, while the Linux patches come out as quickly as the various distros fold them into their updates. And, if that's not fast enough for you, you can always download the source and compile it for yourself, something that Microsoft would never allow.

Re:2 Months is Acceptable?

[dch24]

I didn't claim not to be biased. It's my opinion: "reality has a well known pro-linux bias." Deal with it.

I feel fine calling someone else out on their biases. It's especially fun when they rant about bias to support their bias.

tl;dr: I have an anti-bias-hater bias.

Re:2 Months is Acceptable?

[Trelane]

If it's any consolation, lwn has a nice analysis that contains the following phrase: "the nearly two-month delay between the report and the fix is raising some eyebrows" and ends with the following:

The most unfortunate aspect of the bug is the length of time it took to fix. Not just the two months between its discovery and fix, but also the five years since Delalleau's presentation. We need to get better at paying attention to publicly accessible security reports and fixing the problems they describe. One has to wonder how many attackers took note of the CanSecWest presentation and have been using that knowledge for ill. There have been no reports of widespread exploitation--that would likely have been noticed--but smaller, targeted attacks may well have taken advantage of the flaw.

It's not slashdot, but it does show that Linux/Xorg people are taking the delay seriously and really don't like the delay in this case. There is a more in-depth analysis of what was going on behind the scenes (it's all public information, after all) that you can read when the article goes public in two weeks. Of course, fanboys are going to be fanboys, be they Windows fanboys ("Unfair! MSFT was only given a week to patch it!") or Linux ("Slow news day, lol.") and reality isn't really going to sink past their outer defenses.

Re:2 Months is Acceptable?

[drsmithy]

10 years ago the Slashdot readership may have shown a large bias as you say, but not so much anymore.

Say what ? 10 years ago this was still a site where technology for technology's sake was still considered interesting. These days - and probably for the last 4 or 5 years - if it's technology out of Microsoft, it's automatically bad, and if it's technology out of open source, it's automatically good.

The problem is getting worse, not better (thanks in no small part to kdawson, but he's hardly the only one).

Re:2 Months is Acceptable?

[drsmithy]

I didn't claim not to be biased.

Nor did I say you did.

I feel fine calling someone else out on their biases. It's especially fun when they rant about bias to support their bias.

Er, yeah, except none of the examples you linked to show any sort real bias on behalf of the poster you were criticising.

"Doesn't hate X with a passion" isn't the same thing as "is biased towards X" (unless you're an American, I suppose, and have difficulty dealing with non-extreme viewpoints).

Re:2 Months is Acceptable?

[drsmithy]

Microsoft has thousands of programmers working full-time; Linux is maintained by volunteers, working in their spare time.

False. The majority of work on Linux is done by fulltime employees of companies like Red Hat.

Re:2 Months is Acceptable?

[makomk]

This security flaw was a new and unusual class of vulnerability that's quite tricky to patch - it involves a fairly subtle grasp of how the Linux virtual memory code handles process stacks and memory allocations. Initially, it wasn't even clear whether this should be patched in the kernel at all. The Microsoft vulnerability was a lot simpler and was in a code path that's previously had similar security issues.

Re:2 Months is Acceptable?

[makomk]

Oh, and the Linux issue permitted privilege escalation on systems that run X. Microsoft Windows traditionally hasn't considered this an issue at all - users run as Administrator by default, and even now that UAC's been introduced Microsoft don't actually care when someone finds and publishes a security hole in it.

Take no chances

[chrisdotwood]

I would advise everyone to follow my lead and go back to Windows 98 to keep themselves safe

Root in the kernel == game over

[benjymouse]

I don't get this blind trust in SELinux can do what it was never intended to do. If you compromise the kernel - especially a monolithic kernel like Linux - it really is game over.

Practically every security check (and - yes - that includes SELinux extra hooks) are performed before the actual operation is performed with no kernel lock covering both. Which means that *all* of them are susceptible to concurrent access attacks.

It works like this: The malicious code invokes the syscall passing a structure, e.g. an inode but at the same time the malicious code starts a second thread which after a measured period (clockcycles) modifies the very same structure. By crafting this carefully the attacker can hit the "weak spot" between the security checks and the actual operation. It doesn't work every time due to obvious nondeterminism, but even a 30% hit rate will be exceptionally good in a mass attack.

And you cannot lock down the tools used in this scenario. All processes will need to access memory and spawn threads. Certainly browsers, X servers, pdf readers etc. do.

This is not a bug in the kernel. Avoiding this weakness would involve bigger locks and critical sections which would seriously impede scalability. It is just that the kernel was never designed to withstand attacks from within the kernel itself.

So please stop peddling SELinux as a silver bullet. Once an attacker is inside the kernel it really is game over. SELinux doesn't fix that. Nor was it intended to.

Re:Root in the kernel == game over

[amorsen]

It works like this: The malicious code invokes the syscall passing a structure, e.g. an inode but at the same time the malicious code starts a second thread which after a measured period (clockcycles) modifies the very same structure. By crafting this carefully the attacker can hit the "weak spot" between the security checks and the actual operation. It doesn't work every time due to obvious nondeterminism, but even a 30% hit rate will be exceptionally good in a mass attack.

If this was true, it would be a massive security hole rendering SELinux useless. SELinux isn't just a "last line of defense" thing which has a chance of reducing the impact of other vulnerabilities, it is an implementation of a Mandatory Access Control system. If you can come up with a generic way for a confined root user to bypass SELinux, by all mean publish! If it is as easy as you say it is, you should be able to come up with a demonstration in no time. Even a 1 in a million hit rate would be fairly easy to demonstrate and make you moderately famous in the security community.

Re:Root in the kernel == game over

[benjymouse]

int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
{
                int error = may_create(dir, dentry, NULL); // line 1874

                if (error)
                                return error;

                if (!dir->i_op || !dir->i_op->mkdir)
                                return -EPERM;

                mode &= (S_IRWXUGO|S_ISVTX);
                error = security_inode_mkdir(dir, dentry, mode); //line 1883
                if (error)
                                return error;

                DQUOT_INIT(dir); // line 1887
                error = dir->i_op->mkdir(dir, dentry, mode);
                if (!error)
                                fsnotify_mkdir(dir, dentry);
                return error;
}

Line 1874 is the "old" permission check.

Line 1883-1885 is actually the SELinux hook. Note how this is a restrictive model rather than an authoritative model, i.e. it doesn't encapsulate the operation. It merely checks to see if you are allowed to perform the operation before proceeding with the very same arguments which were passed to the function (e.g. dentry

Line 1887-1888 is the weak spot. If I were an attacker who passed the "dentry" structure to this function I could still hold a reference to that structure. And holding the reference, I can overwrite the memory. If I time my memory write correctly (easier to do on a multi-core processor where I'm not even required to preempt the first call) I can inject my own parameters *after* the security checks. In this case I can create new directories wherever I want.

Remember, this is *not* something I claim you can do from userspace (haven't investigated that), but from within the kernel this is entirely possible!

I fully expect Windows to be vulnerable to similar attacks from within the kernel.

My gripe is how SELinux is expected to be able to confine malicious code which is already executing inside the kernel. It is a speed bump at best. Code running inside the kernel can modify all writable memory. Certainly it can modify memory it allocated itself.

Note, this is not an attack which is made possible by running as root. You need to be running in kernel - and then it doesn't really matter whether you run as root or not.

Re:Root in the kernel == game over

[amorsen]

My gripe is how SELinux is expected to be able to confine malicious code which is already executing inside the kernel.

Ah right. No one should sanely expect this. I just got stuck on your explanation about locks; moving locks around wouldn't help, because the malicious code does not need to respect any locks.

Re:Root in the kernel == game over

[makomk]

You need to pay attention to where the copy from userspace to kernelspace happens. All data structures passed to system calls have a copy made in kernel-allocated memory before they're accessed; otherwise really nasty stuff can happen. The Linux security module hooks and all the other in-tree security checks use the same in-kernel copy as the eventual code to carry out the action, which cannot be modified by user programs.

Re:Root in the kernel == game over

[benjymouse]

Agreed. As I tried to say (perhaps a little convoluted) i expected this copying to happen. But some seem to believe that SELinux will protect against malicious code executing in the kernel. Such code can call APIs directly and can modify kernel-allocated structures. If you can do that, security hooks become moot.

Re:Root in the kernel == game over

[benjymouse]

Ah right. No one should sanely expect this.

You'd be surprised...

I just got stuck on your explanation about locks; moving locks around wouldn't help, because the malicious code does not need to respect any locks.

You are of course correct. A lock will prevent nothing. If there weren't multiple cores one could prevent the process from being preempted during the critical section. But that is moot now.

Re:What I suggest to people

[DJRumpy]

Agreed. If it was a true mac fan, that was just embarrassing (and this coming from me, a true Mac user). If it was a troll pretending to be a mac fan, it was still just embarrassing. All computers are vulnerable to exploits.

Back on topic, this PDF vulnerability reads a lot like the vulnerability exposed in iOS4 that allowed a jailbreak in the user space via a PDF exploit.

Are they related?

Re:What I suggest to people

[Anonymous Coward]

Yes, and Linux doesn't maintain the monolithic kernel structure pioneered in Linux, either. There are kernel modules, and filesystems in userspace, and hardware drivers in userspace, and so forth...

Microsoft blah blah Linux blah blah Mac blah blah

[morgauxo]

Yes, Linux has security bugs. Yes, Windows has security bugs. Yes Mac has them too.

As an internet user if I use for daily surfing without all sorts of virus and adware protection how likely am I to get garbage on it that slows it down and fouls my surfing experience? How about the likelihood of getting something truly malicious which makes things stop working altogether or worse yet steals my data? Is there such a thing as virus and adware protection which does not bog the computer down all by itself? Be honest and ask yourself about this for all three of them.

I've used Linux and Windows quite a bit and I can say for sure that if you use them on the internet the Windows machine is extremely likely to get filled with garbage and need formatting in a few months at best. While bad things could happen in Linux they normally do not. Sorry, I know there is such a thing as a Linux virus but I have never seen one. I've seen plenty on Windows. I don't care that technically a hack is possible or a virus exists somewhere if the probability it will ever reach me is near zero.

Now, Mac... It's probably about the same as Linux as far as safety goes. Why would I want to pay twice as much for my computer though? And it's GUI, sorry, no matter how many self described artsy fanbois tell me it's sexy I still think it's butt ugly. Easy to use? How so? All the common programs have 'shortcuts' in the dock. I have to navigate something named 'my harddrive' to find the rest? Really? Is that thing the actual hard drive contents or some collection of shortcuts or what anyway? What's inside here, applications, data files, library files I don't want to know about? Please, give me a 'start' button anyday better yet, how about a nice big 'K' menu. And the dock is also the pager? Running, minimized programs and 'shortcuts' pretty much look the same down there! I guess for stupid people who don't know the difference between a program running or just being installed that does make it easy. They don't have to strain their precious heads learning about a computer. I suppose this is ok when all you ever run is your browser. I'd rather know what's running so I can close it if the computer starts to get bogged down thank you. No, I don't like that paradigm in cellphone OSs either. Hmm... I wonder how long before Mac users can only install the programs big brother Jobs approves of like the iPhone? On the bright side I suppose you don't have to worry some cracker is going to own your computer when the company you bought it from already does!

Re:What I suggest to people

[MrHanky]

Read your own .sig. Now educate yourself about the XNU kernel. (Hint: it's not BSD! Not even "built on" BSD!) Hope you love it.

Re:What I suggest to people

[hazah]

Doesn't seem to be, because in this case a PDF is just and example of ONE vector of attack. This is quite a bit deeper in the system, the kernel.

only affects idiots

[rubycodez]

any implementation of an X server has been full of holes and dangers, only an idiot runs X server on a server. Learn the command line, you pussies! Run X server somewhere else!

Re:only affects idiots

[Blakey Rat]

only an idiot runs X server on a server.

Running the server version on a, actual server! IDIOTS!!!

Re:only affects idiots

[h4rr4r]

The X server is not server software. It is the processes that lets X clients, other software, write to the display. You are an idiot.

There is no server version, a server should not have that sort of extra crap.

Re:What I suggest to people

[Galactic Dominator]

Parts of the OS X kernel has BSD code like the vfs layer, however it is definitely incorrect to call it a FreeBSD kernel.

Re:Microsoft blah blah Linux blah blah Mac blah bl

[Beelzebud]

Honestly, if you're having to reformat Windows every few months, it's a user problem.

Ad hominem

[benjymouse]

Here is a novel idea: Stop misrepresenting what actually happened and stop ad hominem attacks questioning posters' motives .

Microsoft took five weeks to prepare the Ormandy patch. During that time, they made no comment - there was no transparency into whether or not it would be fixed.

They made no comments? Did you actually look or did you just assume?

• Tavis Ormandy reported the issue June 5th (a Saturday). He wanted MS to commit to a 60-days timeline.
• Tuesday (a busy patch Tuesday, no less) MSRT get back to him and say they can present a schedule the upcoming Friday, June 11th (which is less than 5 workdays after the bug report).
• Not good enough for Ormandy he goes public immediately, Wednesday June 9th on the 3rd workday after reporting the bug

Now to your claim that they "made no comments":

• Microsoft blogs about the issue June 10th: http://blogs.technet.com/b/msrc/archive/2010/06/10/windows-help-vulnerability-disclosure.aspx
• June 10th Microsoft makes another blog entry on the issue (2nd that day): http://blogs.technet.com/b/msrc/archive/2010/06/10/security-advisory-2219475-released.aspx
• June 26th, Microsoft updates the blog entry from June 10th: http://blogs.technet.com/b/msrc/archive/2010/06/10/windows-help-vulnerability-disclosure.aspx (scroll down for update)
• June 30th, Microsoft reports on how code similar to Ormandys PoC code is used in attacks: http://blogs.technet.com/b/mmpc/archive/2010/06/30/attacks-on-the-windows-help-and-support-center-vulnerability-cve-2010-1885.aspx
• July 16th Microsoft releases a security bulletin: http://www.microsoft.com/technet/security/advisory/2286198.mspx.
• August 2nd Microsoft updates the bulletin from July 16th,

Hardly a "no comments" approach. If you click through those posts I think you'll find them smack full of info. And I've even excluded their communication on the preliminary "fix it" tools.

Admit it. You are biased, but not classy.

Like your misrepresentation and ad hominem demonstrate more class?

It seems to me that it is indeed interesting that this fix was 2 months in the making (responsibly disclosed). And that is only measuring the time until the kernel had been fixed. Now the distros would have to pick up on it and perform their own regression testing, prepare packages/updates etc.

GP did raise some really interesting questions. For some reason you chose to disregard them right away and go straight for the mans posting history.

Will you be publishing stats on my posting history as well. Am I a shill, too?

Re:Ad hominem

[Zancarius]

You may have some points. I present to you some data that supports the notion that Ormandy may have had a right to publicize this particular flaw.

http://tech.slashdot.org/comments.pl?sid=1517630&cid=30833162

And an issue with HCP reported in 2002 that sounds similar to Ormandy's discovery some 8 years later:

http://it.slashdot.org/comments.pl?sid=1687452&cid=32586552

~8 years is a lot of time. Also, I believe there was another researcher in that third link who mentioned having reported a similar exploit with HCP some years later.

I do think there's plenty of misreporting from both angles. As you're greatly concerned with ad hominem attacks, I'll let you decide the implications of this for yourself.

Re:Ad hominem

[cynyr]

The opensource world tends not to have days off, this idea of "workday" is almost not in it.

Not agreeing with either side, but Wednesday is 5 opensource "workdays" from Saturday. Can you get MS tech support on a Sunday? Also, every day is patch day in opensource land, so again, who cares it was "patch day" for MS. MS also has a history of doing, "we'll get back to you on friday, ohh he's out today, how's next wednesday, oh he got called out and won't be back in till pigs fly, thank you for your interest".

Also I see no technical discussion of the problem on any of the links you posted, nor any steps that can be taken until MS gets a update out to fix it. Nor was MS very friendly towards discussing the issue with this researcher, as well as dragged google into the whole thing, what the guy does off the clock is his deal, even if he does something similar on the clock.

Did Ormandy do everything right? no, he probably should have responded to the Tuesday communication with, if there is no timeline presented for fixing this bug, and a written guarantee that it will be worked on, Saturday morning I let sys admins know so that can take any available steps to protect their systems/users.

Re:Microsoft blah blah Linux blah blah Mac blah bl

[Anonymous Coward]

Agreed. I only have to install my personal copy of XP once: when I build my new system.

My current install is from 26 Jun, 2008, not coincidentally the day I put together my current system.

Re:This is why I *ONLY* use OS X

[Beelzebud]

Normally I don't buy in to these types of conspiracy theories, but the wording you use there really does sound like an Apple employee that gets paid to post this type of crap to message boards...

It reads like it was written, and approved of, by a marketing team...

There's still a hole.

[Animats]

There's still a hole. See Xorg Large Memory Attacks, section 4. Opening a one-page gap in mapped memory at the top of the stack is a workaround, not a fix.

This looks like bad design. Someone got too cute with the MMU. The basic problem is shared memory between a privileged and a non-privileged program. That just screams "security hole". It was put in to get a performance advantage for graphics-heavy applications on X, probably games. "MIT-SHM" shouldn't be enabled on a production server.

Re:There's still a hole.

[wiredlogic]

The annoying thing when MIT-SHM is disabled (as is the default with Cygwin/X) is that you get annoying warning messages to stderr from remote applications that keep requesting it.

Re:There's still a hole.

[scribblej]

I wouldn't put X11 on a production server in the first place. Why would you?

Assuming you're not serving X11, I mean.

Re:There's still a hole.

[codepunk]

X should not exist on a production server.

Your posts are merely proving OP wrong.

[Anonymous Coward]

Your posts are merely proving OP wrong. Because Odies asked : "Do you honestly think that Microsoft would do nothing if there was a non-patched privilege escalation exploit in Windows?"

You've counted 10.

That would, by the way, be 10 WE KNOW ABOUT.
Now, unless you have windows source and have tested it as thoroughly as devs tested X.Org code, you cannot say there are NO more vulnerabilities.

But can you count how many there are?

No.

Therefore, since they can't be counted, what are they?

Countless.

Re:This is why I *ONLY* use OS X

[valeo.de]

Yes, OS X is more secure. Oh, and Apple doesn't have a fucking atrocious security track record. And that PDF-based 'root my iPhone/iPad in a single click' didn't exist either...

Re:This is why I *ONLY* use OS X

[e065c8515d206cb0e190]

Yes it did. That's how I jail-broke mine.

Re:This is why I *ONLY* use OS X

[valeo.de]

I think your sarcasm detector needs replacing...

Running X as root?

[Anonymous Coward]

I'm confused by the comments saying X can only be run as root.

I'm running it just fine on a couple of my systems by calling startx as a normal user.

Obviously I'm missing something here, but I'm not sure what... Is it something to do with the way drivers work?

Re:Running X as root?

[grantek]

On a Linux system it's generally "setuid root", which means the filesystem permissions allow program can be run by any user, but there's a special flag that tells the kernel to actually give it root privileges, exactly so that it can do special hardware stuff.

You have to be very careful when writing a program designed to run with an effective ID of root, because it's one of the fastest ways to compromise a system if there's a flaw.

Newer versions of Xorg are moving to an architecture where they can be run without root privileges - there's already patches available, and it's an area of interest for a lot of people.

Re:Running X as root?

[Anonymous Coward]

Not just "patches available". It already works fine in specific environments like with Intel graphics. I'm posting this from a vanilla install of MeeGo and Xorg is not root.

Re:This is why I *ONLY* use OS X

[e065c8515d206cb0e190]

You're right, it's broken. Probably because it uses MacOSX.

Btw that flaw was just great... I was reading the new online on my iPhone and some site had an article "flaw in iPhone/iPad PDF", so I read it, and they directly linked a "website that was taking advantage of that flaw for malicious purposes", i.e. jailbreakme.com... I went right away and got my iPhone jailbroken in 2 clicks.
BEST. ARTICLE. EVER.

Modus operandi

[Anonymous Coward]

Check on the linux kernel audit project. It exists, does things like static code analysis and audits most of the code changes for security vulnerabilities. In that last 5+ years they have fixed hundreds to thousands of security vulnerabilities - all silently. It is an official policy of the core developers to handle every security problem via obscurity in short time frame.

The changelog indeed is a gold mine. You can at any point of time find fresh vulnerabilities by tracking it. That leads to every installed and running Linux kernel out there having exploitable known vulnerabilities that have not yet been patched. Every black hat that is interested in Linux kernel knows this and exploits it daily.

Re:Modus operandi

[Alex Belits]

Static analysis produces massive amounts of false positives that are easier to "fix" than to verify.

I believe, it would be a safe bet that there are still no actual vulnerabilities found and successfully exploited by this method -- and the actual exploitable vulnerability the article is about, was not and could not be found by such analysis.

So no, changelog is not a "gold mine" for anything, most of the time if will give you massive load of starting pointers that if/when you will find one that is a genuine security bug and produce an exploit based on it, not even the oldest network-accessible installation of Slackware will have them.

This is a rare exception, though it hardly stands out in the changelog, and only coincidence with Xorg [otherwise completely valid and reasonable] behavior makes exploit possible.

Re:What I suggest to people

[Anonymous Coward]

No no no they paid to get in because it's so PREEETTTTYYY!
And also they have no cell phone reception once inside the walled garden, so it's peaceful and quiet too.

Re:What I suggest to people

[Anonymous Coward]

All systems have bugs, even MACs.

Mac. Short for Macintosh. Did you think it was an acronym for Macintosh Apple Computer or something?

Re:What I suggest to people

[DarkKnightRadick]

And from the second link, which you handily ignore:

http://en.wikipedia.org/wiki/Mach_(kernel) [wikipedia.org]

Neither Mac OS X nor FreeBSD maintain the microkernel structure pioneered in Mach, although Mac OS X continues to offer microkernel Inter-Process Communication and control primitives for use directly by applications.

Re:What I suggest to people

[DarkKnightRadick]

http://en.wikipedia.org/wiki/XNU

Originally developed by NeXT for the NeXTSTEP operating system, XNU was a hybrid kernel combining version 2.5 of the Mach kernel developed at Carnegie Mellon University with components from 4.3BSD and an object-oriented API for writing drivers called Driver Kit.

Oh hey, how about that, components from 4.3BSD (arguably not FreeBSD, but it is BSD).

Re:What I suggest to people

[DarkKnightRadick]

Besides the point. Mac OS X (nor BSD) doesn't use Mach (anymore), though it retains two of its features (though not BSD).

Re:What I suggest to people

[evilviper]

Since its a Microkernel, it can have "servers" for different subsystems, including BSD, which aren't really "kernel modules" in the Linux or BSD sense.

Except, of course, it isn't a microkernel. They ripped that out, first thing, made it monolithic for performance.

I'd love to see a common operating system using a microkernel. That seems to be the only way forward in a world of imperfect programmers and increasing attention towards turning every little flaw into vulnerabilities.

Re:What I suggest to people

[wolf1oo]

I hope this is flamebait, for god's sake...
Anyways, did some research back in the day:
http://wolf1oo.doesntexist.com/files/Viruses_Per_OS.pdf

Now, don't go saying "OH YOUR LINUX INFORMATION IS WRONG, CLEARLY THERE'S A VIRUS." No. This is a security flaw. As it was known when I did the research, no program or malicious software existed for linux that could do damage, unless of course the user is dumb enough to run everything in root....

Shit happens

[udippel]

Must Not Happen

Re:What I suggest to people

[MrHanky]

Yes. Components from. Whereas the basic architecture isn't BSD at all. Evidently, you place yourself firmly in that other group named in your .sig. You're a fucking moron.

Re:What I suggest to people

[Anonymous Coward]

XNU is a hybrid kernel. It's part microkernel part monolithic. The big difference is how memory allocation is handled. XNU does use message passing for system calls so that aspect still exists.

As for commercial operating systems, there are several that use microkernel or hybrid kernels besides Mac OS including Windows and QNX.

mod parent up

[mzs]

Thanks for the simple and short explanation.

Re:Microsoft blah blah Linux blah blah Mac blah bl

[jo_ham]

By default the hard drive (the boot partition, in fact) is called "Macintosh HD". When you click on it you are at the root mount point ( / ) containing the familiar Users, Applications, Library, System that will be familiar to anyone who used a Unix or Linux system before.

If you want to navigate to other programs not on the Dock, just click "Applications" (also in the dock) for a pop-up list, much like the start menu (it just doesn't say "start" on it). Different modifier keys that you can optionally press when you click this representation of your Applications folder [that is much like the Start button] vary the way it displays - like a fan, like a grid or like a regular list, depending on your preference. The number of apps that have "shortcuts" in the Dock is entirely up to you - you can keep it just to running apps if you really want (with the exception of Finder and the Trash, which you cannot remove, although since the Finder is always running it will always display in the Dock anyway [although you can modify the behaviour so you can quit Finder, you cannot remove it from the far left anchor position on the dock]). Putting apps that you very frequently use in the Dock reduces the launch method to a single click, but you are not obligated to do this. You can tell at a glance what apps are running since they have a big white dot under them if you do choose to keep non-running apps in the Dock. It speaks to your character that you think a different UI paradigm means the entirety of its users are stupid; that's one of the biggest non-sequiturs I have ever seen, although that's closely followed by the assertion that Mac users only run a browser.

The Mac user space is set up very similarly to Linux - home folder, apps folder, system folders etc. All of the "data files and library files" are kept separately in logical places. If you are levelling this criticism at the Mac then surely you must do the same for Linux, since the layout is near-identical.

The fact that you don't personally like the Mac UI doesn't make it some hopeless, inferior method of computer interface - just different. There are enough errors and I-don't-want-to-like-it bias in your post (ie, from someone who uses a Linux system day to day, you are either being wilfully ignorant about some really basic things or you have never actually used a Mac and are just repeating things you have read second hand - if you are proficient with a Linux system, the Mac UI and HD layout is not rocket science).

Also, formatting a Windows box every few months? This is not 1995 any more. XP, 7 and (shock horror) even Vista are not that bad any more if they are properly looked after. This does mean AV software for Windows, but there is no need for it to be giant bloatware.

Re:This is why I *ONLY* use OS X

[jo_ham]

You're being baited. The AC is an anti-Apple troll.

Which just means escalation to a different account

[Ungrounded Lightning]

With the switch to kernel modesetting (already happening) there shouldn't be any need for X to mess directly with hardware anymore, and without that it should run just fine without root privileges.

But that just means the X server will be running as something other than root. Doesn't fix the basic problem - which is that any client can use the X server bug to gain the privilege of the X server's account.

If the X server is running as the same account as the client it's not such a big deal. But even if the server is running as the user who is working with the desktop, the client might be something that the user wanted to sandbox into some other account (or otherwise restrict its access, i.e. by limits, chroot, ...). This means it can still break out and corrupt his stuff by seizing the X server's privileges.

Re:What I suggest to people

[abigor]

How does that invalidate the fact that OS X's kernel is based on Mach? The strict microkernel message-passing stuff was abandoned for practical reasons, but the important stuff - which you mention in your own cut'n'paste, even though I'm certain you have no idea what it means - is all there.

Open Source Workdays

[benjymouse]

Workdays was important because that is what was used in the responsible disclosure guidelines. Which recommends waiting 5 workdays of non-communication before taking a vulnerability public.

Responsible disclosure which Google strongly supported until one of their researchers broke it:

From Googles website (emphasis mine):

"This process of notifying a vendor before publicly releasing information is an industry standard best practice known as responsible disclosure. Responsible disclosure is important to the ecology of the Internet. It allows companies like Google to better protect our users by fixing vulnerabilities and resolving security concerns before they are brought to the attention of the bad guys. We strongly encourage anyone who is interested in researching and reporting security issues to observe the simple courtesies and protocols of responsible disclosure. Our Security team follows the same procedure when we discover and report security vulnerabilities to other companies.

Tavis Ormandy knew this. That is why he made a stupid claim that acted in his personal capacity, not as a Google researcher. Even though he used Google resources, Google colleagues and Google paid time.

Also I see no technical discussion of the problem on any of the links you posted, nor any steps that can be taken until MS gets a update out to fix it.

The technical info is there. If you cared to follow the "fix it" links from their blog entries you would see that they designed workarounds.

But the interesting thing here is that after this debacle, 60 days was put forward as an absolute maximum a vendor should spend analyzing and designing+implementing a fix for a vulnerability. With this Linux bug we see 2 groups need to sit down together to work things out. And they spend 60 days before the distros got their hand on the fix. Just interesting, that's all. This was pointed out by the GP of the post I responded to. And he was immediately attacked.

Open source microkernel OS:

[thaig]

Although everyone "slags off" Symbian (really the S60 UI) and declares "Android forever" and all that crap. it has a microkernel OS with File Servers and the rest - EKA2.

http://media.wiley.com/product_data/excerpt/47/04700252/0470025247.pdf

It's out there on hundreds of millions of devices too, and whatever you might say about the UIs ontop of it, it is pretty good in itself.

Let's analyse your assumptions

[jonaskoelker]

Allow me to analyze your assumptions:

Microsoft has thousands of programmers working full-time; Linux is maintained by volunteers, working in their spare time.

How many volunteers, compared to the number of Microsoft programmers? If the volunteers each work one tenth of full time per week but there are twenty times as many of them as there are Microsoft programmers, how does the math come out?

That means that Microsoft can easily allocate more resources to fixing a security bug than Linux can.

I see a type error: Microsoft is an organization, Linux is one or more pieces of software; they seem to not have an "allocate resources" behavior in common. So---who is this "Linux" you speak of? Do you mean Red Hat? Canonical? The Debian project? The collection of hobbyists living in their moms' basements? How does this resource-allocating-Linux-thing allocate its resources? How do you know how easily it does it, and how many resources it has?

This being true, you'd expect Microsoft to get bug patches out quicker than Linux

This assumes that more input resources yields more output results. That's not true, not even in just all the non-degenerate cases (For a controversial example, compare health care systems for price and quality across nations).

the Microsoft patches come out only on Patch Tuesday, while the Linux patches come out as quickly as the various distros fold them into their updates.

How quick are those two time spans compared to one another, on average? (Pick your sample any way you want, as long as you discuss what might be wrong about your sampling method)

And, if that's not fast enough for you, you can always download the source and compile it for yourself

Assuming you have the time and skills to do so. (If you believe it takes virtually no skills, I guess you don't do tech support for family and friends)

Re:Let's analyse your assumptions

[techno-vampire]

Assuming you have the time and skills to do so. (If you believe it takes virtually no skills, I guess you don't do tech support for family and friends)>/i?

I've downloaded and recompiled on occasion because I needed a patch before it reached the Fedora repositories. And, I might add, I can remember when the only way to upgrade your kernel was to download the source, run through whichever config routine you preferred, compile and install it. For the most part, it wasn't hard, after the first time or two. I'd not recommend it to Aunt Millie, but if she needed a patch Right Now, I'd be willing to go over and do it for her. YMMV, and probably does.

Re:Microsoft blah blah Linux blah blah Mac blah bl

[walshy007]

The fact that you don't personally like the Mac UI doesn't make it some hopeless, inferior method of computer interface - just different. There are enough errors and I-don't-want-to-like-it bias in your post (ie, from someone who uses a Linux system day to day, you are either being wilfully ignorant about some really basic things or you have never actually used a Mac and are just repeating things you have read second hand - if you are proficient with a Linux system, the Mac UI and HD layout is not rocket science).

Not rocket science, but quite unintuitive even to a ten year long linux user who's used to doing things at times in odd ways.

Perfect example being installing the firefox dmg on mac os, I tested this with multiple people, so it wasn't just me being a retard. Clicking the dmg to open the window is natural, most people then wait for some kind of installer option if they are used to windows or some kind of direction if used to linux.

Clicking and dragging the little icon to install something is completely non-intiutive to non-mac people. Most just gave up.

Just one example of many, and as a linux user I'd actually use windows over mac os x, because when I drop into an os x shell it's almost useless by default and can take quite some time to install all the typical cli applications required.

Windows is no different in that regard however at least in windows you know where you stand from the start.

Re:Which just means escalation to a different acco

[sproot]

Yes, except the basic problem was fixed in the kernel so whether the X server runs as root or not is irrelevant.

Re:What I suggest to people

[DarkKnightRadick]

Nor is it Mach, now is it?

http://en.wikipedia.org/wiki/Mach_(kernel)

Neither Mac OS X nor FreeBSD maintain the microkernel structure pioneered in Mach, although Mac OS X continues to offer microkernel Inter-Process Communication and control primitives for use directly by applications.

Re:What I suggest to people

[DarkKnightRadick]

Well, I didn't want to say it was pretty self-explanatory, but in reality it is!

http://en.wikipedia.org/wiki/Inter-process_communication

In computing, Inter-process communication (IPC) is a set of techniques for the exchange of data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. IPC techniques are divided into methods for message passing, synchronization, shared memory, and remote procedure calls (RPC). The method of IPC used may vary based on the bandwidth and latency of communication between the threads, and the type of data being communicated.

http://en.wikipedia.org/wiki/Control_flow is the closest I could get to control primitives. Am I far off?

You mention that control primitives and IPC are pretty important and imply that Mach handled them differently. I'll give you that.

Upon further reading on XNU, XNU seems to contradict the Mach (kernel) entry entirely:

The Berkeley Software Distribution (BSD) portion of the kernel provides the POSIX API (BSD system calls), the Unix process model atop Mach tasks, basic security policies, user and group ids, permissions, the network stack, the virtual file system code (including a filesystem independent journalling layer), several local file systems such as HFS/HFS+, the Network File System (NFS) client and server, cryptographic framework, UNIX System V inter-process communication (IPC), Audit subsystem, mandatory access control, and some of the locking primitives. The BSD code present in XNU came from the FreeBSD kernel. Although much of it has been significantly modified, code sharing still occurs between Apple and the FreeBSD Project.[citation needed][dubious – discuss]

You'll note I bolded two sections. Seems more was taken from FreeBSD and not a lot of Mach's original stuff.

But "Ah-ha!" you'll say:

Mach provides kernel threads, processes, pre-emptive multitasking, message-passing (used in inter-process communication), protected memory, virtual memory management, soft real-time support, kernel debugging support, and console I/O.

Really not supporting your argument.

Seems like the Mach and XNU articles need to be updated so they don't contradict each other.

Re:What I suggest to people

[evilviper]

XNU is a hybrid kernel. It's part microkernel part monolithic.

That's like saying it's part invincible, part infinitely fragile.

Yes, it has message passing, but if you don't HAVE TO use message passing, the benefits of microkernels are null.

Re:What I suggest to people

[Ironhandx]

Agreed. If it was a true mac fan, that was just embarrassing (and this coming from me, a true Mac user). If it was a troll pretending to be a mac fan, it was still just embarrassing.

This scares me, the language apple fanboys use more and more resembles a religious following rather than a techie following. Someone needs to stop Jobs before its too late!

Re:What I suggest to people

[DJRumpy]

I don't think that was an Apple 'fanboi' at all. it's a bit too ridiculous to be taken seriously. More likely just someone trolling...badly.

Re:What I suggest to people

[Fri13]

Wrong. The Mac OS X is build top of the Mach microkernel what runs the XNU operating system, from what the BSD is just part of it, being responsible of: process model, user ids, permissions, basic security policies, POSIX API, BSD style system calls, TCP/IP stack, BSD sockets, firewall, VFS and filesystems, System V IPC, crypto framework and various synchronization mechanisms

Rest of the software system
------------- OS border -----------
(Free)BSD + I/O Kit
Mach microkernel

FreeBSD is just part of the XNU OS while Mach is the kernel on it. And no, there is no such OS architecture as "hybrid". That is just marketing.

Re:What I suggest to people

[Fri13]

Actually they did not make it monolithic, it is still Server-Client architecture but they just moved the servers from user space where they would be placed if wanted to follow the original idea of Server-Client architecture. But most times the Server-Client OS is developed so the some of the servers exist in kernel space with the microkernel, but they are never part of the microkernel.

Microsoft did same thing with NT as well. They tried to market it as a new OS architecture called "Hybrid" what would be "fast as Monolithic OS, but secure as Server-Client". But that did not take off because the servers were never part of the microkernel.

Now today, Microsoft researchers say that NT is normal Server-Client architectured OS, where just some of the servers are moved to kernel space but separated from the microkernel.
With their Singluarity project they are using SIP's, what gives one address space where microkernel and all the servers are located among other normal system programs.

If you want to see a common OS using microkernel, there are lots of those from what to choose. Like from kFreeBSD, HURD, Minix, L4Linux, DragonFly BSD, NT and so on....

Re:What I suggest to people

[Fri13]

"As to the whole "hybrid kernel" thing - it's just marketing. It's "oh, those microkernels had good PR, how can we try to get good PR for our working kernel? Oh, I know, let's use a cool name and try to imply that it has all the PR advantages that that other system has""
-Linus Torvalds

Moving servers to kernel space does not make the OS monolithic. You can not have monolithic and server-client together or mixed anyway.

Re:What I suggest to people

[DarkKnightRadick]

Have you not read any of the links I've posted (links to the articles for Mach (kernel) and XNU)?

Re:This is why I *ONLY* use OS X

[NeverVotedBush]

An AC says: "OS X (and even Windows) is far more secure than Linux."

Is that why Macs ship with the firewall turned off by default?

No OS is completely secure. It's just how it goes. Not picking on Macs either (though I really wish Apple would default enable the firewall) - I have a Mac laptop and also have a number of Linux boxes. But the AC post is inaccurate and pure troll..

Re:What I suggest to people

[evilviper]

most times the Server-Client OS is developed so the some of the servers exist in kernel space with the microkernel, but they are never part of the microkernel.

And that's different from loading kernel modules, how?

If everything is running in kernel space, you've given up all the advantages of a microkernel.

If you want to see a common OS using microkernel, there are lots of those from what to choose. Like from kFreeBSD, HURD, Minix, L4Linux, DragonFly BSD, NT and so on....

Searching for kFreeBSD only turns up Debian's efforts to put a GNU userland on a FreeBSD kernel. HURD is as useful as it is popular. NT is a "hybrid" microkernel just like Darwin, which gets it the worst of both worlds. DragonFly has message passing tacked on, but isn't a microkernel as far as I'm aware (I haven't paid that much attention). L4Linux might be interesting if they aren't just using it as a hypervisor, I'll have to look into it.

Re:What I suggest to people

[tyrione]

XNU is a hybrid kernel. It's part microkernel part monolithic. The big difference is how memory allocation is handled. XNU does use message passing for system calls so that aspect still exists.

As for commercial operating systems, there are several that use microkernel or hybrid kernels besides Mac OS including Windows and QNX.

I can't believe it took 5 comments to get the progression of Mach Microkernel [NeXT] to Mach Hybrid XNU Kernel. Seriously, this place as a technically competent lot has moved on.

http://en.academic.ru/dic.nsf/enwiki/331902

XNU

Infobox_Software
name = XNU kernel
caption =
developer = Apple Inc.
latest_release_version =
latest_release_date =
operating_system = Darwin & Mac OS X
genre = Kernel
kernel_type = Hybrid
license = Apple Public Source License 2.0
working_state = In production / development
website = http://kernel.macosforge.org/

XNU is the computer operating system kernel that Apple Inc. acquired and developed for use in the Mac OS X operating system and released as free and open source software as part of the Darwin operating system. "XNU" is an acronym for "X is Not Unix" [cite web | year=2005 | url=http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/glossary/chapter_998_section_1.html#//apple_ref/doc/uid/TP40002859-DontLinkElementID_38 | title=Porting UNIX/Linux Applications to Mac OS X: Glossary | publisher=Apple Computer | accessdate=2005-12-13]

Originally developed by NeXT for the NEXTSTEP operating system, XNU was a hybrid kernel combining version 2.5 of the Mach kernel developed at Carnegie Mellon University with components from 4.3BSD and an object-oriented API for writing drivers called Driver Kit.

After Apple acquired NeXT, the Mach component was upgraded to 3.0, the BSD components were upgraded with code from the FreeBSD project and the Driver Kit was replaced with a C++ API for writing drivers called I/O Kit.

Kernel design

Like some other modern kernels, XNU is a hybrid, containing features of both monolithic and microkernels, attempting to make the best use of both technologies, such as the message passing capability of microkernels enabling greater modularity and larger portions of the OS to benefit from protected memory, as well as retaining the speed of monolithic kernels for certain critical tasks.

Currently, XNU runs on ARM [ [http://www.engadget.com/2007/07/01/iphone-processor-found-620mhz-arm/ iPhone processor found: 620MHz ARM CPU] (2007-07-01 accessdate|2008-01-06] , x86, x86-64 and PowerPC based processors, both single processor and SMP models.

Mach

The core of the XNU kernel, Mach, was originally conceived as a simple microkernel. As such, it is able to run the core of an operating system as separated processes, which allows a great flexibility (one could run several operating systems in parallel above the Mach core), but this often reduced performance because of time consuming kernel/user mode context switches and overhead stemming from mapping or copying messages between the address spaces of the microkernel and that of the service daemons. With Mac OS X, the designers have attempted to streamline certain tasks and thus BSD functionalities were built into the core with Mach. The result is a combination of Mach and a classical BSD kernel, with some advantages and disadvantages of both.

Mach provides kernel threads, processes, pre-emptive multitasking, message-passing (used in inter-process communication), protected memory, virtual memory management, very soft real-time support, kernel debugging support, and console I/O. The Mach component also allows the OS to host binaries for multiple distinct CPU architectures within a single file (such as x86 and PowerPC) due to its use of the Mach-O binary

Re:What I suggest to people

[tyrione]

Besides the point. Mac OS X (nor BSD) doesn't use Mach (anymore), though it retains two of its features (though not BSD).

that mach-o is just for looks.

Re:What I suggest to people

[Fri13]

it can have "servers" for different subsystems, including BSD, which aren't really "kernel modules" in the Linux or BSD sense.

XNU has servers (btw, Darwin is the name of the development platform, XNU OS + Apples official development tools and settings so the Mac OS X closed source ABI's can work with the XNU) and the servers are as well called modules, but the difference just is that the modules in monolithic OS are tightly integrated to the OS architecture. The modularity in monolithic OS is in the binary level, but not in architecture level. While in Server-Client (like XNU) operating system the modularity is in architecture and binary level. The microkernel is separated binary from servers, even that the servers would exist in kernel space, they just does not belong to the microkernel. And microkernel can be protected from the server (modules) crashes, even they would exist in kernel space, it is just much much harder, but still possible to do. Same thing is with monolithic OS architecture, you can protect rest of the OS if the module crash, it is possible but as well littlebit harder to do. But at today Linux, the modules can crash without crashing the Linux OS and by that crashing the whole software system.

Re:What I suggest to people

[Fri13]

You just falled to marketing...

As to the whole "hybrid kernel" thing - it's just marketing. It's "oh, those microkernels had good PR, how can we try to get good PR for our working kernel? Oh, I know, let's use a cool name and try to imply that it has all the PR advantages that that other system has""
-Linus Torvalds

Moving servers to kernel space does not make the OS monolithic. You can not have monolithic and server-client together or mixed anyway. The microkernel is always alone, even it would be with servers in same kernel space. And if you limit the amount of servers making them to serve more different OS functions than in the original Server-Client idea, the architecture is still the Server-Client in the XNU.

Even Microsoft has learn that the marketing "Hybrid" did not work or lead anywhere and they stopped it. They understanded that it just caused lots of problems among new becaming OS engineers in their first lessons in OS classes as the "Hybrid" is pure marketing lie and not scientifical fact.

Example the Microsoft OS resereachers who work with the Singularity OS, they informed tha NT is not hybrid but Server-Client and so does Singluarity, pure microkernel, even that all servers and user processes are at same address space.
It was much easier by that to explain the technology than try to say something "Oh, this has best sides of all but no flaws of them!" and fail with it.

Re:What I suggest to people

[Fri13]

If everything is running in kernel space, you've given up all the advantages of a microkernel.

Not when you use SIP.
http://research.microsoft.com/en-us/projects/singularity/

NT is a "hybrid" microkernel just like Darwin, which gets it the worst of both worlds.

Not acording Microsoft OS reseachers what said that NT use pure microkernel, like Singularity as well. And Darwin is not OS, XNU is. Darwin is XNU + Apples official compilation tools. When you download the Darwin package, you get the tools, XNU OS what is separated to Mach microkernel, I/O Kit and BSD parts and so on. You can compile XNU with own compilation tools if wanted, without the Apple's. But you do not get it work with Mac OS X closed ABI then. You need to know exact Darwin version to know XNU was compiled.

DragonFly has message passing tacked on, but isn't a microkernel as far as I'm aware

It has microkernel, just different way than original idea to implent Server-Client architecture. There is no such thing as "hybrid" in scientifical means, only in marketing.

L4Linux might be interesting if they aren't just using it as a hypervisor, I'll have to look into it.

Idea is to run Linux OS on VM (what L4 would be) and achieve by that faster way to load Linux OS when it crash. It is interesting idea but does not really solve any problems what the monolithic OS can have (!can!) and what reason the Server-Client architecture was done in the first place. The OS still runs in L4Linux as monolithic but just in user space. So it can help to speed up servers downtime when OS crash with few seconds.

http://www.usenix.org/publications/login/2006-04/openpdfs/herder.pdf

Re:Microsoft blah blah Linux blah blah Mac blah bl

[morgauxo]

White dot? There was no white dots to show running applications when I worked in an office w/ Macs. That was a few years ago though. Maybe they added it? Or maybe there is a setting? Everything was set to the bosses preferences and locked down tight. If Mac doesn't try to hide the difference between running and not-running programs then I apologize for that remark. I do think that UIs which work that way (I have seen it on cellphones) work that way to insulate the user from needing a basic computer understanding... Thus the 'stupid' remark.

OK, Windows is better than it was. I'll give that. Running an anti-virus program though is a big negative. I'm sorry, I have yet to see a machine that didn't bog down and run like crap whenever an antivirus was installed. Disabling heuristic scans and limiting file types to actual executable helps but doesn't really fix the problem. Windows also has a tendency to acrue garbage if you install and remove programs regularly. No, I'm not talking about applications containing malware. Install a number of well trusted applications and remove them. Windows will run slower.

Sure.. I do see some Unix heritage in the Mac filesystem. That's great when doing something involved from the commandline. I don't think I should need to go there to run an application though. Maybe there is a menu option which was disabled in the machines I used? I didn't see a way to separate the concept of shortcuts to the executable files of applications and just viewing the actual directory structure.

Ignoring all this functionality stuff even just on an aesthetics basis I think it is just fine for me to state the Mac's UI is butt ugly and inferior. Sure, appearances are subjective but these days it seems like it is almost assumed to be a universal opinion that Mac has the prettiest UI. I'm just making the point that there is at least one person still alive who disagrees.