Slashdot Mirror
Open-Source != Security; PGP Provides Cautionary Tale
Porthop points out this "interesting developer.com story
regarding the security of open source software, in regards to theories that many eyes looking at the source will alleviate security problems."
It ain't necessarily so, emphasis on necessarily. Last week it was discovered that, in some (uncommon) cases, a really stupid brainfart bug makes PGP5 key generation
not very random.
The bug lived for a year in open-source code before being found. If you generated a key pair non-interactively with PGP5 on a unix machine, don't panic and read carefully; you may want to invalidate your key. Update, next day: several people have pointed out that although
PGP5's code
is available (crypto requires code review), it can't be used for any product without permission. Incentive for code review is therefore less than for other projects of its importance, and I really shouldn't have called PGP
"open-source." Mea culpa.
Would this "bug" have been discovered if the source was closed?
Umm... since when is Open Source = security?? Somebody has already posted this link on a previous story already. It describes a kind of trojan that not even source code auditing can prevent.
But of course, seeing that slashdotters never bother to do their research (in spite of habitually telling newbies to RTFM), here comes my obligatory Slashdotter response poll :-P
Poll: Most typical response to this article:
Poll Mastah
I'm actually really grateful to see something like this happen.
Not because I'm anti-open-source, or anti-PGP. Because I think that open-source has led to a few bad habits
1) It's 'good' software. By this I mean most people (Including myself) think that the software, while looking like it works - does exactly what you think it's doing. Oh, some other programmer has checked it I'm sure. Unfortunately I don't think that's the case anymore, after releasing a few things myself - and receiving one piece of feedback for about 1000 downloads.
2) Constant upgrading. I do it. You do it. Everyone does it. I'm not saying that constant upgrades are a bad thing, but it does seem that releases (Aside from the more major of projects) are tested at any deep level. This is more of a bad habit of programmers (Once again I raise my hand, I suck at Q&A) I'd love to see some open source Q&A people inside a project.. I've yet to see an internal release be posted before going up. I know that's what the x.x.1 version is for, but a lot of bugs shouldn't even be in there and they're from 4am coffee splurges and should be checked by friends or whatnot.
3) Ripping code that isn't tested with that setup. *cough* This part really bit me once with some network stuff. Ohh, they did it this way - I want it that way too! Not the best approach in my experiences. It's great to re-use code, but check it out first. I've seen snippets from other peoples code that is both broken and misused, and of course causes small bugs to show up in the app.
K, that's my rant. My 3 bad habits anyway.
Dacels Jewelers can't be trusted.
I think the principle that people are missing is that, all things being equal, a bug/security hole is going to be found a LOT quicker by examining the source than by simply using the program.
I used to think that security through obscurity was a valid security model, reasoning that so long as no one knew how or why something was built, at least in source terms, than it would be better for everyone. A person can't exploit something they don't know is there. The largest problem with the obscurity model is the fact there *are* people who just look for exploits. they get home from work/school and hack away at these utilities. By not allowing the source to be released, and scrutinized, you're going to see bug-fixes arrive later than they should, you're going to see exploits that go for months/years completely unpatched. This makes for all around buggier programs, and, by inference, more exploitable programs.
Open source is by no means the best practice in some specific situations (at least right now). There are other factors than just bugginess and exploitability that software manufac's take into account. But in *general*, the open source model is much more effecient and robust than the *alternative*
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
"It is seldom that liberty of any kind is lost all at once." -David Hume
If it were proprietary, would anybody have even found it? This isn't exactly a fair comparison, as I'm sure you could find a bunch of bugs like this in proprietary code if you could just look at it. OSS will always be more open to critizism because the source code is actually there to criticize!
If I had no sense of humor, I would long ago have committed suicide. -Ghandi
Does this mean that Microsoft now employs about 5 staff worldwide? So far I yet to see Microsoft get it "right". Yes opening up code to a million eyes does mean that more idiots see the code, but it also means that more vetern programmers see it. When was the last time you took a look at any Windows source code?
So a bug was discovered in Open Source software, big deal. It'll get fixed and people will move on. To fix a bug in Windows, you first have to beat Microsoft over the head serverly with it, then, when they deny it exists, you have to create some program that illegally demostrates their bugs. Only then will they admit that there was an unplanned "feature (read bug) and will promptly proceed to shut your program/site/self down permanently... oh and if they get some time... maybe... they might fix the bug (in service pack 13).
Background: I've been auditing GPG lately for using it as a high-throughput non-interactive key generator. So I have some right to talk about this.
Everybody, generating keys non-interactively is ridiculously difficult, because to be honest there's a very small amount of entropy in your system. Clock differentials and specific CPU traces are pretty good, but everything else other derives from the network(and is therefore remotely attackable) or traces itself back to PRNGs(various memory assignment algorithms, etc.)
That's not to say that this isn't a problematic bug, and that it doesn't need correcting. But non-int keygen just isn't that common(yet; I'm working on that), so the exposure is thankfully smaller than it otherwise might be.
As for Microsoft, to be honest I have very little confidence that the RNG's in any web browser are anything that would survive an audit by Counterpane Labs. MS does very good stuff; crypto isn't generally among them(though any of us would be a fool to not note that they're shipping 128 bit SSL by default.)
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
is that having a lot of people staring at the code does not find the
really nasty bugs. The really nasty bugs are found by a couple of
really smart people who just kill themselves. Most people looking at
the code won't see anything
contributing and achieve a high standard."
Open-source is more secure in thge long run, but is less secure immediately.
The idea is that security through obscurity is perfect until someone finds the hole, then it's worthless. In contrast, when using an open source solution, the security is inheirently flawed, because there is no obscurity, but as time goes by it gets less and less flawed, as responsible people find and patch holes, to the point where it's a safer bet than the obscure method.
The most effective real-world security may be to combine both, or only use open methods that have been analyzed long enough that they're virtually certain to be secure.
The security of obscure methods is simply harder to quantify, and you don't know when they become worthless.
Kevin Fox
Kevin Fox
This is true, but that was not the problem. The problem was that they were assigning the read count to the array that was supposed to hold the values that were read! Since they only read one byte at a time, the array always contained the value 1.
...
;)
Here is this relevent code:
char RandBuf;
for(i = 0; i <= count; ++i) {
RandBuf = read(fd, &RandBuf, count);
From the read man page:
ssize_t read(int fd, void *buf, size_t count);
On success, the number of bytes read is returned
As you can see, RandBuf was being set to the number of bytes read, instead of the byte read.
In fact, I have my own issue with that code. The for loop should read:
for(i = 0; i < count; ++i)
But I am not very familiar with the context of this code. The original code would loop count + 1 times while my version will loop count times. This may or may not be the desired behaviour. I guess I'll go send in another bug report
Anyone notice that Extrans doesnt seem to be working? or is it just me.
Those who do not know the past are doomed to reimplement it, poorly.
If you want people to carefully look over your code, make sure that you put an error in it, one that generates a really obvious error. I've been using this technique for a long time now, and it's worked wonders.
Those PGP people are too competent for their own good. If outsiders trust PGP too much to check it, everybody loses.
On a related note, my own incompetence has saved me from this bug--because I've never memorized the command-line options to PGP, I have to use it interactively.
No one thinks open-source makes software invincible to bugs. Anyone who does... well I have some magic beans I'd like to sell you.
The peer-review aspect of open-source is just a nice feature, and actually works most of the time. It isn't an ultimate and guaranteed aspect of it.
People trying to be smart saying that "oh most people looking at the code aren't qualified." Wow, such a revelation. Yes, we thought there was a mystical army of highly trained CS experts poring over all open source code for bugs.
Things slip through the cracks, even in the scientific community's peer review. Humans aren't perfect. Get it through your head.
And yet, people fail to turn this accusing finger all the way around and wonder the same about commercial software. They just excuse it saying "Oh their jobs depend on it, they must check it."
The major driving force in open source is that the programmers actually *use* the software they create. If a bug is found, they *want* to fix it because they are using this software too. They are directly affected. In the case of commercial software, even expensive software, they are not directly affected. Does Microsoft really want to fix bugs? No, it costs them money. In most cases, compatibility issues require companies to buy their software anyway.
So you might say "Hey paying a lot for softare ensures getting good software because the company can pay for experts to pore over every line of code for bugs." Well yeah, but who says they will? They'll only do it as long as it's profitable. Then you'll be stuck with the bugs as fast as you can say COBOL. Oh wait, it will be worse than that because you CAN'T fix it.
No one said open-source was perfect, and just because it isn't doesn't mean the alternative is automatically better.
Maybe there should be a Frequently Used Arguments list. I bet a whole bunch of posts say about the same thing I have. That was a pretty stupid flamebait comment in that article. Oh was it supposed to make us stop and think about something? There are better ways to do it than pasting FUD-style(yes, it was.) flamebait.
Against: If you open the source code, you are making it much easier for crackers to find flaws in your system.
For: Yeah, but there will also be good guys finding flaws too, which will let us fix the bugs faster.
For: If you close the source code, it doesn't mean that crackers won't find flaws. A determined cracker will get in, eventually.
Against: Yeah, but just look around. There are a lot of good guys finding holes in closed source software as well, e.g., Bennett Haselton of Peacefire.
For: Yeah, but the many eye-balls effect is a unique advantage of open source. Closed source software doesn't have that.
Against: Well, the many eye-balls principle is just that, a principle. As this article shows, a lot of people just assume that others are doing the security audit; most are not competent to find flaws even if they are looking; nobody wants to look at a tangled mess of C code, etc. In reality, if your program is not an obviously security-related product (say it's your run-of-the-mill application), you've to admit that many eye-balls won't find any problems there. But a lot of systems are still put at risk because of these "applications".
I think what the critics of open source security are missing is the deterrent power of open source. If they are really right in their claim that more crackers than good guys will be finding flaws in my program, then that's a strong deterrent for me to just code away as I wish. I have a sort of moral responsibility for the code I write (the warranty disclaimers notwithstanding) and I would be peeved if a cracker penetrated a system because of gaping security holes in my work.
The incentive for writing better code is that much lesser if I know that "hell, who's going to be spending time disassembling this code, I've got a deadline to meet".
Sreeram.
----------------------------------
Observation is the essence of art.
It doesn't look like open-source provided an advantage in finding this bug. But because PGP is open source, there are still two advantages:
- The nature of the problem was found. Had this been closed-source software, we likely would have known the keys were non-random but would have no clue why they were non-random under certain circumstances, at least until the creator decided to release this information.
- I can fix the problem. Literally minutes after viewing the Slashdot story, I was in the process of rebuilding my copy of PGP5 after having modified it to fix the bug. I would still have been waiting on a fix for a closed-source program.
As far as I can see, open source still provides advantages over closed source when it comes to finding and fixing bugs.The number of errors in that code is truely disturbing. Here's my contrib for a first try at a decent fix. I hate the code layout though :)
/. tho :) My apologies if gt's or lt's go missing.
/* Make sure we have a count */ /* Make sure we have a valid filedesc */
/* Allocate a buffer for the count, and check we got a valid alloc */
/* If the read fails, bail */ z eof(unsigned char));
/* Free buffer */
God knows whether this thing will format ok when it turns up on
Not too comfortable with the sizeof(unsigned char) stuff, probably better as something like sizeof(*ReadBuf). Anyway, I'm sure theres plenty of errors, get stuck in.
static unsigned
pgpDevRandomAccum(int fd, unsigned count)
{
unsigned char *RandBuf;
unsigned i;
pgpAssert(count > 0);
pgpAssert(fd >= 0);
RandBuf = malloc(sizeof(unsigned char)*count);
pgpAssert(RandBuf);
for (i=0; icount; i++) {
if (!read(fd,RandBuf,count))
break;
pgpRandomAddBytes(&pgpRandomPool,RandBuf,count*si
pgpRandPoolAddEntroy(256);
}
free(RandBuf);
return(i);
}
You can't win a fight.
I am a good programmer, but I am *not* a security expert, nor do I have the time to learn how to be one on top of my other responsibilities. I don't want to use M$ products like IIS and ASP, but I know that if I do - and if a bug or security hole is found - it will pretty much be written off as M$' fault, and not mine, although I will probably have to go back and fix the damage
However, I choose open source software, and we get hacked, my company will *definitely* view it as my fault. Now, I'm not one to play it safe, and I've got Linux/Apache/MySQL/PHP/Perl running all over the place, but still.....this topic makes me worry.
It shouldn't matter which technology you use. if you get hacked, it's your fault or it isn't regardless of which set of stuff you pick. Obviously, if your employer or whatever is going to assign blame because you picked something "weird", you have to cover your ass.
But the point I want to make is that it doesn't matter if you're a security expert or not. Someone, you, the OS vendor, the web server vendor, has already screwed up. There's a decent chance that someone might find said screw-up. If they come after you, you'll be defaced, and there's not a lot you can do to prevent it. In such a situation, the thing to do is to prepare a plan on how to react and recover.
This includes things like buy-in for downtime to apply patches, whether or not you'll want to do forensics and prosecution, or whether you'll just try to get back on line as quickly as possible.
The advantage of open-source is that you'll probably get a patch quicker, or you might even be able to make your own when you see a vulnerability report.
Jamie, before you go stating that "OSS != Security," please consider:
PGP's license has never met the Open Source Definition (it's free to use only under certain circumstances). Despite this technicality, your headline is stupidly sensational and self-defeating. Wouldn't it have been much better to title it "Key Generation Bug Found in PGP 5"?