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

451–460 of 547 posts

Re: The Heartbleed Bug

#451

Post by stcredzero »

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…

we can plug this seemingly endless source of bugs which has been affecting the Internet since the Morris worm. It has now cost us a two-year window in which 70% of our internet traffic was potentially exposed. It will cost us more before we manage to end it.

Could one make a new kind of OS where C programs are compiled to some intermediate representation then when run this is JIT compiled within a managed hypervisor sandbox? Could Chrome OS become something like this? Does this already exist? MS had a managed code OS called Singularity.

Re: The Heartbleed Bug

#452

Post by jcalvinowens »

jerf wrote: post #424
jcalvinowens wrote: post #264

Earlier quoted context omitted.

> Most of the applications I use take roughly 0% of my processor's capacity. We're talking about a server-side vulnerability in OpenSSL here, not applications running on your personal computer. Roughly speaking, making your server code twice as slow means it will cost you twice as much money to run your servers. Of course, that depends a lot on what exactly you're doing and is obviously not always true... but OpenSSL…

"If OpenSSL suddenly became twice as slow, it would cost a lot of people a lot of money." Perspective check: We are talking about a situation in which OpenSSL had NO SECURITY , has had NO SECURITY for two years, and an unknown amount of existing caught traffic is now vulnerable. If the NSA did not already know about this bug (and given that it is not hard to imagine the static analysis tool that could have caught thi…

> We are in a position in which OpenSSL was ENTIRELY INSECURE and has been for years, because of a trivial bug that can pretty much ONLY happen in the exact language that OpenSSL was implemented in!

This is incredibly, incredibly false.

Pointers exist. Raw memory accesses exist. Even if you're writing code in a language that hides them from you, they still exist, and there is still potential for somebody to have done something stupid with them. I guarantee you that there are JVM's in the wild with vulnerabilities as severe as this one. Arguing for the use of languages that intentionally cripple the programmer on the theory they make vulnerabilities less likely is silly.

I'm not denying the severity of this issue. But bugs happen. All we can do is fix them, learn from them, and move on. The lesson to be learned here is that really messy code is a big problem that needs to be fixed, because it makes auditing the code prohibitively difficult.

The proper response IMHO is a ground-up rewrite of OpenSSL. A lot of big players use OpenSSL; financing such an endeavor would not be difficult.

Re: The Heartbleed Bug

#453

Post by mcguire »

pjmorris wrote: post #355
axman6 wrote: post #309

Earlier quoted context omitted.

My first thought too was Ada, it's easily callable from anything that can call C afaik, and has infinitely better support for catching these sorts of bugs than C or C++ do. It's basically made for this kind of project, and yet no one in the civilian population really cares; it's a real shame. Not only does Ada make it easy to do things safely, it makes it very hard to do things unsafely. I've been advocating Ada's us…

Tony Hoare (Mr. Quicksort, CSP, etc...) has softened his stance since "The Emperor's Old Clothes", but his concern was that ADA is too complicated to be understandable and safe. I hated Pascal because the array length was part of its type... but maybe that kind of thinking is apparently what it takes to avoid bugs like Heartbleed.

Can I suggest you take a quick look at ATS? The language itself is kind of horrid (and I am a ML fan) and the learning curve is way steep, but the thin, dependently typed layer over C aspect is actually quite nice.

Note: I'm not suggesting it for current production use, but rather as something that could be expanded further in the future.

Re: The Heartbleed Bug

#454

Post by orthecreedence »

jerf wrote: post #424
jcalvinowens wrote: post #264

Earlier quoted context omitted.

> Most of the applications I use take roughly 0% of my processor's capacity. We're talking about a server-side vulnerability in OpenSSL here, not applications running on your personal computer. Roughly speaking, making your server code twice as slow means it will cost you twice as much money to run your servers. Of course, that depends a lot on what exactly you're doing and is obviously not always true... but OpenSSL…

"If OpenSSL suddenly became twice as slow, it would cost a lot of people a lot of money." Perspective check: We are talking about a situation in which OpenSSL had NO SECURITY , has had NO SECURITY for two years, and an unknown amount of existing caught traffic is now vulnerable. If the NSA did not already know about this bug (and given that it is not hard to imagine the static analysis tool that could have caught thi…

But OpenSSL is embedded in many other languages and applications because it's written in C. Show me a low-level language with a stable syntax that fixes the problems caused by using C that can also be embedded in Java, Python, Lisp, Ruby, etc etc. I don't think you can.

Some things need to be in C because they need to be run everywhere, including embedded in applications. No other language does this, to my knowledge.

Re: The Heartbleed Bug

#455

Post by ionforce »

jdiez17 wrote: post #145
brown9-2 wrote: post #125

Earlier quoted context omitted.

if (1 + 2 + 16 > s->s3->rrec.length) I don't know C well - why write 19 like this?

Those numbers probably have some significance. `1` seems to be "heartbeat type" and `2` seems to be "heartbeat length".

Why not use constants then?

Re: The Heartbleed Bug

#456

Post by eggnet »

Xylakant wrote: post #403
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…

Ruby != Rails. We do a lot of ruby, but practically no rails.

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

Re: The Heartbleed Bug

#457

Post by jcalvinowens »

gnuvince wrote: post #444
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. 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 def…

> Why not put every chance on our side and use languages (e.g. Rust, Ada, ATS, etc.) that make entire classes of errors impossible?

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.

As I've said several times in this thread, somebody has to deal with the pointers and raw memory because that's the way computers work. Using a language where the language runtime itself handles such things only serves to abstract away potential errors from the programmer, and prevents the programmer from doing things in more efficient ways when she wants to. It can also be less performant, since the runtime has to do things in more generic ways than the programmer would.

> Including people responsible for one of the most important security-related library in the world.

I think you've hit on a crucial part of the problem: practically every software company on Earth uses OpenSSL, but not many of them pay people to work on it.

  calvinow@Mozart ~/git/openssl $ git log --format='%aE' | grep -Po "@.*" | sort -u - 
  @baggins.org
  @benl-macbookpro3.local
  @chromium.org
  @cloudflare.com
  @comodo.com
  @cryptsoft.com
  @esperi.org.uk
  @fh-muenster.de
  @fifthhorseman.net
  @fsmat.at
  @gmail.com
  @google.com
  @igalia.com
  @infradead.org
  @innominate.com
  @leeds.pl
  @linaro.org
  @links.org
  @neurodiverse.org
  @openssl.org
  @opensslfoundation.com
  @pobox.com
  @roeckx.be
  @secondstryke.com
  @torproject.org
  @trevp.net
  @v3.sk
  @velox.ch
I was very surprised how short that list is. There are a lot of big names that make heavy use of this software that are not on that list.

Re: The Heartbleed Bug

#458

Post by danielweber »

leocassarani wrote: post #381
FiloSottile wrote: post #215

I've built a web tester for this bug, find it at http://filippo.io/Heartbleed/ It actually exploit the bug, since it was quite trivial, and echo some memory. It's written in Go, no more than 100 lines. I'll release code in some time.

Interestingly, your tool claims our website (SSL-terminated at our ELB instance) is still vulnerable; while this other tool ( http://possible.lv/tools/hb ) claims we are unaffected. Another, known unpatched, app is reported to be affected by both tools. Is it possible that FiloSottile/Hearbleed may report false positives?

From what I've learned, it reports back if it gets something, when it should get nothing.

How vulnerable a specific site is depends on luck. Yahoo must have broken a whole bunch of mirrors because total amateurs can send mail.yahoo.com a certain blob of code and it has a good chance of returning a stranger's password.

Re: The Heartbleed Bug

#459

Post by colinbartlett »

rmc wrote: post #364
mattparlane wrote: post #162

What worries me about this is that the commit that fixes it [0] doesn't include any tests. Is that normal in crypto? If I committed a fix to a show-stopper bug without any tests at my day job I'd feel very amateur. [0] http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...

Sometimes things are time-critical.....

Ah, the old middle-management excuse: "We don't have time to write tests!"
Post reply on HN