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

261–270 of 547 posts

Re: The Heartbleed Bug

#261

Post by rtpg »

jcalvinowens wrote: post #239
rtpg wrote: post #221

Earlier quoted context omitted.

>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…

> 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 code is far from naive).

There are a lot of tricks at your disposal when you know more about the state of the code. And compilers are usually better than humans in this regard.

Re: The Heartbleed Bug

#262

Post by userbinator »

oskarth wrote: post #39

This thing has been in the wild for two years. What are the odds it hasn't been systematically abused? And what does this imply? To me it sounds kind of like finding out the fence in your backyard was cut open two years ago. Except in this case the backyard is two thirds of the internet.

> And what does this imply?

To me, this implies that it's not too easy to exploit, or we would've seen it fixed much sooner.

Re: The Heartbleed Bug

#263

Post by wglb »

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…

You make good points.

However, qmail is written in C and has a very good record. So I would disagree with The fact is that no programmer is good enough to write code which is free from such vulnerabilities.

There seem to be at least two programmers who are capable of that.

Re: The Heartbleed Bug

#264

Post by jcalvinowens »

Dylan16807 wrote: post #244
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…

>no amount of security is worth a 1000% performance hit Yes it is. Most of the applications I use take roughly 0% of my processor's capacity. I can spare a multiple like that outside of a few hot loops. Saying 10x slowdown isn't worth it is like saying no one would ever compute on a phone. Also random BS benchmark http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... says haskell is at least half as fast as…

> Most of the applications I use take roughly 0% of my processor's capacity.

We're talking about a server-side vulnerability in OpenSSL here, not applications running on your personal computer.

Roughly speaking, making your server code twice as slow means it will cost you twice as much money to run your servers. Of course, that depends a lot on what exactly you're doing and is obviously not always true... but OpenSSL is a very performance-critical piece of most server-side software in the wild.

If OpenSSL suddenly became twice as slow, it would cost a lot of people a lot of money.

> Also random BS benchmark says haskell is at least half as fast as C.

I never said my "quick searching" was exhaustive. I suspect the relative performance is heavily dependent on what exactly is being done in the code.

Re: The Heartbleed Bug

#265

Post by Turing_Machine »

stormbrew wrote: post #120
dmix wrote: post #72

Earlier quoted context omitted.

This is the standard command: $ openssl version > OpenSSL 1.0.1f 6 Jan 2014

As far as I can tell, on ubuntu this reports "OpenSSL 1.0.1 14 Mar 2012" for all ubuntu versions, including the fixed one.

Same here.

I got a "security warning" update when I logged in to the server (good), ran apt-get and installed, did openssl version, got the string as noted above (which seemed just a tad out of date).

So... I built and installed from source, and got... the same string.

Annoying.

Re: The Heartbleed Bug

#266

Post by Turing_Machine »

mayneack wrote: post #161
stormbrew wrote: post #120

Earlier quoted context omitted.

As far as I can tell, on ubuntu this reports "OpenSSL 1.0.1 14 Mar 2012" for all ubuntu versions, including the fixed one.

My Linux Mint machine (based on 13.10) went from 1.0.1e Feb 2014 to 1.01 Mar 2012 int the last 2 hours, so that's definitely new.

I think someone screwed up on the version string big time.

Re: The Heartbleed Bug

#267

Post by a8000 »

ballard wrote: post #246
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…

Agree a bazillion times. Go or Java on top. Coding in C is like juggling chainsaws to say you can juggle them. C is certainly better than old school Fortran where memory management wasn't developed until later, but platforms like Erlang, Go and JRuby are really hard to beat. The only problem is convincing people to migrate to different tools and transition codebases to another language. It would take a large project…

Fortran was not meant to be a systems programming language. The fact that it did not have memory management does actually make sense in scientific applications, where you typically know your problem size in advance or can just recompile before a day long computation.

Re: The Heartbleed Bug

#268

Post by gojomo »

sp332 wrote: post #249
gojomo wrote: post #47

What popular SSL client software uses the vulnerable OpenSSL? (Any web browsers, for example on popular linuxes? How about 'curl' when connecting to HTTPS sites?)

How would a client be compromised? I mean I guess a malicious server could send these bad heartbeat packets and sniff the keys, but if the server is pwned then your secrets are already revealed, right?

Imagine you've got a script that, among other things, does a 'wget' against some innocent plain HTTP URL. But an attacker intercepts your request, and redirects you to an HTTPS URL of their choosing.

Yes, wget uses OpenSSL, and follows redirects silently by default.

Now that server uses heartbleed to x-ray your client process memory, collecting all sorts of confidential information, including perhaps credentials to other services.

This bug has a lot of nasty, unintuitive permutations and repercussions that will take time to fully grasp.

Re: The Heartbleed Bug

#269

Post by repost »

comex wrote: post #237
IgorPartola wrote: post #178

Earlier quoted context omitted.

Thanks for this. How is this reading arbitrary memory locations though? Isn't this always reading what is near the pl? As in, can you really scan the entire process's memory range this way or just a small subset where malloc (or the stack, whichever this is) places pl?

The latter, and AFAIK the buffer doesn't get reallocated on every connection, so it should be unlikely that any private keys actually get dumped. However, I could be missing a way to exploit it.

Reading between the lines in the announcement it sounds like dropping and reconnecting may cause it to read memory freed up from a prior connection. It may "just" be a matter of keep trying or it may be a matter of opening lots of connections to consume resources dropping them all then connecting and seeing what was left on the beach after the tide went out.

BTW Amazon AWS/ELM is vulnerable, confirmed publically by their support.

Re: The Heartbleed Bug

#270

Post by elliottcarlson »

jeffDef wrote: post #111

Is there a way to tell if a third-party site has patched the bug? (Upgraded to 1.0.1g) Not much point in changing your password on that site before the vulnerability is fixed.

echo -e "quit\n" | openssl s_client -connect :443 -tlsextdebug 2>&1| [ "` grep -c 'TLS server extension \"heartbeat\" (id=15), len=1'`" -gt 0 ] && echo 'Vulnerable'
Post reply on HN