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
Meaning that...
/dev/random when it is used non-interactive.
pgp5i will eat out of
In linux, with entropy based random (take time between irq requests into a 'pool', then feed into randomness generator as seeds) it is just fine.
Its the other unicies that are broke, not pgp5i.
-- dieman - Scott Dier
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
The reality of the issue is, at least in the few projects I'm involved with, that just distributing software in source format doesn't mean it will be looked at. Not by the end users (this is obvious), but not that much by developers either -- even the core developers usually divide workload by assigning module owners and such, and as a result, code in someone-elses-module rarely gets properly reviewed. Sure, someone might keep an eye on the commit logs but that's hardly a decent way to review evolving code.
So, with regards to security issues, I think things boil down to this: unlike proprietary, binary-distributed software, open source as a distribution mechanism isn't explicitly designed to prevent code review.
If the opportunity for peer review has been left unutilized in a single project, others can use the example to learn. Open source isn't about automatic benefits in software quality -- it's about making work towards better software possible.
Marko Karppinen
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
staticunsigned
pgpRandPoolAddEntropy(256);
pgpDevRandomAccum(intfd,unsignedcount)
{
charRandBuf;
unsignedshorti=0;
pgpAssert(count);
pgpAssert(fd>=0);
for(i=0;i<=count;++i) {
RandBuf=read(fd,&RandBuf,count);
pgpRandomAddBytes( &pgpRandomPool,(byte*)&RandBuf,sizeof(RandBuf));
}
return(i);
}
If count is anything over 1, that call to read() is gonna stomp on the stack.
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."
PGP is NOT opensource developed. It's OSS released.. I.e. cloistered programmers code away then a 'final' product springs forth from their loins fully formed.
The bug was found by outsiders, so OSS made it more secure.
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
Not that I want to bash on the topic, but I think that, "Open-Source != Security; PGP Provides Example" is going a little too far. The linked page says, "Chances are very high that you have no problem. So, don't panic." It says that this only effects the "PGP 5.0i code base". Is the topic supposed to scare everybody out of their shoes to rethink open-source software? I believe that this topic is going a little too far considering that this software probably isn't being looked over by too many people anyways. Oh please, Slashdot, don't turn into ZDnet!
The article that I read said nothing of the kind, but rather, said, 'Open-source advocates tend to assume that open-source code has been thoroughly reviewed for security by the many-eyes theory, but this isn't necessarilly true.'
The alternative of closed-source was mentioned, and dismissed as not being any better.
This article was, in short, saying 'this is a shortcoming of open-source' but it was -not- rehashing the security-by-obscurity argument from the closed-source camp, but discussing the fact that those many eyes may not be looking as close as we assume.
Your response makes -no- sense at all, and has -nothing- to do with this article. It's an answer to the -usual- security debate around open-source but has nothing whatsoever to do with -this- article.
--Parity
--Parity
'Card carrying' member of the EFF.
The scary part is not the hole in PGP. That's been found, and if it hasn't been fixed already, it will be very shortly.
The scary part is things similar to this that HAVEN'T been found.
I get the feeling that the really succesful crackers are probably the types of people who spot things like this and never mention them, just exploiting them for their own use.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
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.
PGP used to be developped in a closed-source way.
Consequence : unseen bug.
Since viewable by open source community, the bug was discovered.
Far from being a demonstration of the insecurity of open sourced code, it's a perfect example of the contrary.
-- javaDragon is an instance of JavaDragon.
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.
That's like coding while saying "We don't have to handle that case; it'll never happen". Bad code is bad code, whether or not the effect is immediately seen.
"Patience is a virtue, afforded those with nothing better to do." - I don't remember
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"?
Nope. Because I allocate the correct buffer length etc, and because I don't assign the read return value into the buffer.
You can't win a fight.
So somebody finds a bug in a open source product, and suddenly that's a proof of how insecure open source is ?
Gimme a break ! This is a proof of the contrary.
Seriously folks, how many bugs like this do you think exist in closed-source commercial products ??
You know, the type of softare where you will never know about bugs like this.
--
Why pay for drugs when you can get Linux for free ?
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
in proprietary code, we'd all have to break laws to even demonstrate that it was broken.
Here we can see that it is fixed, and we can learn from it. _we_ are assured that it was our error of omission, noone else's.
I am willing to pony up and say I screwed up for using open source without reading the source. I have no problem accepting my part of the blame.
"No good deed goes unpunished"
Decaying of a radioactive element? Funny, that. Just read about some guy with a parallel port geiger counter and a microcurie of Americium.
There are better sources that are more environmentally sound--dirty diodes and whatever they've built into the Pentium III look pretty decent.
--Dan
>
/* burn it.*/
...)
> Versions 2.* and 6.5 of PGP do NOT share this problem.
>
This is how this was fixed in pgp 6.5i:
if((fdesc=open( devrandom, O_RDONLY|O_NONBLOCK)) > 0) {
while((numread = read( fdesc, buffer, BUFFSIZE)) > 0) {
for( p = buffer ; numread > 0 ; numread--, p++ ) {
PGPGlobalRandomPoolAddKeystroke(*p);
*p=0;
}
RandBits = PGPGlobalRandomPoolGetEntropy();
StillNeeded = TotalNeeded - RandBits;
}
}
<conspiracy mode>
This bug was introduced in PGP 5.0 and fixed in PGP 6.5. Why wasn't
this reported on bugtrack, a long time ago ? Although the code is
substantially rewritten, I am would be very suprised if the author
of this code in 6.5 didn't see this bug (after all he fixed it
</conspiracy mode>
RFC1925
PGP cannot provide an example of Open Source not meaning security because PGP IS NOT OPEN SOURCE!!!
bye
schani
In this particular situation, the bug was eventually found, so yes, it did work, it just happened to take a year. There are bugs in certain other operating systems that took 4 to 5 years to find. Prime example: The bugs *STILL* being found in Solaris 2.5.
:-)
Now, lesse how long it takes for there to be a source patch to correct the problem. I bet it doesn't linger for months and/or years as other OS's due.
Heck, look how long it took MS to fix the darned smurf attacks..
-- I'm the root of all that's evil, but you can call me cookie..
This is not hypocrisy (or even hipocrisy), though. PGP isn't open-source, its licensing is a pile of pants.
.|` Clouds cross the black moonlight,
However, the source is available so the bug has *been* found *and* located, and most importantly a world-verifyable patch has been produced. Beat that, you closed-source fanatic you...
If M$loth make a mistake they try to close it up, which is utterly stupid. If an open-source project has bugs, they get fixed.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
>I don't use ANY stolen Microsoft software any more.
Good for you!
Given that if you are using stolen Microsoft code your rights are nill, what rights and accountability did you GAIN by buying that Microsoft code?
The EULA applies, and the quote of "MICROSOFT HAS ABSOLUTELY NO ACCOUNTABILITY OR FAULT IN THE FAILURE OF SAID PRODUCT." is valid.
So, lets connect the dots, as you won't answer the accountability question, and instead launch into a comment on stolen software.
Lets look at OpenSource
1) You claim No accountability
(Reality: Most OpenSource has a contract that says the author is not responsible and is to be held harmless)
2) Code is aviable to fix bugs if you find one
3) Bug fix time can be under a week
4) Abandoned programs are supportable by users who find the program still useful
Now lets look at closed source
1) Contract claims No accountability
2) No code is aviable to fix bugs if you find one
3) Bug fix can be never
4) Abandoned programs are abandonded, never to run on newer platforms
Looking at this list, OpenSource puts a burden of responsibility on the user to support themselves, whereas because you can't support yourself with closed source, the burden is (supposed) to be elsewhere. Yet, no closed source company has a LEGAL RESPONSIBILITY to take on that burden. If you are not into personal empowerment or the rights of individuals to control the tools they use, I can see where the 'promise' of some closed source behemoth holding your hand and guiding you along is a sedutive siren song.
As you are an opinionated AC, the question is this: What accountability does Microsoft have to their code?
If it was said on slashdot, it MUST be true!
If you send an unsigned message, then ANYONE can corrupt it, alter it, or trunctuate it.
The idea of message signing is to PREVENT such things. If you don't sign your message, why are you expecting PGP to protect you against attacks which only message-signing would prevent?
There are two rules with PGP:
1. If you don't want anyone without the correct key reading the message, encrypt it.
2. If you don't want anyone to undetectably alter the message, SIGN IT.
The two are orthogonal considerations.
If this bug happened in proprietary software.....
Would it have ever been found?
Would the company have advised its users that they might have weak keys that should be revoked? Or would they fix the flaw silently and keep their customers in the dark?
Open source has other advantages for the consumer.
You can also use an FM radio that does not have muting: tune it off frequency and the FM discriminator will spit out band limited white noise. However, the same caveats apply, and the nice thing about the diode approach is that nobody can screw up your random number source with a simple carrier of reasonable amplitude.
Of course, you always could use a Lava lamp
www.eFax.com are spammers
More and more, good randomness is critical for important computing functions such as encryption. I think it's entirely reasonable for CPU's or other hardware components to include an analog source of randomness, like a tiny white-noise generator. Do any big chipmakers plan to do something like this? If not, why not?
this bug has absolutely nothing to do with how hard it is to find random data. hell, the solution is to call dev/random. it's just that the buffer happens to get overwritten due to a far more mundane bug. ferchrissakes, did you even read the article? did any of the moderators read the article??
/dev/random.
Yes, I did read the article. Your annoyance is understood, however.
/dev/random, rather than the internal entropy engine, was being called in the first place *because* non-interactive entropy gathering is such a difficult problem. PGP had no similar issues when used interactively because they essentially wrote their own interactive entropy gatherer. They couldn't do the same for non-interactive content, so they wrote a (buggy) bridge to
Obviously, they should have verified that the content coming *out* of that bridge was something other than all ones. But the most interesting thing to me is the similarity of this accident to an airline crash or a school shooting--an intensely rare situation, made notable and newsworthy *by* its rareness. We pay little attention to the moderately common problems(invisible security issues lurking beneath most closed source cyrpto), but both the extremely common issues(buffer overflows) and rare ones(this PGP hack) get lots of press.
Interesting.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Yes, a standard CFB or stream encryption algorithm has that weakness. Which is why you usually combine it with an (encrypted) CRC or cryptographically sign it. These are protocol-level issues.
And the fix is obvious, you said it yourself. If you don't sign the message in some fashion, you deserve to lose. Signing the message prevents most (all?) of these attacks.
If you do a 'gpg -e', you had better know what the security issues are. Of course, this applies to using ANY encryption software, no matter what settings you use on it. If you don't know your encryption software and what the options mean, you shouldn't be using it.
BTW, just including (and encrypting) the hash of the decrypted message isn't enough to protect against these attacks.
If the message is for multiple recipients, recipient A could decrypt the message, alter it, compute the correct hash for the altered message, and then repackage and send the altered message along to the other recipients who will accept this message as legitimate. To prevent this, the hash of the correct message should be 'signed' in some fashion where only the origional sender can create it. This process describes GPG's 'sign' option, which we know works.
Signing and encryption are orthogonal features and needed in different situations. If I am sending details of an auction to N people, I don't care who reads them, but I do NOT want them to alter the messages sent to the other recipients. If I just encrypt the message but leave it unsigned, noone can read the messgae, but they may alter it. (Admittedly, not very useful for communication, but useful for storage. For example, storing private stuff on a hard drive/floppy.) Finally, I may encrypt and sign the message.
You could consider it a user-interface issue. Maybe GPG should (by default) sign the message whenever the user requests encryption?
[[BTW, if you want to take this conversation to email, I'll be happy to. Unfortunately, my email address no longer works; I can email you.]]
Damn. you're right :) Is a new bug *frown*, I guess I should probably get rid of the loop, but without knowing exactly the function of the procs below the read I can't be sure what is appropriate. Rats.
You can't win a fight.