Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Bug Software Linux

No ELF Vulnerability in 2.6 Kernel 86

Posted by Hemos 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."
This discussion has been archived. No new comments can be posted.

No ELF Vulnerability in 2.6 Kernel More

No ELF Vulnerability in 2.6 Kernel

Comments Filter:

  • No ELF vulnerability eh? (Score:5, Funny)

    by NightWulf ( 672561 ) on Monday May 30, 2005 @11:13AM (#12676530)
    What about the DWARF and GNOME vulnerabilities though? Eh where's your answer now Greg?

  • Oh _that_ makes sense (Score:5, Interesting)

    by /ASCII ( 86998 ) on Monday May 30, 2005 @11:13AM (#12676532) Homepage
    I saw this story on OSnews [osnews.com] 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? (Score:5, Interesting)

    by m50d ( 797211 ) on Monday May 30, 2005 @11:14AM (#12676537) Homepage Journal
    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 made it work by running:
      # echo 992FE4:336FF00 > /dev/kmem
      as root.
      • Don't do that.
        • Actually, it doesn't do anything on Gentoo 2.6 on AMD64. I'm sure it used to in the 2.4 days. Instant hard lock. Although, thinking about it - it might be part of the GRSec restriction [grsecurity.org] I have compiled into the kernel - to disallow things from writing to /dev/kmem.

          [ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port

          Nope, didn't choose that option.

      • Re:Why so confident? (Score:5, Funny)

        by maxwell demon ( 590494 ) on Monday May 30, 2005 @12:32PM (#12676988) Journal
        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 :-)
        • Instead of bothering with your whole disk, if you just upgrade the first 512 bytes of the disk, you get the same effect. Try
          dd if=/dev/zero of=/dev/hda bs=1 count=512
          Of course, I don't recommending doing anything you learnt from a webpage unless you fully understand what it does.
          • The sad thing is that if everyone took your recommendation then nobody would understand the things they find on webpages.
          • Do NOT do this. The first 512 bytes of a hard drive make up the boot sector of the drive. If you do what he showed you, it will overwrite the boot sector of the hard drive in question (In this case /dev/hda, the master and first hardrive on the first ide channel). This would make the computer unbootable!

  • If the tree falls in the woods, no-one hears it... (Score:4, Interesting)

    by meuon ( 888133 ) on Monday May 30, 2005 @11:16AM (#12676554) Homepage
    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.

  • The bug's author? (Score:5, Funny)

    by Looke ( 260398 ) on Monday May 30, 2005 @11:24AM (#12676585)
    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 ...

  • Huh (Score:1, Funny)

    by Anonymous Coward
    "The bug's author confirmed that no one has been able to repro the exploit"

    That's really comforting.
    • Most importantly, can the bug's authour able to reproduce the exploit? And if so, under what conditions? Shouldn't this be the subject of a report rather than an article?

  • Thoughts in my head at the moment... (Score:3, Interesting)

    by suitepotato ( 863945 ) on Monday May 30, 2005 @11:34AM (#12676650)
    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... (Score:4, Interesting)

      by r6144 ( 544027 ) <r6k&sohu,com> on Monday May 30, 2005 @12:03PM (#12676814) Homepage Journal
      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.

  • As an Elf... (Score:5, Funny)

    by Zakabog ( 603757 ) <john.jmaug@com> on Monday May 30, 2005 @12:04PM (#12676815)
    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.

  • isec rules (Score:4, Interesting)

    by diegocgteleline.es ( 653730 ) on Monday May 30, 2005 @12:18PM (#12676901)
    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.

  • Many Exploits don't work as advertised (Score:5, Informative)

    by HidingMyName ( 669183 ) on Monday May 30, 2005 @12:24PM (#12676931)
    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).

    • one thing i think is an issue is its hard to make exploits that work against a range of kernels as offsets etc change. but with some effort most of them could be adapted to other kernels which have the bug but need slightly different numbers to exploit it.

      its not like the ms world were there are very few builds all released by ms. with linux anyone can make thier own build and its very likely that an exploit will need tweaking for each one.

      • one thing i think is an issue is its hard to make exploits that work against a range of kernels as offsets etc change. but with some effort most of them could be adapted to other kernels which have the bug but need slightly different numbers to exploit it.

        It is hard to say, the exploits are typically released with mysterious hard coded values in them, with no documentation of how those values are computed. Also many exploits claim to exploit race conditions. Often, the vulnerability these folks write

    • Re:Many Exploits don't work as advertised (Score:4, Insightful)

      by tiny69 ( 34486 ) on Monday May 30, 2005 @01:16PM (#12677221) Homepage Journal
      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.....

      • 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 t

      • When this happens, the author is typically flammed because he didn't break the exploit.

        Important coded is being maintained by flim-flam artists?

        :)
        hawk

    • 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 random
    • ... or even more evil, a certain proprietary source company paying people who know what they are doing to write passable exploits that don't actually work, flood us with these and Linux starts to look less and less secure in comparision with their numbers of security vulnerabilities.
  • All I can say is, some jerk bit my 2.4.21 system with this bug. This past week has not been a happy week for me.

    --Quentin

    • Re:2.6 may be fine, but 2.4 isn't (Score:1, Informative)

      by Anonymous Coward
      Probably not this bug, anyway. 2.4.21 is extremely old (will be 2 years old in two weeks time), and has a number of other vulnerabilities (including several other elf bugs). Step into 2005, upgrade to 2.4.30 :-)
  • I read ELF as "Extremely Low Frequency" and was thinking "how can a really slow clock lead to an exploit?" Then I read the bleeping header...

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close