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

481–490 of 547 posts

Re: The Heartbleed Bug

#481

Post by dllthomas »

Xylakant wrote: post #476
eggnet wrote: post #456

Earlier quoted context omitted.

But rails is written in ruby. So it can't have security bugs, right?

Sure it can and I'm not surprised it has. But if you're trying to point out flaws in ruby, at least use examples for flaws in ruby - not flaws in something written in ruby. It's not like web frameworks in other languages magically don't suffer from XSS injection attacks.

The issue at hand is a flaw in something written in C, though. I agree the point wasn't well made (is there any reason to think those errors would not have been made had the project been written in C?) but your objection isn't quite right.

Re: The Heartbleed Bug

#482

Post by ahomescu1 »

What's interesting is that RFC 1122 from 1989 warned about problems like these, and gave a very good approach to prevent them from occurring:

At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability

[IP:1]: "Be liberal in what you accept, and conservative in what you send"

Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue. In general, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design, although the most serious problems in the Internet have been caused by unenvisaged mechanisms triggered by low-probability events; [...]

Re: The Heartbleed Bug

#483

Post by lockes5hadow »

gcv wrote: post #155
ams6110 wrote: post #48

Earlier quoted context omitted.

Worse, it's retroactively unfixable: Even doing all this [revoking certs, new secret keys, new certificates] will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. So it would be a good idea to change all your passwords to critical services like email and banks, once they have issued new certs and updated their openssl.

How do you suggest going about finding out if a bank updated the OpenSSL version in its DMZ?

My plan is to wait until the cert changes. If they don't change the cert then there is no point in updating my password anyway.

Re: The Heartbleed Bug

#484

Post by tel »

khafra wrote: post #389
CCs wrote: post #354

Earlier quoted context omitted.

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…

Write everything in Coq.

Perhaps more reasonably: write the core of your application in Coq and have it expose a DSL for writing business logic atop this infallible core.

Re: The Heartbleed Bug

#485

Post by sukuriant »

BrandonMarc wrote: post #470

Tinfoil-hat time: is it interesting that within hours (?) of public disclosure of the bug, there's a domain, a logo, a full writeup, everything. The paranoid part of me says the nefarious powers-that-be want me us to use the latest version, as though that would further their goals somehow. Common sense says I'm just being silly. I just wonder.

A close reading of this thread shows that CloudFlare(?) knew about the vulnerability for a week. It's been known for at least that long

Re: The Heartbleed Bug

#486

Post by jevinskie »

jnbiche wrote: post #406
jevinskie wrote: post #251

Earlier quoted context omitted.

How about Ada? It is time tested! GNU's Ada shares the same backend as GCC so it can be pretty fast. Good enough for DoD. =P Edit: I say this having used VHDL quite a bit. I appreciate its type strictness and ranges.

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.

Re: The Heartbleed Bug

#488

Post by strcat »

jcalvinowens wrote: post #478
kibwen wrote: post #466

Earlier quoted context omitted.

> I don't think intentionally preventing the programmer > from doing certain things the computer is capable of > doing on the theory it makes errors impossible makes > sense. With arguments like this, we'd all be back in the days of non-structured programming languages (enjoy writing all your crypto in MUMPS). Every modern language, including C, restricts itself in some way in order to make programs more predictable…

> With arguments like this, we'd all be back in the days of non-structured programming languages You're confusing the difference between syntactical restrictions and actual restrictions on what one can make the computer do. I define "things the computer is capable of" as "arbitrary valid object code executable on the CPU". (Valid here meaning "not an illegal instruction".) Any language that prevents me from producing…

Rust forces you to draw safety boundaries between safe and unsafe code, but you can do almost strictly more than C in unsafe Rust. It has support for inline assembly, SIMD, packed structs, and well-defined signed integer overflow. None of these is part of standard C or C++, and is only available through compiler-specific dialects. There wasn't even a well-defined memory model with support for atomics before C11/C++11.

Re: The Heartbleed Bug

#489

Post by steveklabnik »

jnbiche wrote: post #408
Pacabel wrote: post #398

Earlier quoted context omitted.

They are generally better than nothing, however. And they do generally offer better performance, better predictability, an a simpler implementation than other approaches to memory management and garbage collection. Maybe a language like Rust will offer a safer alternative at some point, but that point surely isn't today, and probably not tomorrow, either. Maybe there are other languages that offer better safety, but…

>Maybe a language like Rust will offer a safer alternative at some point, but that point surely isn't today, and probably not tomorrow, either. Rust absolutely does offer a safer alternative today. The only problem with Rust at this point is that the standard library is in a state of great flux, which makes it hard to use the language for serious projects. But the memory safety is there. And even with all the changes…

There are three current known production deployments of Rust, yes. I don't know if they're using 0.10 yet, but they exist.

Re: The Heartbleed Bug

#490

Post by kibwen »

jcalvinowens wrote: post #478
kibwen wrote: post #466

Earlier quoted context omitted.

> I don't think intentionally preventing the programmer > from doing certain things the computer is capable of > doing on the theory it makes errors impossible makes > sense. With arguments like this, we'd all be back in the days of non-structured programming languages (enjoy writing all your crypto in MUMPS). Every modern language, including C, restricts itself in some way in order to make programs more predictable…

> With arguments like this, we'd all be back in the days of non-structured programming languages You're confusing the difference between syntactical restrictions and actual restrictions on what one can make the computer do. I define "things the computer is capable of" as "arbitrary valid object code executable on the CPU". (Valid here meaning "not an illegal instruction".) Any language that prevents me from producing…

Quoting your other post:

  > in C, I can make the computer do absolutely anything I 
  > want it to in exactly the way I want it to. Maybe I 
  > don't like 8-byte pointers on my 64-bit CPU, and I want 
  > to implement a linked list allocating nodes from a 
  > sparse memory-mapped pool with a known base address 
  > using 16-bit indexes which I add to the base to get the 
  > actual addresses when manipulating the list? That could 
  > be a big win depending on what you're doing, and 
  > (correct me if I'm wrong) there is no way to do that in 
  > Java or Haskell.
This is possible in Rust, you'll just need to drop into an "unsafe" block when you want to do the pointer arithmetic. In the meantime, everywhere that isn't in an "unsafe" block is guaranteed to be as safe as normal Rust code. Furthermore, even Rust's "unsafe" blocks are safer than normal C code. Rust is a systems programming language, so we know that you need to do this stuff. We have inline assembly too! Our goal is to isolate the unsafety and thereby make it easier to audit.
Post reply on HN