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. "
Read the article. Clicked on the link.
Guess what ad the page displayed?
"You may want a security package.
You don't know how it works.
(In fact, nobody does.)
Maybe you would prefer a trustable one.
It's...
Nessus.
Free.
Open-sourced.
..."
The words are not right, but the idea is there.
Roland.
Gotta love paranoia. But I agree, it is very easy to hide a backdoor in closed source, but certainly not impossible to hide one in open-source. I think the easiest would be, being a little careless on getting the bounds on a buffer exactly right, then you have a nice little buffer overflow that no one yet knows about, and when found, is attributed to mistake rather than malice :)
I don't see where he's saying this. He's instead saying that open source doesn't guarantee that bugs will be seen, or that being seen they will be fixed. Both very important caveats to ESR's open source propaganda, IMO.
Score:5???
It is certainly true that open source projects seem to have less bugs than closed source ones, but that doesn't matter in the computing industry. As a consultant researching the freeware phenomenon started by Linus Torveldes and his operating system Linux, I read Slashdot to get "inside info" on the open source community. However the level of naivety about the computing industry displayed here does sometimes drive me to post, as I am doing now.
The fact of the matter is, CTOs at most companies don't care about issues of ideology. They have no idea about who Richard Strawlman is, and they don't care either. What they want from software is someone to blame when things go wrong. This is why they choose Windows as a platform for their mission-critical enterprises, because it has the backing of a major corporation who can provide the illusion of safety. They don't care about how many bugs there are, they just want that support from a trusted source.
This is why open source will not truly flourish in the computing market. Your average CTO will not want to use a piece of software for their mission-critical systems that has the image of being supported by a group of long-haired, bearded hippy hackers who are engaged in all kinds of illegal penetrations into other people's data. This may not be true, but it's what they will think.
The solution - open source projects need to gain respectiblity by incorporating under the law. This would get them the trust of tech-savvy computer people everywhere, and allow them to become respectable solutions for the industry.
Unless you read and understand the source code, at the level of a security genius, there is no difference between downloading a package, and typing ./configure --prefix=/usr/unsecure/bin; make and downloading a binary image from slashdot's secret warez trading forum
Lets face it, none of us sysadmins ever read the code that deeply. I remember once finding a security bug in the md5getty program, where it actually rendered the system less secure than the standard getty. This was after we had been running it for weeks. It only showed up after I noticed wierd log messages, pointing to a root exploit based around the use of the "system" system call.
My point is, security is not free, it is something you need as a matter of policy. You also need some very good legal backup for when things get nasty, and if you use open source software for mission critical apps, believe me, things WILL get nasty.
thank you
ESR forgot to mention one of the strongest sides of OSS: when there's a flaw in the security, you can fix it. And even when you can't there are always others who will do it for you. Even if you read from every damn newspaper on the Earth that a Microsoft product you're using has a backdoor, you can't do anything about it except upgrading to Apache.
LinuxToday has a little piece by ESR where he acknowledges that it's not really a backdoor as ZD and the experts who found it said. But the point of his original article still stands, security through obscurity doesn't work.
You missed the point about the Thompson's trojaned C compiler. It was designed not only to insert a backdoor into /bin/login whenever it detected that it was being compiled, but to insert this backdoor producing code into cc itself, if it detected that cc was being recompiled.
Thus Thompson could distribute clean source, but still guarantee that the trojaned binaries would propagate, since you had to use his trojaned cc binary to compile a (trojaned) cc binary from (clean) source.
Now if someone had compiled Thompson's cc source with a *different* C compiler, the resulting binary would have been clean. But at the time, his compiler was the only one available.
--
Now I DO know how to code. I'm taking my super-happy C++ coding classes in high school, so I know my way around a compiler and the like. So, after reading this article, I thought "hey, lets see if I can understand this NOW!" Guess what? It's still spaghetti code. I still can't unstand a stick of it, other then the PRINTFs and SCANFs. That's it. And I got a 98% in the class.
Being able to read other people's code is not a skill that I think is taught well, or indeed taught much at all.
I've been working as a programmer for 5 years now, and have developed a pretty good knack for reading and figuring out code. Which is good, because where I'm working now, we have code (ugly code) lying around that's 18 years old. I don't even know if the authors are still alive - they sure aren't still working here, though!
But this skill is purely something I've developed through experience. I did a CompSci degree at uni - we wrote lots of code, and we learnt a lot of interesting and useful things. But we never did anything along the lines of learning how to read code. So don't feel too bad if you haven't learnt that in your high school C++ classes.
It's a shame..
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.
I work on a closed source project. Part of our process is to have a code review. I've been part of them, and I've had them done to my code.
Now this isn't as extensive as the theroitical work that could be done to closed source, it is more then the simple evaluation would inditcate.
Of course we are an exception. One of our old alpha testers went elsehwere, and she described her expirences as follows "They came ot me and said 'Two weeks in test! thats the longest anything has been in test, ship it'. 'Ship it, there are still bugs.' 'Yeah, but we know where they are.'" The project I'm working on was just shipped last week, and it spend 8 months in test. To get out of test that quickly we had to ship with a long list of bugs. We are not any worse then anyone else at coding.
Our test process is made much easier in that this is release 1.0, and we designed the hardware from the ground up. If we had to support as many different PCs as say linux or NT does, out test process would be much longer.
The claim is not that peer review sets up a magic world where only the kind of heart will discover security holes. Rather, it is that one is not at the mercy of the vendor once the vulnerability has been discovered. Nor is anyone at the mercy of the vendor when the product's architecture is found to be its greatest vulnerability. Moreover, with the source out in the open, the vendor can't deny the existence of the vulnerabiliy.
To me, all of the white-hat peer review is just one feature of many that leads to greater security in the free software universe.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
This is actually something I've thought about a lot. I'm involved in an Open Source security company (www.Protectix.com) and we produce network security appliances. It turns out that in this business, the licenses and warrantees specifically say that the company is not liable for basically *anything*. Obviously, that's suboptimal for the consumer, but in today's litigious society it seems that everyone specifically disclaims all "fitness for purpose", etc implied warrantees. There are insurance companies that are getting into the intrusion and loss insuring business, but their number crunchers are having a hard time coming up with a reasonable model for loss probabilities and amounts due to lack for actuarial data on this sort of thing. I think that some day you may see security companies offering an insurance policy along with their service, underwritten by the big insurance houses. That is likely some years away and will initially be quite pricy, IMHO.
This is not to say that companies don't care about the customer's security! The security business is reputation-dependant and companies will do everything they can to make sure the customer (and their reputation) is defended.
Mark
Mark
1) Is anyone readining it?
The evidence says yes. There was an attempt to post a trojan in open source recently (I lost the URL- help, anyone?). It lasted _ten_ _hours_ before it was discovered. And this question applies doubly so to closed source- as not just anyone can read it, only employees can read it. And most companies that I know of don't implement any sort of code review, so often a peice of code is only ever read by one person.
2)
Are they qualified to review the code? Some yes, some no. Once again, the exact same question can be applied to close source. Opps, most closed source isn't reviewed, even by unqualified programmers!
3)
It's easy to hide vulnerabilities in complex, poorly documented source code. This I'd agree with- especially _unintentional_ vulnerabilities. On the other hand, it's also hard to _maintain_ such code- and in the open source world, over time it tends to get reimplemented. Sendmail worries you? Try using smail or qmail instead. And, if anything, complex, poorly documented source code is more likely in closed source projects where the assumption that only the original writter will ever see the code, and as they already understand it, comments and simplicitly are optional. Besides, writting comments and refactoring code takes time, and I have a deadline this week...
4)
There is no strong gaurentee that source code and binaries have any relationship. Ah yes, Ken Thompson's paper. Thompson's paper assumes only one compiler, ever. You always compile gcc with only gcc- never Sun's cc, or IBM's xlc. It also assumes that any version of the compiler will recognize any other version of the compiler- so gcc 1.0 would recognize the source code to gcc 2.4, AND be able to insert the back door correctly into the produced binary! It'd also have to recognize the source code to tools like objdump and gdb as well, and insert the proper back doors into _them_ as well. I knew Ken Thompson was legendary- but this defies the imagination.
And, once again, there's no evidence of this on the closed source world either. Prove to me that Visual C++ isn't inserting back doors into Windows...
5) Open source makes it easy for the bad guys to find the vulnerabilities.
I was wondering when this chestnut would show up. The implicit assumption here is that the bad guys can't disassemble code- an assumption proveably false. There was a famous quote an IRA terrorist reportedly once said to Prime Minister Thatcher once- "We only have to be lucky once. You have to be lucky all the time." Security analysts face the same problem- the crackers only have to find _one_ vulnerability, while the security people have to find _all_ of them. You're not making the cracker's lives much difficult, but you're making the white hat's lives all but impossible.
Open source is not a security silver bullet- and I don't know of anyone outside a few anonymous cowards who claims that. Open source _is_ better than closed source for security. No ifs, ands, or buts.
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?
Mister AC was refering to the option value of open source (which certainly exists). Certainly there are free rider and easy rider issues with open source, as with all public goods- but that option value is real, and is something that is not always available with closed source software.
Evangelicism on either side of the security debate is of little use to people who actually have to implement security solutions. And the more value that is placed on that security, the higher the option value of open source is.
Pax -- Ob
Don't worry, I have many years of experience but I still can't just glance at code and know what's going on. Firstly it's time consuming. Secondly, unless you have direction (you want to find out who a small piece works), it's easily to be overwhelmed, especially for bigger projects - you need to apply the "divide and conquer" approach. The smaller your ulterior motive, the harder it is to get into and understand somebody else's code, let alone start finding security bugs. In some ways, the best approach is to review the code with another person... you can discuss it as you go and motivate each other.
We do code reviews at work and they can take hours. That's just small sections of code - no more than a few hundred lines. Looking at somebody else's code takes sometime just to get up to speed.
I got really annoyed with Mozilla crashing on my SMP machine a couple of months ago. I downloaded the source, compiled it and then starting running it through Visual C++. Guess what, after spending a whole Saturday doing that I give up (don't give me a hard time, I know I didn't stick at it long enough to get anywhere useful). It takes a long time, and I don't have the time. I already work 8 to 12 hours a day, after which I want to get away from the computer and spend time with my girlfriend, etc.
So, my point. Although open source means that there is the potential for more eyes looking at the code, does this really happen? How many people just extract and compile, or just install a package? That's effectively no different to closed-source binary distributions. About as close as I've got to the source is when I've had to set a pre-processor define in a kernel header, or when I've got unresolved linker errors building the kernel. The rest of the time I can't be bothered... it's too much effort and I just want it to install and work.
By reading this comment (or clicking this box, or opening this package, etc) you give me the right to kill you. Now, when I'm holding the smoking gun, I'll have a hard time staying out of jail.
You bring up a valid point. The MS EULA, as it currently stands, is probably not legal. However, the fact that Microsoft would print such a EULA, legal or no, should give some sort of idea as to how much they are likely to support you. After all, despite the fact that Microsoft's EULA is probably not legal, and despite the fact that Microsoft installations have been known to melt down and lose companies millions of dollars, there has never been a case that has even tried the legality of the EULA.
Why is that, you ask? It's quite simple. If you did sue Microsoft the only thing that you could be sure of is that you would be in court for the rest of your natural life with the most capitalized company on the planet. Microsoft has the resources to completely bury all but the best-funded of companies. You could spend millions of dollars, waste hundreds of man-hours and then lose the case in the end. The only way that a court case like this would be worth your company's time and money would be if they happened to be able to prove, in a court of law, that they lost even more money than the court battle would cost due to Microsoft's negligence.
Dr. Kevorkian's case, on the other hand, was a criminal case. That means several very important things. First of all it meant that the US Government (possibly the only group in the world better funded than Microsoft) would be paying the lawyer fees. In other words the money in the equation was on the other side. If Dr. Kevorkian would have had unlimited funds the case might well have ended up like the O.J. Simpson trial. First rate lawyers clearly can make a big difference (Dr. Kevorkian actually waived his right to a lawyer and defended himself, Yikes!).
The second major difference between Dr. Kevorkian's trial and the trial that you would get were you to take Microsoft to court regarding the EULA is that there is very little legal precedence for responding to issues of software failure. Dr. Kevorkian had a video of him killing one of his patients. He even admitted that this was the case. Given that evidence the state laws were quite clear. As a plaintiff against Microsoft you would have to prove (beyond a reasonable doubt) that Microsoft knowingly created a defective software product, and that the defective software product was responsible for your lost income.
Good Luck trying to prove that against Microsoft's lawyers.
Not to mention that with UCITA becoming law in many states across the nation soon the MS EULA might become completely legal. The fact that Microsoft is lobbying hard to make the UCITA law in all 50 states should give you an idea as to how much Microsoft is concerned about its customers...
I'd say ESR's argument is very strong and not at all refuted by the opposing piece. I find it personally satisfying the ESR is able to get so much mileage out of a FUD tactic invented by Microsoft.
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.
:) .
How do you know?
Maybe it's part of Microsoft's policy to introduce such an innocent backdoor with every program. And maybe some open source superhacker is grinning to himself knowing that nobody noticed his supercleverly-disguised harmless backdoor in the Linux kernel.
Even if we didn't find it, it doesn't mean it isn't there
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
Bruce
Bruce Perens.
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.
How would you at all determine whether anybody is an expert at security then, short of being one yourself? It's all about reputation. And to my knowledge, the developers of e.g. OpenSSL and OpenSSH have a reputation that at least approaches that of developers at RSA and say, F-Secure. With the big difference that RSA and F-Secure can point fingers at flaws in OpenSSL/SSH design, and not always the other way round. Although a lot of security companies, probably not without reason, tend to be openish themselves; this at least partly goes for RSA and F-Secure also.
/of reputation/, looking over their shoulders. If it doesn't get dismissed then chances are the 'core team' of that piece of code are probably quite expert.
The point here is that open source is auto-hardening. 'Normal' closed commercial software which is being attacked is hopefully fixed, but nobody, expert or not, can review the resulting, if at all, design changes. What remains is name calling: 'Novell had this flaw' 'Microsoft had that' 'SCO such and such'. With open source name calling doesn't really help cause everybody (including experts) can see whether you are actually adapting.
I think that incompetent open code would be rather quickly dismissed by people
About peer review: of course most people potentially having a look at the code don't know what they're looking at. But there are always experts ou there, who tend to be interested in their field. You bet they are watching!
In a broader view, of course there are no guarantees that open source software is 'secure'. But security/encryption related OSS packages probably are, more or less. If other packages use these few firmly audited crypto libs for encryption related stuff, and adapt a 'secure' coding style with regards to buffer overflows/memory leaks and such (which is reviewable by a much larger group, although I admit yet not everybody), then what results is very nicely secured software. I don't see this advantage in the closed source world.
Apache as an example: everybody can check out and see that apache uses mod_ssl uses openssl. Also, everybody can check out whether Apache has been audited. So everybody can make a rough estimate about the security mindedness of Apache.
IIS: not so (apart from experience)
I apologize for my less then compact writing here, this could be better I'm sure. The point is that while there is no guarantee, there can hardly be a disadvantage. Overall people will be better out with open source.
In the end they don't really disagree; where ESR says Open Source security would be better almost by definition, whereas Elias Levy notes that the 'open source way' is potentially better but it all depends on the many eyes actually watching/being able to watch for harmful code (the cc malicious chicken and egg problem aside; but proprietary software doesn't seem to offer any advantage here).
Then again, there's mostly a small team of hard core developers for any open source project, and especially the (mostly technical) security related stuff. Any nasty stuff would probably have to be done by someone inside such a team. An outsider trying to submit something 'bad' would very probably be noticed by one of the core members.
So if, as a user, you don't want to code everything yourself, it all comes down, I think, to trust. The only question in the open source vs proprietary case is: who do you trust more in the end, a proprietary developer team or an open one.
Security by Obscurity could maybe temporarily help the Proprietary case, but the 'Exploit-Found' scenerio would always turn out better for Open Source: more fixers, hence quicker fixes. And the fix-it-yourself option.
Tell him about the NSA backdoors and the "Netscape engineer are weenies" ... even if it's 100% bollocks, it worked for me! Hey, Microsoft does'nt have to have a monopoly on false advertisement ...
Of course when you're reading device drivers, you should have the hardware datasheet in hand, so that you'll have some idea what's going on...
---
Either back-door bugs are obvious as hell, in which case they could be picked up by review by ten people, max. Or they're not all that obvious after all.
Good God man, you have all ready stated that you do not know how to program. I would imagine that you have no idea who the Apachie group are and do not know the large companies that pay to have Apachie developed. Then again, you could be a toll.
Furthermore, the more people there are checking the source, the more there are out there introducing bugs, for the hell of it. Even if "Apache" is bug free, how can you tell that the disk you got passed by your third cousin who got it from his ex-boss who got it from "some guy" is?
Oh come on, do you not know that you can verify the source with a digital signature from a trusted source? Yep, your a troll.
It would seem far more useful to me if source was "open" in the sense that you could get a copy of the code on production of a reasonable description of what you planned to do with it, what improvement you wanted to make, plus at least two references from people who were prepared to establish your bona fides. Kind of like the criteria for getting a reader's ticket to a law library.
This is not Law, troll. If the package maintainer is a good manager, he will know what is good and allow it in. I guess you want to spread the LIE that these packages just get moved around without a single person looking at the code. SOMEONE MUST LOOK AT THE CODE BEFORE IT IS PLACED IN THE MAIN DISTRIBUTION TREE. ok, ok, so my karma is going to get tanked for this flame, but I don't care. I am DONE with these trolls.
--fatboy
If I download, say, a GPL'd firewall who is legally responsible when it let's through an attacker?
:-)
This whole idea of "blame" doesn't mean much anyway. If you pay a few thousand bucks to Microsoft for your office network, and someone breaks in and trashes everything, Microsoft is not held responsible. You can't sue them. You agreed to that in your license. Tough luck!
So I really don't see why people run around scared of OSS because they don't have anyone to sue...
Cheers,
Vic
From the article: "simply being open source is no guarantee of security." ... Most everybody can agree with that, I think. He does an excellent job of making that point, as expected.
For those of us who suffer from the horrible HTML at securityfocus.com: the unframed article and just for good measure the unframed BugTraq Archives. Really, guys, a banner ad is fine but you've got 3/4 of the browser filled with useless flashing crap. Stop it.
Open Source Software certainly does have the potential to be more secure than its closed source counterpart.
But make no mistake, simply being open source is no guarantee of security.
So, in the end what he wants to state that it's not a given that open-source software is more secure, but the potential is there....
exactly. Elias Levy isn't arguing against open source, and certainly not proposing that closed source is more secure. he's just reminding us not to get *too* carried away, and stressing that actually reading code is a good thing to do. your reply just proves that you were expecting an "argument", i.e either for or against "us", the OSS guys. reality isn't black and white, and I thank Elias Levy for reminding us.
ESR is trying to single handedly re-create the "man month" - the idea being the more eyes you throw at the problem the faster/easier/better things happen.
This is demonstrably untrue.
Ha ha very funny. The "man month" myth only applies where there is lots of designing and communication overhead. Lucklily looking for bugs requires neither. I think there are now officially more trolls on slashdot than normal posters. You smack one down, two more pop up.
Scuttlemonkey is a troll
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.
Searching for basic exploits can be hilariously easy. Read the CDC's Tao of Buffer Overflows All you have to do is input a bunch of text into a field and see if the program breaks. Not much harder than grep sprintf or scanf.
Scuttlemonkey is a troll
You can argue that OSS isn't more secure. However there is the possibility that the code was reviewed and it is secure. If it wasn't reviewed and there is an exploit, you have the source and can fix immediately. You don't need to wait for the "vendor" to "fix it".
I thought "hey, lets see if I can understand this NOW!" Guess what? It's still spaghetti code. I still can't unstand a stick of it, other then the PRINTFs and SCANFs. That's it. And I got a 98% in the class.
:-)
;-) you can often find it in other places, for example, the web site the code came from, or news group archives, or the linuxdoc project, etc.
;-) badly structured code and use of obscure library functions all contribute to code being difficult to read.
:-)
Hang in there. In programming as in any other highly developed speciality it takes a while to get from where you have to start as a beginner to where the pros are working. And also, don't give up. Just because you don't understand the first function in a listing (that's actually pretty normal) doesn't mean you can't go somewhere else in the listing and start with something you *do* understand. Hint: start at the bottom and read up. Start with "main"
Another factor is that you often have to have a pretty good grounding in the application area the code is written for before you can have a clue what it's doing, so if you're reading cryto code, go check out some crypto sites and maybe get a cryto bood. Same goes for security. Read the howto's and get an idea what the apps are trying to do. Good documentation helps a *lot* too, and while it may not always be included in the source code
And then there's just outright bad coding style... it's often not your fault that you can't read something right away. Poorly chosen variable names, unecessarily redundant code
But the main thing is just experience. It takes a minimum of 3 years to get to a professional level of knowlege in c++ and until you get there, you'll have to pick and choose the code you work on and you'll have to work hard to understand typical pieces of production code. Also consider that you'll get there faster if you start with a language other than c++ - say, Java or Python, because the concepts you need to learn are much more clearly expressed in those languages with fewer obscure and distracting features.
In the meantime, don't worry, there are still plenty of eyeballs out here that can read and understand this stuff
--
Life's a bitch but somebody's gotta do it.
What might that be exactly? Was it the linux kernel itself, or something tacked onto one of the distributions? I can't think of any terribly significant bugs in the kernel that were exploited by "black hats" before the vulnerability was published (and normally patched). In any case, the latency between a working exploit circulating amongst black hats and the knowledge of that bug is about nill. Yes, I realize there have been some DoS vulnerabilities in the kernel and some relatively minor security issues (relatively recently, say the past 2-3 years), but all of these to my knowledge have been published by white hats (those who publish their work, not exploit others). I fully realize that this is not "effective security", insofar as many admins can't secure their machines before the so-called script kiddies can. In terms of "ultimate security" (as I described in my previous post) though, I still believe Linux to be well ahead of NT.
The problem is that this is hard to prove empirically. If we know about the exploit shortly after blackhats do, then it's hardly "ultimate." And if we do not know,...well we just don't know. We can, however, make some inferences. We all know the abismal record of microsoft when it comes to bugs. For example, we know this recent "Netscape engineers are weenies!" backdoor remained unobserved by the general population for years. Yet it is hard to deny that any sufficiently motivated individual could have discovered it. Thus we can reasonably infer that an organization such as the KGB could have taken advantage of this bug (not that it was all it was cracked up to be) and exploited a great many machines before the public ever saw a fix. While I realize that i'm comparing apples to oranges here, I've yet to see an analogous situation with the Linux kernel, and I've seen enough with NT (in and of itself) to connect the dots....
I disagree though. It does raise the bar for the average "black hat" to create a _viable_ exploit. While it is mindnumbingly dull for most "white hats." Sure, you can look for certain key strings with a hex editor, but it is not comparable to looking at the entire code and seeing it in context. Certainly if you look at the actual number of published exploits for NT they are relatively few. So we must either conclude that your average black hat has a number of NT exploits which the informed public is unaware of, or they simply don't have it. In either case though, a) neither the admins nor microsoft is doing much about it b) Microsoft gets away with it because the hacking incidence of NT isn't much worse than Unix (and some would argue better) c) a relatively small group of intelligent and motivated individuals can punch holes in almost every NT box on the internet. In other words, the possibility of a highly sucessful systematic attack against supposedly secure NT installations is not exactly outlandish.
I am differentiating between the Linux kernel and the distributions. I fully realize that the actual implimentation of Linux in the various distributions is less than secure. I'm asking you to enumerate what bugs specifically in the kernel were discovered by blackhats before the whitehats. The mainstream press is useless when it comes to technical details such as this.
Umm, no. The backdoor exists, just it was not all it was cracked up to be. I believe I alluded to this in my previous comment too. Nonetheless, it is not terribly relevant to my point. Microsoft screwed up. The public did not notice it for years. The degree of the severity of the bug is essentially irrelevant, it was certainly significant enough to get noticed. It certainly casts doubt on Microsoft's auditing practices.
As for being a member of the Linux FUD community, my record speaks otherwise.
FYI: http://www.techweb.com/wire/story/TWB20000417S0001
hardly irrelevant, or non-existant.
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
The author makes the point that the compiler itself can be trojaned. (This was noted 17 years ago!)
In this case, the compiler was trojaned so that it recognized when the "login" program was being compiled and inserted a backdoor. It ALSO would insert this same code when compling the source code for the compiler ITSELF.
So you could download the source code for the compiler, and it would be clean, but then you would have to COMPILE it, and as soon as you did the trojaned compiler would generate another trojaned binary. So the authors point is that you have to use a binary compiler, and it can be a weakness - even if its open source.
I have to wonder if the binaries would be identical however... And if running the diff command on them would result in any difference between them?
It certanly creates an interesting problem.
Try to hack my 31337 firewall!
Sometimes I enjoy following the links these guys give th thier pathetic home pages. Always good for a laugh - kind of like the "worst of the web" contest. These guys are the finalists.
This goober has a broken link to his resume... Ooo I think I'll hire him! and some kind of wish-list for his house that includes "2 soaker hoses".
A fiercly proud Texan - that should say it all...
The attacker, of course. :-)
Beyond that, if I really wanted to blame someone else, I would go with whoever decided to use that particular firewall software. The same would go for a closed-source program too: the person responsible for its quality is whoever chose to buy it.
If that responsibility ever fell upon me, I would have to make a choice about who I trust more: the vendor's reputation, or my own competence (and curiosity) combined with the maintainer's reputation.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
With open source, you can trust whoever you choose to. It can be a "random" consultant, or it can be one who you have known for 20 years, or it can be an employee, or it can be your brother, or it can be yourself, or it can be the maintainer (of either individual packages, or of a whole distribution).
That last choice -- trusting the maintainer -- is exactly equivalent to trusting the vendor of a closed source product. (How is downloading a fix from Red Hat any different than downloading a fix from Microsoft?) So, in the worst case, open source is identical to closed source. The cool thing is, you don't have to take the worst case if you don't want to. But for convenience's sake, you can, and many people do.
No, it's the "freedom mentality", where the whole point is that you get to assign your trust to whoever you think best merits it.
You see having choices as being a burden, rather than empowering.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Yes, any boob can review it. So what?
Ah, I see your problem. You are assuming that since "any boob" can review it, that means "any boob's" modifications will be fed back into the main source tree. Fortunately, you are mistaken. The decision to accept a change is made by the project's maintainer. It's not, as you seem to imagine, some kind of free-for-all where anyone can change anything.
How could that possibly be, as you say, "more useful"? Why would you ever want to place any restrictions -- at all -- on who is allowed to know and understand things? If all of those things are needed just to read about law (not just to legislate and judge it), then it sounds like the software profession is far more advanced and reasonable than the law profession. You should be copying us, not vice-versa.
Restrictions should only be placed upon those who create and modify software (and that's the case, with both open source and closed source). With open source or custom software, the end user has the final decision on how strict or lax those restrictions are. With shrink-wrapped closed source software, the end user has no control of those restrictions, or even knowledge of what those restrictions are or if they even exist.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
You have raised a very good point, and one that I was sorry not to see mentioned in the article.
The first reaction of some companies when a security exploit is reported publicly is to go into full-on damage limitation mode, by denying that there is any problem. In the current stock market climate especially, where technology stocks are dropping like the proverbial stone, companies are going to be engaging in face-saving activities more and more often.
Sure, they may well quietly assign a developer (or a team of them) to tracking down and fixing the problem, but the people who are actually using the software will not be taking the precautions that they should be to protect themselves. In the time it takes for the company to own up to the problem, unnecessary, avoidable damage will have been done. (Or if it was unavoidable, at least people would've known that they were taking a risk.)
I'm not saying that this sort of thing happens very often now, but with hordes of stock holders to pacify, you can be pretty sure that it'll happen more often in the future.
Cheers,
Tim
It's official. Most of you are morons.
Peer review of software is not as crucial as in physics. Everyone wants to check the theory of cold fusion or the proof of Fermat's last theorem because they are used as building blocks for further research. When Fermat's last theorem was proved, it opened up more possibilities. Software can also be used as building blocks but new source code almost never cause a revolution. People also prefer to reinvent the wheel instead of reusing source code.
However, open source software can be audited and that's what some white hats do. The Linux Security Audit Project is actively searching for holes by reading the source code. This includes lots of gifted programmers who can smell a hole from far away.
I'm sure that commercial software is also audited inside the companies but close software gives you false sense of security. It's easier for you to make sloppier code and leave temporary holes because "nobody knows about them anyway." But if you know that bad guys are going to read your source code and exploit it, you really concentrate more on security. And even if bad guys are not going to read your code, you don't want to be laughed at for leaving holes the size of Titanic.
But while peer review is not as common as many think, it doesn't mean that it's useless on unexistant. How many of you have actually checked Andrew Wiles's proof of Fermat's last theorem? Only a handful of extremely intelligent and gifted mathematicians can do that and have done it and that's enough for the whole "community" to trust the theorem. So even if only a handful of programmers check important source code, it's enough if those guys are as gifted as Linus Torvalds or Alan Cox.
He's right in that its more complex and nuanced than the simple "everyone will review this" model; unfortunately I think he's emphasised the wrong and less important nuances.
There's two reasons why TIS wouldn't get feedback from their code: noone is reading it, or noone found anything bad to say about it. My own impression of TIS code was that it is pretty high quality, and there wasn't anything bad to say about it. I don't know of any serious holes reported in Gauntlet.
People do read source, and the point of open source is that you at least have the option. Most people don't sit down and read slabs of code before installing it, they wait until they have a reason to do so. For security software, one of those reasons is that someone has found a breach.
Sure, open source means the bad guys can pick through it and find a hole, but they can do that with standard reverse engineering tools with binary-only releases too. But as soon as someone sees a break-in involving and open-source program, you can both audit it and *fix* it. And a piece of software which has shown one flaw is sure to get a lot more attention. If there were holes in Gauntlet, TIS would be deluged in email after the first compromise.
There's another nuance going on here which Levi completely ignores. Because a developer knows their code is going to be visible for all to see, they're much more likely to keep their code clean (and if they don't, someone else will). A programmer in a commercial environment writing code which will only ever be released as a binary is more likely to hack something now to hit the ship date, with a solemn promise to fix it in the next release (and hoping nobody will find the flaw before then).
Code is complex, and reviewing it is also hard; security makes it even more difficult because security isn't a functional property (see http://www.counterpane.com/whycrypto.html). In commercial environments, code reviews are often skipped in order to keep to schedule, with the rationale of "well, the tests pass". You simply can't test the security of a system - it has to be designed in, and it has to be there from the start.
In other words, he's right that programs like ssh is large and complex, and may well have subtle flaws. But there's absolutely no reason to think that a similarly sized closed-source program won't have similar problems; my feeling is that it is more likely, because the closed source commercial model precludes the possibility of code-review at several levels (we don't have time, noone else will see the code anyway). The open source model encourages code review by
Anyone who regularly looks at attrition's defaced mirror knows that a dominating portion of the blackhat crackers out there are using well known bugs and exploiting lazy (or overburdened, or unqualified) administrators instead. Most crackers are looking for noteriety first and everything else second. That's why web pages are defaced, credit card numbers are posted, etc. etc. How many blackhats do you think are looking for the bugs and keeping their mouths shut about it? I'm not saying it never happens, but certainly having open-source does more good than harm.
And another thing, if its so easy to grep for strcpy then why hasn't it been done to the code in the first place? Why isn't it automatic?
from the article : "Whatever potential Open Source has to make it easy for the good guys to proactively find security
vulnerabilities, also goes to the bad guys."
yes, that's true
more, it should frighten people
but fear is a good thing
some time ago experiments in england demonstrated that when people feel in danger when driving they are safer. The experiment was to remove the central line of a dramatically lethal road. The result was near zero car crash.
Other studies showed since cars become safer (airbag and other security stuff) accidents increase in number and even in danger because people drive faster. Therefore drivers feel safer and drive faster and when they crash, it hits much harder.
Man kind is such that we prefer forget danger.
When we believe someone else will review an open source code, we do not review it.
However it stands the same for close source. "We" believe corporations do a "good" job and we buy the soft eyes wide closed.
In either case we forget the danger.
So what ?
Open source has in this matter one advantage compared to closed source : the bad guys can review security holes from the source and we know it. That must keep us awake, fasten our belt and drive slower.
We must use open source soft and realise that it does not protect us more that closed source. however it will keep us alert and enable us to have a better understanding of why we choose such security parameter.
when will we need a security licence test ?
;-)
The world belongs to those who get up early. - I'm far from being the king of Earth then
The C compiler backdoor mentioned affected only people who installed the binary, instead of recompiling the compiler themselves
That still doesn't stop this from happening: I have an "un-broken compiler", I down load the new source containing the back door, I of course don't read the whole freaking source, I just compile it. Someday down the road I compile a new login with my now broken compiler, and I am busted.
I agree that my ability to fix this is greatly enhanced in an open source environment, but my point is that it just isn't the binary, you need to trust (or audit yourself) the entire source. This is something that no one can do on their own. Fortuantely, since we all have the source, we can all watch each otehrs back, if you will.
If, for example, you're using Red Hat Linux and you don't trust us for whatever reason, all it takes is "rpm --rebuild /mnt/cdrom/SRPMS/* ; rpm -U --force /usr/src/redhat/RPMS/yourarch/* /usr/src/redhat/RPMS/noarch/*".
Once again, how do I know you haven't fucked with the source code? In fact, if there is a back door, one might just leave it in the CD sources to defeat just this work around.
My point is, make or rpm --rebuild does not necessarily fix this. They need to be executed on reviewed source. This isn't a slam against open source. Like I said, the only place you have a chance is in an open source environement. I just don't want people to get a false sense of security, "I can just rebuild everything fom the source and I am safe."
Seems to me that there's a market for various sorts of warranties as a value-added service to open source. But I doubt that anyone is going to give a blanket warranty that a firewall or anything else is hacker-proof, whether that something is open or closed source. In both cases the downside liability is just too great.
The folks who built your home didn't give you a warranty that it was burglar-proof. Even my alarm company only promises intrusion detection and rapid reaction...
A. Michael Froomkin,
U. Miami School of Law,POB 248087
Coral Gables, FL 33124,USA
I have a blog.
is here
He basically points out that OSS is not perfect, but can be considered better than closed-source.
I forgot to write the rest of this post....
Clearly we have the problem of "But is Microsoft liable anyway?" Well, ethically I think the answer is "yes". Legally the answer is "no" or, more accurately, "currently, no".
But I think we will soon see an eConsumer Protection Act that changes "currently no" to "maybe" and eventually "yes", DMCA and UCITA notwithstanding.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
If I download, say, a GPL'd firewall who is legally responsible when it let's through an attacker?
My common-sense approach would be to blame the network admin unless it was a bug of such an egregious nature that it constituted negligence on the part of the company. Many products (see: Microsoft) have just these kinds of bugs in them. So a smart network admin gets something Open Source.
Could a sufficiently crafty company claim that, since you have the source, certifying that it is secure and bug-free is up to you? And, if so, will we see companies moving to Open Source releases for liability protection?
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
No question, Thompson's "Reflections on Trusting Trust" ( http://www.acm.org/classics/sep95 ) was and remains a delicious thought experiment. Levy is right to remind us of it (and his exegesis is a model of clarity, if nearly as long as the original...), and Eric should certainly have taken it on board in sounding off about the automatic merits of Open Source when it comes to security.
But the Trusting Trust thought experiment is confined to a small world where (1) there's only one compiler -- Ken's -- for compiling the compiler; (2) the login program is immutable enough to guarantee recognition by Ken's compiler every time it is compiled; and (3) there are no other security checks outside the login program. I don't see this as a practically useful description of the free software world as it is today.
Even if there were only gcc, and login were carved in stone, I don't think Ken's diabolical backdoor would be applicable. If there's one person in this entire world you could trust not to do something ingenious and backhanded with passwords, it's the author of gcc.
And even if that we dispense with that previous "even if" and admit that free software has a fundamental Catch 22, it's still clearly a preferred route to any closed source alternative. The idea that the "bad hats" will always get there first is scaremongering -- unless you think that, for example, Mixter must be a "bad hat" by definition because he scripted and published proof-of-concept code that demo'd DDoS attacks.
Democracy certainly has it's own fundamental Catch 22s. If you think this is an argument for dusting off and resurrecting Mussolini, then you'll probably want to take Levy's warning very seriously indeed.
--
el bid
Levy isn't on any side, unless you count security as a side. Being a long-time subscriber to bugtraq, I can tell you that it doesn't matter to him whether it's closed, open, or slightly ajar, as long as it's secure.
Sorry couldn't resist. Actually I think Streetlawyer has a point.
"Open source" does not help you if you can't (or dont have time to) understand the source.
Read the other guys post, *you* is not you who can't code, it's the same people who wrote Linux. Having the source means *someone* can. Without it, only one per^H^H^Hcompany can, it's I think this recent situation shows exactly how motivated they are to do that. And BTW, you're agreeing with a troll which just makes this thread even funnier.
--
+&x
Was Streetlawyer trolling? a troll savant? Don't know. My opinions are (as usual) my own.
/. is now (at least the ones who post), they can't even recognize the trolls. Of course, this is because the trolls run the place now, because they get fed so often. Most of the time it's just fun to laugh at, but what can I say, it's monday, so there ya go.
Check his user info, or check the underthreads, or read his (or DMG's??) TrollHOWTO, You can read some of it here, there's a link at the bottom
But that's how misinformed, naive, or just plain ignorant most of
--
+&x
yes, but I wasn't sure if you were "streetlawyer". I need to update the other one. Writing about /. is not my day job, just a sick fascination.
--
+&x
It's me, "Hi!"
It's a hundred thousand other me's, all of whom have vested personal interest in seeing the software run properly for some reason or another, each of whom is not only willing, but eager to fix those bugs which annoy him/her.
*You* don't have to fix shit. *You* never have to see a single line of code if you don't want to. Herein lies the beauty of the whole thing. You can simply sit on the sidelines and reap the collective good of the effort exerted on the Open Source software you use.
Installing the latest bugfix is simply a different terminology for what Micros~1 callsd "upgrading," and it doesn't (usually) cost a damn thing.
Your ignorance borders on FUD. The notion that you must edit Open Source code personally line by line is so blatantly wrong that you do us harm by spreading it.
Anthony
"I think any time you expose vulnerabilities it's a good thing." -Attorney General Janet Reno
MS's hotfixes and service packs are also free.
Point well taken. But Micros~1's entire revenue model centers around phrases like "upgrade path." I should know this, I'm unfortunate enough to administrate 8 production NT servers.
When something needs to be fixed on one of these servers, or (more appropriately) when one of Microsoft's "hotfixes" of "service packs" breaks something on one of these *production* servers, my employer has to expend huge amounts of time (time==money) and money to figure out what caused the problem, and then (usually) purchase new software from Microsoft to "fix" it again.
Neither I (who administrate) the servers and care, or my employer who owns them (and doesn't), get to see a single line of code in either case. We have no idea what the "fix" will do, and no way of finding out other than installing it.
I prefer Open source because it's free as in speech anyway
Anthony
"I think any time you expose vulnerabilities it's a good thing." -Attorney General Janet Reno
I need a solution that does not require an expert for daily use
Not to rag on you guran (I very much agree with your point), but to rag on a different angle I see meant by that statement daily:
Get a fucking calculator.
Middle management seems to live under the perpetual delusion that these inconprehensibly complex conglomerations of silicon, plastic, and electrons are somehow going to magically "work" all by themselves some day, and yet still can't seem to figure out how to work Outlook when their system is running fine.
"I need a solution that doesn't require an expert."
"I need a solution that doesn't require me to learn or think."
"How do I forward this chain letter?"
"What do you mean don't open letters that say 'Good Times'."
"I think I just deleted The Internet."
Anthony
"I think any time you expose vulnerabilities it's a good thing." -Attorney General Janet Reno
I don't see why they didn't release a fixed dll
:) You seen their source? Neither have I. You seen how amazingly shoddy, unreliable, and *fundamentally* unstable (unstable in that "there's a still a couple serious pointer errors in the pre-1990 code" way) their software is? What do you imagine their code looks like? How easy do you think it is for a bunch of people motivated only by salary to fix something obscure in a couple million lines of badly maintained code? How long you think that takes?
.dll
I do
I see why they don't just release a fixed
Anthony
"I think any time you expose vulnerabilities it's a good thing." -Attorney General Janet Reno
Okay, so they argue that Open Source Software isn't perfectly secure. Very little is. I see no argument that Closed Source Software is any more secure. And this implies...?
--The basis of all love is respect
Paul.
You are lost in a twisty maze of little standards, all different.
MS's hotfixes and service packs are also free.
Sometimes. Other times, they're given names like "Windows 98" and are charged for.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
Obviously, if you have a computer, and you don't wish to develop the expertise to administer it yourself, you have to find someone you trust. My lawyer thought he had someone to trust with his Microsoft box. Guess what? That person installed a back door. Who found it? The Linux expert at my lawyer's ISP.
-russ
Don't piss off The Angry Economist
Nobody accepts that liability now. Read the fine print. Everyone disclaims any liability for anything their program does. The only thing you get with your Microsoft program is a guarantee that you have an exact and reliable copy of their copy of the bits.
-russ
Don't piss off The Angry Economist
Remember how the closed source sendmail's had Eric's DEBG botch for years after the open source version has diked it out?
-russ
Don't piss off The Angry Economist
There are basically two kinds of software users out there: the ones who really care about security and the ones that don't. The ones that do can be recognized by trappings like: no software gets installed without the software security staff reading the results of an independant security audit based on access to the source; no users are allowed to install anything, only security admins can authorize that; It's someone's full time job to stay on top of security notices and updates/patches; etc.
The type that does not care will often protest that they do. However, they then turn around and say things like "we'll just use XYZ vendor's product because they're a large stable company that, it would seem, would have no reason to wish us ill."
We can ignore the second type of company (what the article in question is really talking about) because they will be insecure no matter WHAT they are running. Running MacOS just makes them slightly more secure because that's not what the script kiddies are looking for. If they're going to install Red Hat 6.0 and walk away from it for 2 years, assuming that it's "safe", they'll be wrong. There are numerous security problems with any OS release, and if you don't stay on top of them (and/or find them up front) you're screwed.
In the case of the company that really cares, OSS is much more attractive. For starters, you can re-compile every single binary from source. Second, you have the ability to fix the bugs that your internal security audits fix, while you wait for an official patch. For mission-crittical software, this can be immesurably important.
I remember dealing with a market-data vendor when I was working for a medium-sized financial firm. They wanted to pump their proprietary protocol over the Internet and through our firewall, so I said "no problem, just a) give us your source so that we can perform a security review or provide us with the results of an independant security review in writing." They litterally laughed in my face. Needless to say, their data feed did not happen.
Not everyone cares this much, but when you do, Open Source solves a lot of problems and makes many things much easier.
Presumably you're referring to Microsoft Security Bulletin (MS00-025), which, though it had been outed by a couple of groups already was not released until 6:00 pm Pacific on Friday. Or are you referring to the three security bulletins that Microsoft held under wraps until after 6 pm Eastern on Friday Mar. 31? Microsoft does not have a history of timely reporting and fixing of security problems. Moreover, they have a tendancy of holding onto advisories until after business hours on a Friday.
The author was right about one thing. Open Source is not a panacea. However, where we are vigilant, it does work to improve security. Where there are enough qualified developers (like in the Linux kernel) looking for security related issues, Open Source provides us with an excellent opportunity to track down and fix bugs. Moreover, it means that we do not have to rely on a single source for fixes.
Nobody appears to be mentioning one very important advantage of Open Source when it comes to security. Even if Open Source software were more insecure than Closed Source software, it provides an advantage that Closed Source will never be able to provide. Developers can learn from other developers' mistakes. Developers can learn how to recognize and avoid common security problems in code by looking at advisories and the code before/after the fix. A new developer certainly cannot look at the IIS code and see how the latest buffer overflow bug caused problems, or how Microsoft fixed it. Do I learn _anything_ by applying Post SP6 Hotfix xxx? No. Do I learn anything scanning through a patch in source form for Apache? YOu bet.
The author does present an important point. Many Linux users now do not build from source even when it's available. Many don't even have the source to most of their tools/applications, even though it's available. Remember, if you don't exercise your freedom, you don't get the full advantage of it. Build from source. Read the source. Learn from other people's mistakes wrt security, so you don't make the same mistakes yourself.
Sorry, but I don't really get your point here. So you don't trust the guy who installs OSS software on your computer, but you do trust the guy who installs MS software on your computer? Or do you think because the OSS guy has the source of the program, he (m/f) will put in backdoors so he can get back on you? Don't you think the MS guy has several ways to misconfigure the system in such a way he'll be able te get back in without you ever knowing it and that it'll be even easier to do? It looks pretty obvious you're on the law side of IT, not on the technical side! *ducks and runs*
Thimo
--
Avoid the Gates of Hell. Use Linux!
I have contributed to open source projects, and I have had other people contribute to my projects. And I can tell you this. Both of them have made me a better programmer.
The project that I contributed to was a graphical email client. I had been toying with writing my own, when I found one that looked like it had good potential. Unfortunately it would not work with my mail server. I checked out the SMTP code in it and it was completely hacked together--not really following the RFC. I sent the author a complete rewrite of that section, and if he used it he will have learned a lot. (The experience also made me realize that I am not about to ever use that mail client since the rest of it looked equally hacked together and the author was reluctant to consider advice.)
In another case, I published one of my own programs as open source. In less than a day, I had a reply from someone telling me that I had used an "older" style of signal handling, and he
sent me a rewrite of some of it. Naturally I was following textbook examples from somewhere and it was out of date. I now have a modern example of good signal-handling to work from when I write new programs.
You may agree or disagree that OS projects are better, but I can tell you this: YOUR projects will be better if you open the source.
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)
- Nessus: Free. Open-sourced. Up-to-date.
- GNU Privacy Guard 1.0
Slightly ironic, isn't it?Pp.
It's a simple matter of complex programming.
This has happened with sendmail wu-ftp several years ago. It was released as a "new" version and it was even distributed from the wu-archive server.
I got the following in a private email, and thought I'd pass it along:
JHC> I have replied personally because I had moderated the discussion and
JHC> couldn't post...
JHC> You asked:
JHC> be honest I have never heard of it happening in the OSource community
JHC> (there must be some examples?...>>
JHC> One that is close to my heart is ALSA (www.alsa-project.org). It's a
JHC> project to completely rewrite digital audio and music support in the
JHC> Linux kernel. It will replace the crufty and outdated OSS architecture
JHC> which is cross-UNIX and very entrenched; so this decision seems pretty
JHC> gutsy (to me, at least).
JHC> I'm sure there are probably other examples.
Email address hidden to protect the innocent from spammers..
EZ
-'Press Ctrl + Alt + Delete to log on..'
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
This is a well-made point.
-Who- make the big -painful- decisions with OSource code? Does anyone have the strength and power to say 'This section of code is lousy, lets accept the 'hit' of re-writing it.'?
This must be an area where OSource can score over closed models, but to be honest I have never heard of it happening in the OSource community (there must be some examples? I have a vague memory of Mr Carmack saying he wanted to rewrite some Linux network code?). Is it a case of you do it, and then hope that your changes are accepted by the wider community, does this encourage you to start?
OTOH I have seen it twice in a closed context (admittidly in a 'quality over quantity' embedded controller market). Legacy code was looked at and a decision made that "we spend man-years dealing with all the problems from this, it is a bottomless pit of bugs and we pay a fortune to the one geek who understands it, if he ever leaves we're stuffed!". Suddenly a corporation will invest in fixing it up-front because they can see a payback in the mid-term, (obviously we're not talking M$oft here..)
EZ
-'Press Ctrl + Alt + Delete to log on..'
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
I'm not going to go that far, but this is really a question of how do we pay open source developers. Black-Hats are being effectively paid for their work, either by bragging rights or by illicitly made money.
Until someone comes up with another way to as effectively pay for this type of code review, we can expect this to be way to get the review done.
What I have always wondered is what if some malicious hacker was able to add a backdoor to a distro that was on an official mirror a few months after it was released? By then, people would have gone over the code and not seen any backdoors. What reason would they have to go over it again in 6 months after the backdoor has been put in?
Remember it, write it down, take a picture, I dont give a fsck!
This was also done with ircii years and years ago. As I remember the backdoors lasted a while.
The article *completely* ignores the factor of how long it takes for a bug to get fixed. It's all very well claiming that OSS has as many bugs as proprietary, but when vendors of proprietary software have little to no incentive to fix problems and often depend on bug fixes to sell the next version of the software I'd go with the OSS solution, which is far more likely (and, in fact, this pans out in the statistics) to fix a bug much faster.
Ok, it was a bad example. However, I looked at the Mozilla source, smaller programs my friends wrote, and even basic .C sample programs from across the web, and it went right over my head. Sure, i'm not the BIGGEST, baddest programmer in the world, but I can hold my own.
People are reading the source code, but you have to be a 'black hat hacker' to understand it.
,-----.----...---..--..-....-
' CitizenC
' WebMaster, PlanetQ3F
`-----.----...---..--..-....-
The gentlemen who wrote this article is brilliant -- there is no doubt it my mind, and he definately raises some interesting issues.
.. not good at programming. Words like "compile", "./configure", and "make" were as forign to me as "Je parle francais comme une vache espanogle." ("I speak french like a spanish cow.") Once, I tried looking at the source code for BitchX. ONCE. The code itself was spread across a gazillion (I forget the exact number) files.
When I first installed Linux, I was
Now I DO know how to code. I'm taking my super-happy C++ coding classes in high school, so I know my way around a compiler and the like. So, after reading this article, I thought "hey, lets see if I can understand this NOW!" Guess what? It's still spaghetti code. I still can't unstand a stick of it, other then the PRINTFs and SCANFs. That's it. And I got a 98% in the class.
So I submit that it is not that nobody is reading the source for programs. Rather, TONS of people are reading it, they just don't know what they are looking at.
,-----.----...---..--..-....-
' CitizenC
' WebMaster, PlanetQ3F
`-----.----...---..--..-....-
I am reminded of the American Red Cross' philosophy toward swimming: "Every person a swimmer, every swimmer a lifesaver" or words to that effect. They wish to promote safety in the water by having everyone properly trained to a) swim and b) rescue swimmers in trouble. In the (perhaps never existed) golden age of computing, everyone knew enough about code to write things and understand at least some of other people's code. Some serendipitous results of the OSS movement may be to increase the pool of potential peer reviewers who are qualified to critique code, improve code readability and documentation, (save the whales, halt global warming, and put a chicken in every pot and shoes on all the world's children). Okay, I know. But I think it's possible at least that things will improve in this regard if not to the utopian "Every computer user a coder, and every coder a debugger" state.
I am quite civilized, and I should be brought a beer immediately. -- Bruce Sterling
Have a look at: Trojan added to TCP wrappers source on FTP and you will see this was done. It was less than a day before it was noticed by someone who downloaded and read through the source. This is of course an example of security related software so the odds on it being checked are > than luser toyz.
Maybe you live in interesting times
Well you'd probably have to decompile it or look thru the assembly code. Not an easy task. My one professor told us of that nasty little trick a few weeks ago, kinda makes you a little paranoid :)
I really, really, reaaalllyyy wanted to mention the fact that SecurityFocus had retracted the "weenies backdoor" in any of the articles aleady posted about said bug, especially since it seemed to have already been straightened out the first time around. By then, though, the anti-MS FUD had already taken over.
I guess that's what happens when you're doing things up to the minute...
--
--
E2 IN2 IE?
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.
I agree--it would be an interesting experiment, but my gut feeling is that the "patch" would be quickly ferreted out and removed.
The reason I say this is because there are some die-hards who dig into every patch, just to figure out what they do. Suspicious-looking patches would quickly raise a red flag. Aside from obviously malicious code, this includes code which seems unnecessarily complex, incorrectly documented, or is intentionally obscured.
It's not foolproof--I suppose you could build up a backdoor through a series of well-planned innocuous patches, but frankly, I like the odds better with open source than when you don't even have the source to begin with.
First of all, I am not a Linux zealot (though I use it daily), and I'm not a programmer. So, while I am not qualified to say anything, I hope I am seeing it objectively.
Everything in that article seems to be true, but I don't think it tells the whole story.
I remember reading something that Theo DeRaalt (sp?) said about the inherent security of OpenBSD. He said that while you can find at exploit security bugs in any OS, a bug only takes about an hour of work to fix. With OpenBSD, you get the patch as quickly as possible, but with commercial software, you have to wait and wait for an official patch to be released.
Moving on, I don't understand how that Thompson compiler (which inserts malicious code into the login program, and into itself when recompiled) is a serious problem. I'm running Red Hat 6.0, and my version of gcc came straight off of the install CD. If, for whatever reason, I needed a new one, I'd see if I could get another precompiled version from Red Hat or the FSF. THEY aren't going to screw me over, and if they tried they WOULD be caught very quickly.
It is true that having the source available allows crackers to discover potential targets, but this vulnerability doesn't seem to add up to much when compared to the advantages (securtiy-related, and otherwise) of having an open-source system. When crackers learn something new, it seems to spread very quickly. So quickly, I think, that it balances everything out in the end. In fact, it might actually tip the balance the other way, since you get a bug fix much quicker with open-source systems.
These are just my opinions, and I'm really not qualified to say much, but I thought I'd share them in case other people want to comment on them and correct any misunderstandings that I have.
take care,
Steve
========
Stephen C. VanDahm
MS's hotfixes and service packs are also free.
YOUR ignorance also borders on FUD.
No, the HOWTO is mine. You did E-mail me about it and I sent you a copy IIRC. Did you get it? If not, reply and I'll send it again.
I've helped people who are incredibly clueless when it comes to computers in general. They know how to use the tools of their daily work (that may be exellent) but they lack the deeper understanding that helpes you and me when something breaks or otherwise changes their environment.
They don't mind having an "expert" setting up their system. They *do* mind having to call support because their system crashes.
They want to learn and think about their *real* job and leave the backstage computer business to those who knows it better.
My car doesn't magically "just work". However I dont need to know every detail to drive it. If I'm completely clueless repairs will be expensive. If I spend all my time under the hood, making it run perfectly, I would have to find another job (or another girlfriend)
The same goes for computers. For most people there is a balance, where they know enough to avoid "deleting the internet" but spend most of their time doing "real" work.
All opinions are my own - until criticized
Unmaintained OSS and (even worse) unsupported closed source SW is a terrible risk.
Poorly maintained/supported code is only too common, and that goes for both the free and closed variety.
Was Streetlawyer trolling? a troll savant? Don't know. My opinions are (as usual) my own.
All opinions are my own - until criticized
The original post in this thread could be a slashdot troll (no not a "slashdot troll", they deal with a certain lady and hot grits. A *real* troll on slashdot), since it expressed a non-/.-cosher opinion. I didn't care, since I heard the same argument so many times by very sane people outside slashdot.
When you can state such main stream opinions for trolling purposes, it says more about the forum then anything else I'm afraid.
So if it was a troll it was a troll savant. (a term I hereby claim instantly copylefted)
All opinions are my own - until criticized
Unless they are sold as upgrades like Windows98/2000 :-)
Sorry couldn't resist. Actually I think Streetlawyer has a point.
"Open source" does not help you if you can't (or dont have time to) understand the source.
Most of the time "Open source" is not worth a shit without a maintainer. (Nor is closed source SW BTW)
I must know where to get the *latest* version, I must know where to find *reliable* developers. I must know how to handle "Fix it *now*, cost is not important" situations.
I need a solution that does not require an expert for daily use
And "I" in this case is anyone who is computer savvy, but makes a living with running computers, not by making them run.
Some OSS fulfills those needs, some commercial SW does too. Neither open or closed source rubbish does.
All opinions are my own - until criticized
The C compiler backdoor mentioned affected only people who installed the binary, /mnt/cdrom/SRPMS/* ; rpm -U --force /usr/src/redhat/RPMS/yourarch/* /usr/src/redhat/RPMS/noarch/*". You can't do something like this with closed-source software, so this is actually another argument for open source.
;) ).
instead of recompiling the compiler themselves - binaries that have been tampered with
can exist both in open source and closed source software. With open source, however, you can make sure you're actually using what the source generates.
If, for example, you're using Red Hat Linux and you don't trust us for whatever reason, all it takes is
"rpm --rebuild
While it is right that a lot of people just use open source applications than actually reading the code, the fact
that everyone can read it is still a big advantage - if someone breaks into my system, at least I can immediately figure out how and FIX IT instead of waiting for Microsoft or whoever to issue an updated binary.
Alternatively, if I don't have the knowledge to fix it, I can just hire someone to do it (probably cheaper than taking the server offline until Microsoft releases a fix).
Also, many people working on the same source has the definite
advantage that everyone can use other people's fixes - if someone finds a bug in, say, sendmail, and a Linux person finds a quick fix, chances are BSD users can just use the same fix immediately (and vice versa).
(Try applying an OS/2 fixpack to Windows NT as a counter-example in the proprietary world
This message is provided under the terms outlined at http://www.bero.org/terms.html
Actually the example you've cited shows that you SHOULD be using Linux (or *BSD or whatever).
You won't find any "Microsoft engineers are weenies!" backdoors in open source code, at least not a couple of days
after it has been released.
At Red Hat (the same is probably true of most other distributors), we do check
source for backdoors before putting it in the distribution. (Of course we can't guarantee we find all bugs that can lead to security problems though).
Also, experience shows open-source is usually FASTER at providing fixes, and you have the advantage of
"if your distributor doesn't provide a fix, just get it from another".
This message is provided under the terms outlined at http://www.bero.org/terms.html
It would seem far more useful to me if source was "open" in the sense
that you could get a copy of the code on production of a reasonable
description of what you planned to do with it, what improvement you
wanted to make, plus at least two references from people who were
prepared to establish your bona fides. Kind of like the criteria for
getting a reader's ticket to a law library.
For what purpose? I think you're misunderstanding the concept of open source.
It's not that everybody can just put in changes that will affect anyone but himself. No maintainer would permit a patch introducing a backdoor into the base release.
Even if a maintainer did it, someone else would notice, bugtraq, slashdot and others would inform the public, and that maintainer wouldn't keep the package for long (open source licenses generally permit forks), and a fixed version would be made available immediately.
Requiring to describe what you want to do is an unnecessary problem for people who just want to read the code for learning, or to see whether or not something can be optimized. Not every contributor will (or can/should) become a major contributor.
Requiring references is even worse - how would anyone get started?
If open source required references, I'd probably be cleaning toilets or selling shoes instead of working for Red Hat - when I got started, I didn't know anyone else doing open source stuff, so by your terms, I wouldn't have seen a single line of code, much less started extending and fixing things...
This message is provided under the terms outlined at http://www.bero.org/terms.html
:) I must admit I can't imagine what their code looks like - I've never worked in a closed-source environment or any other environment motivated only by salaries.
;)
However, this particular thing should be VERY easy to track down even in totally messed up code.
We all know the password is stored backwards in the binary, so it all comes down to searching for the string
"!seineew era sreenigne epacsteN" in the code, then looking where it's accessed and
removing that code.
Anyone @microsoft.com: Here's an offer. Give me the source code (to all of Windoze and this dll) and I'll fix this backdoor in less than 5 minutes. Only condition: I want to be able and allowed to
submit the code to wine for whatever use they see fit.
This message is provided under the terms outlined at http://www.bero.org/terms.html
Even if "Apache" is bug free, how can you tell that the disk you got passed by your third cousin who got it from his ex-boss who got it from "some guy" is?
Welcome to the world of PGP/GPG/etc signatures for packages. It is entirely possible to get a verified version of whatever package you would like-- just go to the "official" FTP site or mirror, and download the source AND signature, and verify it. The official version usually has all the latest secuity patches integrated (maintainers know that these are critical fixes, and integrate them tout suite) and will typically be signed by some manner of digital signature.
Of course, this does open up the problem that you allude to that anyone can sign a package (provided they have a key pair), but the maintainers of any package that you need to use will likely be involved in the web of trust brought about through the key signing process. For more info, see the PGP FAQ's and look for information about key signing.
It would seem far more useful to me if source was "open" in the sense that you could get a copy of the code on production of a reasonable description of what you planned to do with it, what improvement you wanted to make, plus at least two references from people who were prepared to establish your bona fides. Kind of like the criteria for getting a reader's ticket to a law library.
The release version of any package is going to be pretty well checked over by the maintainer, and from a trusted source. The resisitance to the type of bureaucracy that you recommend is one of the best things about the OpenSource community.
Now I DO know how to code. I'm taking my super-happy C++ coding classes in high school, so I know my way around a compiler and the like. So, after reading this article, I thought "hey, lets see if I can understand this NOW!" Guess what? It's still spaghetti code. I still can't unstand a stick of it, other then the PRINTFs and SCANFs. That's it. And I got a 98% in the class.
:) Go get some books.
Sorry, but you *don't* know how to code, no matter what you teacher says. If all you can identify is PRINTFs and SCANFs, I'm already thinking about the great programs you create. If you don't know how to program, source code isn't for you. Think of is as a feature.
--MSM
--MSM
iToday - Relevant technology news daily, free
Sure, the source code is available. But is anyone reading it?
They can or cannot. But if you don't build they won't come. Today how many programmers work with open source? It's kinda like saying in the early years of the car that it's better to have a horse, since with a car you didn't had roads to go everywhere. True, but this doesn't mean that the concept of a car is wrong. We can get to a point that there are more OSS than programmers, but as more and more companies adopt OSS, and put theis programmers to review the software they will use, this problem will be solved.
Even if people are reviewing the code, that doesn't mean they're qualified to do so.
True, and this is different of closed source how? But them you're comparing the knowledgement of the security review team (if there is one) on the company to the knowledgement of the entire world. Where do you thing would lie more people prone to find errors?
It is easy to hide vulnerabilities in complex, little understood and undocumented source code.
Yep, right again. But remember Netscape. How many years have they spend with a codebase hard to work with and extend? Slow and insecure? Why did this change when they openned the source? Because new people, excited to contribute needed something simples. Have you ever worked in a big software company, with 1st layer and 2nd layer managers? It's "do this, fix this and make it work". Building a house in sand.
People joke that Microsoft doesn't want to open Windows because people would laugh at its code. Truth is, OSS is different, you don't have so much tight control as in a company. Some people say to not mix code and politics, but we must, to understand OSS's potential. Understand how different things are in a company and in a mailing list. What would happen if Netscape decided to not use Gecko? Think about that. I was reading about a table bug in Netscape 4 that was discovered in Netscape 1!
There is no strong guarantee that source code and binaries of an application have any real relationship.
Bullshit. Trusted sources... The example given here was to an extreme. (it is, for me, the greatest hack I know of). If you don't trust the source, just compile the source. Truth is, we need better tools for software deployment. Ok if a bug is discovered a patch is issued in days. And then what? How many people among the users will issue the patch? Most of them will wait till the next version. We need something down to the OS level that could automatically update software and libraries from a trusted source. But then again, this is a problem with most programs and OSs.
Open Source makes it easy for the bad guys to find vulnerabilities.
Bullshit. Most of the vulnerabilities are related to input, when the software comunicates with the world. When it reads a file, accepts a data packet, etc. This in any software. You just focus in the 1% of the code that has something to do with external data. Data validation to avoid buffer overflow, invalid commands or characters, etc... This in an open or closed software.
But make no mistake, simply being open source is no guarantee of security.
Did anyone say that you just have to open the source to be safe? You mostly touched points that are related to both systems, but are easily addressably by OSS. It doesn't mean that all the open software out there that is open is ineherently better than a similar closed one, but that is uses a better method of development and debug proccess.
--MSM
--MSM
iToday - Relevant technology news daily, free
It might be true that not all fixes gets back to the publishers. When I find something that doesn't work, I fix it, and SOMETIMES I remember and have the time to report the fix back.
I know for sure that there is a bug in qpopper 3.0, which can kill the users instance of the process. I have one user for whom it has happened twice in the last 3 months that he was able to reproduce it with the current state of his mailbox and client. No further details until the bug is located and fixed.
This is one example of a known bug that has not yet been fixed. I have enabled debugging, and when it happens again in a month or two, I will be able to start locating the bug. But until then, I might be suspectible to a buffer overflow attack. I could just as well use FrontPage. I have the same security.
Yes, Free Software still needs a maintainer. Especially for official stuff. However, if the maintainer (say) gets in a bad accident and can't work for a month, someone else (or multiple people!) can easily adopt the project and keep going. There's the potential for code review, so if a million people use the software, and only a thousand of those (aside from the developers) actually read and examine it, that's still a thousand more than ANYTHING closed. And chances are that if there's something nasty in there, at least one in a thousand will probably find it and write a patch or start informing people.
-RickHunter
But it may give you the ability to read herring. I know someone who reads albacore just for the halibut. But then, he has a degree from Baitball, which is the largest School of Tuna. And while most of us can only work with hexidecimal notation, he has the ability to follow eight threads at once in octopus. I must admit, though, that his credentials are somewhat fishy. I guess it's time for me to clam up.
Erchie
Except you then pick a vendor whose software is constantly rated the highest security risk by most of the serious security spcialists and consultancies.
And, to make matters worse, if you ever tried to translate those 3,000 words of legalize that come with every MS product into English (Could someone upgrade BabelFish to do this? Must be worth a PHD ) it reads --- "Thanks for the money, if it doesn't work tough".
Old COBOL programmers never die. They just code in C.
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?
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
Molog
So Linus, what are we doing tonight?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
One point that was raised that strikes me crucial to the whole argument is the actual numbers of people reviewing the code. This is a very revealing statistic, and I wish someone out there would make a proper study of this, rather than rely on purely anecdotal data.
Personally, to be honest, I have only looked at a small portion of the entire Debian boxes which I run. The Windowmaker source and some kernel drivers. And even then, I did not have the experience or expertise to know if the code I saw was weak. And I know of SysAdmins whose recommendation was to install the RPM's and run. IMHO, we really need to evaluate the truth of this before we start selling open source as a panecea for insecure systems. Don't get me wrong - open source is still better than closed course software. But the benefits of this can be sold on its own merits, without having to FUD Microsoft.
Now I DO know how to code. I'm taking my super-happy C++ coding classes in high school, so I know my way around a compiler and the like. So, after reading this article, I thought "hey, lets see if I can understand this NOW!" Guess what? It's still spaghetti code. I still can't unstand a stick of it, other then the PRINTFs and SCANFs. That's it. And I got a 98% in the class.
For any project, serious or recreational, if it's spagetti code it will never reach its potential. Period. One person - i.e. the original author - may have a fairly comprehensive understanding of what the code does, but if nobody else can come close to understanding its functions without commiting major time to digging through the mess, it will never get the examination and development that having many people work on the code brings. Of my own personal projects, the early ones (before I discovered that copious comments not only made life easier but speeded up development because I could clarify my own ideas when writing the comments) are useless now, either as starting points for new projects or just for code reuse. My point is that for a project to acheive its intended goal, especially if security is the main focus, the source code has to be clear, well documented and fully modularized as far as possible. Failure to accomplish this, including random global variables floating all over the place and sections of code which end up getting treated as a black box because they are near-impossible to decipher, will leave a project falling short.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
If you grant that, out of the gate, there is nothing about Open Source software that makes it more secure than proprietary software, you cannot avoid the conclusion that Open Source is still more secure simple due to the fact that security patches come in overwhelmingly faster with Open Source products. But you would not even want to grant that premise, because, in well-oiled Open Source projects (not crap like sendmail), the peer review process *does* work, and it works well.
So, are we all damned then? Is open software deemed to be a flop? No, of course not. The reason being that most core people involved in develompemnt/auditing of open source software is pretty good at what they're doing, and they know their specific software (or part of the software) just as thorougly as their own pocket.
So I submit that it is not that nobody is reading the source for programs. Rather, TONS of people are reading it, they just don't know what they are looking at.
Taken that avarage rewiever weighs about 80kg, there will only go about 13 reviewers into a ton. That doesn't sound like to many. :-)
(PS! The arguments presented above were not targeted specifically on you. They were just meant as general ranting.)
Nah, he's just saying that having 98% in a prog course is not equal to the ability to read cod. I fully have to agree with that. Being a programmer does not help you in these matters. Maybe being a gypsy or something would. I don't know.
As RickHunter stated above, an excellent example of this is the apt-get front-end to the Debian package system. This is now a standard package with Debian.
You provide it with a list of trusted servers, and tell it which categories of packages (main, non-free, etc.) you want to get from that server.
Every once in (insert number here), you do this:
apt-get update
(refreshes list of available packages and version numbers)
apt-get upgrade
(Brings all packages up to the latest version. In some cases, it may decide to hold back certain packages if upgrading them might cause things to happen that you don't want to happen. If you want to upgrade these, you can do an "apt-get install ")
apt will prompt you for certain things (ie, to ask whether you want to keep your configuration files or install the new default ones), but it handles dependencies and is pretty much automatic.
Supposedly something like apt is now available for RPM, but I haven't checked.
WMBC freeform/independent online radio.
Well, it should at least be in WINE - maybe future Windows apps won't run without a .dll containing that phrase?
This article does make very interesting reading and raises quite a few points. Initall reading would say it was on the 'open-source' side, but it left me with the feeling it was more on the 'closed-source' side.
Yes, open-source software will have hackers et al examining the code, and not many 'real users' may look at the code, but the article omitted to make the point that when the bugs are found they are very quickly fixed - unlike recent Microsoft bugs where they are still denying that these bugs exists. In open-source software they would have probably been confirmed upteen times and fixed (not just 'worked-around') by several different people.
It really just depends on your viewpoints I suppose and whose pocket you may or may not be in.
Richy C.Richy C.
--
Now, let us just pause a moment and think here. What is the most popular webserver software - Apache. Is it open source or closed source? Ditto for Perl, sendmail/qmail, Linux/NetBSD, the DNS software etc.
If system administrators couldn't examine the code would they trust such mission-critical system on this software? They might not look at the code, but at least they've got the oppourtunity if they feel the need. It's all about choice.
Richy C.
--
That isn't true. How about this:
By reading this comment (or clicking this box, or opening this package, etc) you give me the right to kill you. Now, when I'm holding the smoking gun, I'll have a hard time staying out of jail.
IIRC, Dr. Kevorkian made his patients sign documents disclaiming his actions. Wasn't he convicted? I really can't remember, I wasn't really following it very closely...
But, how many people have the time and initiative to read through poorly documented code looking for potential problems? Not a whole lot. And the fact that any 12-year-old can install an RPM with a graphical tool, and any 13-year-old can ./configure; make; make install doesn't help any. Finding bugs means sticking your hands in the source code and compiling on some alternate and unsupported system (Win2000, Solaris, Darwin, Minix, etc) with a different compiler, different libraries, etc.
There is no strong guarantee that source code and binaries of an application have any real relationship.
There is if you roll your own, you fool.
I woke up this morning, I was feeling kind of high, it was me, Jesus Christ and Haile Salassie I.
The article quite astutely points out something that's been bugging me for a while -- that open source software likes to pretend it's analogous to the concept of "peer review", whereas it's actually "review by any boob that can manage to do ftp:", which has no equivalent in the scientific community. Either back-door bugs are obvious as hell, in which case they could be picked up by review by ten people, max. Or they're not all that obvious after all.
Furthermore, the more people there are checking the source, the more there are out there introducing bugs, for the hell of it. Even if "Apache" is bug free, how can you tell that the disk you got passed by your third cousin who got it from his ex-boss who got it from "some guy" is?
It would seem far more useful to me if source was "open" in the sense that you could get a copy of the code on production of a reasonable description of what you planned to do with it, what improvement you wanted to make, plus at least two references from people who were prepared to establish your bona fides. Kind of like the criteria for getting a reader's ticket to a law library.
-- the most controversial site on the Web
I'm running my own little IT law practice here, and I sure as hell can't walk into all those line numbers and start deleting things. So I have to trust it to someone else. And who do I trust? Some random "consultant", who'll probably put in a new back door of his own, plus a trojan to blackmail me with later? Or Microsoft, who for all their faults, know that they have to produce fixes for these things on a timely basis.
See, this is the "hobbyist mentality" which presumably explains why nobody I know uses Linux, et al. It's all fine for one guy running his personal homepage, and for a homepage, it may be the best you can get. But for someone who actually wants to do something with a computer, they don't have the option of spending valuable billable hours grovelling through code because someone wanted to call their competitors "weenies".
-- the most controversial site on the Web