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.
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
> 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.
I'm sure there's a hundred things wrong with what I've said, I'm not a hacker
You mean, like what you said there :
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
Of course, unless the superuser deliberately destroyed the security of its Linux and added "." to his PATH, this would never happen, as it would not execute the "ps" in the user's directory.
But I see your point.
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.
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.
You can't believe it because you (1) are making up an argument for the aim to refute it, commonly called a strawman, and (2) treat a collection of people as an individual. (Is there a fallacy name for this too?)
/. users, you find both people who say "duh" in the one, and others who say "Stop Fudding" in the other story.
ad (1)
Mitnick did not say "it's easier to hack" (I assume TFA/you mean "crack" here) which would mean that it's easier to get unauthorized access.
In fact TFA quoted Mitnick as saying that finding vulnerabilities in OSS code is easier, since it's easier to analyze for holes. This is true for both black-hats and white-hats, so it gets evened out somewhat. On the other hand, finding holes in closed source is harder for black-hats, but fixing them is impossible for white-hats, so overall this might put black-hats at an advantage.
And you leave out that OSS is not just "GPL the source and put it on a server". Mature OSS projects generally are modularized well, because parallel development is greatly hampered otherwise. Closed projects tend to be much dirtier in this respect.
Incidentially, this separation also helps secure coding.
ad (2)
It should not be a surprise that among > 1,000,000
Actually, what happens is this:
Some people say "duh", because, well, duh, but you leave out the supporting argument that while Mitnick's assertion is obviously true, TFA left out the fact that it is easier to fix also.
Other people say "FUD", because they forget that Allchin is somewhat right: putting Windows in the open now, necessarily with insufficient preparation and code cleanup, would make it more insecure. But that does not mean that it couldn't be more secure had it been constructed in the open from the beginning.
And I can't believe there are idiots who modded you +5 Insightful.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns