Slashdot Mirror
Mitnick on OSS
comforteagle writes "Infamous cracker Kevin Mitnick (turned security consultant) has come out to say that he'd prefer to 'hack' open source code vs proprietary closed code. "Mitnick says that open source software is easier to analyse for security holes, since you can see the code. Proprietary software, on the other hand, requires either reverse engineering, getting your hands on illicit copies of the source code, or using a technique called 'fuzzing'." He further says that open source is more secure, but leaves you wondering questions if enough people are really interested in securing open source code."
In other news, it's easier to see where you are going when you have your eyes open.
I figured I'd add a little more to how "fuzzing" works as the article left me a little disappointed as to what it actually is. There are a few things online about it, including a decent white paper written by Ilja van Sprundel. There's also a large amount of fuzzing going on to test the security of WAP. It's basically the standard buffer overflow attack.
... silently idling waiting to do it's malicious purpose ...
The crux of this attack is using a buffer overflow to gain superuser privileges. This might be trivial on Windows, so I'll relay the "la/ls" story to you regarding how to gain it in Linux. The part of this trick involves figuring out how to get an executable file from your machine to another user's machine. Let's say you know some company or institution is running a webserver on their unix/linux machines from a server and you go to visit their site. Now, their code isn't completely up to date and there's a security hole in one of their web applications. You know (after toying around with said web app on your home machine) that certain large chunks of hex in a field will result in a submission that essentially writes your binary to their $HOME directory. The name of this file will be, of course, "la."
Now hopefully their home directory is like mine and it's full of crap. So they'll never notice the "la" file but everyday they use that machine, they type "ls" to display the file. One day, their finger slips and they type "la" resulting in the execution of my binary. Instantly, another executable is written, this time called "ps" and a thread is started that simply spin locks on the processor--chewing up cycles. The machine might slow or freeze but an admin will notice this process and go into the users directory (as root) and type "ps -al" to see all the existing processes. Instead, it executes your "ps" virus and subsequently, the spinlocking stops with "ps" printed to output with the super user killing "la" and thinking everything is fixed. In the background however, the "ps" process is active
I'm sure there's a hundred things wrong with what I've said, I'm not a hacker--I just like to point out possible security holes.
Improbable but not impossible.
One more thing about the article, the beauty of OSS is that it is impossible to implement security through obfuscation--a major pitfall to security in application design.
My work here is dung.
Many of you may be unfamiliar with the term "fuzzing."
....
I was when I read the article and have done some research and fuzzing is:
What is fuzzing?
- Sending semi-random data to an application
- Semi-random: good enough so it'll look like valid data, bad
enough so it might break stuff
- When people hear "fuzzing" they imediately think http, THERE IS MORE TO FUZZING THAN JUST HTTP !!!
- You can fuzz:
-- Network protocols
-- Network stacks
-- Arguments, signals, stdin, envvar, file descriptors,
-- Api's (syscalls, library calls)
-- Files
In general, most of the time it is a waste of time, but if you are "lucky" you could find a vulnerability and maybe with a little more research a way to exploit the code.
More information can be found at this PDF Article - http://static.23.nu/md/Pictures/FUZZING.PDF (Very Large 90+ Pages)
Windows? I haven't used that since 1999. Fix the Slashdot Problems
He's got the same general (valid) outlook that the rest of us have: open-source code is easier to tinker with because you can see how and why it works. That is an intrinsic element of having open-source code.
Just because Mitnick has said what thousands - neigh - millions have said before, doesn't mean it's new and exciting. Doesn't make it news.
Informatus Technologicus
Once again proving his technical prowess!
http://religiousfreaks.com/> Anyone want to explain what this 'fuzzing' is?
For teenagers it means to skip shaving for a few days.
Not sure how that helps crack software, though. Maybe it gives you a 1337 look that inspires more experienced crackers to share their secrets.
Sheesh, evil *and* a jerk. -- Jade
To be honest, when you look at the incentive for securing OSS vs Closed Source code, neither one is all that enticing.
As of now, there's really no penalty with selling code that isn't secure. It's accepted (for some reason) that computer code will have holes, and you really, really have to have a horrible program before anyone will think of ditching it. Even then if it's mission critical (all the more reason to be secure) it seems people are loathe to switch to something else.
So as a coder for a Closed Source app., my motivations would be:
1. Make the boss happy. Get code done.
2. Once program A is done, start work on next money making program.
3. Patch when boss says it's necessary to patch.
For Open Source it's not that much better. The only real motivation to write good code is so that it's either accepted into the project in the first place, and then once accepted everyone doesn't poke holes in your crappy code.
The difference is that people coding OSS are doing it because they want to, so hopefully have a little more motivation to look at the other code in their project. It's interesting to them, so they're a bit more likely IMO to look at it. The person getting paid has no incentive to look at the code (at least while on work time) unless the boss tells them to. Since rehashing old code doesn't usually make money, the only time to look at old code is when a patch is a necessity.
Separated at birth?
He who knows best knows how little he knows. - Thomas Jefferson
I think I'd agree with Kevin if he said:
"I'd prefer to hack open source with FEW AUTHORS."
There's no doubt that lots of eyes and a security focus have helped Apache, but there's lots of open source shitware (for example, just Google up a list of PHP messageboards) that don't have basic input validation controls, require too much access to the operating system, use plain-text or unsalted MD5 passwords or contain other gaping holes.
Without those extra eyes helping out...yes, many open source projects are easier to hack than similar closed source projects.
Infamous cracker Kevin Mitnick (turned security consultant) has come out to say [...]
/.?
Why does race have to enter every discussion on
I'm sure there's a hundred things wrong with what I've said, I'm not a hacker--I just like to point out possible security holes.
Let's dive into what *is* wrong...
First of all, files in your home directory are normally not in your $PATH on any Linux system. Anyone who has their system set up like this, *let alone* having their $HOME have priority over /sbin and /usr/sbin, deserves to be shot.
Secondly, a webserver should (and does by default in any distro I know of) runs as the nobody/httpd/apache/someone user, and does not have a home directory. So any exploit in the web server would not allow you to write a 'la' binary anywhere.
Third, your whole attack scheme is just a big run around for no reason. If you can write a binary called 'la', why wouldn't you just write it as 'ls' in the first place, istead of crossing your fingers and hoping he mistypes? And if you can write a binary to disk, you can also obviously execute it, so why don't you? Why would you wait around? Is it because you hope someone is going to log in as root and run it? Because if that is the case, you will be way out of luck, because root *never* has $HOME in his path (and the webserver shouldn't be able to write to /root anyways).
This isn't how these kinds of attacks work... what *usually* happens is, the buffer overflow allows one to write and execute files as the unprivilidged user. The cracker attacks and does this to gaina remote shell on the machine, as this unprivilidged user. They then use this shell to try to find holes in other system services that may not be remotely exploitable, for example say mysql or postgresql. If mysql is running locally and not set up right, they could use it to gain full superuser privilidge by SELECT'ing to a file. Then, all bets are off.
Alexander "brunes69" de Large: Oy! Lookie what we have here, droogies
Droogies: [in unison] HE FORGOT ABOUT PERMISSIONS!
Alexander "brunes69" de Large: [bending over with his cane against his cod piece] That's right. And what happens to slashdotters we viddie that make mistakes?
Droogie A: We brow beat them into a bloody pulp
*Alex and the droogs continually beat the poor slashdotter while emitting "Singing in the Rain"*
eldavojohn: Please
My work here is dung.
Look, everyone knows that opening your source is a double-edged sword. It's not like your intent to open source summons the Buffer Overflow Fairy who magically waves their Valgrind wand and your code is perfect. The whole point is to get the bugs out in the open so that everyone can see them and patches can be submitted by a larger number of contributors. The idea is that it gets rid of the bugs faster.
The fact that Mitnik says this doesn't damage the case for open source at all. The Captain Obvious comments are just pointing out that Mitnik is just saying, "I like easier work over harder work." Or maybe, "It's really fucking tedious to analyze a binary without the source." Does that stop people from finding bizzare bugs in closed source code? Absolutely not.
Slashdot. It's Not For Common Sense
All of you who are commenting that this is an obvious idea may be missing the point.
;)
We all know that security through obfuscation in cryptography is stupid: peer review illuminates the crevices the architect never conceived. But is all open source code subject to this same sort of peer review? If you've ever worked on an open source project, how much time to do sit down and pour over the code looking for security flaws.
Essentially, it's the same problem with Wikipedia: peer-review requires 1) the skill of the peers matches or exceeds the skill of the author, and 2) peers are actually reviewing, and 3) peers are trustworthy. It's the second criterion that Mitnick was questioning.
What's more, since it seems like accidental (and very subtle) bugs result in most security holes that don't get noticed. Wouldn't it then be trivial for someone with a great amount of skill to simply insert a hole? Either by subtle manipulation of existing code or by direct implementation in a segment which they are responsible for coding. If its done well, the 'oops, coding error!' excuse could always be proffered in the event the tampering was detected.
If I wanted to attack a system which I knew ran on OSS (and I had mad coding skillz), I think I would try to obtain some method of working on one of their software packages. Either directly or by 'acquiring' someone else's permissions if that was easier. Then I would insert a piece of backdoor code in a little used (or often used-'hidden in plain sight') code segment. Once the next release is running on that system, exploit the code, and get out. Depending on my goals, the operation could very likely be done before a hole is found and a patch is issued. As a small bonus anyone else installing that software would have the same vulnerability. Of course, some user level app won't be able to induce this scenario, but you get the idea.
Proprietary software doesn't have this vulnerability in so much as the programmers are much more tightly regulated by a company who has legal and monetary interests in controlling its code base and holding its employees accountable. (whether this actually happens is another discussion)
For all the self-righteousness of the open source movement, I remain convinced that the primary reason that more open-source packages are not targeted for attack is because they are not an appealing target. Specific implementations are not in popular use (globally), or they are too close to home. Meaning its preferable to attack your enemy than your family.
Reminds me of the neat story (from Psychology of Computer Programming, I think) where a tiger team was trying to crack an installation's security (at the installation's request). Said installation ran IBM mainframes, and received patch tapes from IBM on a semi-regular basis. So the team wrote their own patch, put it on a tape, and sent it to the target along with a typical covering letter on IBM headed paper, and then waited for them to install their backdoor for them.
Which they did :)
Why would you listen to anything Mitnick has to say? His attacks were based on social engineering, and he got caught. He's missed nearly a decade of technological development, and he wasn't a technical genius to start with either. And if it hadn't been for Shimomura's and Markoff's success in manipulating and blowing the story out of proportion for their own fame and fortune, Mitnick wouldn't have been more than a footnote.
So when Mitnick says it is easier to hack OSS software, people say "duh"
When Microsoft says "making our stuff open source will make it easier to find vulnerabilities", people say "Stop FUDing, Microsoft"
I dont see how can you beleive it when Mitnick says it and how you can refute it when Allchin says the same thing.
My opinions are my own, and do not necessarily represent those of my employer.