In the midst of the hubbub over the Microsoft "backdoor" recently uncovered, ESR took the opportunity write to Slashdot about why this can't happen in Open Source software.
Apache has never had an exploit like this, and never will. Nor will Linux, or the BIND library, or Perl, or any of the other open-source core software of the global Internet. Open-source software, subject to constant peer review, evolves and gets more secure over time.
Is he right? Should we try to put a backdoor in Perl source to prove him wrong? :-)
Too late.
chip on 2000-04-17T07:57:27
Well, it's not really a back door, but it is undocumented behavior that nobody seems to have noticed is possible. It reports an apparent attempt to subvert suidperl:
if (PL_rsfp = PerlProc_popen("/bin/mail root","w")) { /* heh, heh */
We should at least add a Configure variable for the actual location of the mail binary. :-)
By the way....
chip on 2000-04-17T07:59:06
.... Eric is, as usual, trying to set the terms of debate. And, I think, he's doing a very good job of it. He may get flamed by the geeks who think he's being simplistic, but just watch -- next time there's a trojan or back door, dozens of geeks will chime in with "Open Source would have made this impossible."
:-)
Perl doesn't ride on the OS tide.
Well, I'm not a huge ESR fan anyway but this article made such huge generalisations it was all rather fluffy and pointless.
He appears to define 'Open Source' as 'famous Open Source software that everyone knows and loves and hasn't had any major security flaws recently'. One might point out just how long it took to fix some of sendmail's horrors.
Open Source has not by definition been extensively reviewed, and I would guess that most Open Source software has been very narrowly reviewed. Sure the big famous stuff has plenty of eyeballs, but what about all the little bits and pieces that fill freshmeat and 1000 other 'my free program' web sites.
The knowledge that an independant 3rd party might have read the code and might have understood it and might have seen a problem and might have reported it and it might have been fixed doesn't thrill me much beyond the fact that for certain software the 'might' becomes an 'almost certainly'.
Good news is that since Perl is one of these, I guess we can count ourselves in.
I've never really felt that Perl rides on the tide of Open Source - indeed, it is more the other way around. Perl is, and has been, a genuinely innovative thing. It is good because it is _good_ not because it is open source.
Re:Perl doesn't ride on the OS tide.
mock on 2000-04-20T00:15:37
Aleph1's recent article on securityfocus.com
http://www.securityfocus.co m/templates/article.html?id=19 makes many of the same points as you do. As well, he makes the point that the people reading the source may not be knowledgable enough about security issues to properly audit the code. Why else would we keep seeing the same type of exploits being used over and over again (buffer overflows, symlinks, failure to drop privs, bad crypto)? The Dansie Shopping cart problem that recently came through BUGTRAQ is a prime example of this; the source was available, but until something went wrong, nobody thought to check it for security problems. In this case, there was a blatant back door in the code that had been there for some time. This was code written in perl, so there was no excuse not look it over. Come to think of it, what opensource project other than OpenBSD has actually undergone a code audit for security? I don't think there's much of a solution to the problem other than making people aware of the problem, and publicly embarrasing them on mailing lists if they code something insecurely (especially if they put a back door in).
Some day Reality will match the rhetoric...
Elian on 2000-04-21T19:28:22
I do wish Eric would stop with these sorts of nonsensical declarations. There's nothing inherent in Open Source that makes these back doors impossible, nor particularly obvious. Heck, Ilya could have a dozen back doors scattered in the regex code and nobody would notice. (And this is not counting buffer overrun possibilities as back doors) And someone with full repository access could do all sorts of damage.
We're counting on the honor and integrity of the keepers of the source with the big OS projects just as we are with binary-only releases. OSS is arguably less secure, since potential attack points (like buffer overrun issues and lame cleanup code) is visible to be exploited, while with closed source projects the vandals at least have to go to some effort to ferret out the vulnerabilities.
Examined source is only secure after the bugs have been fixed--before they've been fixed it's less secure.
