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

541–547 of 547 posts

Re: The Heartbleed Bug

#541

Post by SparklingCotton »

sspiff wrote: post #538
spoiler wrote: post #529

Earlier quoted context omitted.

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.

JavaScript would be terrible, because it's easy to hide unwanted behaviour in counter-intuitive corners of the language. Besides the language peculiarities, a garbage collected or interpreted language is very vulnerable to side channel attacks because of the large amount of complicated behaviour that is being glossed over by the language runtime. (One example would be garbage collection rounds and timing attacks, but…

C and AsmJS are just as open to side channel attacks. AsmJS is safe, C is unsafe.

I'd take javascript over C any day.

Re: The Heartbleed Bug

#542

Post by SparklingCotton »

CCs wrote: post #354
ballard wrote: post #254

Earlier quoted context omitted.

That's what I like about Ruby. ;) Even in C, Go or Python, I column align any text that is remotely similar, so differences are obvious. Clean code might be extra work but the net work (maintenance) should amortize less. Reducing cognitive load for large supportable production codebase cannot be underscored enough.

There's no "just use X" type of answer in security. Sep 2013 "All versions of the open source Ruby on Rails Web application framework released in the past six years have a critical vulnerability that an attacker could exploit to execute arbitrary code, steal information from databases and crash servers." https://groups.google.com/forum/#!topic/rubyonrails-security... Nov 2013 "A lingering security issue in Ruby on Ra…

There is a "just use X". If you code in a language where you can express the invariants in your code, and make the compiler check those invariants, then your code is immune to all of the vulnerabilities that we have seen in OpenSSL.

The fact that these languages don't automatically do all my system administration tasks for me is not an argument against using them.

http://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solutio...

Re: The Heartbleed Bug

#543

Post by SparklingCotton »

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…

What you say can easily be disproved, and you are simply asking for too much if you ask for something to be a drop-in replacement for OpenSSL. Some re-architecting is requred simply because of the insecurity of C.

For example, a shared library that implements SSL would have to be a shim for something living in a separate process space.

http://hackage.haskell.org/package/tls

That is a Haskell implementation of TLS. It is written in a language that has very strong guarantees about mutation, and a very powerful type system which can express complex invariants.

Yes, crypto primitives must be written in a low level language. C is not low level enough to write crypto, neither securely nor fast, so that's not an argument in its favor.

Re: The Heartbleed Bug

#544

Post by SparklingCotton »

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

No it simply does not, because the language forces you to write pure functions. The type system invites you to express invariants.

There are very fundamental connections between strong typing, program verification, and proofs.

http://en.wikipedia.org/wiki/Curry-Howard_correspondence

Thus, the argument that Haskell probably has the same, is simply false.

There are large web platforms in Haskell. Yesod is probably the largest eco-system. It is clearly not as well used as RoR, but anyone can dig through large amounts of code to try to find these bugs.

What Haskell has that everyone else has are bugs/misunderstandings in how protocols are implemented. Sometimes there can be fundamental bugs in the run-time-system. However, large classes of bugs are fundamentally less likely to appear than in less safe languages.

Re: The Heartbleed Bug

#545

Post by sspiff »

SparklingCotton wrote: post #541
sspiff wrote: post #538

Earlier quoted context omitted.

JavaScript would be terrible, because it's easy to hide unwanted behaviour in counter-intuitive corners of the language. Besides the language peculiarities, a garbage collected or interpreted language is very vulnerable to side channel attacks because of the large amount of complicated behaviour that is being glossed over by the language runtime. (One example would be garbage collection rounds and timing attacks, but…

C and AsmJS are just as open to side channel attacks. AsmJS is safe, C is unsafe. I'd take javascript over C any day.

Guarding against side-channel attacks in any language is hard. Guarding against them in Javascript is probably impossible. Whether you would take Javascript over C is irrelevant. It would still be a terrible choice for a security framework. Perhaps modern system languages, such as D or Go might be suitable.

Re: The Heartbleed Bug

#546

Post by ogourment »

pvg wrote: post #224
pbsd wrote: post #191

Earlier quoted context omitted.

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…

We might be stuck with C for quite a while but then maybe the more interesting question is 'how does this sort of thing get past review?'. It's not hard to imagine how semantic bugs (say, the debian random or even the apple goto bug) can be missed. This one, on the other hand, hits things like 'are the parameters on memcpy sane' or 'is untrusted input sanitized' which you'd think would be on the checklist of a potent…

I think you mentioned the right keyword: "checklist". If you scan the http://wiki.openssl.org website carefully, you will be scanning it carefully. (ie. not finding anything). It doesn't seem to be a good practice yet to use checklists for code reviews. Could this change? I hope: http://www.infoq.com/presentations/agile-code-reviews

Re: The Heartbleed Bug

#547

Post by funkiestj »

ballard wrote: post #254
lambdasquirrel wrote: post #152

Earlier quoted context omitted.

I've felt that C makes this code easy to write because it makes doing the right thing hard. What you are describing is just a lot of work in C, compared to a language with something akin to Java's generics, which are in turn an afterthought in the ML family of languages. What we're asking for is not that complicated from a PL standpoint. A generic streams library? Economics plays an invisible part here. Someone writi…

That's what I like about Ruby. ;) Even in C, Go or Python, I column align any text that is remotely similar, so differences are obvious. Clean code might be extra work but the net work (maintenance) should amortize less. Reducing cognitive load for large supportable production codebase cannot be underscored enough.

you get it but the opinion of "C and C++ are fine for SSL, the OpenSSL guys just screwed up" is plain wrong.

This is a question of priorities. We have speed and security. If you chose C/C++ (non-existent automated checking of memory access) you are chosing speed first, security second.

If security is critical then you need to chose a language that makes array out of bounds access well nigh impossible. This is an easy problem -- we have languages that will give this to us.

What percentage of exploits in the wild come from array (and pointer) access out of bounds? I'd venture to say it is above 50%.

Rather than have programmers everywhere "try hard to be careful" writing this code, let them use a safer language and have a few really smart folk work on optimizing the compiler for said language to make the safety checks faster (e.g. removing provably unnecessary/redundant checks).

People think that chosing C/C++ has a better business case (i.e. better performance / scaling) because "being really careful" works most of the time. The problem is when heartbleed (or the next array out of bounds access bug) hits the the business case's ROI no longer looks so much better than the safer path.

A better language won't eliminate all security holes but it can eliminate a huge class of them and allow engineers to focus the energy they used to spend on "being really careful about array access and pointers" on other tasks (be they security, performance or feature related).

EDIT: stating the obvious .. there are good uses for C style languages but writing large bodies of software that needs to be resistant to malicious user attacks is not one of them.

Post reply on HN