The Heartbleed Bug

Post by jcalvinowens » Tue, Apr 08, 2014, 3:20 AM UTC

rtpg wrote: post #261

jcalvinowens wrote: post #239

Earlier quoted context omitted.

> There are languages that make it very very hard to write bad code. Haskell [...] Sure, but how much slower is Haskell than an equivalent implementation in C? Some quick searching suggests numbers like 1000% slower... and no amount of security is worth a 1000% performance hit, let alone a vague "security mistakes are less likely this way" sort of security. Being secure is useless if your code is so slow that you hav…

>Sure, but how much slower is Haskell than an equivalent implementation in C? Some quick searching suggests numbers like 1000% slower... With things like stream fusion ( http://research.microsoft.com/en-us/um/people/simonpj/papers... ) , which I imagine would capture a lot of crypto calls, GHC can generate some very performant code (paper contains examples of hand-written C code being beat by Haskell code, and the C…

Post by clev » Tue, Apr 08, 2014, 3:24 AM UTC

imsofuture wrote: post #171

zmillman wrote: post #5

Does anyone know how Amazon's Elastic Load Balancers are affected? I can't find anything on the AWS site

Likewise, same question for Rackspace's Cloud LBs.

Post by nullc » Tue, Apr 08, 2014, 3:30 AM UTC

wyager wrote: post #196

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…

Speaking of proofs, how about we write security critical code in haskell? You need a very simple runtime, but beyond that it would work pretty much wherever. Most memory-related bugs are automatically eliminated, and security proofs are easier.

Post by bcl » Tue, Apr 08, 2014, 3:33 AM UTC

ineedtosleep wrote: post #4

A couple more data points: I'm running Fedora 19 and Arch on my main dev machines/VMs and as of this posting are considered up-to-date. Both are vulnerable: [Fedora19] $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 [Arch] $ openssl version OpenSSL 1.0.1f 6 Jan 2014

Post by bcl » Tue, Apr 08, 2014, 3:36 AM UTC

cheald wrote: post #7

ineedtosleep wrote: post #4

A couple more data points: I'm running Fedora 19 and Arch on my main dev machines/VMs and as of this posting are considered up-to-date. Both are vulnerable: [Fedora19] $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 [Arch] $ openssl version OpenSSL 1.0.1f 6 Jan 2014

Yeah, I haven't seen any new RPMs for RHEL/CentOS/Fedora yet. Kinda concerning, since I'd expect vendors to be given advance notice and the chance to prep updates to coincide with the announcement. All my RHEL5 boxes are running 0.9.8, though, at least.