Open-Source != Security; PGP Provides Cautionary Tale
Posted by
jamie
on Sun May 28, 2000 10:15 PM
from the no-silver-bullet dept.
from the no-silver-bullet dept.
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.
This discussion has been archived.
No new comments can be posted.
Open-Source != Security; PGP Provides Example
|
Log In/Create an Account
| Top
| 225 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
open source sees more bugs (Score:3)
Open Source != Security (Score:3)
Umm... since when is Open Source = security?? Somebody has already posted this link [acm.org] 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:
Open Source contributions. (Score:4)
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.
Open Source and Security (Score:3)
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
Somebody found it didn't they? (Score:3)
Which cave were you living in all this time? (Score:4)
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).
Non Interactive Keygen is a Hard Problem (Score:5)
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
Bill Joy on many eyes... (Score:3)
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."
Re:open source sees more bugs (Score:3)
Slashdot is almost as insecure as Windows, and delivers only bare-minimum security.
I challenge you to find a security bug in any version of VMS past 4. This is one of the most closed, propritary operting systems in production, and also one of the most secure (even attained B2 - when is an open source OS going to get a security rating?)
Missing the point. (Score:5)
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
Re:Linux has a entropy pool based /dev/random (Score:5)
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.
Security Through Carefully-Chosen Incompetence (Score:4)
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.
Damn it. (Score:5)
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.
Re:Which cave were you living in all this time? (Score:3)
If you read the EULA on the pirated Microsoft software that you install, IT CLEARLY STATES THAT MICROSOFT HAS ABSOLUTELY NO ACCOUNTABILITY OR FAULT IN THE FAILURE OF SAID PRODUCT.
Open source as a deterrent (Score:3)
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.
Re:Open Source and Security (Score:3)
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.
No. Finding any type of bug by using is a heck of a lot easier than finding bugs by examining source. Just imagine auditing 50k lines of source. Now imagine using a program, and discovering some subtle flaw in the output, like the wrong number of significant digits in some tabulated data displayed on a web page.
The value of Open Source is not the ability to find bugs, but to fix them. In fact, one of the strong motives for free releases of betas is so that the program will have lots of users, thus increasing the chances that bugs will be found before the official release.
It would be interesting to do a study. I bet that if you graph bugs/line it falls proportionately to the number of users for both closed and open source programs.
In other words... test Test TEST. And then test again. And when your finished testing, you might want to consider some tests.
Open Source still has an advantage (Score:4)
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.Disturbing (Score:3)
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);
}
Re:The scary part. (Score:3)
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.
Ready, Aim (at foot)... (Score:3)
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"?
Re:Non Interactive Keygen is a Hard Problem (Score:3)
Best solution I found mentioned hooking a AM radio mistuned up to the mic port--then people mentioned FM had more entropic properties. Your big problems are, 1) You've seriously got to deal with the fact that a 60hz bias is coming off of the nearby AC transmitter/power supply, and 2) an attacker can pretty easily broadcast patterns at you on the exact frequency you're trying to be mistuned to. Since anything that's receiving a signal is also transmitting it(thus causing major privacy issues when a parking lot scans to see what stations people are listening to by picking up their "sympathetic"(corrent word?) retransmissions), you should remotely be able to determine the AM/FM band being used. Not Good.
I was thinking for a bit that deriving entropy from a the differential sync between many different NTP servers might be decent, but A) This doesn't scale and B) The differential sync, even at the minute scale, likely isn't more than a couple bits per resync. So you'd need to scan a few hundred servers a dozen times before you could create a 2048 bit key.
I need to create about 200 of 'em. A day. Soon to be 500. *sigh*
Interesting thought of the hour: Randomness isn't contained in the numbers themselves. Is a Royal Flush random? Depends how it was dealt.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Re:Ready, Aim (at foot)... (Score:3)
Comments like yours are our editorial accountability :-)
Many crypto bugs are hard to find. This bug should not have been. Passing in a pointer to a buffer and then assigning the function result to that same buffer? I bet there exists an automated tool which understands the parameters to read() and would find that error.
It's not like read() is an obscure system call. Using it improperly like this is practically criminal.
And I never said "OSS != Security," in fact, I explicitly said the two were not necessarily equal, "emphasis on necessarily."
OK, you got me there - Dan Kaminsky also wrote in to mention that its license prohibits commercial use, adding "many of the eyes that would have otherwise been directed at the PGP codebase wouldn't touch the product."
I'm not entirely sure that's true. PGP should naturally attract a lot of eyes by virtue of being high-profile. Many of the people who would be or should be looking for bugs like this one are up-and-coming cryptographers, for whom finding a bug in PGP would garner street cred. They wouldn't care whether they could use the code commercially.
Still, point taken. Let me talk to a friend who knows PGP better than I do, and I'll look into revising the headline and/or updating the story in the next few hours.
When we get two submissions that are both important, and related, it makes for a more interesting discussion to link them together. Unfortunately I think many readers are only reading the PGP story, and skipping John Viega's excellent article [earthweb.com] - or at least there hasn't been much discussion of it, which is a shame.
Jamie McCarthy