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

181–190 of 547 posts

Re: The Heartbleed Bug

#181

Post by steveklabnik »

yaakov34 wrote: post #154
azth wrote: post #102

Earlier quoted context omitted.

That's why I have high hopes for Rust. We really need to move away from C for critical infrastructure. Perhaps C++ as well, though the latter does have more ways to mitigate certain memory issues. Incidentally, someone on the mailing list brought up the issue of having a compiler flag to disable bounds checking. However, the Rust authors were strictly against it.

I'd disagree about C++. In my experience, the only things it adds is (1) a false sense of security (since the compiler will flag so many things which are not really big problems, but will happily ignore most overrun issues), (2) lots of complicated ways to screw up, such as not properly allocating/deleting things deep in some templated structure, and (3) interference with checking tools - I got way more false positiv…

To be clear, Rust _does_ expose the raw underlying computer the way C/C++ does, it's just off by default rather than on.

Re: The Heartbleed Bug

#182

Post by rcxdude »

mark-r wrote: post #37

Any chance this bug originated with the NSA? It seems like it would fall under their goal of subverting the infrastructure that keeps secrets on the internet. Of course this is exactly why such a goal is a bad idea - an unprotected internet causes widespread damage.

I don't think so - while the NSA would dearly like to have the access that this vulnerability would allow, they would dislike even more if anyone could have it. If they're going to insert a backdoor they're going to be damn sure only they have the key.

Re: The Heartbleed Bug

#183

Post by azth »

yaakov34 wrote: post #154
azth wrote: post #102

Earlier quoted context omitted.

That's why I have high hopes for Rust. We really need to move away from C for critical infrastructure. Perhaps C++ as well, though the latter does have more ways to mitigate certain memory issues. Incidentally, someone on the mailing list brought up the issue of having a compiler flag to disable bounds checking. However, the Rust authors were strictly against it.

I'd disagree about C++. In my experience, the only things it adds is (1) a false sense of security (since the compiler will flag so many things which are not really big problems, but will happily ignore most overrun issues), (2) lots of complicated ways to screw up, such as not properly allocating/deleting things deep in some templated structure, and (3) interference with checking tools - I got way more false positiv…

>(2) lots of complicated ways to screw up, such as not properly allocating/deleting things deep in some templated structure

Wow, that sounds scary. Do you have any references or further reading about this?

Re: The Heartbleed Bug

#184

Post by stusmall »

malandrew wrote: post #150
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…

Is anyone working on an OpenSSL port in rust, which lacks the memory vulnerabilities of C?

They are still making breaking changes to the language so I really doubt it.

Re: The Heartbleed Bug

#185

Post by IgorPartola »

What are the chances that the NSA is having a field day with this in the 24-48 hours that it will take everyone to respond? Also, is it possible that CA's have been compromised to the point where root certs should not be trusted?

Re: The Heartbleed Bug

#186

Post by ParadisoShlee »

Note that this bug affects way more programs than just Tor — expect everybody who runs an https webserver to be scrambling today.

"If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle." - torProject

Re: The Heartbleed Bug

#187

Post by sitkack »

malandrew wrote: post #150
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…

Is anyone working on an OpenSSL port in rust, which lacks the memory vulnerabilities of C?

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

Re: The Heartbleed Bug

#188

Post by WhiteDawn »

flym4n wrote: post #66
Dorian-Marie wrote: post #8

Earlier quoted context omitted.

Not affected directly on Mac OS: OpenSSL 0.9.8y 5 Feb 2013

Unless you installed the macports version, which is 1.0.1f

Homebrew has updated to 1.0.1g since 6:00PM GMT. It's important to note that this isn't an issue unless you have an outward facing service that uses TLS and the brew/macports library

Re: The Heartbleed Bug

#189

Post by squidsoup »

sitkack wrote: post #187
malandrew wrote: post #150

Earlier quoted context omitted.

Is anyone working on an OpenSSL port in rust, which lacks the memory vulnerabilities of C?

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.

Re: The Heartbleed Bug

#190

Post by sitkack »

yaakov34 wrote: post #105
lawl wrote: post #98

Earlier quoted context omitted.

If that would work Virtual Machines and runtimes wouldn't have vulnerabilities. So uhm. Yeah, that doesn't work either. Edit: Btw since HN has this obessions with Tarsnap, it's written in C btw. So you should stop obessing about it and downvote me some more.

This argument came up in the thread from a few years ago. It is quite wrong-headed. I would like to give a clear answer to it: Virtual machines and runtimes may be vulnerable to malicious CODE. That's bad. Programs written in unmanaged languages are vulnerable to malicious DATA. That's horrible and unmitigatable. Vulns to malicious code are bad, but they may be mitigated by not running untrusted code (hard, but doabl…

Steps for better security

    1. use a managed language
    2. use a provable language (Haskell, Idris, etc)
Effective Psyops Against Standards and Open Software https://www.youtube.com/watch?v=fwcl17Q0bpk
Post reply on HN