Slashdot Mirror

← Back to Stories (view on slashdot.org)

Tool Kills Hidden Linux Bugs, Vulnerabilities

Posted by Soulskill on 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."

5 of 47 comments (clear)

  1. 90% false positives?! by Cyko_01 · · Score: 4, Funny

    sounds like he needs to run it on his own code

    1. Re:90% false positives?! by Anonymous Coward · · Score: 4, Interesting

      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?

    2. Re:90% false positives?! by Anonymous Coward · · Score: 3, Insightful

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

  2. Re:Automatically detect bugs and vulnerabilities?? by jensend · · Score: 4, Insightful

    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.

  3. Forbidding embedded libraries is common on distros by Anonymous Coward · · Score: 3, Informative

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