Domain: shellcode.org
Stories and comments across the archive that link to shellcode.org.
Comments · 9
-
Re:Suuuuure
All the bugs I find and report which result in Advisories are as a result of source code auditing.
It looks like I made the CERT list a couple of times, e.g. uw-imapproxy.
But these bugs are trivial things in applications which are either "extra", or not typically installed.
Fixing bugs in programs is important, but having a list of 500 simple buffer overflows in rarely used games (for example) on Linux says nothing about the relative security of Linux vs. Windows.
The worlds are too different, comparing every application included in Debian, say, against Windows would only make sense if you installed every single shareware/freeware/optional piece of software on the windows machine - and that clearly isn't a real world scenario.
-
Re:What!?
True, and the original poster seems to foolishly believe that ASCII text can't be used to exploit a buffer overflow. Firstly, it can (random googled link), and secondly, you can send anything you want over the network, whether the spec says "binary data" is OK or not, unless there's some kind of filter that only lets certain types of bytes through.
-
Re:Why not just look at this?
This is good too, generic examples for many OSs
-
Oooh wonder how well this works ..
I audit code for fun, write exploits to see if things are practical.
I'm also hirable - reckon my chances will go up if I write a mass mailer?
;) -
Re:Odd they bring this up now
That's not entirely true, there are many tutorials on discovering and exploiting security holes on Linux / Unix platforms.
Everything from the classic Smashing The Stack For Fun And Profit paper to more recent ones.
Bugtraq deliveries daily reports of exploitable flaws in software lots of it for Unix systems - granted that few people use most of the toy packages which people post bugs for, but they still exist and it's still mostly trivial to discover them.
I audit code and it's depressingly easy to find flaws in Unix software.
-
Re:Hmm ...
I audit code and have found lots of problems in games.
Whilst they might seem trivial there are good reasons for patching them.
Consider a game which is exploitable to gain gid(games) and can modify the highscore file, then wonder if the proven buggy game doesn't check the scores properly - I could be in a position to run code whenever you run the code to show the high scores.
This takes the exploit from boring gid(games) to more interesting "become anybody who runs the game".... and sets up the route to a local root!
Other times its more simple, some binaries are installed writeable by GID(games) so subversion is trivial
.. -
Re:Just goes to show...Combing through code looking for buffer overflows is tedious and repetative. How many programmers really do it all the time, every time?
I don't know about programmers, but I've been Auditing Debian Packages for security holes for a good few months now.
You are correct, it's tedious, dull, and repetitive - but its nice when you get a good result.
-
Re:The article is definitely correct! yay!
Frankly I cannot believe that exploits are harder to find or write than they used to be.
I've been auditing Debian source code for a few months now and I'm still finding trivial bugs that have security impact.
Sure it's much easier for me to do this as I have the source code available, but I bet that people skilled in assembly language armed with a good decompiler would have a similar score against binary targets.
I've even been writing tools to allow this kind of binary scanning (again for Linux and Debian especially) so it could well be the case that people with little assembly language could be doing it.
-
Re:Not enough eyes to make the bugs shallow...
Except, noone wants to audit code.
Some people still want to audit code.
Although it has to be said it's not something many people have the time or patience for.