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

241–250 of 547 posts

Re: The Heartbleed Bug

#241

Post by zik »

amalcon wrote: post #139
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…

Nothing in the standard prevents a C compiler + tightly coupled malloc implementation from implementing bounds checks. Out-of-bounds operations result in undefined behavior, and crashing the program is a valid response to undefined behavior. If your malloc implementation cooperates, you can even bounds-check pointer arithmetic without violating calling conventions. It's quite a shame that there isn't a compiler that…

I implemented this once in my C interpreter picoc. Users hated it because it also prevented them from doing some crazy C memory access tricks, so I ended up taking it out.

Re: The Heartbleed Bug

#242

Post by comex »

pbsd wrote: post #210
profquail wrote: post #200

Earlier quoted context omitted.

Why not write the code in C# (for example) and extract it to $SYSTEM_PROGRAMMING_LANGUAGE? It wouldn't be much different than what Xamarin are doing now for creating iOS and Android apps with C#.

Using C as an output language, backed by guarantees at the higher level, could certainly work. I believe ATS [1] works this way, and can even avoid garbage collection altogether if desired. I understand it is not an easy language, though. Nimrod [2] also generates C, but as I understand it garbage collection is unavoidable. [1] http://www.ats-lang.org/ [2] http://nimrod-lang.org/

This is one reason I'd like to see the removed LLVM C backend brought back and modernized, with Rust as the source language. Rust is safe, has no mandatory garbage collector, and has a much lower impedance mismatch with C or C++ than most higher level languages, so it should work well for libraries that are expected to integrate with C code.

Re: The Heartbleed Bug

#243

Post by pbsd »

yaakov34 wrote: post #238
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…

First, I do realize that rewriting the software stack from the ground up to have only managed code is a huge task. I do think that as an industry, we should set a goal of having at least one server implementation along these lines (where 'set a goal' may mean, say, grants or calls for proposals). Microsoft Research implemented an experimental OS like that, although it probably didn't have all the features a modern OS…

That was a very reasonable response, I can roll with that.

Just one thing: when I brought up talking directly to the hardware, I did not mean just for performance's sake. Avoiding side-channel attacks often requires to have high control over the generated machine code, and that is the primary reason to not do it in higher-level languages (unless they also permit that level of control).

Re: The Heartbleed Bug

#244

Post by Dylan16807 »

jcalvinowens wrote: post #239
rtpg wrote: post #221

Earlier quoted context omitted.

>The problem with C is that a lot of people don't write it well. There are languages that make it very very hard to write bad code. Haskell is a good example of where if your program type-checks, there's a high chance it's probably correct. C is a language that doesn't offer many advantages but offers very many disadvantages for its weak assurances. Things like the Haskell compiler show that you can get strong typing…

> There are languages that make it very very hard to write bad code. Haskell [...] Sure, but how much slower is Haskell than an equivalent implementation in C? Some quick searching suggests numbers like 1000% slower... and no amount of security is worth a 1000% performance hit, let alone a vague "security mistakes are less likely this way" sort of security. Being secure is useless if your code is so slow that you hav…

>no amount of security is worth a 1000% performance hit

Yes it is. Most of the applications I use take roughly 0% of my processor's capacity. I can spare a multiple like that outside of a few hot loops.

Saying 10x slowdown isn't worth it is like saying no one would ever compute on a phone.

Also random BS benchmark http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... says haskell is at least half as fast as C.

Re: The Heartbleed Bug

#245

Post by tiagocruz »

jlgaddis wrote: post #174
mstrem wrote: post #137

From the CloudFlare blog: "This bug fix is a successful example of what is called responsible disclosure". I just discovered this now and yum info openssl Yields 1.0.1e as available package which is vulnerable. I guess not all "stakeholders" have been warned properly - or am I jumping to conclusions?

Apparently Red Hat, Debian, and Ubuntu weren't (from what I gather from reading mailing list posts) -- no idea who else. That's not responsible at all, IMO. Whoever was in charge of this (NCSC-FI?) isn't very good at coordinating.

https://access.redhat.com/security/cve/CVE-2014-0160

https://bugzilla.redhat.com/show_bug.cgi?id=1084875

Re: The Heartbleed Bug

#246

Post by ballard »

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…

Agree a bazillion times.

Go or Java on top. Coding in C is like juggling chainsaws to say you can juggle them. C is certainly better than old school Fortran where memory management wasn't developed until later, but platforms like Erlang, Go and JRuby are really hard to beat.

The only problem is convincing people to migrate to different tools and transition codebases to another language. It would take a large project like FreeBSD, LLVM or the Linux kernel to move the needle.

Re: The Heartbleed Bug

#247

Post by sp332 »

lawl wrote: post #49

Holy shit. That seems worse than the debian openssl debacle. If i got that right ALL openssl private keys are now potentially compromised. I hope vendors push fixes soon, and then I guess I'm busy for a few days regenerating private keys.

Oh it's even worse, basically every secret you had in your server processes' RAM was potentially read in real-time by an attacker for the last 2 years.

Re: The Heartbleed Bug

#249

Post by sp332 »

gojomo wrote: post #47

What popular SSL client software uses the vulnerable OpenSSL? (Any web browsers, for example on popular linuxes? How about 'curl' when connecting to HTTPS sites?)

How would a client be compromised? I mean I guess a malicious server could send these bad heartbeat packets and sniff the keys, but if the server is pwned then your secrets are already revealed, right?

Re: The Heartbleed Bug

#250

Post by josh-wrale »

dfc wrote: post #214
josh-wrale wrote: post #77

Earlier quoted context omitted.

Just saw the following updated when I did an 'apt-get clean; aptitude dist-upgrade' on Debian Wheezy: libssl1.0.0 openssh-client openssh-server openssl ssh

I just wanted to point out that you really do not need the `apt-get clean.` Obviously your work flow is your business but I wanted to speak up in case you thought it was needed before upgrading packages.

I meant to say 'apt-get update'. Thanks for the heads up. I like to be sure I have the latest package metadata.
Post reply on HN