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

441–450 of 547 posts

Re: The Heartbleed Bug

#441

Post by munger »

sexmonad wrote: post #34
ams6110 wrote: post #30

Earlier quoted context omitted.

Writeup was too long. We need to know the short and sweet of what to fix.

Update to 1.0.1g, redo all crypto. That is, revoke certs and keys and regenerate.

What you probably want is to re-key your cert, do not revoke it. Revoking with some CA's (such as GoDaddy) means to essentially cancel the remainder of the valid date forever and requires purchasing a new cert to secure the same domain. You are forfeiting the rest of its value.

When you re-key, it will automatically deactivate the previous cert and is free. It also gives you the opportunity to update to SHA-2 or increase the key to 2048 bit, which you should do unless you have unusual and extreme legacy support needs (and must keep SHA-1 a while longer).

Re: The Heartbleed Bug

#442

Post by mietek »

pdpi wrote: post #375
mietek wrote: post #286

Earlier quoted context omitted.

This project attempts to measure the overhead of calling out from $LANGUAGE and into C, which is the reverse of what's necessary to solve the problem stated here — to write a low-level library in a high-level language. There are other means of achieving a secure implementation, such as programming in a very high-level language, such as Cryptol, and compiling to a low-level language: http://corp.galois.com/cryptol/

No, it's the exact problem we're faced with here: Calling OpenSSL from the outside is something you do a handful of times. The OP was concerned about parts of OpenSSL that require direct hardware access (thus, should be written in C). Because those parts of the code are extremely hot, having to cross FFI boundaries to reach them might be prohibitively expensive.

Fair enough. Here's one attempt at a fast high-level AES library, with hardware acceleration using AESNI, and some benchmarks:

http://tab.snarc.org/posts/haskell/2012-07-07-building-a-bet...

Re: The Heartbleed Bug

#443

Post by colinbartlett »

userbinator wrote: post #262
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.

It's extremely easy to exploit once it is known. The question is simply: Did people know about it and not disclose so they could keep exploiting it?

Re: The Heartbleed Bug

#444

Post by gnuvince »

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.

Including people responsible for one of the most important security-related library in the world. No matter how good and careful a programmer is, they are still human and prone to errors. Why not put every chance on our side and use languages (e.g. Rust, Ada, ATS, etc.) that make entire classes of errors impossible? They won't fix all problems, and definitely not those associated with having a bad code base, but it'd still be many times better than hoping people don't screw up with pointers lifetime.

Re: The Heartbleed Bug

#445

Post by rkuykendall-com »

syncsynchalt wrote: post #437

Note: if you use mint.com, it's likely hitting your banks with your login on your behalf today. You'll still want to change those passwords even if you didn't use banking sites during the known vulnerability window.

The "known vulnerability window" is over 2 years.

Re: The Heartbleed Bug

#447

Post by orthecreedence »

tragomaskhalos wrote: post #349
yaakov34 wrote: post #238

Earlier quoted context omitted.

First, I do realize that rewriting the software stack from the ground up to have only managed code is a huge task. I do think that as an industry, we should set a goal of having at least one server implementation along these lines (where 'set a goal' may mean, say, grants or calls for proposals). Microsoft Research implemented an experimental OS like that, although it probably didn't have all the features a modern OS…

Do not like the term "C/C++", and especially in this context. Modern C++ makes avoiding this sort of bug as easy as doing so in the "managed" languages already discussed. This is as much a cultural as a technical problem; C really is in the last chance saloon for this sort of problem, we have the solution to hand, but a strong cadre of developers will still only consider C for this sort of work.

The problem, and I think this may have been touch on somewhere else in the thread, is that C++ can be really complex to wrap. So embedding a C++ library in another, higher-level language can be very tricky. It often requires wrapping the parts of the API you want to use in C.

I'm fine with low-level libraries being written in C++, but would hope that developers expose a C API around everything.

Re: The Heartbleed Bug

#448

Post by spatten »

benmmurphy wrote: post #395
spatten wrote: post #282

Earlier quoted context omitted.

I'm totally confused by this. I'm running ubuntu LTS 12.04 and did sudo aptitude update sudo aptitude upgrade openssl and then ran openssl version -a and got the same results as you. How can it be built on January 8th if the patch was just made today? [EDIT] running sudo aptitude upgrade upgraded properly and now I'm getting a version that was compiled earlier today. I'm guessing I needed to update another package as…

upgrade will work because it updates libssl1.0.0 which is the package you want upgraded :) Openssl is the command line package and libssl1.0.0 is the library. i was able to upgrade openssl without upgrading libssl1.0.0. ben@ip-10-0-0-76:~$ dpkg -s libssl1.0.0 |grep Version Version: 1.0.1e-3ubuntu1 ben@ip-10-0-0-76:~$ dpkg -s openssl |grep Version Version: 1.0.1e-3ubuntu1 ben@ip-10-0-0-76:~$ sudo apt-get install opens…

Thank you. That makes more sense now.

I'm guessing that tons of people will run into this. I bet a blog post would get you some traffic... :)

Re: The Heartbleed Bug

#449

Post by orthecreedence »

rtpg wrote: post #221
jcalvinowens wrote: post #193

Earlier quoted context omitted.

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

How do I embed your Haskell library in my Lisp program? This is where C shines...it can be used everywhere, including embedded in other programs, now matter what language it's in.

Re: The Heartbleed Bug

#450

Post by mcguire »

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…

"Rust has a lot of promise, but even now it keeps changing every other week..."

A larger problem, in my opinion, is that things like OpenSSL are used (And should be!) from N other languages. As a result, calling into the library requires almost by definition lowest-common denominator interfaces. Which is C.

C code calling into Rust can certainly be done, but I believe it currently prohibits using much of the standard library, which also removes a lot of the benefits.

C++ doesn't, I think, have as much of a problem there, but I'm somewhat skeptical of C++ as a silver bullet in this case.

I don't know about Ada and any other options.

[ATS, anyone?]

Post reply on HN