The Heartbleed Bug • Hacker News Board

Re: The Heartbleed Bug

#361

Post by lmm » Tue, Apr 08, 2014, 8:43 AM UTC

CCs wrote: post #354

ballard wrote: post #254

Earlier quoted context omitted.

That's what I like about Ruby. ;) Even in C, Go or Python, I column align any text that is remotely similar, so differences are obvious. Clean code might be extra work but the net work (maintenance) should amortize less. Reducing cognitive load for large supportable production codebase cannot be underscored enough.

There's no "just use X" type of answer in security. Sep 2013 "All versions of the open source Ruby on Rails Web application framework released in the past six years have a critical vulnerability that an attacker could exploit to execute arbitrary code, steal information from databases and crash servers." https://groups.google.com/forum/#!topic/rubyonrails-security... Nov 2013 "A lingering security issue in Ruby on Ra…

Rails does plenty of "make life easier for the programmer" things that I would expect to increase the risk of security issues. Do you have those kind of problems for e.g. Haskell?

Re: The Heartbleed Bug

#362

Post by morgante » Tue, Apr 08, 2014, 8:47 AM UTC

malandrew wrote: post #159

We really need to see some of the big companies take down their services until they've fixed this and call out for every company out there to audit themselves and confirm to users that this is serious and should be checked and that no service should stay online until they've patched their systems. This should get attention beyond just techies. Business as usual is not acceptable since every day that goes by is the op…

> I would not be surprised if people at the NSA, GHCQ and most state security services are going into overdrive right now to get access to anything and everything that is vulnerable to this bug.

I assume the NSA has known about this bug for a long time and has been actively exploiting it.

Re: The Heartbleed Bug

#363

Post by tlarkworthy » Tue, Apr 08, 2014, 8:52 AM UTC

72deluxe wrote: post #359

Dylan16807 wrote: post #313

Earlier quoted context omitted.

SSL itself is a tiny fraction of the CPU load on a normal webserver. The idea that it's expensive has done more harm than many other things. It wouldn't cost anything except on accelerator boxes.

Is it really a tiny load? Have you ever looked at the throughput values quoted for VPN routers that do their encryption in software (not hardware like the expensive Cisco ASAs)? If you compare the non-VPN throughput with the VPN-throughput, the software encryption is massively massively slower, so I would argue that software encryption is not a tiny load on a normal webserver, unless the webserver was not getting any…

yes encryption (and database) is the hot spot when I do load testing, the bit in the middle can be optimized to near nothing.

Re: The Heartbleed Bug

#364

Post by rmc » Tue, Apr 08, 2014, 8:55 AM UTC

mattparlane wrote: post #162

What worries me about this is that the commit that fixes it [0] doesn't include any tests. Is that normal in crypto? If I committed a fix to a show-stopper bug without any tests at my day job I'd feel very amateur. [0] http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...

Sometimes things are time-critical.....

Re: The Heartbleed Bug

#365

Post by dijit » Tue, Apr 08, 2014, 9:01 AM UTC

betadreamer wrote: post #256

I'm not a security guru... So what kind of attack can this cause? Does this mean https will not be secured if the site uses vulnerable OpenSSL?

it means if you're running a bad version of openssl then someone can dump the entire contents of your ram, including public/private keys, and anything that is in memory such as passwords and even DB connections.

Re: The Heartbleed Bug

#366

Post by dkarapetyan » Tue, Apr 08, 2014, 9:02 AM UTC

orblivion wrote: post #305

dkarapetyan wrote: post #194

Honestly, why aren't the formal verification people jumping on this? I keep hearing about automatic code generation from proof systems like Coq and Agda but it's always some toy example like iterative version of fibonacci from the recursive version or something else just as mundane. Wouldn't cryptography be a perfect playground for making new discoveries? At the end of the day all crypto is just number theory and num…

You may be interested in Quark, which is a browser kernel written using Coq http://goto.ucsd.edu/quark/

Yes, why doesn't the same thing exist for SSL? The fact that quark was funded by the NSF means that there is interest in actually doing stuff like this.

Re: The Heartbleed Bug

#367

Post by yuhong » Tue, Apr 08, 2014, 9:04 AM UTC

jcalvinowens wrote: post #193

yaakov34 wrote: post #90

There was a discussion here a few years ago ( https://news.ycombinator.com/item?id=2686580 ) about memory vulnerabilities in C. Some people tried to argue back then that various protections offered by modern OSs and runtimes, such as address space randomization, and the availability of tools like Valgrind for finding memory access bugs, mitigates this. I really recommend re-reading that discussion. My opinion, then a…

> C and other languages without memory checks are unsuitable for writing secure code I vehemently disagree. Well-written C is very easy to audit. Much much moreso than languages like C# and Java, where something I could do with 200 lines in a single C source file requires 5 different classes in 5 different files. The problem with C is that a lot of people don't write it well. Have you looked at the OpenSSL source? It…

My favorite is that the Morris worm dates back to late 1988 when MS was starting the development of OS/2 2.0 and NT. Yea, I am talking about the decision to use a flat address space instead of segmented.

Re: The Heartbleed Bug

#368

Post by twic » Tue, Apr 08, 2014, 9:14 AM UTC

rtpg wrote: post #221

jcalvinowens wrote: post #193

Earlier quoted context omitted.

> C and other languages without memory checks are unsuitable for writing secure code I vehemently disagree. Well-written C is very easy to audit. Much much moreso than languages like C# and Java, where something I could do with 200 lines in a single C source file requires 5 different classes in 5 different files. The problem with C is that a lot of people don't write it well. Have you looked at the OpenSSL source? It…

>The problem with C is that a lot of people don't write it well. There are languages that make it very very hard to write bad code. Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. C is a language that doesn't offer many advantages but offers very many disadvantages for its weak assurances. Things like the Haskell compiler show that you can get strong typing…

> Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct.

I really wish people would stop saying this. It's not in the slightest bit true. Making this assertion makes Haskellers seem dangerously naive.

Re: The Heartbleed Bug

#369

Post by raphinou » Tue, Apr 08, 2014, 9:21 AM UTC

FiloSottile wrote: post #215

I've built a web tester for this bug, find it at http://filippo.io/Heartbleed/ It actually exploit the bug, since it was quite trivial, and echo some memory. It's written in Go, no more than 100 lines. I'll release code in some time.

My upgraded debian and ubuntu boxes are still reported as vulnerable.... Who's wrong, who's right?

Re: The Heartbleed Bug

#370

Post by zvrba » Tue, Apr 08, 2014, 9:21 AM UTC

amalcon wrote: post #139

yaakov34 wrote: post #90

There was a discussion here a few years ago ( https://news.ycombinator.com/item?id=2686580 ) about memory vulnerabilities in C. Some people tried to argue back then that various protections offered by modern OSs and runtimes, such as address space randomization, and the availability of tools like Valgrind for finding memory access bugs, mitigates this. I really recommend re-reading that discussion. My opinion, then a…

Nothing in the standard prevents a C compiler + tightly coupled malloc implementation from implementing bounds checks. Out-of-bounds operations result in undefined behavior, and crashing the program is a valid response to undefined behavior. If your malloc implementation cooperates, you can even bounds-check pointer arithmetic without violating calling conventions. It's quite a shame that there isn't a compiler that…

Oncoming Intel memory protection extensions: http://software.intel.com/en-us/articles/introduction-to-int...

"Intel MPX is a set of processor features which, with compiler, runtime library and OS support, brings increased robustness to software by checking pointer references whose compile time normal intentions are usurped at runtime due to buffer overflow."