Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Tool Kills Hidden Linux Bugs, Vulnerabilities

Soulskill posted more than 2 years ago | from the cockroaches-hiding-in-your-tux dept.

Operating Systems 47

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

cancel ×

47 comments

Sorry! There are no comments related to the filter you selected.

Linux has no vulnerabilities (-1, Troll)

CmdrPony (2505686) | more than 2 years ago | (#38142032)

So why release this?

Re:Linux has no vulnerabilities (-1)

Anonymous Coward | more than 2 years ago | (#38142048)

Ponies!

Re:Linux has no vulnerabilities (-1)

Anonymous Coward | more than 2 years ago | (#38142066)

Fuck yeah, ponies.

Re:Linux has no vulnerabilities (-1)

Anonymous Coward | more than 2 years ago | (#38143762)

Balogna pony.

Re:Linux has no vulnerabilities (0)

Anonymous Coward | more than 2 years ago | (#38142058)

Dear Troll, what part of "bugs and vulnerabilities" can not you comprehend?

Re:Linux has no vulnerabilities (0, Troll)

Baloroth (2370816) | more than 2 years ago | (#38142072)

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

Re:Linux has no vulnerabilities (0)

ozmanjusri (601766) | more than 2 years ago | (#38142154)

Re:Linux has no vulnerabilities (-1)

Anonymous Coward | more than 2 years ago | (#38142280)

^pedophile

Re:Linux has no vulnerabilities (0)

Anonymous Coward | more than 2 years ago | (#38144800)

^Microsoftie

Re:Linux has no vulnerabilities (0)

Anonymous Coward | more than 2 years ago | (#38142278)

lessee, openssh uses openssl libs, a problem in the libs works up
to the apps, developer forgets to update libs - root!
not theoretical

Re:Linux has no vulnerabilities (-1)

Anonymous Coward | more than 2 years ago | (#38142364)

Pull your head out of your ass, Linux has no flaws!

Re:Linux has no vulnerabilities (-1)

Anonymous Coward | more than 2 years ago | (#38142588)

Blatant Microsoft FUD! Don't fall for it!

Re:Linux has no vulnerabilities (-1)

Anonymous Coward | more than 2 years ago | (#38142780)

lessee, openssh uses openssl libs, a problem in the libs works up
to the apps, developer forgets to update libs - root!
not theoretical

Nice to see that our little MS apologist has returned. How does it feel to suck ballmer's cock all day long?

Re:Linux has no vulnerabilities (-1)

Anonymous Coward | more than 2 years ago | (#38144398)

How much do you get paid to post your drivel?

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

Anonymous Coward | more than 2 years ago | (#38142070)

"Regression Testing"

It apparently shut down his website... (0)

ameen.ross (2498000) | more than 2 years ago | (#38142092)

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

Hell Yes (1, Informative)

Anonymous Coward | more than 2 years ago | (#38142190)

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:Hell Yes (1)

Anonymous Coward | more than 2 years ago | (#38142470)

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!

Re:Hell Yes (0)

Anonymous Coward | more than 2 years ago | (#38143780)

1. elf binary infection papers were cutting edge at the time
2. he was not a leader of gobbles.

Re:Hell Yes (0)

Anonymous Coward | more than 2 years ago | (#38145244)

you're wrong, he also lead el8 and is a current member of zf0/geist

Re:Hell Yes (0)

Anonymous Coward | more than 2 years ago | (#38145296)

This is so wrong it's not funny =/

Re:Hell Yes (0)

Anonymous Coward | more than 2 years ago | (#38144408)

we're still on efnet btw, but it's kind of dead (old b4b0 member)

Great too for DoD (-1, Offtopic)

mmontuori (2508452) | more than 2 years ago | (#38142228)

I think DoD will love this tool and start using it as a requirement for systems... http://www.montuori.net/ [montuori.net]

90% false positives?! (4, Funny)

Cyko_01 (1092499) | more than 2 years ago | (#38142348)

sounds like he needs to run it on his own code

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

Anonymous Coward | more than 2 years ago | (#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:90% false positives?! (3, Insightful)

Anonymous Coward | more than 2 years ago | (#38144728)

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

Re:90% false positives?! (1)

madhi19 (1972884) | more than 2 years ago | (#38145934)

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.

Re:90% false positives?! (2)

arkenian (1560563) | more than 2 years ago | (#38146174)

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??? (1, Insightful)

mark-t (151149) | more than 2 years ago | (#38142472)

Turing Halting Problem, anyone?

Re:Automatically detect bugs and vulnerabilities?? (4, Insightful)

jensend (71114) | more than 2 years ago | (#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:Automatically detect bugs and vulnerabilities?? (1)

Anonymous Coward | more than 2 years ago | (#38143344)

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?? (2)

seandiggity (992657) | more than 2 years ago | (#38143556)

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. (1)

Anonymous Coward | more than 2 years ago | (#38143750)

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

Re:Uh, yes. (1)

Anonymous Coward | more than 2 years ago | (#38144392)

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

Re:Uh, yes. (2)

dkf (304284) | more than 2 years ago | (#38153248)

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 had published 14 years ago.
  2. 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.

Not really. (1)

jensend (71114) | more than 2 years ago | (#38155626)

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

Re:Automatically detect bugs and vulnerabilities?? (0)

Anonymous Coward | more than 2 years ago | (#38143960)

The technique the GP is referring to sounds a lot like model checking [wikipedia.org] . 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?? (0)

Anonymous Coward | more than 2 years ago | (#38144540)

The input to a program is modelled as an infinite vector, therefore the set of possible configurations is still infinite.

Silvioooooo (-1)

Anonymous Coward | more than 2 years ago | (#38142576)

http://www.quickmeme.com/meme/35c9tt/

security circus (1)

sunr2007 (2309530) | more than 2 years ago | (#38145112)

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:security circus (2)

wdef (1050680) | more than 2 years ago | (#38146664)

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.

Re:security circus (0)

Anonymous Coward | more than 2 years ago | (#38146874)

"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 (0)

Anonymous Coward | more than 2 years ago | (#38146376)

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 (3, Informative)

Anonymous Coward | more than 2 years ago | (#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...

what about windows (1)

hesaigo999ca (786966) | more than 2 years ago | (#38147884)

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

Re:what about windows (1)

pimpsoftcom (877143) | more than 2 years ago | (#38149682)

No it would be worthless since it would just detect every file as insecure.

Re:what about windows (1)

hesaigo999ca (786966) | more than 2 years ago | (#38150110)

LMAO!

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>