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
From what I've noticed over the past few years, most projects have a small circle of core developers that understand enough of the source to actually catch subtle bugs. The 'many eyes' concept tends to be another one of those 'in theory it should work' conculsions. Not to knock open source projects, because many are absoultly amazing in their accomplishments, yet tend to suffer from inner-circle syndrome.
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
Read this article by John Viega, one of the authors of Mailman. He talks about how Open sourced software does not necessarily mean security, how many eyes on does not mean they will look for loopholes, and why. Also other interesting points.
This is a complete joke, if a person wants to find a security hole in a program don't care one bit if their copy of the source code was obtained legally, they will just get it any way they can, whether it be downloaded from an illegal site or decompiled themselves.
The friendly programmers however, do care about the legality of their source code, and are the ones who will gain access through open source.
So quite simply, open source means little increase in hackers finding flaws to exploit, but gives a huge increase in the number of programmers solving the problems.
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 article mentions two very important aspects unique to open source projects: security audits and obfuscated code. I know that I hate looking at spaghetti code and the world of open source community development can be great spaghetti code generator. It works but can be very difficult to debug. Under strict development guidelines this can be reduced (e.g. NASA space shuttle code). Unfortunately, it's going to be difficult to dictate a strict programming model when the programs are developed on the programmer's own time. Plus, security audits by other companies is something that OSS can't afford (unless a company like Red Hat pays for it). Yes, I know that many security experts examine the Linux OS and its code. While I still believe that Linux is more secure that most OSes out there (especially Windows 98/2000), we should not be zealots. Commericial development houses can enforce standards and pay to have extensive external audits.
GnuPG is okay, right?
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
"This problem was found by Germano Caronni , and verified by Thomas Roessler and Marcel Waldvogel . "
I.e. If it wasn't open-source the problem would *STILL* be unfound. PGP 5i isn't a bazarr developed app, so it still has all the 'benifits' of commercial development. It was OSS that found that bug.
OSS make it more secure. The article that claims otherwise is irresponciable journalism.
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
PGP 5i doesn't meet the DFSG (or the OSD), so it's not open source. In particular it fails the "okay for for-profit use/distribution". Lots of people refuse to even both with the new PGPs, especially with GPG out now.
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.
While no one argues that open source provides perfect security, it isn't fair to say that open souce is insecure. Bottom line: what would the likelyhood of discovering this bug and getting a fix out be if the source was closed?
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.
make some money
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!
Likewise, you can't argue that Closed Source is or isn't Secure, because closed source could be more secure if it's professionally audited, or it could have blatantly dangerous bugs pass through if it's not.
I think what I'm really trying to say, is that I'm not surprised, and I don't understand why everyone else is surprised about this. Good thing they found the bug though!
the real at&t mix
One of the problems I see is that a lot of the users who download and run Open Source software have no desire to learn to program and couldn't contribute to the security even if they wanted to. Just because a piece of software is downloaded 1,000 times, doesn't mean that it's been downloaded by 1,000 programmers who have a could understand the source.
http://crummysocks.com
On the second link of this article, if you scroll up, you will see convincing evidence that open source software has nothing to fear about security competition from closed source software.
Here is a direct link, read the first article, although I doubt you will be surprised.
Those who do not know the past are doomed to reimplement it, poorly.
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.
i looked at the report, and it does not appear that your assessment is correct. the problem is in pgp5i, being that it does NOT read from /dev/random where it should. it doesn't matter if the entropy is there or not. basically the problem was something like
randomBuf = read(random_fd, &randomBuf, 1)
intending to read one random byte into randomBuf. which it does in evaluating read, but then promptly overwrites that value with the return of the call to read, which is the number of bytes read, which is always 1 (unless you get an error, but how often does that happen?)! so the buffer is always '1', even on linux. damn, if that doesn't suck.
a comment on the issue of open source having more eyes on the code...
it may be nice to have more eyes on the code, but what worries me is testing. it's what even the most experienced coder wouldn't think of that can come up in those really weird deviant test cases, after which you smack your forehead, say "shit!", and fix it. true, we have tons of people using and reviewing the code, but does it really get as rigorously tested as when, in commercial development, people are paid to do nothing other than put it through the wringer? just a thought.I guess I'd be interested in knowing how long the flaw has been in the code, and also who wrote this particular block of code.
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.
Slashdot's choice of "sensationalized" headlines is getting to be as bad as the mainstream media! saying that PGP is proof that opensource is insecure.. That is the most misleading headline I have ever read.. I would almost call it blatently lying.
If PGP was NOT opensource this "flaw" would have never been released to the public. this is why Opensource works. Yes it took a YEAR for this flaw to surface. BUT IT SURFACED! Besides, pgp is pretty sophisticated software, it makes the linux kernel look like a "hello world" program.
Over the past few weeks, I have seen some very por choices for headlines, you guys either need to hire an editor to process stories before publishing, or start thinking before posting.. (Gee, something all slashdotters should do!)
I would hate to compare slashdot reporters with that of the holland sentinel's or muskegon cronicles reporters (Sensational first! facts last!)
change that headline or post an apology, PGP is proof that Opensource is more secure! (If microsoft owned pgp, they'd call that a feature!)
Do not look at laser with remaining good eye.
My other first post is car post.
I propose a new method of security programming that takes the best from both models.
Just imagine; the security and stability of Win2000 excellently obfuscated with the ease of use and proprietory extensiveness of all *nices.
I call it "Steve"
"Anybody who tells me I can't use a program because it's not open source, go suck on rms. I'm not interested." (LT 2004)
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.
a) Its Rob's site he can do as he pleases.
b) Having your postings at -1 is hardly censorship. I read at -1 all the time.
c) Arguing that having a post at -1 is censorship is like saying "hey, my letter to the editor in your newspaper isn't on the front page, I'm being censored!"
d) Did I mention its Rob's site, he can do whatever he wants? If you don't like it, you are free to post / go elsewhere.
DrLunch.com The site that tells you what's for lunch!
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.
Windows is stupid? What do you expect? 50% of the population has an IQ under 80. - Trivial Pursuit
huh? Isn't 100 the median IQ? Doesn't that mean that 50% of the population has an IQ under 100, not 80?
DrLunch.com The site that tells you what's for lunch!
That wasn't the problem as count was always set to 1 by the caller anyway, although it is very poor coding because, if count has to be 1, why bother having it as an argument. asking for bugs.
The actual bug is assigning the return from read() back to Randbuf. DOH! Turning on compiler warnings probably would have found the bug at the first compile, because the conversion from ssize_t (the return type of read()) to char loses precision. (and I would argue is one of the many implicit conversions in C that shouldn't exist anyway).
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.I've been wondering where that moderation choice is?
I guess that it'd be ripe for abuse with people marking opinion as misinformative, but hopefully moderation/metamoderation guidelines could sort that out.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Comment removed based on user account deletion
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.
Comment removed based on user account deletion
(-1, Strawman)
nuff said.
"Patience is a virtue, afforded those with nothing better to do." - I don't remember
Hey people, don't you realize that this is the same kind of argument as:
"What do you mean, smoking causes lung cancer? My grand-father smoked all his life and he lived to see his 100th birthday!"
Now come on! It's obvious that open-sourcing a program won't magically turn it into a secure one. Just the same with smoking: it won't automatically mean you'll develop lung cancer. It's all about average. You can say that, in general, open-source program (especially those about security) will be a lot safer if everyone can look at the code and check if it has holes. Yes, this bug stayed around for a long time. So what? If the program had been closed source, it's quite possible that it would never have been found. It's not because something breaks a general trend that it automatically nullyfies this trend. Don't jump into the propaganda band-wagon!
Religion is the best example of mass psychosis
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"?
shouldn't your read be !read(fd,RandBuf,1) as per the Buf-Fix that was posted :)
:wq ~ ~ ~ ~ ~
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 how do we deal with bugs in open source software?
How do we deal with bugs in closed-source software?
---
Dammit, my mom is not a Karma whore!
(Of course, it would be kinda difficult to break into a system by exploiting a non-random PGP key)
...
Got Warez?
To get my first Windows application running was painful, but to figure out why it was blowing up after a couple hours of use was a nightmare. I formulated dozens of theories as to what could be the problem, and disproved many of them. Finally at one point I inadvertantly changed the order in which I allocated my memory blocks, and the problem magically vanished. This, and hundreds of bugs like it are daily worked around and forgotten by programmers who have given up wasting their time with the no-solution solutions from Microsoft. Bugs like these are found, squashed and shared in Open Source products.
If you code the innards, there is just no comparison, nor is their any counting the number of bugs much more disruptive than the PGP bug you've mentioned, that will never be isolated and fixed in proprietary code, because there's no money in it.
Name a single piece of microsoft software that is used voluntarily. You can't because there isn't any. People use MS office because they have to be compatable with MS Office, and microsoft makes sure no one else can be 100% compatable. People use Windows because they still are forced to buy Windows on their computers.
In the server market, Microsoft provides the grease in the direction of using all microsoft products, and the walls come up as soon as any other product is used. Sure Samba makes a good file/print server, but if you want PDC compatability with NT clients and servers, you gotta pay Mr. Bill.
Once anyone in the company decides they want groupware someone points out there's always Exchange, which works with Outlook, but if you try using anything else, on either side, it's just a shoddy mail server and a creepy mail client. So you get roped into buying Outlook for everyone and using Exchange for at least the in-house mail (though only a free product will work properly for internet mail, interestingly enough.)
Microsoft's products do not play well with others, and that has been the cornerstone fo their existence, making sure that if you want to work with other companies who use microsoft, you have to buy microsoft too. They got away with it because they had no competition initially and were able to break other people's products at the OS level later.
Of course either you are a troll or have not paid attention to the Microsoft business model.. in either case you can be excused for making a simple mistake.
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"
if this were a closed-source program, how long would it have taken the security problem to come to light? And the point is by that time, there have been more layering of important code coming from the one piece of buggy code.
--------- Beware the dragon, for you are crunchy and good with ketchup.
I have one acronym for the masses:
GNUPG!
"The majority of the stupid is invincible and guaranteed for all time. The terror of their tyranny, however, is allev
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
disagree, because you talk so much speculation and not much more.
You seem to know a lot about the demographics of Linux use. You should probably go out and exploit this straight away (selling Pokemon Linux maybe?)
Professional programmers make lots of mistakes too: look at Microsoft or Apple (or any other software company). Buggy code doesn't usually get people fired... they just get moved around. If you're that poor a programmer, and you don't get out voluntarily, you're making your own hell.
-T is highly commendable, but -w is better (but of course, that *is* what you meant).
And to bring it back to the topic, security rests in the processes you use, rather than in the software [Shneier]; an open peer review process may not catch everything, but it's better than the alternatives, imo. Agreed that there is a risk in *assuming* that oss is safe simply because it's open.
do you code, troll?
dec
Okay, I'll give you that... But I think the article about software engineering for the space shuttle had it right. The reason there's so much buggy code out there is because coders don't pay any (or enough, anyway) attention to the fases of the coding process before the actual code-writing. If you spend enough time designing (as in specifications, etc) before coding you can get pretty close to flawless code....
.,@
Why is it that in most other disciplines the process of creating something is regulated in detail, while coders always just seem to hack their way through till it works? We need a change of attitude.
By the way: I'm as bad as the next guy... I love to hack, I hate the design-process
xchg
xchg
jmp emailMe
In a closed source system how long would it have taken for it to be found? And how long would it have taken the company to actualy own up to the fact that it existed?
We've all heard this speil before. The consept of "security through obscurity" is antiquated at best and down right ignorent at worst. In a closed source model a company dosn't even have to admit that the flaw exists let alone work to fix it any time soon. Microsoft is famous for this (ya ya...I know...microsoft bashing...don't take this the wrong way. I'm sitting at a Win2k box writing this so don't just chaulk it up to me being another microsoft hater). They have made an art form out of using the terms "Its a feature not a bug" and "We put it there for a reason, but, ummm, we can't tell you why because its a trade secret". Microsoft fielded Hotmail with a bug that allowed anyone to read the accounts of 40 or so million subscribers, password or no password, and never bothered to apologize. How long did it take them to even admit that they were valnerable to something as small and stupid as an OOB attack let alone release a patch for it. Or to stop shipping there OS's and DUN patch to consumers (read consumer as people who shouldn't be expected to know what VPN is let alone know how to secure it) with VPN support left in a wide open insecure state.
Microsoft bashing aside most other companies are just as bad. PcAnywhere is shipped out with a default profile that allows unencrypted connectings from anyone, consumer firewalls and DoS protection utilities are a joke at best, etc.
The closed source software community has no accountability. You've all seen the line "This product comes with no warrenty express or implied not even the implied warrenty of merchentability or fitness for a puricular purpose" in shrink wrapped licence agreements. Come on...what that basicly says is "oh...we know we advertised this as a secure product but we don't actualy have to make it one...or even make it function at all if we don't want to"
We don't except this attidude with any other product that we buy why do we exept it with software? Software manufacturers don't have to produce a quality product because there is no liability if they don't. And the effect of this for security products is that manufacturers don't have to produce products that are actually secure, because no one can sue them if they make a bunch of false claims of security.
The thing that open source software provides is a small messure of accountability and a way to fix the problem even if the origanal producer dosn't give a rats ass about it. If you make something thats junk in an open source model someone somewhere is going to call you out on it and that someone has the code to back them up and if you don't respond in an intellegent manner to the problem (just don't care or use another line MS is famous for "oh...that will be fixed in service pack XXX which will be released on insert date made up of insanly bignum's here") the end user has the recourse of either a: fixing the problem themselves or b: making the problem widly known so that someone with a better understanding of the programming language, etc, can fix the problem for them.
The OSS model is *not* perfect, far from it, and anyone who ever claimed that it is should cut down on the hallucinagens, but even given its inharent problems its still a damn site better then the alternative of just being able to say "I didn't do it, can't prove a thing!!!"
And yes I know my spelling/grammer sucks tonight but as its 3:30 in the morning here and I'm just heading to bed so you can live with it just this once ;)
--
"The Net interprets censorship as damage and routes around it."
-John Gilmore
PGP cannot provide an example of Open Source not meaning security because PGP IS NOT OPEN SOURCE!!!
bye
schani
Recent chipsets from Intel (see the doc) contain a hardware random number generator. This is interesting as an additionnal source of randomness, especially in servers where the usual randomness provider (i.e. the user in front of the keyboard and mouse) is not there. [Granted, a server is connected to a network, which tends to supply randomness too.]
What is the common wisdom on that new "feature"? Should it be trusted?
When someone finds a security hole in closed software (Outlook) - everyone jumps at the chance to say Obscurtiy != Security, and the people as M$ are all a bunch of idiots for making those mistakes.
When a security hole is found in an Open Source project, it's simply a "brain fart" and it doesn't "necessarily" mean anything. The double standard is ridiculous.
It's cases like this where I'm happy that at least with close-source you have someone to blame, rather than open-source where everyone can pass the buck with the phrase "Well, if you're so concerned, why don't you do it."
I think Jamie Zawinski was on to something when he said:" You can't take a [...] project, sprinkle it with the magic pixie dust of 'open source,' and have everything magically work out."
--Me
I have a sig, and this statement is false.
As this applies to PGP ist does not have anything to do with Open-Source. GPG is the Open-Source project, NOT PGP. Hell, why should anyone use PGP in first place? GPG is the only clean solution.
Yup. You either missed the fix or added a new bug - you decide which since its your code. Your suggested code will loop "count" times reading *UP TO* count bytes each time which means you will read up to (count * count) bytes which is not what is expected. If your code had !read(fd,RandBuf,1) then you would read up to count bytes total. The other fix would be to add some "count -= bytesRead" code in the loop.
You could build a random noise generator easily and cheap. Here's an example circuit. The idea is to amplify the natural noise of a transistor (white noise) and then hook that to soundcard. Cost is < $10 + the price of wallwart.
I think most (honestly critical) people would say that the higher the number of eyes checking a body of code the lower the mean bug lifetime will be. But, as with any distributed value, one can always get a measurement way out on the tail of the distribution. This is why anecdotal evidence is not very useful for trying to find out how some quantity is distributed.
After all, the number of crypto-nerds staring at the pgp5 source code during source code scanning (rather than illegally exporting - there we go again - they want the elgal loophole, not the practical attack), and during all bug hunting afterwards must have been in the hundreds, but yet this bug stays there for a year.
And don't knock M$ here - have you seen some of the papers they've published? Did you know that Product Cipher works for them know (the author of Magic Money)? They have some of the top guys working for them, but these guys work on real world apps, rather than crypto-crap like untraceable money and new algorithms we don't need.
On a related note, you might be interested to read a talk I gave at HIP 92 on PGP. I don't know whether they ever fixed the most serious problem, that of being able to undetectably modify/truncate unsigned but encrypted messages, and to be honest, I can't be bothered to check - give me S/MIME anyday. Gary
But not for long (a few weeks).
Enjoy.
Gary@hotlava.com
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..
Then why does he have a $90,000/year sallary for running it and 366,666 shares of Andover.net stock?
Doesn't make any money my ass..
They're debating security addons on the list and refusing them almost unanimously because they seem to be all spec no substance. Frankly I would just add the security as an option and at the same time develop my own. Perhaps even raise the issue with the spec writers. There's no telling what the kernel hackers will do, but I do see them doing more than MS would do in a lifetime.
The message on the other side of this sig is false.
The same way I don't need a copy of Goodyear's tire design to slash a tire.
Obscurity is acop out.
The message on the other side of this sig is false.
>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!
>Under strict development guidelines this can be reduced (e.g. NASA space shuttle code)
Got a link for this?
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.
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??
okay, the reason i sound pissed off isn't that nobody's reading the article. it's that people are so eager to hear that the failure is due to some inherent difficulty of the problem. it's not. it's a goddamn bug--the kind everyone predicted would be more absent in magical open-source software. this puts the lye to the claim that "with a million eyes, all bugs are shallow." christ, this bug was incredibly shallow anyway, and managed to live in the code for a year.
sh_
Interested in learning Chinese or Japanese? check out Chinese/Japanese-English Dictiona
- The size of the bazaar (number of participants) affects the "health" and success of the bazaar, even if not a pre-condition to successful bazaar startup.
- Not simply "size" but "effective working size" has important implications for the continued progress of the product and strength of the bazaar.
- Debugging by testing includes factors which give the bazaar a very much smaller "effective working size"
- There are alternative debugging methods which might be used to counter a small "effective working size."
- There are activities and natural progression which tend to erode the "effective working size" of the bazaar over time.
Visit RocketAware - hundreds of categories, tens of thousands of links.Open source software and the FAQs, info, and Q&A needed to use it. (For software developers.)
The whole issue of many eyeballs finding bugs in OSS code only works if people are actually looking. Just because the code is open does not mean thousands of developers are looking at it/working on it. How many people are actively looking at something like Apache, compared with PGP?
You have to remember that the reason ony piece of Open Source software is successful (meaning popular, reliable, high-performance) is that people are actively interested in it. A year ago, when Apple decided to open up their Darwin components, there was this big hoopla, but in the end, how many people really cared about it, compared with, say, existing GNU/Linux projects?
Open Source is a social phenomenon more than a technical one.
Yeah, ok, everyone may think MS is the big evil because, "They don't let us see their code!" Whine. Whine. Whine.
I have always been of the opinion that this whole idea of letting a lot of people look at code to keeps out bugs was a total joke. I'm sorry, if I had to trust a programmer that had the skills I did 10 years ago to maintain a piece of code, let alone to develop an algorithm that performed better than exponential time, I'd have a lot of problems on my hands today. The fact is, any monkey can learn a programming language. Any monkey can write an algorithm that "works." This "hole" just goes to prove the point. Don't get me wrong, I wouldn't generalize this incompetence to the point that I'd believe that every OS programmer is a monkey. Come on though, a fricking high school kid adding a k-k00l mod to a time critical application? I don't think so.
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?
a) I know this, but isn't the site about community and not dictatorship? Slashdot is more than Rob and kin posting stories. Slashdot is also the trolls, karma whores, me-tooers, and the random intelligent posters.
b) The default threshold is +1. Not counting the fact that most people will leave it at this, few people ever set their threshold to -1. They think it's nothing but mindless trolls spewing endless lines of caps and junk.
c) See b).
d) See a). Also, I like this site. I'd hate to see it lose all sense of community because someone decides to babysit Signal 11 and make sure no one goes against the party line.
Also, does open source man really deserve a bitchslap? His posts are the most humorous things on slashdot. All the +5, Funny posts are something along the lines of "BilL HaTeZ suX0RZ my C0ck0r!@" There's a big difference between writing a pedophilic incest story and a several page play staring the teen, pouting, firm natalie portman.
Isn't the whole point of moderation and karma being overridden when Rob steps in and bitchslaps someone? The system is written, let it handle itself. If it's not working, figure out something else. The slashcode is publicly available with several active developers registered on it, surely the "thousands of eyes" that are so often mentioned in support of free software could help out with developing a system.
No, I don't see it as my holy right to have slashdot run as I see fit. I just don't want to see it run down because someone decides to instate totalitarian control over it. Slashdot consists of more than just the code, the hardware, and the people running it in the background. Slashdot is us.
I concur with the 2 ACs. You're the reason I stare at natalie portman with wanting eyes now. I thought she was kinda sexy (if a little underripe) in the professional, but you rekindled my love for her youngness and vibrance. You, sir, are a hero. So much of slashdot is missing out on your posts because you default to -1. Poor ignorant bastards.
Here's a very worrying thing about the interactive key generation.
Whenever I use PGP 5.0i on linux to generate a key, it says immediately ``Thanks, that's enough'' after it requests random key input.
Question:
Does this mean that the interactive key generation is not taking any randomness from my input?
If so, then my keys are in big trouble.
Comment removed based on user account deletion
All of a banks protocols are open, at least as far as your money is concerned. Go in and talk to one of the reps-- they'll tell you exactly what money entrusted with them is being used for, what interest is being returned, etc.
Much Love,
"S"HM
*****
(I refuse to spellcheck out of contempt for your belief system)
I know this wasn't the point, but how about having a game (FreeCell?) collect the time between moves. This could be stored in a file to be used for randomness generation. Whenever the supply of randomness started getting low, the user could be directed to play the game for awhile (wouldn't everyone just HATE that!)
For improved performance, several games could be modified to collect the random statistics, and some sort of "normalizer" could modify the timings so that they were within a standard range.
(Of course, this would create a brand new file that was in need of VERY careful protection from intrusion, so it might not be the most secure of methods, but then ANY infected system is vulnerable, stored keys or not.)
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
What worries me is that the suggested fix is also incorrect. When you are doing something as important as key generation, you shouldn't just ignore the return from read! You should check for a failed read and handle it appropriately (where the definition of "appropriately" depends strongly on the PGP code and perhaps a bit on the /dev/random code, neither of which I have the time to read at the moment, unfortunately).
No serious Open Source advocete ever said that Open Source was the magic bullet for better security. It is true that several less informed have interpeted several statments by the more vocal 'leaders', but tha actual assertion is that Open Source code allows for a greater chance of discovering such errors.
Every test that can be made on closed source code can be made on open source code. Open Source also gives you the advantage of being able to see the code and find out what and where an error might be.
The real advantage isn't the ability to find it fast, in fact Open Source security holes and closed source security holes are found with about equal speed. The real advantage is in the speed at which the fix can be made.
In the example of the PGP problem, the article gave the fix. All one would need to do is find the offending line, replace it and recompile. It is likely that updated source files and binaries are already available, and binary patches won't be far behind.
In the closed source world, we are left up to the dictates of a company to decide when or if it will get fixed. Many closed source products have had published holes in their code for years, which is to be fixed "in the next release". With Open source, such things can be rectified more rapidly.
This is the "security advantange" of Open Source. Having the code available does give a small advantage of finding an error that way, but the great advantage is the ease of fixing it when a problem is actually found.
There is a civil war coming in the United States. Remember which side has most of the guns
Atom-Age makes a box that will produce good random numbera at 19.2Kbaud..
http://www.nshore.com/atom_age.htm
Starman97@Gmail.com (bring it on spammers)
Comment removed based on user account deletion
Comment removed based on user account deletion