Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Heartbleed Bug

heartbleed.com

Post reply on HN
Print view View original

221–230 of 547 posts

Re: The Heartbleed Bug

#221

Post by rtpg »

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…

>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 for free, and there's no longer many excuses to run around with raw pointers except for legacy code.

Re: The Heartbleed Bug

#222

Post by tlrobinson »

M4v3R wrote: post #167
tlrobinson wrote: post #42

Earlier quoted context omitted.

No, Bitcoin doesn't use SSL/TLS. It could have implications for Bitcoin web services that use HTTPS, of course.

But couldn't it be the case that with this bug you could sweep private keys from server's memory if they happen to be in there, because bitcoind is using them at the moment?

Yes, I would put that under the "implications for Bitcoin web services that use HTTPS" category. For context, the deleted question asked about the "Bitcoin blockchain" so I was responding to that specifically, with the added caveat for Bitcoin services that use HTTPS.

Re: The Heartbleed Bug

#223

Post by codygman »

pbsd wrote: post #191
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…

This sort of argument is becoming something of a fashion statement amongst some security people. It's not a strictly wrong argument: writing code in languages that make screwing up easy will invariably result in screwups. But it's a disingenuous one. It ignores the realities of systems. The reality is that there is currently no widely available memory-safe language that is usable for something like OpenSSL. .NET and…

I believe Haskell could be up to the job, but I heard that there were some difficulties in guarding against timing attacks. However those could have just been noise. I know that a functional (I believe and haha) operating system was made in Haskell.

Aren't Operating Systems lower level than OpenSSL?

Re: The Heartbleed Bug

#224

Post by pvg »

pbsd wrote: post #191
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…

This sort of argument is becoming something of a fashion statement amongst some security people. It's not a strictly wrong argument: writing code in languages that make screwing up easy will invariably result in screwups. But it's a disingenuous one. It ignores the realities of systems. The reality is that there is currently no widely available memory-safe language that is usable for something like OpenSSL. .NET and…

We might be stuck with C for quite a while but then maybe the more interesting question is 'how does this sort of thing get past review?'. It's not hard to imagine how semantic bugs (say, the debian random or even the apple goto bug) can be missed. This one, on the other hand, hits things like 'are the parameters on memcpy sane' or 'is untrusted input sanitized' which you'd think would be on the checklist of a potential reviewer.

Re: The Heartbleed Bug

#225

Post by gojomo »

tlrobinson wrote: post #103
gojomo wrote: post #70

Earlier quoted context omitted.

Yes, Bitcoin the system/protocol doesn't inherently use TLS. But, with the "rpcssl=1" option, the reference Bitcoin client's RPC interface would be using SSL, and specifically OpenSSL. I'd guess a ton of online Bitcoin services reliant on hot wallets do this. So cue the thefts, or 'thefts', any minute now.

True, though I would hope most services don't have public facing bitcoind instances to begin with...

Ideally, no, but with SSL, and a very-strong password, it might not be worse than other options for automating payouts... until a major bug like this comes along.

For comparison, the Bitcoin RPC password timing bug - https://github.com/bitcoin/bitcoin/issues/2838 - would have been a more slower and blatant/detectable way to compromise the same sorts of bitcoin RPC daemons.

Re: The Heartbleed Bug

#226

Post by AnthonyMouse »

squidsoup wrote: post #189
sitkack wrote: post #187

Earlier quoted context omitted.

Why port all the security vulns over to Rust? There are already a handful of SSL implementations, it isn't horribly hard to do. Maybe start with http://hackage.haskell.org/package/tls

I think over the last few months we've seen some pretty concrete evidence that implementing SSL securely is horribly hard to do.

Be that as it may, porting OpenSSL to any other language is Not Recommended. The code is hideous and the documentation is practically non-existent.

The only reason anyone can recommend using OpenSSL is that it's so widely used and battle worn that vulnerabilities are more likely to be patched than in some arbitrary obscure SSL library without all the warts. If it had been published as-is for the first time in 2014 then no one would touch it.

In addition to that, if you're going to create an SSL implementation in a new language, it would be much preferable to do it without the BSD advertising clause, which you're stuck with if you start with OpenSSL.

Re: The Heartbleed Bug

#227

Post by pbsd »

rtpg wrote: post #211
pbsd wrote: post #191

Earlier quoted context omitted.

This sort of argument is becoming something of a fashion statement amongst some security people. It's not a strictly wrong argument: writing code in languages that make screwing up easy will invariably result in screwups. But it's a disingenuous one. It ignores the realities of systems. The reality is that there is currently no widely available memory-safe language that is usable for something like OpenSSL. .NET and…

>Additionally, although the parsing portions of OpenSSL need not deal with the hardware directly, the crypto portions do. So your memory-safe language needs some first-class escape hatch to unsafe code. A few of them do have this, others not so much. For the other points there is some debate, but don't most serious languages have a C FFI?

OpenSSL and similar libraries spend most of their time processing short packets. For example, encrypting a few hundred bytes using AES these days should take only a few hundred CPU cycles. This means that the overhead of calling the crypto code should be minimal, preferably 0. This is in part what I meant by "first-class". Perhaps I should have written "zero-overhead" instead.

I googled around just now for some benchmarks on the overhead of FFIs. I found this project [1] which measures the FFI overhead of a few popular languages. Java and Go do not look competitive there; Lua came surprisingly on top, probably by inlining the call.

Before you retort with an argument that a few cycles do not matter that much, remember that OpenSSL does not run only in laptops and servers; it runs everywhere. What might be a small speed bump on x86 can be a significant performance problem elsewhere, so this is something that cannot be simply ignored.

[1] https://github.com/dyu/ffi-overhead

Re: The Heartbleed Bug

#228

Post by dfa0 »

phillmv wrote: post #51

Given the severity of this bug, the UX of the site is failing anyone who isn't a fulltime sysadmin. Suggestion: big, bold TLDR ("The sky is falling. Check your OpenSSL version right now") with a link on what to do sorted by OS vendor. Step 1: Here's a command to spit out your OpenSSL version. If it is the following string, go to step 2. Step 2: Here's how to update your OpenSSL. Here are links to guides on reissuing…

On a linux box: [For each set of certs used for each of your public facing sites...]

1. Open a terminal[cd into] /etc/path_to_ssl_certs_folder[per site].

Ex. /etc/ssl/nginx

2. Regen the certs [example nginx mail server]

openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:4096 -keyout mailkey.pem -out mailcert.pem

[this command generates a private key and server cert and outputs to pem's] [Note also the key sizes are 4096, you may want 2048. AND I use -sha256, as sha1 is considered too weak nowadays. These certs are valid for 3650 days...10 years]

Since the command overwrites certs/keys in the current directory of the same name as the outfiles...that's it...you're done. Just restart nginx.

If you change a self-signed cert, like above, expect a new warning from the client on the next connection...this is just your new cert being encountered. Click permantly accept..blah blah.

------------------------------------------------------------------------

On a Windows box:

1. open an admin cmd window and run 'mmc'.

2. Add a new snap-in for Certificates as local machine.

3. Find and 'Disable all purposes for this cert'.

4. Import your new certs from your 3rd party or that you rolled yourself from your enterprise CA.

5. Test new cert.

6. Delete old cert.

[If you run your own CA, you should already know what to do...]

Re: The Heartbleed Bug

#229

Post by dfc »

0x0 wrote: post #149
eikenberry wrote: post #144

Earlier quoted context omitted.

Debian comes with a handy tool for this called 'checkrestart' in the debian-goodies package. sudo apt-get install debian-goodies sudo checkrestart

Thanks for the hint, I hadn't heard of this one. Should be built-in to apt, I think! :)

It seems like you are somewhat new to the Debian utopia. Here is another great package that a lot of people are not aware of `apt-listbugs.` After you say "yes" to apt-get upgrade, apt-listbugs queries bts for bugs in the packages:version you are about to install. If any bugs are found you have the chance to review the report to see if it applies to you and if it does you can have apt-listbugs pin the package so that the new buggy version is not installed. Every night at midnight (i think) apt-listbugs queries bts to see if the bugs are still relevant and unpins the package if the bug is no longer relevant. It is especially handy for testing/unstable/experimental.

By default it only prompts you for grave-serious bugs. I have been bitten a couple of times by "important" bugs so set listbugs up so that it also checks for "important" bugs. This makes it a tiny bit noisier but not enough to make me switch to the defaults. Changing the severities is easy:

   diff --git a/apt/apt.conf.d/10apt-listbugs b/apt/apt.conf.d/10apt-listbugs
   index 13b5409..857f3f4 100644
   --- a/apt/apt.conf.d/10apt-listbugs
   +++ b/apt/apt.conf.d/10apt-listbugs  @@ -4,5 +4,5 
   @@ DPkg::Pre-Install-Pkgs {"/usr/sbin/apt-listbugs apt";};
   DPkg::Tools::Options::/usr/sbin/apt-listbugs "";
   DPkg::Tools::Options::/usr/sbin/apt-listbugs::Version "3";
   DPkg::Tools::Options::/usr/sbin/apt-listbugs::InfoFD "20";
  -AptListbugs::Severities "critical,grave,serious";
  +AptListbugs::Severities "critical,grave,serious,important";
   // AptListbugs::IgnoreRegexp "FTBFS";

Re: The Heartbleed Bug

#230

Post by blazespin »

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…

Java, yes, hmmm.. Oh wait, but Java VM is written in C and is a host to some of the worst web browser zero days we know of.

Fundamentally, I think we're going to have to give up on security and start handing out drivers licenses to anyone who wants to use the internet.

Post reply on HN