Re: Debian libssl security (Cause???)
On Fri, May 16, 2008 at 04:02:48PM -0400, Ted Unangst wrote: On 5/16/08, Ross Cameron [EMAIL PROTECTED] wrote: Mmm this isn't the first time I've heard of bogus reports from Valgrind. How does one politely inform the Debian project to not trust it explicitly and to human audit anything it flags? I think people are placing too much blame on valgrind. valgrind doesn't tell you Delete this line of code. It says You are using uninitialized memory here. The correct fix is to initialize the memory, not delete the line of code. It's not about trusting or not trusting the tool; it's about responding correctly. I've seen innocuous valgrind reports, but never wrong ones. I also saw a valgrind report ignored as innocuous because it didn't seem to cause trouble, only to be the root cause of a problem that cost a minimum of $50,000 to resolve later. Yeah, using tools such as valgrind can help a lot, but the danger side is that it will cause actions to be taken by people who do not understand the code, just to silence valgrind. Since valgrind flags the location of the use of uninialized mem, and--of course--not the root cause, developers can easily be mislead and apply the wrong fix. I think we have a clear demonstration of the danger of using a tool without proper understanding of the code here. In addition, the vague posts from both sides on openssl-dev mailing lists did not help too. -Otto
Re: Debian libssl security (Cause???)
On Sat, 2008-05-17 at 08:36 +0200, Otto Moerbeek wrote: Yeah, using tools such as valgrind can help a lot, but the danger side is that it will cause actions to be taken by people who do not understand the code, just to silence valgrind. Since valgrind flags the location of the use of uninialized mem, and--of course--not the root cause, developers can easily be mislead and apply the wrong fix. I think we have a clear demonstration of the danger of using a tool without proper understanding of the code here. In addition, the vague posts from both sides on openssl-dev mailing lists did not help too. -Otto This might be a good example. I'm working on a CLI which is rapidly turning into a mini-shell. I'm not using readline, or other commonly used things to gather input, for the purposes of my own learning and keeping code portable I've elected to write my own functions. Every time I make major changes, I run the program through valgrind. Example results: ==10858== ==10858== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1) ==10858== malloc/free: in use at exit: 48 bytes in 5 blocks. ==10858== malloc/free: 12 allocs, 7 frees, 4,182 bytes allocated. ==10858== For counts of detected errors, rerun with: -v ==10858== searching for pointers to 5 not-freed blocks. ==10858== checked 63,724 bytes. ==10858== ==10858== LEAK SUMMARY: ==10858==definitely lost: 37 bytes in 3 blocks. ==10858== possibly lost: 0 bytes in 0 blocks. ==10858==still reachable: 11 bytes in 2 blocks. ==10858== suppressed: 0 bytes in 0 blocks. ==10858== Use --leak-check=full to see details of leaked memory. As you can see, my program is in its infancy and not much is allocated. I have a leak due to some input stuff not freeing things that are strdup()'ed (I know about this) and I have done a pretty good job of being defensive so far. If something I inherit from libc leaks or throws errors, I quickly know and can explain it. Its not my program, its stuff I used from xxx function. Valgrind is something that is (ideally) used as you go. If you screw up, it will tell you. It should not be dismissed like trivial compiler warnings, but it should also not invoke some kind of knee jerk reaction. Its not exactly the world's best auditing tool for someone who is not used to using it every step of the way. Taking something you are unfamiliar with and trying to correct whatever valgrind complains about is asking for trouble beyond trivial warnings. What amazes me about this whole mess is that at least 1/3 of the GNU core utilities issue many complaints but they are ignored. When you package software, the only reason for squelching the valgrind results of other people's work is to keep those who install your package from asking about those warnings. Like I said in previous posts, shit happens. Nobody needs to be nailed to a cross for this. The lesson to be learned is: Q. Why does your x-y-z package throw so many warnings? A. I am not quite sure, I'm going to ask the developers who wrote it. Well, I know why its happening, but I can't quite be sure why the code that causes it is in there. Cheers, --Tim -- Monkey + Typewriter = Echoreply ( http://echoreply.us )
Debian libssl security (Cause???)
Anyone got any thoughts on what the Debian project has been doing to OpenSSL to have caused this in the first place?
Re: Debian libssl security (Cause???)
On Fri, May 16, 2008 at 01:31:54PM +0200, Ross Cameron wrote: Anyone got any thoughts on what the Debian project has been doing to OpenSSL to have caused this in the first place? yes, read the stuff posted earlier, it contains all relevant links. To summarize, to silence a bogus valgrind warning, almost all seeding of the PRNG used by openssl was removed. -Otto
Re: Debian libssl security (Cause???)
Mmm this isn't the first time I've heard of bogus reports from Valgrind. How does one politely inform the Debian project to not trust it explicitly and to human audit anything it flags? On Fri, May 16, 2008 at 1:41 PM, Otto Moerbeek [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 01:31:54PM +0200, Ross Cameron wrote: Anyone got any thoughts on what the Debian project has been doing to OpenSSL to have caused this in the first place? yes, read the stuff posted earlier, it contains all relevant links. To summarize, to silence a bogus valgrind warning, almost all seeding of the PRNG used by openssl was removed. -Otto
Re: Debian libssl security (Cause???)
From: Ross Cameron Sent: Friday, May 16, 2008 8:31 AM To: Otto Moerbeek Cc: misc@openbsd.org Subject: Re: Debian libssl security (Cause???) Mmm this isn't the first time I've heard of bogus reports from Valgrind. How does one politely inform the Debian project to not trust it explicitly and to human audit anything it flags? On Fri, May 16, 2008 at 1:41 PM, Otto Moerbeek [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 01:31:54PM +0200, Ross Cameron wrote: Anyone got any thoughts on what the Debian project has been doing to OpenSSL to have caused this in the first place? yes, read the stuff posted earlier, it contains all relevant links. To summarize, to silence a bogus valgrind warning, almost all seeding of the PRNG used by openssl was removed. -Otto That only works if the people who are explicitly human auditing the software is smart enough to know that you can't implicitly trust something like Valgrind anyway. So telling them isn't really all that useful (if they were that smart, they would already know). I'm not saying that the Debian devs aren't smart, I'm just saying that they aren't smart enough that I would trust them to build a secure system. This is why I use OpenBSD instead of Debian Distorted Dingo oh wait... or is that some other linux that uses the stupid names? oh well... s
Re: Debian libssl security (Cause???)
* Ross Cameron [EMAIL PROTECTED] [2008-05-16 14:30:39]: Mmm this isn't the first time I've heard of bogus reports from Valgrind. How does one politely inform the Debian project to not trust it explicitly and to human audit anything it flags? On Fri, May 16, 2008 at 1:41 PM, Otto Moerbeek [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 01:31:54PM +0200, Ross Cameron wrote: Anyone got any thoughts on what the Debian project has been doing to OpenSSL to have caused this in the first place? yes, read the stuff posted earlier, it contains all relevant links. To summarize, to silence a bogus valgrind warning, almost all seeding of the PRNG used by openssl was removed. -Otto They probably have figured it out. This is a pretty big screw-up--it was in the tree since September 2006. You don't do something this bad and not learn from it =). -- Travers Buda
Re: Debian libssl security (Cause???)
On Fri, 16 May 2008, Travers Buda wrote: They probably have figured it out. This is a pretty big screw-up--it was in the tree since September 2006. You don't do something this bad and not learn from it =). And now the social engineering fallout from it as well with all the 'new SSL certificate'-style phishing that was in place before this event... -- Monty Brandenberg, Software Engineer MCB, Inc. [EMAIL PROTECTED] P.O. Box 426188 [EMAIL PROTECTED] Cambridge, MA 02142-0021 617.864.6907
Re: Debian libssl security (Cause???)
On 5/16/08, Ross Cameron [EMAIL PROTECTED] wrote: Mmm this isn't the first time I've heard of bogus reports from Valgrind. How does one politely inform the Debian project to not trust it explicitly and to human audit anything it flags? I think people are placing too much blame on valgrind. valgrind doesn't tell you Delete this line of code. It says You are using uninitialized memory here. The correct fix is to initialize the memory, not delete the line of code. It's not about trusting or not trusting the tool; it's about responding correctly. I've seen innocuous valgrind reports, but never wrong ones. I also saw a valgrind report ignored as innocuous because it didn't seem to cause trouble, only to be the root cause of a problem that cost a minimum of $50,000 to resolve later.
