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

311–320 of 547 posts

Re: The Heartbleed Bug

#311

Post by Athas »

stormbrew wrote: post #258
comex wrote: post #242

Earlier quoted context omitted.

This is one reason I'd like to see the removed LLVM C backend brought back and modernized, with Rust as the source language. Rust is safe, has no mandatory garbage collector, and has a much lower impedance mismatch with C or C++ than most higher level languages, so it should work well for libraries that are expected to integrate with C code.

> removed LLVM C backend What are you referring to here?

LLVM used to have a backend that could convert its low-level bitcode to portable C.

Re: The Heartbleed Bug

#312

Post by jsmthrowaway »

elliottcarlson wrote: post #270
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'

That can false-positive, for what it's worth, in servers with fixed TLS heartbeats (instead of removing them).

Re: The Heartbleed Bug

#313

Post by Dylan16807 »

jcalvinowens wrote: post #264
Dylan16807 wrote: post #244

Earlier quoted context omitted.

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

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.

Re: The Heartbleed Bug

#314

Post by porlw »

e12e wrote: post #283
YZF wrote: post #218

Earlier quoted context omitted.

I'd disagree with your disagreement ;-) C++ has constructs that let you build safer and more secure systems while maintaining good performance. You can write high performance systems without ever touching a raw pointer or doing manual memory management which is something that you can't really do in any other language. Yes, you need to trust the underlying library code which is something you have to do for pretty much…

Does anyone have experience with (auditing) systems built using pascal/delphi? I realize that Ada might be a better choice if headed in that direction -- but it always felt to me like pascal actually had a pretty sane trade-off between high and low level, and that C generally gave a lot of the bad parts of assembly while still managing to obfuscate the code without really giving that much in terms of higher level str…

Pascal gets a bad rap, but that's due to the limitations of the original "pure" language. Something like Turbo Pascal which took features from Modula-2 is actually be a very good alternative to C for systems programming.

- Stricter type checking than C, (e.g. an error to add a centigrade value to a Fahrenheit value without casting)

- Bounds checked arrays and strings

Turbo Pascal added:

- Selectively turn off bounds checking for performance

- Inline assembler

- Pointers and arbitrary memory allocation

I don't think there's anything you can do in C that you can't do in TP. For example, it was easy to write code that hung off the timer or keyboard interrupts in MSDOS, which is pretty low level stuff.

The important thing is that the safe behaviour should be the default, you have to mark unsafe areas of code explicitly. This is the opposite to how it works with C.

Re: The Heartbleed Bug

#315

Post by lox »

Scary what the implications of this will be for OpenVPN traffic that has been captured and stored over the past 2 years.

Re: The Heartbleed Bug

#316

Post by chirayuk »

danielhlockard wrote: post #278
chirayuk wrote: post #274

Earlier quoted context omitted.

Would love to see the code and test it against a rebuilt a patched nginx.

Just run it against it?

Well, I was interested in actually testing it out in code. I got it working with the pyOpenSSL bindings (I had to expose struct ssl_method_st, SSL_get_ssl_method, ssl_write_bytes and rebuild cryptography for pyOpenSSL.) Fun times.

Re: The Heartbleed Bug

#317

Post by HappMacDonald »

astrange wrote: post #303
repost wrote: post #269

Earlier quoted context omitted.

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

If it just reads the up-to-64KB after that allocation, wouldn't you expect to see the server process segfault before too long? Of course, servers helpfully just start themselves back up again. As for scanning for key material, I wonder how to tell that 256-bit random data is the 256-bit random data you want.

Well, one way is to brute iterate through every potential 256-bit string you dredge out of the canal against the known public key.

If you can dredge up 64kB of fresh data every time, that's 511,744 tests per shovelful which is quite a bit to sift through from a performance perspective but it's also a trivially parallel task.

Additionally, folk might know of even better ways to narrow that down. For example, the data representation in memory might have easy to grep for delimiters.

Re: The Heartbleed Bug

#319

Post by cdelsolar »

Gygash wrote: post #306

Found a Python PoC: http://s3.jspenguin.org/ssltest.py Edit: and just used it to dump 64K from a known-vulnerable device we control. Got a session cookie. Jeez.

JESUS CHRIST, all sorts of private information. Patch your servers now!

Re: The Heartbleed Bug

#320

Post by InclinedPlane »

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…

A 1000% performance hit means that you have to spend 10x more on hardware, and you have to spend more time engineering for scalability. That extra cost outright kills projects in the womb. If the choice is launching something valuable to users and that pulls in revenue but is flawed, even seriously so, and doing nothing because it's just not feasible to do what you want within any reasonable cost/performance metrics... well then, you have your own anthropic principle right there.
Post reply on HN