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

521–530 of 547 posts

Re: The Heartbleed Bug

#521

Post by oneeyed »

jevinskie wrote: post #486
jnbiche wrote: post #406

Earlier quoted context omitted.

An interesting new project written in Ada is a DNS server called Ironsides, written specifically to address all the vulnerabilities found in Bind and other DNS servers [1]. "IRONSIDES is an authoritative DNS server that is provably invulnerable to many of the problems that plague other servers. It achieves this property through the use of formal methods in its design, in particular the language Ada and the SPARK form…

Yikes, I didn't know the latest GPL compiler doesn't contain a linking exception. That is disappointing.

This is wrong: the compilers distributed by the FSF (as part of GCC) have the linking exception. The ones distributed by AdaCore don't: they exercise their right to transform the modified GPL (with exception) into the GPL before redistribution. But the one in your Linux distribution is likely the FSF one.

Re: The Heartbleed Bug

#522

Post by panzi »

How feasible would it be to write things like nginx, Apache, web browsers etc. so that they can use both OpenSSL and NSS, where you could choose what to use via config switch? Then it would be easy to "fix" such a bug when it occurs. The probability that both libraries have a vulnerability at the same time is probably very low.

Re: The Heartbleed Bug

#523

Post by jnbiche »

oneeyed wrote: post #521
jevinskie wrote: post #486

Earlier quoted context omitted.

Yikes, I didn't know the latest GPL compiler doesn't contain a linking exception. That is disappointing.

This is wrong: the compilers distributed by the FSF (as part of GCC) have the linking exception. The ones distributed by AdaCore don't: they exercise their right to transform the modified GPL (with exception) into the GPL before redistribution. But the one in your Linux distribution is likely the FSF one.

No, it's absolutely correct. He wrote that the latest compiler doesn't have a linking exception, which is correct. The FSF compiler generally lags at least a year or two behind the AdaCore one.

For example, it has only just gotten (partial) Ada 2012 features, a full 3-4 years after the AdaCore GPL compiler.

Re: The Heartbleed Bug

#524

Post by einhverfr »

dtech wrote: post #386
lmm wrote: post #361

Earlier quoted context omitted.

Rails does plenty of "make life easier for the programmer" things that I would expect to increase the risk of security issues. Do you have those kind of problems for e.g. Haskell?

Haskell problably has/would have the same kind of problems, but finding examples will be a lot harder in the absence of large well-used web platform à la RoR

Once you are doing functional programming a bunch of classes of problems including a bunch of classes of security problems go away.

For example, here, if the guarantee of functional programming is that a given input leads to a given output and has no memory side effects, then your attack surface area is a lot, lot smaller.

Re: The Heartbleed Bug

#525

Post by jbailo »

I used the OpenSSL library for building a SAML token parser in JBoss (java). All the front end stuff was java and OpenSSL was used for public/private key decryption and validation of SAML tokens and signatures. I'm not sure exactly what an OpenSSL "server" -- it sounds like there is a feature which you can implement (or not) in your webserver to test the SSL/TLS listener.

However, you could -- as I did -- use anything else as your interface for the web. Why would you specifically include a heartbeat for just SSL is beyond me. If a website is up and running, you'll know it with the usual methods, the https codes. You don't need a separate "heartbeat" for telling you that an internal mechanism for processing a protocol is running...do you?

Re: The Heartbleed Bug

#526

Post by mcv »

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…

> My opinion, then and now, is that C and other languages without memory checks are unsuitable for writing secure code.

I think they can be used to write secure code, but it has to be done carefully, with really thorough checks and unit tests, and a constant awareness of the vulnerabilities.

Everything I've heard about OpenSSL so far, suggests it was done by a bunch of cowboys who don't care about code quality. Those people shouldn't be writing C, but a safer language.

Re: The Heartbleed Bug

#527

Post by LBarret »

sspiff wrote: post #409
yaakov34 wrote: post #157

Earlier quoted context omitted.

It is indeed astonishing how simple-minded this bug is. But these bugs come in all levels of complexity, from simple overstuffed buffers to logical ping-pong that hurts your brain when you try to follow it. We need to get rid of them once and for all. If the whole world can't use a certain tool effectively, then the whole world isn't broken; the tool is bad.

Machine level languages like C and C++ aren't necessarily bad tools, even in their current states. However, I agree that they might be bad tools for the purpose of writing security libraries.

There are not bad tools, but not the best either. If you spend mental stamina on trivial things, you have less for the important ones, the ones a compiler cannot check.

This kind of tool (SSL) should be written in ada or haskell.

Re: The Heartbleed Bug

#528

Post by gnaffle »

thisrod wrote: post #142
ori_b wrote: post #106

Earlier quoted context omitted.

In keeping with the tradition of bad car analogies, that's like saying "Driving cars with automatic traction control won't make accidents go away, so automatic traction control is pointless". Languages with bounds checks on array accesses don't solve everything, but that doesn't mean that they don't work. They do remove entire classes of silent failures that can potentially slip through the cracks in C-like languages…

Do you know of any controlled experiments to test the safety claims for automatic traction control? People used to say similar things about ABS. Then the experiments were done, it turned out to be pointless or possibly dangerous, and people started talking about traction control instead. Automatic bounds checking could well fail the same way that ABS did: programmers won't bother defining a packet data type, because…

ABS pointless? The Wikipedia article disagrees, so I'd certainly like to know more: http://en.wikipedia.org/wiki/Anti-lock_braking_system#Effect...

ESC is certainly shown to be effective, although I don't know about traction control: http://en.wikipedia.org/wiki/Electronic_stability_control#Ef...

Re: The Heartbleed Bug

#529

Post by spoiler »

LBarret wrote: post #527
sspiff wrote: post #409

Earlier quoted context omitted.

Machine level languages like C and C++ aren't necessarily bad tools, even in their current states. However, I agree that they might be bad tools for the purpose of writing security libraries.

There are not bad tools, but not the best either. If you spend mental stamina on trivial things, you have less for the important ones, the ones a compiler cannot check. This kind of tool (SSL) should be written in ada or haskell.

Why not Go, or JavaScript? I'm sorry, but specifying which language should be used is petty.

C and C++ are just fine, the fact that the OpenSSL guys cocked it up is not the language's fault, it is theirs. There are efficient ways to prevent this type of bug.

Re: The Heartbleed Bug

#530

Post by lkbm »

So, Google and Codenomicon independently found this two-year-old vulnerability at approximately the same time? How does that happen? Are they both looking at the same publicly-shared fuzzing data, or was there a patch that suddenly made it more obvious?

The obvious concern would be that one found it a good while ago, and just didn't bother announcing it until the other team was anyway. I don't believe that's what happened here, but I'm curious what the mechanism actually was.

Post reply on HN