Slashdot Mirror


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

86 comments

  1. Hold on CowBoy by Anonymous Coward · · Score: -1, Offtopic

    Give us some time to read the earlier stories first. Why is H posting another story in less than 15 minutes ?

    1. Re:Hold on CowBoy by Anonymous Coward · · Score: 0

      5 minutes to be precise. May be world is coming to an end and Hemos want to post as many stories he can before it.

  2. 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 smittyoneeach · · Score: 1

      Someone should have a DROW with him.

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    2. 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
    3. Re:No ELF vulnerability eh? by Taladar · · Score: 1

      Especially since Dwarfs and Gnomes are smaller than Elves and thus fit through smaller security holes...

    4. Re:No ELF vulnerability eh? by tanek · · Score: 2, Funny

      Aw come on, don't be such a TROLL.

    5. Re:No ELF vulnerability eh? by maxwell+demon · · Score: 1, Funny

      Well, let's see if I can get a cheap Karma, too :-) (However I guess it will just end up Funny with several Overrateds ...)

      GNOME (GNU Network Object Model Environment) is a desktop environment.

      GNU of course is short for GNU's Not Unix, so the second-level expansion of GNOME is GNU's Not Unix Network Object Model Environment. Which indeed is a true statement, since GNU indeed is no Unix Network Object Model Environment.

      Of course recursive expansion of GNU does no good. GNU's Not Unix Not Unix doesn't make much sense. GNU's Not Unix Not Unix Network Object Model Environment doesn't sound any better.

      BTW, are there any GNU vulnerabilities in the Linux kernel? You know, I'd not like to have a wounded GNU in my computer. It would only give me trouble with the animal welfare activists. Of course DWARF vulnerabilities could cause trouble with Amnesty International, so it's also something you really want to check.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    6. Re:No ELF vulnerability eh? by Anonymous Coward · · Score: 0

      Don't forget OGRE (http://www.ogre3d.org/)

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

    8. Re:No ELF vulnerability eh? by Anonymous Coward · · Score: -1, Troll

      Someone should have a DROW with him:

      http://www.geocities.com/angiemtg/

    9. Re:No ELF vulnerability eh? by Anonymous Coward · · Score: 0

      And GNO/ME is a Unix-like environment for the Apple IIGS (see here).

      I think there might also be some kind of program launcher or something for Unix called GNOME which is newer, not sure. :-)

    10. Re:No ELF vulnerability eh? by Anonymous Coward · · Score: 0

      Does that mean that DWARFs are in alliance with ELFs agains GNOMEs?

    11. Re:No ELF vulnerability eh? by Ramscoop · · Score: 1
      Hmmm... Does my name, then, make me vulnerable?

      /Stefan Elf (really!)

  3. 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.
    1. Re:Oh _that_ makes sense by Erik+Hensema · · Score: 1

      Indeed, osnews clearly has the two issues confused.

      --

      This is your sig. There are thousands more, but this one is yours.

    2. Re:Oh _that_ makes sense by Anonymous Coward · · Score: 0

      evan?

      You must mean "even", but then again, English is probably not your primary language.

    3. Re:Oh _that_ makes sense by /ASCII · · Score: 1

      Thank you captain obvious

      --
      Try out fish, the friendly interactive shell.
  4. Repro? by Anonymous Coward · · Score: -1

    Is it that hard to spell out reproduce? Even though that's something many on Slashdot will never do.

  5. 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 caluml · · Score: 2, Funny
      I made it work by running:
      # echo 992FE4:336FF00 > /dev/kmem
      as root.
    2. Re:Why so confident? by tehshen · · Score: 1

      Don't do that.

      --
      Guy asked me for a quarter for a cup of coffee. So I bit him.
    3. 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. Re:Why so confident? by caluml · · Score: 2, Funny
      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.
    5. Re:Why so confident? by shaitand · · Score: 1

      The sad thing is that if everyone took your recommendation then nobody would understand the things they find on webpages.

    6. Re:Why so confident? by caluml · · Score: 1
      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 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.
    7. Re:Why so confident? by Anonymous Coward · · Score: 0

      For the uninitiated, this wipes your MBR/partition table. Generally not recommended.

    8. Re:Why so confident? by pimpsoftcom · · Score: 2, Informative

      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!

      --
      - d
  6. FP! by Anonymous Coward · · Score: -1, Troll

    yay! FP!

  7. 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 -
  8. How does this happen? by Anonymous Coward · · Score: -1, Offtopic

    Well, if the cable modem (router/gateway I assume) has a firewall, it will obviously block all invalid packets, and sometimes DoS attacks.
    Otherwise, all (I think) cable modems / routers will give away their IP, BUT they should all protect the users behind them, through natting or dhcp.
    But even then, the machine behind can be targeted using various techniques (one is to exploit the router itself).

    If you're not talking about a router, then yes, the IP of the Windows machine (like linux) is exposed which means anyone can run checks and such on services which are vulnerable.

    But then it really depends on how up-to-date your windows machine is. It's still highly unlikely that it'll be exploited, unless someone (clueless person) clicks on a link to activate a virus or such through an email, or activates a service for back-door entry.

    BTW, note that the jpeg flaw was fixed very quickly, and most machines weren't vulnerable anyway (such as mine).

    Windows XP is actually very stable, supporting multiple networked users (multi-user and multi-tasking), but lacks in that all accounts by default have admin privilege(!). And that is mostly the reason behind all the viruses, spyware and auto-spam-servers.

    Besides all that, since most Windows vulnerabilities aren't based on a kernel attack (unlike linux), but instead the services you have activated, you can simply disable the ones you don't need, and just be sensible about which applications you open through emails (hopefully none!).

    But even after all that, a user can come along and browse the web using IE and activate some activex component, or installs some other IE component or JScript which allows entry to the machine.

    If the user isn't using IE and isn't running a server (such as httpd), then it's quite unlikely that anything bad will happen. Unless someone specifically targets the machine and scans for all activated services, etc, and launches an attack against an un-patched vulnerability.

    I would be brave enough to state that a Win2k / WinXP / Win2003 is just as secure as UNIX / FreeBSD / OSX, if: -

    * The user using the machine doesn't have admin rights,
    * Windows and related networking software is kept up-to-date,
    * Doesn't use IE / related mail product.

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

    1. Re:The bug's author? by Anonymous Coward · · Score: 0

      A career choice made by a large portion of Microsoft's employees...

    2. Re:The bug's author? by Anonymous Coward · · Score: -1, Troll

      Man, are you ever witty. Ripping on MS is so original.

      What do you define as a large portion anyway? MS employs 40,000+ people, many of which have nothing to do with actual code. I find it hard to believe that they write bugs.

      But that's fine. You keep on using your bug-free whatever it is that you use. If you're that naive to believe something is bug-free just because it's not from MS, perhaps you should take a cyanide breathmint.

      And please don't bother me with the fix cycle. I don't care how quickly other people patch bugs. You're the one that insinuated MS is the only group of people that write bugs.

    3. Re:The bug's author? by Jace+of+Fuse! · · Score: 1

      Shhhhhhhh!!! That's secretly what MANAGERS are doing, and all this time you thought they were totally worthless!

      --

      "Everything you know is wrong. (And stupid.)"

      Moderation Totals: Wrong=2, Stupid=3, Total=5.
  10. Huh by Anonymous Coward · · Score: 1, Funny

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

    That's really comforting.

    1. Re:Huh by Anonymous Coward · · Score: 0
      lol, I don't know which part of that sentence to bitch about first.

      I guess no one has re-achieved professional status through this exploit. Does bug-authoring pay well these days?

    2. Re:Huh by Anonymous Coward · · Score: 0

      Does bug-authoring pay well these days?

      I'd say yes. :o)

    3. Re:Huh by ThePromenader · · Score: 1

      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?

      --

      No, no sig. Really.

      ThePromenader
  11. and there was NO head in a bag by Anonymous Coward · · Score: -1, Troll


    [ominous music]
    June the 4th, 1973, was much like any other summer's day in Peterborough,
    and Ralph Mellish, a file clerk at an insurance company, was on his way
    to work as usual when --- [da dum!] Nothing happened! [dum dum da dum]
    Scarcely able to believe his eyes, Ralph Mellish looked down. But one
    glance confirmed his suspicions. Behind a bush, on the side of the road,
    there was *no* severed arm. No dismembered trunk of a man in his late
    fifties. No head in a bag. Nothing. Not a sausage. For Ralph Mellish,
    this was *not* to be the start of any trail of events which would not, in
    no time at all, involve him in neither a tangled knot of suspicion, nor
    any web of lies, which would, had he been not involved, surely have led
    him to no other place, than the central criminal court of the Old Bailey.
    [muttering voices, Judge's gavel banging.]

    But it was not to be [ominous music returns]. Ralph Mellish reached his
    office in Dulls-ells Street in Peterborough, at 9:05 a.m., exactly the
    same time as he usually got in!

    [door opens]
    "Morning, Mr. Mellish"
    "Morning, Enid"

    Enid, a sharp-eyed, clever young girl, who had been with the firm for only 4
    weeks, couldn't help noticing the complete absence of tiny but tell-tale blood
    stains on Mr. Mellish's clothing. Nor did she notice anything strange in Mr.
    Mellish's behavior that whole morning. Nor the next morning. Nor at any time
    before or since the entire period she worked for that firm.

    "Have the new paper clips arrived, Enid?"
    "Yes, they're over there, Mr. Mellish."
    [faintly] "Oh..."

    But for the lack of any untold circumstances for this secretary to
    notice, and the total non-involvement of Mr. Mellish in anything illegal,
    the forweight of the law would insure that Ralph Aulds Mellish would
    have ended up like all who challenge the fundamental laws of our society.
    In an iron coffin with spikes on the inside.

    -- MPFC

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

  13. linux for boisterous wackos by Anonymous Coward · · Score: -1, Troll

    It is imperative that I give you the following information, which linux wants concealed from the public. First off, the real question here is not, "To what degree is linux going to tell everyone else what to do?". The real question is rather, "Why doesn't it point a critical finger at itself for a change?" As you ponder the answer to that question, consider that it hates it when you say that it feels obligated to erect a screen of flatulent verbiage to hide the real world from its victims. It really hates it when you say that. Try saying that to it sometime, if you have a thick skin and don't mind having it shriek insults at you. I have never been in favor of being gratuitously ultra-loquacious. I have also never been in favor of sticking my head in the sand or of refusing to create a world in which expansionism, autism, and antidisestablishmentarianism are all but forgotten. As amazing as it seems, there is still hope for our society, real hope -- not the false sense of hope that comes from the mouths of what I call politically incorrect caustic-types, but the hope that makes you eager to lend support to the thesis that its op-ed pieces prove that it did little to no research before concluding that it can walk on water. In all fairness, linux will stop at nothing to leach integrity and honor from our souls. This may sound outrageous, but if it were fiction I would have thought of something more credible. As it stands, I challenge linux to point out any text in this letter that proposes that its expedients provide a liberating insight into life, the universe, and everything. It isn't there. There's neither a hint nor a suggestion of such a thing. I can guarantee the readers of this letter that if Fate desired that linux make a correct application of what it had read about parasitism, it would have to indicate title and page number, since the Pecksniffian, violent organization would otherwise never in all its existence find the correct place. But since Fate does not do this, linux is a faithful student of Sun Tzu, the ancient Chinese strategist who advocated demoralizing one's enemy as the highest art of warfare. Whatever weight we accord to that fact, we may be confident that I would be grateful if linux would take a little time from its rigorous schedule to improve the lot of humankind. Of course, pigs will grow wings and fly before that ever happens. While I agree with others' assessment that linux would rather talk about making changes than actually make them, still, I correctly predicted that linux would extinguish the voices of opposition. Alas, I didn't think it'd do that so effectively -- or so soon.

    Linux's callow newsgroup postings can be quite educational. By studying them, students can observe firsthand the consequences of having an organization consumed with paranoia, fear, hatred, and ignorance. Prudence is no vice. Cowardice -- especially linux's lethargic form of it -- is. Essentially, I want to make this clear, so that those who do not understand deeper messages embedded within sarcastic irony -- and you know who I'm referring to -- can process my point.

    Linux is so intolerantly devoted to its own prejudices that its perception of reality is thoroughly warped for a variety of reasons. For instance, it's linux's belief that my letters demonstrate a desire to concentrate all the wealth of the world into its own hands. I can't understand how anyone could go from anything I ever wrote to such an illaudable-to-the-core idea. In fact, my letters generally make the diametrically opposite claim, that I'm willing to accept that as linux feels less and less need to conceal its zingers, it makes increasingly open moves towards loathsome gnosticism. I'm even willing to accept that its representatives are the carrion birds of humanity. But it is not uncommon for it to victimize the innocent, penalize the victim for making any effort to defend himself, and then paint the whole repugnant affair as some great benefit to humanity. I am not in any way placing the blame on linux for boisterous wackos who pre

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

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

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

    1. Re:isec rules by Anonymous Coward · · Score: 0

      In fact they've found 10 out of the last 9 vulneratbilities.

  17. 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 petermgreen · · Score: 1

      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.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    2. 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)
    3. Re:Many Exploits don't work as advertised by Anonymous Coward · · Score: 0

      This is most likely because FC2 uses a no-exec stack and address randomization.

      Exploits released to the lists are for generic linux systems without these protections.

      Don't worry though, you will still be owned, but just not by public exploits.

    4. Re:Many Exploits don't work as advertised by HidingMyName · · Score: 1
      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 about seems plausible. Other times these folks just make wild claims about what kernel versions they think are vulnerable but when I go read the kernel source I see that the vulnerability was closed. There is definitely a need to standardize testing and analysis of exploit code and vulnerabilities, and a need for places that publish such data to vet their data, to screen out the poseurs and focus on the credible security researchers.
    5. Re:Many Exploits don't work as advertised by HidingMyName · · Score: 2, Interesting
      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.
    6. Re:Many Exploits don't work as advertised by iabervon · · Score: 2, Interesting

      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.

    7. Re:Many Exploits don't work as advertised by zygut · · Score: 1

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

    8. Re:Many Exploits don't work as advertised by hawk · · Score: 1
      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

  18. 2.6 may be fine, but 2.4 isn't by CoolQ · · Score: 2

    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

    1. Re:2.6 may be fine, but 2.4 isn't by Anonymous Coward · · Score: 1, Informative

      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 :-)

    2. Re:2.6 may be fine, but 2.4 isn't by MerlinTheWizard · · Score: 0

      2 years may be extremely old for the Linux kernel, but it's like brand new for any Windows kernel...

    3. Re:2.6 may be fine, but 2.4 isn't by Anonymous Coward · · Score: 0

      Isn't the Windows kernel patched every two weeks?

    4. Re:2.6 may be fine, but 2.4 isn't by MerlinTheWizard · · Score: 1

      Nope, I think it's once a month, at most. And it's not particularly the kernel that gets patched, but various components. I believe the kernel itself is hardly ever modified...

  19. Re:If the tree falls in the woods, no-one hears it by Eternally+optimistic · · Score: 1

    It could also be that the original analysis as wrong, and the priviledge escalation was due to the exprimental setup, not a problem in ELF.

    --
    What keeps me going is my inertia.
  20. What about 2.4??? by Anonymous Coward · · Score: 0

    Has anyone confirmed the bug in 2.4?

  21. Re:If the tree falls in the woods, no-one hears it by JFitzsimmons · · Score: 1

    If the conditions for an exploit are so specific that is is hard to create them even if you're trying then the exploit isn't all that dangerous...

    --
    Beware he who would deny you access to information, for in his heart he dreams himself your master. -Anonymous
  22. "no one has been able to repro the exploit" by Anonymous Coward · · Score: -1, Flamebait

    Shouldn't that be:

    "no one has been able to repro the 'sploit"

    Just to get all your leet abbrev's in one sentence.

  23. Re:If the tree falls in the woods, no-one hears it by Anonymous Coward · · Score: 0
    "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."

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

  24. V2.6 kernel of what? by Anonymous Coward · · Score: 0

    Yes I know the whole world revolves around Linux, but it would still be nice if articles like this wouldn't just take for granted that everyone knows what they're referring to, when it isn't named anywhere.

  25. Bug author == programmer by Urusai · · Score: 1

    And I call it job security, FYI.

  26. Re:If the tree falls in the woods, no-one hears it by Jeff+DeMaagd · · Score: 1

    If it really is a bug, then the people that claim its existence should devise a more reliable means of replicating the bug.

  27. Re:If the tree falls in the woods, no-one hears it by Jeff+DeMaagd · · Score: 2, Interesting

    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.

  28. Paul's earned the benefit of the doubt by Anonymous Coward · · Score: 0

    Paul has found a metric shit-ton of extremely subtle and interesting flaws in Linux. If you google for ihaquer@isec.pl, you'll see that he's a world class security researcher. I don't know him personally, but as someone who does this kind of research for a living, it's obvious to me that he has the right mix of technical acumen and destructive creativity necessary for doing high-end vulnerability research.

    All I'm saying is that if he's wrong, then no one should begrudge him a mistake in light of his other findings. That said, he's probably not wrong.

    1. Re:Paul's earned the benefit of the doubt by tota · · Score: 1
      I agree, he has come up with some very interresting bugs in the past. It is just that this one is not one of them.


      It is a shame to see that this bug prompted the immediate release of a new 2.6.11.x stable series patch, when other real bugs did not and took over 10 days from discovery to patching. (see latest .11)...

      I don't think that the new and improved stable release system is working perfectly yet.

      --
      TODO: 753) write sig.
  29. 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.

  30. Re:If the tree falls in the woods, no-one hears it by Creepy+Crawler · · Score: 2, Interesting

    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?

    --
  31. what about by Anonymous Coward · · Score: 0

    But what about all of those a.out vunrebilities that are out there right now

  32. Re:If the tree falls in the woods, no-one hears it by Mornelithe · · Score: 1

    Yes, but most people don't follow every clever little maxim to their potentially absurd logical conclusions.

    --

    I've come for the woman, and your head.

  33. Re:If the tree falls in the woods, no-one hears it by SumoRoach · · Score: 1

    You just described an exploit where the situation was *easy* to create and the poster was talking about a situation where the situation was hard to create.

  34. Re:If the tree falls in the woods, no-one hears it by Creepy+Crawler · · Score: 1

    There was the same obfusication in both. Timing based attacks are 'not cool' unless used in conjunction with other security measures.

    In the most likelyhood, some idjit will think this is 'security' and secure a telnetd on a port. Then when they're hacked, oh-nos! Thats when they realize from the logs the attack came from within the ISP. Big surprise.

    Anyways, I'd prefer to use standard queries for networks and not have everyting hidden... Having sshd running with no key-sharing is plenty secure enough for me (well, with obvious nsa-patches.. heh heh heh).

    --
  35. Yet another case of too many TLAs by Mark+of+THE+CITY · · Score: 1

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

    --
    The clearance system sounds logical. It is not. It is completely arbitrary. -- John Bolton
    1. Re:Yet another case of too many TLAs by Anonymous Coward · · Score: 0

      Surely you mean YAC OTM TLA's ?

  36. Re:Random one time bug by RedLaggedTeut · · Score: 1

    Yea, in fact I have come across "random one time bugs" that caused me "to shrug my shoulders" and most of the time they turned up again in the last days before I had to deliver the project, which I wasn't always succesful at.

    --
    I'm still trying to figure out what people mean by 'social skills' here.
  37. Re:If the tree falls in the woods, no-one hears it by Anonymous Coward · · Score: 0

    You just described an exploit where the situation was *easy* to create

    If you know the reason it worked in the first place, yes. If there is a one in a 5000 timing chance it will work and you don't know it, recreation becomes a bit more frustration

  38. The user.. by Anonymous Coward · · Score: 0

    " a malicious user "

    Do we know the identity of this malicious user? If so, can't we just "fix" him? :)

  39. Re:If the tree falls in the woods, no-one hears it by Anonymous Coward · · Score: 0

    You missed the point grasshopper. It's a comment on perception, not reality.

  40. Re:If the tree falls in the woods, no-one hears it by shaitand · · Score: 1

    Arguably, the world would be a very different and much improved place if they did.

  41. Re:If the tree falls in the woods, no-one hears it by Mornelithe · · Score: 1

    Well, I suppose all Christians would be blind and handless, so it's a start.

    --

    I've come for the woman, and your head.