What is Digg?Sponsored by Bing
How Many Calories Are In Alcohol? view!
bing.com - Handy guidelines help you get your drink on and keep the weight off.
117 Comments
- joebaloney, on 07/19/2009, -3/+43"That does not look like a kernel problem to me at all," Torvalds is quoted as saying in one message. "He's running a setuid program that allows the user to specify its own modules. And then you people are surprised he gets local root?"
Maybe I'm wrong, but it sounds like the guy who reported the flaw was pissed that he wasn't getting enough attention and so wrote an "exploit". - ThantiK, on 07/19/2009, -7/+44For those of you who don't know this...ITS ALREADY BEEN PATCHED...in fact, was patched HOURS ago in 2.6.30.1
Secondly, it's a compiler optimization issue. - theonlywizdum, on 07/19/2009, -2/+39This is not a virus.
- warp99, on 07/18/2009, -5/+41"Although the code correctly checks to make sure the tun variable doesn't point to NULL, the compiler removes the lines responsible for that inspection during optimization routines."
So how is this an issue with the kernel? Spangler is using setuid for the exploit which is inherently insecure in the first place. Nevertheless it should be fixed prior to release regardless of who is at fault. - Runningflame570, on 07/19/2009, -2/+30Made me think of this bash.org quote-
andrewy: linux exploits are like IF THE MOON IS IN FRONT OF VENUS AND YOU ARE LEFT HANDED AND SOMEONE ALREADY HAS LOCAL ACCESS AND YOU HAVE YAEWS (YET ANOTHER EMACS WEB SERVER) INSTALLED IT MIGHT BE POSSIBLE UNDER CERTAIN CONDITIONS TO BECOME ROOT - christoast, on 07/19/2009, -9/+34Title is conspiracy truth bending to get attention
- Nitrodist88, on 07/19/2009, -4/+26It's foolhardy to assume that anything is perfect and impenetrable.
- glinsvad, on 07/19/2009, -3/+24"The real story here is how subtle it is, and that the compiler itself introduced it during code optimization."
Wouldn't that be more of a compiler issue then? You can do a lot with source code, but you're still relying on the compiler to interpret it correctly. Otherwise, the build procedure simply ought to turn off optimization for the affected objects. - inactive, on 07/19/2009, -9/+28Buried as inaccurate
"That does not look like a kernel problem to me at all" - Torvalds - Thirtysixway, on 07/19/2009, -3/+21Yeah, looks more like a compiler issue and not kernel issue.
- theonlywizdum, on 07/19/2009, -2/+19No one claimed that Linux is 100% secure, the beauty of open source software is that there are now thousands of people working on ways to fix it, instead of a small group of developers. Expect a fix or temporary patch within the next few days.
- merky1, on 07/19/2009, -10/+25This is why I love Linux. If this was a windows exploit, the public wouldn't know about it until 1/3 of the world was infected, even then all we would get is a patch for "critical security." But with Linux, we have people looking at both the exploit and the source code instead of some "tiger team" making presentations and timelines.
- Frostek, on 07/19/2009, -4/+18Yes, Windows has a unmatched reputation for security...
/s - Runningflame570, on 07/19/2009, -3/+16Tens of thousands of hosting services, financial institutions, HPC researchers, and embedded systems providers amongst others. Next question?
- S1ngular1ty1, on 07/19/2009, -1/+14The PWN TO OWN contest begs to differ...
Video
http://www.youtube.com/watch?v=no11eIx0x6w
Article
http://dvlabs.tippingpoint.com/blog/2008/03/27/day ... - scriptcoder, on 07/19/2009, -4/+17This is like dumb people downloading Antivirus 2009 and then complaining that Windows is always infected.
Except much much nerdier. - drag, on 07/19/2009, -0/+12>> VMS's principal security difference between UNIX was the introduction of ACLs (access control lists). However, not too long after POSIX also standardized the use of ACLs (and Linux supports them), but they are rarely used, in favor of the older POSIX permissions system.
You mean _extended_ access control lists. The POSIX uses ACLs for normal POSIX permissions. User/Group/World + Read/Write/Execute is actually access control lists. Just very simple. Linux supports _extended_ ACLs.based on a POSIX _DRAFT_. The Extended ACLs was never made a standard. Why? Because Microsoft has already have widely used Extended ACLs for NTFS.
So Linux you have 3 sets of Extended ACLs you have to deal with... The normal POSIX-ish Extended ACLs, Microsoft Extended ACLs, and NFSv4 Extended ACLs.
Why NFSv4 is different? Because the folks at Sun Microsystems that worked on NFSv4 followed Microsoft's documentation and matched the Extended ACLs with Microsoft's. The only problem is that Microsoft's REAL implementation does not match their documentation. Their documentation was either out of date or deliberately misleading. So the SAMBA guys got it right because they reverse engineered the Microsoft protocols and ignored the documentation.
Fun stuff.
>> So how is this an issue with the kernel? Spangler is using setuid for the exploit which is inherently insecure in the first place. Nevertheless it should be fixed prior to release regardless of who is at fault.
Your confused. Their is a bug with the SELinux settings that breaks the security around the setuid binaries. That is one exploit. The actual local exploit that uses the NULL point bug does not require a setuid binary. It can be done without using it.
>> Buried as inaccurate
>> "That does not look like a kernel problem to me at all" - Torvalds
Torvalds is 100% wrong with that statement. It is absolutely a kernel problem. The bug was caused by a stupidly obvious programming mistake. A common C problem that should of been obvious to anybody examining the code.
The bug was not normally exploitable. Depending on the compiler used on the kernel it can randomly be exploitable or not-exploitable. The GCC settings required to make it exploitable is just happenstance. If the kernel was properly coded then it would of never been a problem regardless of the GCC options. - inactive, on 07/18/2009, -1/+13Q {
The "NULL pointer dereference" bug has been confirmed in versions 2.6.30 and 2.6.30.1 of the Linux kernel, which Spengler said has been incorporated into only one vendor build: version 5 of Red Hat Enterprise Linux that's used in test environments. The exploit works only when a security extension knows as SELinux, or Security-Enhanced Linux, is enabled. Conversely, it also works when audio software known as PulseAudio is installed.
} - S1ngular1ty1, on 07/19/2009, -1/+12Security is almost always a pain in the ass. You can't have ease of use and really good security. The two are most often at odds with each other.
- HappyScrappy, on 07/19/2009, -5/+15Because the object code with the problem (produced from the source code) is in the kernel. This the problem is an issue with the kernel.
To be honest, the code in the kernel is written wrong. Yes, gcc is removing some lines, but the programmer made this possible by putting a pointer dereference before the nil check in the code. - NetJoe, on 07/19/2009, -2/+12I was always taught once a hostile kernel module is installed its time to format the drive. That's what made microsoft lock virtually everyone out of ring 0 in vista (with all the headaches that brought)
SELinux must be some slick stuff if it's intended to survive or contain that kind of compromise.
Linus Torvalds:
"He's running a setuid program that allows the user to specify its own modules. And then you people are surprised he gets local root?"
Not sure I quite understand the article, or trust the author is accurate, but I haven't read the kernel mailing list for many moons now. I do trust Linus to speak true, even in ugly situations with no more than limited bias. More than I can say for most newscopy. - mrsteveman1, on 07/19/2009, -3/+12You're right, however you're talking about a baseline permission system that is what like 30 years old? I'm sure its in POSIX or SUS somewhere, but there are better additions on top of it like SELinux, which is so fine grained it drives me crazy. This specific exploit gets around SELinux apparently, but overall it is an example of more capable systems that already exist to address the security issue.
AppArmor is another one that provides a fair amount more security without driving me crazy. - theonlywizdum, on 07/19/2009, -1/+10Because he's wrong.
- sirhomer, on 07/19/2009, -0/+9It really seems to be a combination of things going wrong here, a strange interplay between many different systems that leads to this exploit. GCC is making some assumptions, which it might or might not have the liberty to do since it's pretty ambiguous what is going on.
Here is the code in the kernel that causes the exploit (tun.c):
struct sock *sk = tun->sk;
if (!tun) return POLLERR;
The first line there is a struct being dereferenced to a field in the struct. Even if the pointer to the struct itself is equal to 0 (the "tun" variable), the fact that that the assignment is to a field in the struct means that the assignment would actually pass a positive other then NULL value to the "sk" variable. If tun was dereferenced directly it would make more sense to optimize NULL pointer check out, but this is not what is happening here.
Anyways to fix this exploit you simply swap the code as such:
if (!tun) return POLLERR;
struct sock *sk = tun->sk;
And GCC will not optimize out the NULL check, because the deref hasn't occurred yet. - AngelBunny, on 07/19/2009, -3/+11No, you run programs that have escalated privileges but you yourself should not have it ie root. Also, the programs (or even scripts) you are using to achieve whatever task is at hand should of had the code looked over a million+ times by tons of people to make sure it isn't exploitable itself and isn't a trojan. Only a weak admin would blindly escalate privileges for a simple task or use an untested program with root.
- HappyScrappy, on 07/19/2009, -3/+10How's that?
If you have a fully-patched linux running SELinux (which is supposed to INCREASE security), you are susceptible.
Seems like the title is accurate to me. - Runningflame570, on 07/19/2009, -1/+8Because JaycobC is being a troll.
- sirhomer, on 07/19/2009, -0/+7@HappyScrappy
VMS's principal security difference between UNIX was the introduction of ACLs (access control lists). However, not too long after POSIX also standardized the use of ACLs (and Linux supports them), but they are rarely used, in favor of the older POSIX permissions system.
VMS never has had a mandatory access control system, and such functionality wasn't introduced to Windows until Windows Vista, but it has existed in Linux in the form of SELinux for quite awhile. - S1ngular1ty1, on 07/19/2009, -0/+7Any OS connected to the internet is inherently insecure. Only way to be 100% secure is to unplug, oh and not install any untrusted software.
There will always be unintended flaws in OSs or the software that runs on them. No OS is immune. - sirhomer, on 07/19/2009, -1/+8@HappyScrappy
Wrong.
All compilers will let you get away with that. A compiler can't know if any given pointer will be null at compile time. Hence the pointer of runtime null pointer checks.
Also if foo is a NULL pointer, foo->bar is not necessarily a NULL dereference. The -> operator is essentially a pointer arithmetic function, it takes the value of foo and adds some offset to it, then deferences it. So if foo is NULL (0), then foo->bar might be something else. - eropuri, on 07/19/2009, -2/+9I thought Linux, for example, has had fine-grained access controls in the kernel for years. A quick Google search suggests since 1999. So what the hell are you talking about? Why doesn't using capabilities suffice when it lets you, for example, to bind to a privileged port without jumping to root?
http://linux.die.net/man/7/capabilities - Darkhacker, on 07/19/2009, -0/+7I'm not one to question Torvalds, but I do have to wonder why someone would deference a NULL pointer before checking it. I just wrote up a test case and I was shocked to find that GCC didn't throw a warning on such code with -Wall. Interestingly, the code runs just fine when compiled normally. However, it segfaults when compiled in debug mode and valgrind reports a memory error on it.
Could someone be so kind as to explain why it's not a kernel bug? I'm sure there are other factors at play and other systems at fault too, but I've always been taught not to do this. - smacksaw, on 07/19/2009, -1/+7There goes PulseAudio being a pain in the ass.
ALSAtime! - m6ack, on 07/19/2009, -0/+6Actually... It's really a kernel bug -- not really a compiler bug.
int baz(struct something *foo)
{
struct child_of_something *foobar = foo->bar;
if (!foo) /* Compiler may optimize away. */
return AN_ERROR;
do_anything(foobar);
}
If you try to dereference first before the check, the compiler, that knows noting about what is going outside the function, says AH Ha... the pointer can't be null, because you just told me that it's safe, because you're using it already... So I can optimize out the check!
If bar is NULL, trying to dereference it is wrong, and will result in seriously broken code. You have to test your variable before the dereference... then the compiler will see that, yes, the null check matters because you haven't already screwed the pooch by trying to do something unsafe with it in the first place.
int baz(struct something *foo)
{
struct child_of_something *ok;
if (!foo) /* Compiler won't optimize away */
return AN_ERROR;
ok = foo->bar;
do_anything(ok);
}
Actually, one would hope that the compiler would be smart enough to realize what is happening throw a warning when it suspects this kind of a programming error... On the other hand, I suppose that there are so many warnings that show up during compile of the kernel that such would get lost in the sea.
Anyway, the interesting thing about this story is that a set of bug-fixes for NULL dereferencing in the kernel is already in the queue for release ~1 _day_ after this 0day was announced. I don't think we'd see that kind of a response out of any company driven OS. - 3242130193, on 07/19/2009, -0/+6You have a good point with setuid, then you just start talking out of your ass to lose all credibility.
Obviously, no admin or user will check every line of code that they install; but here's some news for you: there's a huge community of users that review code all over the place every day. Sure, not everything gets looked at, and even if it does, there are still exploits possible. At least the sources are usually trustable. Even if you install software from repos, you have no idea whether the precompiled packages are packaged as the source is written. If you're really that paranoid that you have to read every line of code in every program you install on your system, you're never going to get a damn thing done. But it's not necessary; what you're asking for security senselessly paranoid and laughingly impractical.
Linus himself has admitted that setuid is going to cause problems for a long time. But it's still the best security model in the business and any tool that thinks otherwise (especially the security through obscurity dumbasses) really doesn't have a clue about computer security. - mrsteveman1, on 07/19/2009, -0/+6Even if it doesn't require SELinux, the scope is still severely limited if only those running 2.6.30 are affected, there is a significant isolation going on here since not everyone runs the same version of the kernel.
- HappyScrappy, on 07/19/2009, -2/+8Wrong.
The code does
blah = foo->bar
if (0 == foo)
{
exit();
}
if (blah == somethingerother)
The code dereferenced foo before checking it. This is incorrect code. Yeah, some compilers would let you get away with this, but that doesn't mean you didn't write your code incorrectly.
x = x++;
is completely illegal, but some compilers will let you do it. So if you do this, does it mean it's the compiler's fault you did it? - HappyScrappy, on 07/19/2009, -4/+9SELinux is a start. The problem is that none of this is integrated into base UNIX (or linux), so it breaks all kinds of programs. Heck AFS only separated file permissions from setuid and it still broke all kinds of things.
It takes a long time to undo mistakes once they become systemic. UNIX isn't far down that path yet. - JQP123, on 07/19/2009, -1/+6I think you're right; however, I also think you missed his point.
If it's exploitable, shouldn't *someone* be pissed when it doesn't get attention? - Runningflame570, on 07/19/2009, -1/+6Haven't talked to many people who run Linux, have you BigVi? Nobody who knows anything would be so foolish as to say something like that. What is true is that Linux is MORE secure than the other popular OSes out there.
- theonlywizdum, on 07/19/2009, -0/+5It's foolhardy to assume that the subtle visual and audible clues that indicate sarcasm can be read over the internet.
- demonthises, on 07/19/2009, -0/+4I believe he was being sarcastic.
- thcobbs, on 07/19/2009, -2/+6Actually, it can occur with SELinux, AppArmor, OR non-enhanced systems.
- mrsteveman1, on 07/19/2009, -1/+5My point was, as everything is with security, the scope of impact is relevant. The impact of this exploit is going to be severely limited if it only applies to systems with SELinux enabled.
- ileftfark, on 07/19/2009, -1/+5Wow - SELinux actually allows PA or any user in unconfined_t map at 0. Reminiscent of the Cheddar Bay!
http://www.youtube.com/watch?v=UdkpJ13e6Z0 - Runningflame570, on 07/19/2009, -0/+4Actually OSX is both worse than Windows and Linux. That is pretty laughable considering how singularly focused on security BSDs can be oftentimes.
- m3arvk, on 07/19/2009, -0/+4Can't you just compile the code sans and use the "don't optimize" compiler flag?
- HappyScrappy, on 07/19/2009, -1/+5Well, let me put it another way.
When this problem is fixed, where will that fix be?
In the kernel. Because the problem was in the kernel. I guess you wouldn't have to worry about this kernel problem if you didn't have a single setuid binary on your system. But if you have one, due to this error in the kernel, you may be at risk. - mrBitch, on 07/19/2009, -0/+3RE: .. The bug requires physical access to the server, so no... it's not a huge security issue, or didn't you read the article?
FTA :
" .. By itself, Spengler's exploit does not work remotely."
Buried for facts? - rico169, on 07/19/2009, -2/+5I think, that if you look at things without the Linux-Rose coloured glasses, you will find that most Windows exploits take place AFTER Microsoft has already released the patch. People are usually either too lazy or ignorant to bother installing the patch provided OR they are using an illegal copy of windows. Boo hoo for the pirates.
-
Show 51 - 100 of 119 discussions
© Digg Inc. 2009
— Content created and posted by Digg users is