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.
The Heartbleed Bug
111–120 of 547 posts
Re: The Heartbleed Bug
#112As of now (21:04 UTC) this isn't fixed in Debian https://security-tracker.debian.org/tracker/CVE-2014-0160 nor Ubuntu http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20... Got a long night ahead :/
Ubuntu 12.04 patch ready https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5....
Re: The Heartbleed Bug
#113Earlier quoted context omitted.
Just received an upgrade on Ubuntu 12.04 LTS as well, apt-get clean issued before updating. EDIT: If you are using DigitalOcean, the update is not yet on their mirrors. Issue 'sudo sed -i "s/mirrors\.digitalocean/archive.ubuntu/g" /etc/apt/sources.list;sudo apt-get clean;sudo apt-get update;sudo apt-get upgrade' to get the patch. Check the comment by 0x0 above ( https://news.ycombinator.com/item?id=7549842 ) to find…
I can confirm this for vanilla Ubuntu 12.04 LTS. I've been checking for the past hour. The updates for the following just appeared: Setting up libssl-doc (1.0.1-4ubuntu5.12) ... Setting up libssl-dev (1.0.1-4ubuntu5.12) ... Setting up openssl (1.0.1-4ubuntu5.12) ...
Yup, in Ubuntu 12.04 LTS version 1.0.1-4ubuntu5.12 is what you need.
Here's the changelog: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...
Re: The Heartbleed Bug
#114Any 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 knew I was going to be attacked for saying this, but isn't it a real possibility? We already know that they tried to weaken RSA.
It is evil to make totally unsupported accusations, even against the NSA. I've downvoted you, twice.
Re: The Heartbleed Bug
#115Earlier 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…
What? Sorry, that doesn't make the least amount of sense.
If you have a VM your code is DATA! You can have say format string bugs in managed languages too, see for example: http://blog.stalkr.net/2013/06/golang-heap-corruption-during...
I'm sorry, but you're agrument here is plain bullshit.
Using your logic the whole kernel/browsers etc should be written in a managed language.
A browser is basically a VM for webpages though. I'd bet that chrome/firefox/IE have more severe vulnerabilities than openssl per time though.
I just... You can't argue with bullshit sorry.
Your might get less buffer overruns okay, but is it more secure in the end without any doubt?
I doubt it.
Re: The Heartbleed Bug
#116Earlier quoted context omitted.
I believe the reason they got access was one of their customers found it and reported it to them, and they reported it to OpenSSL, and then it somehow leaked (either with the OSSL release, or someone else) and then they posted their now-public writeups of it.
That's not correct. One of the individuals who discovered the bug contacted us as a large provider of SSL termination services. We were asked not to further disclose the details until it was officially patched and announced by OpenSSL. The official announcement occurred today after which we put up a post to let our customers know that they were protected.
Ah, my apologies. That's unfortunate, though, that OpenSSL doesn't have such a list, and that a larger population was not necessarily contacted.
Thank you for the information, though.
Re: The Heartbleed Bug
#117There 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…
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.
So reducing the attack surface isn't a laudable goal in your book, because hey the VM itself can have vulnerabilities so there isn't a point? I think the point is that programmers will always make these mistakes and we should limit as much as possible the type of unsafe code that is written to as small an attack vector as possible. You're never going to eliminate vulnerabilities, but we sure can try and reduce the likelihood of them occurring. If there is some objective measurement to be made that says this isn't the case, i.e. the number of JVM vulnerabilities like this outstrip or is on par with client side vulnerabilities that occur in purely C/C++ applications I would love to see it.
Ultimately, I think the better answer will ultimately be a language that inherently provides the primitives for safe memory management but that's low-level and highly peformant, i.e. Rust or something like it.
Re: The Heartbleed Bug
#118"goto fail;" doesn't seem that bad now huh.
Lovely how these GNU/Linux freedom fighters were LOLling their asses off earlier, but when it happens to them they sweat themselves and cry for spoon-fed instructions to compile a software package from its sources.
- sent from my Mac
Re: The Heartbleed Bug
#119Earlier 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.
So reducing the attack surface isn't a laudable goal in your book, because hey the VM itself can have vulnerabilities so there isn't a point? I think the point is that programmers will always make these mistakes and we should limit as much as possible the type of unsafe code that is written to as small an attack vector as possible. You're never going to eliminate vulnerabilities, but we sure can try and reduce the li…
There's a problem with your logic here.
You're not neccesarily reducing the attack surface. You're adding complexity. While you might reduce the attack surface on low level bugs. You might open yourself to new bug classes.
Downvote me however you guys want. It's just not that easy.
If you could eliminiate the common cold by killing the guy with the running nose, don't you think someone would have done it?