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/Famous hacker says it's easier to find holes when they let you look at the source! News at 11!
:-)
Is this really all that suprising? If you've got a mentality of "how can I break this?" it's much easier to figure out how if you can look at how it's built. Unfortunately, having a hacker able to look at a system is not the same thing as having the original designers catch the issue. If you wait until hackers get ahold of it, they'll find ways to exploit the problem before the patch is in wide distribution. That's what makes this dangerous.
Thankfully, the majority of those who are looking at the code have less selfish reasons, and are happy to share any issues they see. Thus the "many-eyes" philosophy depends heavily on the good will of the common man. Personally, I wouldn't have it any other way.
Javascript + Nintendo DSi = DSiCade
> 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.
Oh, really? I think so.
In this day and age with all of the security problems (especially with MS), OSS trying to gain market share, I'd think that every OSS coder would be really mindful of any potential holes. Especially if he knew that another developer would be looking at it. I would be really embarassed (if I were a developer) if I got an email saying something to the effect of "Hey dumbass, nice job of preventing buffer overflow there at line: xxx in abcdef.c! Don't worry, no one will EVER exploit that hole!"
Infamous cracker Kevin Mitnick (turned security consultant) has come out to say [...]
/.?
Why does race have to enter every discussion on
The dude was a social engineer. I've seen no evidence that he ever wrote an exploit himself.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
We all have seen how difficult it is to hack Microsoft's closed-source, proprietary code.
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.
I fail to understand the obsession with hackers and security!
These people are like art critics.
They can't write great code themselves so they pick apart other peoples. A valuable niche job to be sure, but not deserving of some sort of "star" status of their own.
Why is there not more attention on the great developers? I don't see many interviews of kernel devs......
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.
Now, for what it's worth, much that seems obvious isn't true. It seems like a good notion that open software allows people to more easily figure out how to fix holes. This is certainly true. However, it also makes it easier for hackers to find holes as well.
The fact is, assuming we had two nominally identical projects, one closed-source and one open-source, bugs would be easier to find by *everybody,* good and bad. The question, which Mitnick alluded to, is this - are there sufficiently more good-guy" eyes on the code to ensure that bugs are found/fixed more quickly, to account for the fact that bad guys can find bugs faster?
The answer to that question isn't a guaranteed "Yes." In many cases it works, but I don't think in all. I realize that people around here like the notion of free software. I do too. But that doesn't mean that it works in practice the way it does in theory. We have to actually question how many people are actively maintaining the code compared to how many "bad guys" are looking to exploit it. I think for most projects this ends up working for us, but it's not guaranteed.
In other words, taking for granted that OSS is more secure because it's OSS is a dangerous mistake.
Mr. Mitnick is forgetting that most people want to see the proprietary software code because it is closed to prying eyes. Where as OSS being open to everyone is less appealing. And any issues that need to be fixed will be in a shorter time due to more people around the globe working on it. Where as with Proprietary software you have a small team working on it. They also have the added task (in Microsoft's case) of it having to be test on many different systems due to the large and various types of machines the software is being run on.
"Mitnick was arrested in 1995 by the FBI for hacking. He served five years in prison, including eight months in solitary confinement after it was alleged that he could launch nuclear missiles by whistling into a telephone." ...following the previous 40 years of whistling past the graveyard to deal with nuclear missiles.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
You exposing your entire source code for public scrutiny, and this is more secure the closed proprietary software?
How and why?
I think people are deluded into thinking that because a project like Linux is secure, and that Linux is Open Source, ergo Open Source software must be secure. This is convoluted and dangerous logic.
I think OSS is the most insecure software out there. Think of it. Anybody could take RedHat's source code, create their own distro filled with back doors and zombie daemons, and then distribute this OS supposedly under the guise of a secure RedHat release. This goes with any of the countless personalized Linux distros out there. Same goes for Open Office, etc, etc, etc. If you are not careful (and it is easy not to be careful when OSS is distributed largely with P2P software and bit torrents), you can end up purposely installing a corrupted OS or application whose code base as been hacked INTERNALLY and exposes your data to great risk.
Also, your security protocols and measures are all exposed to public scrutiny. Perhaps among the Open Source community that this exposure allows them to create more secure software, by collectively working to plug holes and make the code base rock solid. But this ignores the fact that people with the same skill set but with vastly different intentions can use the same source code to FIND holes and to WRITE exploits using the original source code as its base. Wouldn't it be more difficult to find a security flaw if it uses the original source code as its base.
I just never bought the whole OSS is more secure then proprietary software bit. The fact you have to reverse engineer proprietary software (which is full of guess work) and THEN start to find ways of exploiting it suggests proprietary software is more secure by obscurity. I think people are just making assumptions based on the fact that Windows, a closed OS, is not secure, thus closed software is less secure. Its the same mistake as assuming OSS is more secure because Linux is more secure. OS X isn't open source (for the most part) and it is secure.
In the end, I think that if someone truly wanted to target OSS and make it a victim of hackers they would more easily find exponentially greater security flaws and deliver more damaging payloads simply by the fact they can use the ACTUAL code as a basis for their attacks. OSS has the benefit of being treated with respect by the hacker and OSS communities, its a hobbyist community after all, why sabotate your favourite pasttime? But if OSS produces the dominant OS and applications of choice for the corporate and government communities I think this whole myth of OSS as being more secure will be ended, very quickly.
I haven't thought of anything clever to put here, but then again most of you haven't either.
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.
Why do people listen to Kevin Mitnick on technical issues? He never once wrote a single line of code. He never once used anything he himself had created. All he was good at was using other people's tools, making hime a glorified script kiddie with connections to get the tools he needed. The only difference between him and your average script kiddie is he had specific targets that usually had something he wanted which motivated his attacks, instead of just randomly hitting vulnerable systems.
He proved he was a moron when he used the same MIN/ESN pair for his OKI the entire time Shimomura was tracing him down.
Remember the Alamo, and God Bless Texas...