No ELF Vulnerability in 2.6 Kernel

gaijincory writes "Greg KH, the co-maintainer of the 2.6 kernel has posted a comment on lwn.net confirming that there is indeed no such ELF vulnerability as spelled out by Paul Starzetz on isec. The bug was originally thought to be particularly nasty, allowing a malicious user to gain elevated privileges using a carefully crafted binary which would exploit the kernel's Executable and Linking Format. The bug's author confirmed that no one has been able to repro the exploit."

Comments

Oh _that_ makes sense

[/ASCII]

I saw this story on OSnews today, but they made it out to be about the Hyperthreading issue. But that didn't make any sense since that is not ans OS bug at all, but a hardware issue. (If it is evan an issue)

Why so confident?

[m50d]

They've tested it and been unable to reproduce the vulnerability. But vulnerabilities are tricky things. I'm glad they still bothered to patch the kernel.

If the tree falls in the woods, no-one hears it...

[meuon]

Is it a bug, if it can't be reproduced? Not yet, anyway. Did he really create this vulnerability problem, at least once? - so many people get sloppy on scientific method, conditions, variables.. and recording the details. Especially me. And what they think happened, did not.

Thoughts in my head at the moment...

[suitepotato]

First, the obligatory joke to set the questions:

According to Starzetz report, the flaw is in the function elf_core_dump(), (...)

That writes itself. Adding in references likening this to bears and woods is optional and subliminal.

Anyhow, if there is an ELF core dump bug and no one else steps in it, does it really matter? Did it really happen?

Do we dump the kernel, insist on a grooming of all ELF involved code, and rebuild and recompile?

What is the threshold anyhow for reproducing a bug? How many people must do it? If only one person reports activating the bug, do we ignore all their documentation of the event as if it was spurious because we couldn't do it? Do we wait till a malware write manages it?

What is the proper level of concern here?

Re:Thoughts in my head at the moment...

[r6144]

There is a bug if the code does not always work the way its author intended (i.e. it would bomb out if some more assertions are inserted). Sometimes the code still happens to work in all cases, but it is still prudent for the kernel developers to fix the code so that it is kept clean.

Of course, if the bug is not exploitable, system admins might delay updating the kernel if a reboot is inconvenient, but for kernel developers, every bug should be fixed whenever possible.

Re:If the tree falls in the woods, no-one hears it

[Richard_at_work]

Or it can simply be a fact that modern computer systems (both hardware and software) change states so much every second that its next to impossible to recreate the exact state required without having a rig that recorded the origional state and set it up as a test system. It could be a very obscure bug that requires some very exacting conditions that only occur extremely rarely, thats why noones been able to replicate it. Im sure that in the course of development, all programmers have come across a random one time only bug that causes you to shrug your shoulders, watch out to see if it ever happens again, but get on with life.

isec rules

[diegocgteleline.es]

They've discovered most of the linux kernel vunerabilities in the latest ~2 years or so, and they've always disclosed them friendly, so I don't think they deserve all this noise. It's better to think that there're vulnerabilities and fix them than the contrary.

Re:If the tree falls in the woods, no-one hears it

[Jeff DeMaagd]

What I didn't say is that there's a certain level of responsibility to the person reporting a problem. If they want a claim to fame, then they should be able to prove its existence, rather than making everyone else work furiously track it down, because for all anyone else knows, it could be a complete fluke at best, or at worst, a total fraud.

Re:If the tree falls in the woods, no-one hears it

[Creepy Crawler]

How very wrong..

A while back (in '92) there was the 'PS' bug.

Because ps lists full processor charts of whats running, how much cpu time, and how much mem used up, it requires root access (hence a suid root bit set).

When you run it, it would create a /tmp/.root/ps exec file that woukld then proceed to copy state from the kernel and then be read back into the real PS. This file would only last 1/1000 of a second before rm got it.

Now, how would you hack a system like this to get root? On this specific SUN system, /tmp did not have group sticky on and so it didnt control who overwrote others' files. Turns out if you do a timed attack (of calling ps, moving /tmp/.root/ps to your ~, and then edit it to be a shellscript that calls bash), root was easy to get.

Since this depended on a variable on state, you would run it in a script that called ps about 5000 times, and then BAMN! You have root.

I guess getting root isnt all that dangerous when you have to the attack some 5k times... Now is it?

Re:Many Exploits don't work as advertised

[HidingMyName]

The mostly likely one is that exploits are intentionally broken when released. The reasons why are numerous and have been discussed before. But it's common to find exploits that have intentional programming errors. Every so often, an exploit author will release a "working" exploit on BugTraq. When this happens, the author is typically flammed because he didn't break the exploit.

Unfortunately the effort of trying to find the bug is often large, and many times when I read the kernel or application code the claimed vulernability is not present in a version that the exploit writer claims is susceptible. Given the quality of exploit code I've seen written recently, it may be unintentionally broken :-). Remember, raising false alarms helps the bad guys, perhaps if they can't safely publish a working exploit they should not publish any.

Another common cause is the author didn't design the exploit to be portable. If the author returned to libc in the exploit and they wrote it on say a Slackware system, the exploit probably will not work as written on FC2.

But these authors make all sorts of claims about what environments are vulnerable, no?

There are times when vulnerabilities exist only when a complex list of environmental conditions are met. A certain kernel version, using a certain version of libc, compiled with a certain version of gcc with a particular compiler option, on a particular filesystem.....

That may be true. There certainlly is a need for a good test facility coupled with the repositories. Being fast and wrong in disclosing vulnerabilities is not nearly as helpful as being right.

Re:Many Exploits don't work as advertised

[iabervon]

Most likely, there is some other factor which is preventing the exploit from working. So the vulnerability is actually exploiting some bug, but then some other check prevents anything untoward from happening. Ideally, there would be some way of checking the integrity of a process or of the system, which would identify after the fact that an exploit violated the security model in some way that had little effect (e.g., a function returned to an unmapped address, indicating a stack attack failure due to randomized memory arrangement).

In most cases, anyway, a partial exploit leads to a child process segfaulting rather than exiting normally, which is a pretty good test; it indicates something's wrong, even if it doesn't matter for some other reason. (And it's always possible that there could be a way around the check that caught the first try)

It would also be nice if there was a kernel memory location for proof-of-concept exploits to write, and a root-only syscall to write it. That way, you could have a simple demonstration that an attack got to write kernel memory or got root, without needing to determine what the exploit does, how to verify that it needs to work to do it, and how to clean up after it to try again.