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

491–500 of 547 posts

Re: The Heartbleed Bug

#491

Post by Xylakant »

dllthomas wrote: post #481
Xylakant wrote: post #476

Earlier quoted context omitted.

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.

The issue at hand is an error that is typical for C (unchecked out of bound memory access). It's a class of error that does usually not occur in other languages. The vulnerabilities in Rails were XSS vulnerabilities and an information leak - both classes of errors typically found in web application frameworks.

The first is an example of an error made more common by the language design, the other an example of errors typical for a class of applications. There's a fundamental difference here. There's a ton of reasons to criticize ruby and it brings its own set of flaws and problems, some rooted in the language and some rooted in its ecosystem - but the given examples just show that web applications are hard to get right. That's why this is not "a point not well made" but rather "sorry, you're attacking a strawman here".

Re: The Heartbleed Bug

#492

Post by tjgq »

bostik wrote: post #475
repost wrote: post #269

Earlier quoted context omitted.

Reading between the lines in the announcement it sounds like dropping and reconnecting may cause it to read memory freed up from a prior connection. It may "just" be a matter of keep trying or it may be a matter of opening lots of connections to consume resources dropping them all then connecting and seeing what was left on the beach after the tide went out. BTW Amazon AWS/ELM is vulnerable, confirmed publically by t…

> It may "just" be a matter of keep trying I gave this some thought earlier today, and expect that address space randomisation can make this bug eventually expose the server keys. You need to hit an address that has been just vacated from a (crashed) httpd worker. Most implementations clear encryption key material on exit, but a crashed process never got to run that code.

In most systems, this will only work within the same process. Contemporary Unix kernels always allocate zeroed pages to processes, so it's impossible for a process to recover data from another unless there's a kernel bug.

Re: The Heartbleed Bug

#493

Post by dllthomas »

Xylakant wrote: post #491
dllthomas wrote: post #481

Earlier quoted context omitted.

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.

The issue at hand is an error that is typical for C (unchecked out of bound memory access). It's a class of error that does usually not occur in other languages. The vulnerabilities in Rails were XSS vulnerabilities and an information leak - both classes of errors typically found in web application frameworks. The first is an example of an error made more common by the language design, the other an example of errors…

I'm not arguing the other side. I think you are correct. I just think you needed to point to the reason the parallel construction didn't work.

Re: The Heartbleed Bug

#494

Post by nadahalli »

rkuykendall-com wrote: post #468
syncsynchalt wrote: post #462

Earlier quoted context omitted.

The window in which the vulnerability was publicly known. I'm trying to come up with a personal security model that doesn't end with me living in a cabin in the woods.

Ah, comforting lies. Here's mine: "My data isn't important enough for any of this to affect me. "

Not you. But (someone connected to)+ you.

Re: The Heartbleed Bug

#495

Post by eliteraspberrie »

hf wrote: post #433
eliteraspberrie wrote: post #422

Earlier quoted context omitted.

The cost of a cryptography code review is about $5-10k per week.

Thanks! So how does this work: Say I have this project and I want it audited -- would you (or the company/person that you had in mind) give me an estimate like "I'd need 3 weeks for 25, 5 weeks for 50 or 10 weeks for 95% coverage" or do you simply analyse away for a week (or whatever time I'm willing to pay you) and try to find something ?

I don't have personal experience with it, but apparently these things are booked months in advance, on a contract basis. The engineer doing the audit spends an agreed number of weeks finding as many problems as they can, and hand you a report at the end.

Re: The Heartbleed Bug

#496

Post by dfc »

rurban wrote: post #440
whyleyc wrote: post #27

Earlier quoted context omitted.

Sooo in layman's terms - we only need to be worrying about HTTPS and not SSH ?

If it would be that easy. ssh not, but all those. Some of them actually use the heartbeat feature. curl seems to be the worst. $ apt-cache showpkg libssl1.0.0 => http://perl514.cpanel.net/libssl1.0.0.depends (186 deps)

I am having a lot of trouble figuring out what you were attempting to convey in the first four sentences in your comment.

The one thing that I can discern is that you printed a list of every package that depends on libssl1.0.0 for your configured repositories. But you have no idea if those programs make use of heartbeat. ssh (and everything related like libpam-ssh) is on that list and does not use TLS. The same can be said for many others such as tpm-tools, ntp/ntpdate/openntpd, xca and so on.

Re: The Heartbleed Bug

#497

Post by jcalvinowens »

kibwen wrote: post #490
jcalvinowens wrote: post #478

Earlier quoted context omitted.

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

Interesting. Clearly I need to explore this more. :)

Re: The Heartbleed Bug

#498

Post by sliverstorm »

tptacek wrote: post #24
gojomo wrote: post #15

Does SSH (specifically sshd) on major OSes use affected versions of OpenSSL? [answer pulled up from replies below: since sshd doesn't use TLS protocol, it isn't affected by this bug, even if it does use affected OpenSSL versions] What's the quickest check to see if sshd, or any other listening process, is vulnerable? (For example, if "lsof | grep ssl" only shows 0.9.8-ish version numbers, is that a good sign?)

The bug is in the handling of the TLS protocol itself (actually, in a little-used extension of TLS, the TLS Record Layer Heartbeat Protocol), and isn't exposed in applications that just use TLS for crypto primitives.

Ok, so is TLS Heartbeat accessible in every service that uses TLS?

The big one that comes to mind aside from https is smtp/tls, e.g. port 587

Edit: Apparently a PoC on STARTTLS has already been written, so smtp/tls is definitely vulnerable

Re: The Heartbleed Bug

#499

Post by CCs »

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.

C != OpenSSL. Some [1] would argue OpenSSL is not representative at all what C can do. Maybe you should check out Redis for beauty [2] and joy [3].

On the same note C != C++ either and you can write large systems in C++ without ever using memory allocation. You can use only bounds checked functions.

And you can have large security holes if you're not careful, no matter which language you pick.

[1] http://news.ycombinator.com/item?id=7556407

[2] http://johnpwood.net/2012/07/18/the-beauty-of-redis/

[3] http://news.ycombinator.com/item?id=2275413

Re: The Heartbleed Bug

#500

Post by est »

profquail wrote: post #416
est wrote: post #205

Earlier quoted context omitted.

Because if you write that in C#, you have to bundle 54MB common runtime and GC withit.

Did you actually read my entire comment, or did you just see "C#" and post a knee-jerk reaction? If you extract code from C# to C, you don't need a GC or any of the .NET class libraries -- you'd just have a standalone C file to use like any other.

> If you extract code from C# to C, you don't need a GC or any of the .NET class libraries

The problem is, you do need them. There's no 1:1 C# -> C extraction. You have to extract at least some part of the CLR along with.

Post reply on HN