Slashdot Mirror
SecurityFocus Responds To ESR Column On OSS Security
RabbitInTheMoon writes: "Elias Levy, moderator of BUGTRAQ and Chief Technology Officer of SecurityFocus.com has written an article about Open Source Software security in response to the recent message from ESR published here. He makes some very interesting points. Maybe this will clear up some of the misconceptions about open source security. "
Elias Levy seems to be saying that security through obscurity does work, because he thinks that everyone is lazy/dumb.
Personally, looking at the evidence of the last few years, I'm not so sure I agree with him. Yes, *theoretically* open source software could go unfixed for a long time, but what we have seen is that it seems to be much more common for closed source software to have holes in it for years.
Regarding his point that black-hats will find the holes in open source: who do you think is finding the holes in closed source stuff? I'd still rather have the "window of opportunity" be of shorter duration, and I think I get that with open source.
Open source is not a panacea, but it's still safer in the long run, IMO.
New XFMail home page
/bin/tcsh: Try it; you'll like it.
What the article omitted is the issue of how quickly bugs get fixed. Certainly patching things on the fly is much easier with open source, and there are alternate ways to get fixes. This, of course, can be a weakness, if you're not careful who you get your fixes from. But overall I think it's a strength.
Re sendmail and the DEBUG (and WIZ) commands: those commands were quite well known in the 1980's, but one has to look at the times to understand the issue in context. Until the Morris worm, people never really paid too much attention to back doors; the Arpanet was much more of a friendly club than the Internet of today. Also, sendmail wasn't really open source back then anyway; the vendor supplied it as a binary (often with proprietary extensions). You could plug in your own version of sendmail if you were motivated to, but you'd often lose something in the process, such as YP username resolution or some such. I still remember binary patching sendmail to turn off the DEBUG and WIZ commands because they were so obviously braindead (no particular kudos for that; just find the DEBUG and WIZ strings and overwrite them with nulls).
I don't think that "more people checking source" = "more out there introducing bugs". Most people who hack the source are doing it for their local site. They may well be introducing bugs, but they're not spreading very far. Certainly they're not likely to propagate back to the master source tree, assuming that the people controlling the master source are anywhere on the ball. Most people also don't need to get open source packages via back channels; it's just too easy to get it officially (most of the major Linux distributions include a ridiculous number of packages). One can argue about where they get their source -- with some validity, at least in principle -- but for players such as Red Hat, SuSE, and the like they employ enough known clued people so that there's a good chance that they're getting their software from reasonably trustworthy sources. Along those lines, I'd be more worried about warez; that always comes from back channels, and there are too many places where it's easy to stick nasties on (just do a rogue installer that installs a virus along with the real package).
Aside from moral issues, the problem with vetting access to open source software is the usual chicken and egg problem. How do you verify someone's bona fides if they don't get a chance to do something in the first place? For the maintainer of a package deciding whether to accept a change it's reasonable that that maintainer use whatever standards he or she wants. For simply inspecting the code, or making local modifications, why go through all this?
I'd like to point out a few problems with your comment.
The Gauntlet firewall published by Trusted Information Systems was not an Open Source program. It's what we call "disclosed source-code", and that's very important because that difference means that nobody had much reason to read it or work on it. The software license didn't provide them any incentive to do so - you would have only been fixing bugs in a program that somebody else has an exclusive right to sell. Who wants to be the unpaid employee of another company? With real Open Source, you have the same right to sell the program as anyone else, or to distribute it for free, for that matter, and thus you aren't some company's unpaid dupe. For an explanation of what Open Source is, see The Open Source Definition .
At the time of the Morris Internet worm, the BSD software distribution of which Sendmail is a part was under a restrictive license and required an expensive ATT Unix license before you could get the system. This is also not what we today know as Open Source. Besides, you are writing about the epochal Internet virus, and few people even considered Internet security before that event.
Yes, all compilers have a bootstrap problem. One can avoid it by compiling the compiler with another compiler, once in a while, and then compiling the result with itself. This method can also be used to detect the Trojan: compare the generated executable with one that doesn't have another compiler in its heritage - if there's a significant difference, look for a Trojan there.
Most users do not compile their own applications, but they get them from a trusted source who has compiled them and cryptographicaly signed them. You might not be aware that in all Linux distributions of any import, the packager does compile all programs. If there is a trojan slipped in, you can trace it to the person who compiled the program and bring charges if necessary.
And what good would it do anyone to grep through source code for strcpy()? We've already done that ourselves, and have fixed obvious problems.
Sure, it's no guarantee, but it's much better than the alternative, which lets Microsoft embed snide comments (if they really aren't trap-doors, embedding a trap-door would be as easy) in their software and have them undiscovered for years.
Bruce Perens.
As far as the Open Source advocates go, I generally find ESR the most levelheaded. ESR is probably right insofar as a blatant backdoor with "Netscape engineers are weenies!" would never escape scrutiny in something such as the Linux kernel. However, his claims were a bit too broad to be digested meaningfully by the masses. Levy addressed ESR's claims. Levy was not claiming "security through obscurity" in and of itself is sufficient. Quite the contrary, he said that many black hats can operate a hex editor and find bugs that way. What he did say was that closed source can offer a significant obstacle to discovery of trivial bugs by black hats. Although it might be obvious when you think about it, many Open Source people hold it as an article of faith that if you take the same source, any source, and Open Source it, it automatically becomes effectively more secure in, say, 6 months. This is simply not the case when you look at the empirical evidence. In other words, if you own some source code to an application, "opening" your code may hurt or it may help your effective security. The change in security is contingent on the specific situation.
For example, do you really believe that Mozilla is any more secure than Netscape? It obviously contains hundreds of thousands of bugs still. Open source has yet to resolve even more obvious stability bugs, so I think it is reasonable to assume there are significant security issues there as well. Not enough qualified people are truely spending the time to examine and fix it. So what we have is source with bugs, but a situation where any blackhat hacker can run grep/sed/awk/perl/etc on it to look for trivial bugs. If this same source were closed, it _would_ raise the bar for creating a viable exploit significantly.
On the other end of the scale, we have something like Linux's kernel. Thousands of qualified people really do work and look at the code. The size is managable. The code is easy to understand. The code is modular. All this works in Linux's favor. I sincerely believe the Linux kernel in and of itself (e.g., not the thousands of binaries that come with Linux distros) to be more secure than NT's.
To make a long story short, the change in security is contingent on the situation. That being said, I do think Open source affords significantly improved security against highly systematic attacks against dedicated attackers. The more reviewed Open source code (e.g., Linux) is at the very least a moving target. The odds of a single blackhat exploiting a bug en masse before the thousands of white hats can close it is quite slim. In other words, although Linux and NT may appear equally secure today, this is just against your average black hat. Your average black hat really isn't all that intelligent or motivated. So Microsoft can afford much less secure code due to their closed source nature and still maintain apparently equal security. Some organization, let's say the KGG, could throw enough brains at Microsoft binaries to create a program to silently scan and backdoor every Microsoft server on the internet, using this as a gateway to more sensitive internal company data (e.g., many companies have worthless firewalls)...A few admins may notice something foul, but many don't fully understand the security model. Fewer yet have the skill to reverse engineer such an attack even partway. And virtually no one other than the big bad evil blackhat group would have the resources or the time to create a working exploit. Consequently, Microsoft can never be made to look sufficiently foolish to force them to do anything. Operations cannot shut down just because of suspected bugs. It would continue getting exploited.
The bottom line is that apparent security (e.g., the number of known NT exploits vs known Linux) and ultimate security (in scenario's such as the one described above) are different....
...gotta run. bye
Yeah, this article says nothing we don't already know.
Yeah, no kidding. But when the source is closed, I guaranteeno one is reading it. Just because the author and many of the developers he knows are not over-conscientious and don't read the source doesn't mean that there aren't many of us out there who do. I personally review the code to almost every piece of software I use regularly, to the best of my ability. Yeah, I may not be "qualified" to "judge" something like Sendmail, but at least I can have the piece of mind that its developers are not trying to pull a fast one on me, as Microsoft did. If I don't feel "qualified" to judge some code, I reread it until I am. Maybe that's just me. No wait, that's not just me -- that's a lot of people out there, and that's why open source works.
And leaving your car parked in a parking lot makes it easy for car thieves to find. What is that supposed to mean? The issue is not, and never was, the "bad guys" finding vulnerabilities. Last thing I heard, the bad guys find vulnerabilities in closed source stuff all the time. The issues are prevention and the ability to fix bugs as they are noticed. I can fix the bugs myself if I find them, I can apply patches myself, I don't have to wait for a new version or a binary patch to replace the compromised DLL's or shared library.
darren
Cthulhu for President!
(darren)
One interesting, and usefull, thing to do would be to intentionally put a harmless (say deleting a specific file that has almost no chance of existing like /usr/adfasdf.txt) peice of malicious code in one of the large open-source software packages such as Apache or Samba. Depending on how active the development is the code may be found in a day, or a year or even more. No-one knows as this has never been done before. But someone should try, if only to test if the usual security through peer-review will work at all.
After that a similar test (perferably a whole bunch to be statisticly valid) on some closed source software would be in order. Any MS programmers here?