Slashdot Mirror

← Back to Stories (view on slashdot.org)

No ELF Vulnerability in 2.6 Kernel

Posted by Hemos on from the good-news-bear dept.

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."

16 of 86 comments (clear)

  1. No ELF vulnerability eh? by NightWulf · · Score: 4, Funny

    What about the DWARF and GNOME vulnerabilities though? Eh where's your answer now Greg?

    1. Re:No ELF vulnerability eh? by mikrorechner · · Score: 5, Informative


      Just FYI:
      DWARF (Debug With Arbitrary Record Format) is a format for debugging information for ELF files.

      (Yes, I know the parent is joking.)

      --
      "Oh, a lesson in not changing history from Mr I'm-my-own-Grandpa." - Dr Hubert Farnsworth
    2. Re:No ELF vulnerability eh? by CamilaAcolide · · Score: 4, Funny

      Ahhh, just like old times... "MY DWARF IS GONNA DEBUG THAT ELF!" "OK, ROLL 1D20" ... "YOU MISSED, THAT ELF HAS NO VULNERABILITIES!!"

  2. Oh _that_ makes sense by /ASCII · · Score: 5, Interesting

    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)

    --
    Try out fish, the friendly interactive shell.
  3. Why so confident? by m50d · · Score: 4, Interesting

    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.

    --
    I am trolling
    1. Re:Why so confident? by maxwell+demon · · Score: 4, Funny

      Hmmm ... this gives me an idea. You can extend a file from the shell by using the >> operator on it. Maybe I might be able to double my memory for free by just doing cat /dev/kmem >> /dev/kmem.

      This technique could have other uses as well. Your hard disk is too small? Well, double your hard disk space with cat /dev/hda >> /dev/hda. You can even make a floppy as large as your hard disk by typing cat /dev/hda >> /dev/fd0!

      Well, actually I think I'll make my main memory and disks grow infinitely:

      cat /dev/zero >> /dev/kmem & cat /dev/zero >> /dev/hda &

      SCNR :-)

      --
      The Tao of math: The numbers you can count are not the real numbers.
  4. If the tree falls in the woods, no-one hears it... by meuon · · Score: 4, Interesting

    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.

    --
    Mike Harrison -
  5. The bug's author? by Looke · · Score: 5, Funny
    Who's "the bug's author"? He who discovered it or he who wrote the code?

    "I'm a bug author. Today I've written five bugs!" Sounds like a nice career choice ...

  6. Thoughts in my head at the moment... by suitepotato · · Score: 3, Interesting

    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?

    --
    If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
    1. Re:Thoughts in my head at the moment... by r6144 · · Score: 3, Interesting
      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.

  7. As an Elf... by Zakabog · · Score: 4, Funny

    Speaking for myself, and elves everywhere, this is great news. I can finally use my favorite OS without worrying about any attacks I'm opening myself to.

  8. Re:If the tree falls in the woods, no-one hears it by Richard_at_work · · Score: 4, Interesting

    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.

  9. isec rules by diegocgteleline.es · · Score: 3, Interesting

    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.

  10. Many Exploits don't work as advertised by HidingMyName · · Score: 5, Informative
    Our research group works in intrusion detection. As part of our research we wanted to generate host based intrusions in a Linux environment (Linux 2.6.2 kernel running on Fedora Core 2 without security patches applied).

    We found that almost all the exploits we tried did not work as advertised. Yet the security advisory lists blindly post these as if they work. While the design/implementation issues may be present in a range of kernels, I'm beginning to think that these exploits are not vetted, and that the exploit writers look for a possible weakness and publish a piece of software that sort of pokes at it and claim success. It is very frustrating, since if the vulnerability can be exploited, a bogus exploit gives a false sense of security (since you can't compromise the system using it).

    1. Re:Many Exploits don't work as advertised by tiny69 · · Score: 3, Insightful

      There are several possible causes for this.

      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.

      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.

      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.....

      --
      Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
  11. Re:If the tree falls in the woods, no-one hears it by shaitand · · Score: 3, Insightful

    'I had a project manager once who had a saying: "If it didn't happen twice, then it didn't happen once."'

    Was he a zen monk? If you follow that philosophy then all occurances are first occurances and therefore never happen, causing the next occurance to again be the first.