Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Security Linux

Tool Kills Hidden Linux Bugs, Vulnerabilities 47

Posted by Soulskill from the cockroaches-hiding-in-your-tux dept.
mask.of.sanity writes with this excerpt from SC Magazine: "Australian researcher Silvio Cesare has released a tool capable of automatically detecting bugs and vulnerabilities in embedded Linux libraries. The script correlates vulnerability advisory CVEs for third-party libraries to determine if holes have carried over to Linux platforms or have not been patched. Such holes often escape the eye of developers because the libraries may not be kept updated with sources. This is further compounded because vulnerabilities in cross distributed packages can leave Linux platforms vulnerable."
This discussion has been archived. No new comments can be posted.

Tool Kills Hidden Linux Bugs, Vulnerabilities More

Tool Kills Hidden Linux Bugs, Vulnerabilities

Comments Filter:

  • And they're going to call the tool... (Score:2, Insightful)

    by Anonymous Coward

    "Regression Testing"

  • Hell Yes (Score:1, Informative)

    by Anonymous Coward

    Go Silvio. He use to hang out with the kids in b4b0. Glad he is still kicking around and being productive. He also published something pertaining to binary infection based on vulnerabilities in the elf format circa the early 00s.

    • Re: (Score:1)

      by Anonymous Coward

      Go Silvio. He use to hang out with the kids in b4b0. Glad he is still kicking around and being productive. He also published something pertaining to binary infection based on vulnerabilities in the elf format circa the early 00s.

      He was also very famous as a leader of the infamous GOBBLES hacking crew. Go Silvio!

  • 90% false positives?! (Score:5, Funny)

    by Cyko_01 ( 1092499 ) on Tuesday November 22, 2011 @06:59PM (#38142348) Homepage
    sounds like he needs to run it on his own code

    • Re:90% false positives?! (Score:4, Interesting)

      by Anonymous Coward on Tuesday November 22, 2011 @07:40PM (#38142818)

      Since his tool looks for vulnerabilities and not "bugs" (if you want to call them that), it would be pointless to run the tool on itself with the aim of reducing false positives.

      Also, to put that statement in context:

      "While about 90 per cent of vulnerabilities produced by the tool were false-positives, Cesare said vetting the results takes seconds and was considerably faster than using manual processes."

      That sounds like a worthwhile improvement, no?

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        I think what the grandparent meant is that a tool which reports 90% noise is a tool that people don't use.

        • So what it was just released the more this tool get used the less false positives you get in future version. Likely by whitelisting the recurring false positive.
        • My understanding is that most of the IA "scanning" tools out there have very high "false positive" rates, but that's because they're really designed to eliminate all "known good" and present anything slightly questionable to the user, as an alternative to purely manual review. So a 90% FP rate is not necessarily something that would prevent people from using the tool.
  • Turing Halting Problem, anyone?

    • Re:Automatically detect bugs and vulnerabilities?? (Score:5, Insightful)

      by jensend ( 71114 ) on Tuesday November 22, 2011 @07:31PM (#38142720)

      You probably already know this, but Rice's Theorem etc only apply to supposed decision procedures. It's quite possible to write a program which will often recognize that other programs have some nontrivial semantic property (halting, having a particular kind of bug, etc) and will decide correctly on a broad class of real-world programs. You just can't write one which will always give you a yes or no answer in finite time and always be right.

      • Re: (Score:1)

        by Anonymous Coward

        Theoretically you can. All physical machines are finite state machines, so you can enumerate all configurations (and hence, all bugs) in finite time.

        • Theoretically you can. All physical machines are finite state machines, so you can enumerate all configurations (and hence, all bugs) in finite time.

          ...but you can't write a *general algorithm* to do that.

          • Uh, yes. (Score:1)

            by Anonymous Coward

            The poster actually provided one. "Enumerate all configurations". Start in every possible start state, run the program and stop once the machine reaches a previously seen state (that'll be an infinite loop, so the machine will never halt given that program and input), or halts. Since the machine can only have a fixed number of states (finite size) either of those two things will within at most N steps, where N is some fixed (probably very very large) number.

            Of course if you actually had a machine large enou

            • Re: (Score:1)

              by Anonymous Coward

              You iterate every possible state... Tell me how you detect that a given state is an errant or "bug" state.

            • Re: (Score:3)

              by dkf ( 304284 )

              The poster actually provided one. "Enumerate all configurations". Start in every possible start state, run the program and stop once the machine reaches a previously seen state (that'll be an infinite loop, so the machine will never halt given that program and input), or halts. Since the machine can only have a fixed number of states (finite size) either of those two things will within at most N steps, where N is some fixed (probably very very large) number.

              Of course if you actually had a machine large enough (enough memory, CPU, etc.) to do that, you'd want to use that to actually run your program...

              Won't work.

              1. You underestimate just how much state will be required. Really. I've written code to do this sort of detection in the past (where the subject program was provably finite and small) and it took gigabytes of memory to tackle programs with only a few bits-worth of real state. (You can do better by working with a model of the program, but then you've got problems ensuring that the model actually correlates with reality.) Heck, I even found that Google's indexed the papers that I wrote on this and ha

            • Just saying that the machines it's running on will all be finite doesn't buy you anything over analyzing behavior on a TM with its infinite tape; you'd have to have a bound on the amount of storage available to all the computers it will ever run on.

              To put this another way: you could enumerate all the possible states it could enter when running on a particular machine. But that only tells you about the behavior of the program on that machine, not about the semantics of the program. The program could always b

  • The round 1 of security circus has begun. how many times we av been told that a single tool will detect the vulnerabilities and hidden bugs? and then some one exposes the tool or a vulnerability which is not discovered by the tool.then a new tool will emerge and the cycle repeats. "Given enough eyes all bugs are shallow "

    • Re: (Score:3)

      by wdef ( 1050680 )
      You're talking about snake oil tools from commercial interests. This tool doesn't detect bugs. It just looks for code similar to that of documented vulnerabilities from what I read. This cuts down the laborious business of trying to vetting code against thousands of advisories and reduces this to a list of possible matches. It doesn't remove the need for a real engineer to go over that list and check for false positives. But it's a huge improvement.

  • Forbidding embedded libraries is common on distros (Score:3, Informative)

    by Anonymous Coward on Wednesday November 23, 2011 @08:47AM (#38147230)

    At least Debian and Fedora, and likely every other non-shitty Linux distro *strongly* object to packages with embedded libraries, for exactly this reason: it is *unsanitary* and *dangerous*: it breaks the flow of security and regular bug fixes, and it greatly increases the exposure of users to both bugs and security holes.

    It gets so bad that Debian has a standing bad blood with the Ruby community because Ruby is "embedded third-party library hell", and therefore Debian maintainers either considers Ruby stuff unpackageable, or have to get in fights with upstream because they unbundle the libraries and suddenly upstream actually has to do its job and make sure their stuff works with more recent versions of the third-party libraries... (when it is an older version, that's a Debian bug).

    If you got games from the Humble Bundle 1 and 2, you likely know that *for up-to-date latest stable Debian, Ubuntu, Fedora...*, many of the SDL bugs related to sound and video are fixed by removing the libraries duplicated in the game tarball, so as to use the ones shipped by the distro...

  • When is he coming out with the windows one???

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close