Slashdot Mirror

Tell me why I need Windows 10 again?

http://www.tedunangst.com/flak/post/efficient-music-players-remain-elusive

OpenBSD

Whoops. Better make sure you're patched.

Microsoft

Yeah, because Windows 10 has no problems parsing strings or managing memory safely or anything.

Oh, really? A trainwreck?

Explain this, then: [Source is here]

The following CVEs were fixed in earlier LibreSSL releases:
              CVE-2015-0206 - Memory leak handling repeated DLTS records
              CVE-2014-3510 - Flaw handling DTLS anonymous EC(DH) ciphersuites.

            The following CVEs did not apply to LibreSSL:
              CVE-2014-3571 - DTLS segmentation fault in dtls1_get_record
              CVE-2014-3569 - no-ssl3 configuration sets method to NULL
              CVE-2015-0204 - RSA silently downgrades to EXPORT_RSA

Let's see... 5 CVE were either fixed in LibreSSL or did not apply to it. That's not too bad for a "trainwreck".

And what about that little dig at NetBSD? Hmmmm... You mean some people take stuff from OpenBSD and make it less secure? The plot thickens.

Oh, and by the way, that OpenSSH thingie? Yup, it came from the last "open source" version of SSH, the commercial software. In other words, OpenBSD devs took something already existing and made it better. Hmmm... I think you just don't know what you are talking about...

Listen, you can find OpenBSD programmers annoying and even call them "masturbating monkeys", but they know their stuff. Period. Calling what they do a "trainwreck" is hyperbole at best and just plain untrue at worst.

This being said, to get back on topic, auditing OpenSSL is not a bad idea. Far from it.

I hope you're not recommending OpenBSD as an alternative for better long term support.

More than a year old? You're out of luck.

They were vulnerable because openssl took specific measures to counteract the defense mechanisms present in openbsd. See this writeup.

Even Coverity could not detect the problem.

In other news, there was also a 4-year-old flaw in OpenSSL. In the same way this bug was publicly reported (CVE-2010-5298) for years, without no one taking the responsibility to fix it.

Here's a detailed report of the bug by OpenBSD developer Ted Unangst. It was finally fixed in the recent quality assurance effort conducted by the OpenBSD guys.

In other news, OpenSSL gets a 4-year-old flaw patched. The catch here is that the bug was not only 4 years in the codebase, but it was publicly reported (CVE-2010-5298) for 4 years, without no one taking the responsibility to fix it.

OpenBSD developer Ted Unangst made a detailed report of the bug. It's not as severe as Heartbleed, but still allows remote attackers to inject data across sessions or cause a denial of service (use-after-free and parsing error) via an SSL connection in a multithreaded environment.

In other news, OpenSSL gets a 4-year-old flaw patched. The catch here is that the bug was not only 4 years in the codebase, but it was publicly reported (CVE-2010-5298) for 4 years, without no one taking the responsibility to fix it.

OpenBSD developer Ted Unangst made a detailed report of the bug. It's not as severe as Heartbleed, but still allows remote attackers to inject data across sessions or cause a denial of service (use-after-free and parsing error) via an SSL connection in a multithreaded environment.

Actually, it's possible to remove all errors and imperfections, if you would be satisfied with being boring.

No. Software for which you can guarantee that no error exist is not only boring: it is useless.

To prevent the next Heartbleed, it's more productive to donate to LibreSSL.

You do not get my point. You may succeed in rendering it less probable. But you cannot prevent it.

I do get your point, and I disagree. Perhaps my point is not so clear, so I'll rephrase it: For a protocol as complicated as SSL, it's difficult to guarantee that a program is free of bugs, but it is possible to create a program free of exploits. With sufficient discipline in specific domains, it's also possible to create bug-free specifications. Computer programs are just math, and a lot of math can be proved. The key is to decompose programs into pieces that humans can reason about. That's what Crockford means by "error-resistant" programming.

I see that you're a Ruby programmer. It's difficult to create the Heartbleed vulnerability in Ruby. I guess you could do it if you did all your processing in a custom IO object "for performance reasons," like OpenSSL's custom malloc. That sort of silliness is all over the OpenSSL project, and that's what the LibreSSL project is eliminating. Now, the Ruby runtime itself is a complicated program and not bug-free, but every fix in the runtime eliminates a bunch of bugs in many Ruby programs.

Similarly, the OpenBSD project has a bunch of practices and programs to eliminate or mitigate the severity of exploits. At this point, I trust them more than I trust OpenSSL. So, we should support LibreSSL.

Even though I've never used it...

And there you go with the problem with it. OpenBSD has no holes in the install as long as you don't mess with the config and actually turn on a service and as long as you upgrade to each new version which can't (practically) be done automatically. It's almost unusable to a normal user.

Still; I'm going to install it today and all of you should send the project some money 'cos lots of the important security software such as OpenSSH comes from OpenBSD.

Yes it did. You were not vulnerable if you have built OpenSSL with the feature disabled.

Except that OpenSSL actually didn't run with the "feature disabled" (internal freelist-based memory allocator) due to uninitialized memory bugs in OpenSSL that required newly allocated blocks of certain types to have memory set in them from previously freed blocks. See details here.

This bug would have been utterly trivial to detect when introduced had the OpenSSL developers bothered testing with a normal malloc (not even a security focused malloc, just one that frees memory every now and again). Instead, it lay dormant for years until I went looking for a way to disable their Heartbleed accelerating custom allocator.

it's a very good read.

They thought malloc was too slow.

http://www.tedunangst.com/flak...

It usually isn't especially fast. Lots of software avoid using malloc where possible.

They thought malloc was too slow. http://www.tedunangst.com/flak...

Yes, malloc() would have blown up on occurrence and the problem would have quickly been found and resolved. here's the skinny.

Yeah, Ted Unangst (OpenBSD) looked into it.

http://www.tedunangst.com/flak...

Basically: someone took advantage of the OpenSSL Malloc allowing use-after-free. What is this, SimCity for Windows?

considering that the real bug is OpenSSL's malloc, where it was reusing 'freed' memory I think that's the bug that is critical.

Well. no.

The bad bit of code is, per http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf:

struct {
        unsigned short len;
        char payload[];
} *packet;

packet = malloc(amt);
read(s, packet, amt);
buffer = malloc(packet->len);
memcpy(buffer, packet->payload, packet->len);
write(s, buffer, packet->len);

The bad bit is that "amt" is not checked against "packet->len", so the copy into "buffer" reads off the end of the allocated data structure "packet". The data read may be freed memory, or it may be allocated memory.

The only way malloc could completely protect against the bug would be by putting an unmapped guard page after every malloced block - making every malloced block at least one page long and slowing malloc down by the time needed for all those munmaps. (Probably making malloc slow enough to incite OpenSSL devs to implement their own malloc layer...)

I think the real bug is in the RFC.

Look at the fix:

/* Read type and payload length first */
if (1 + 2 + 16 > s->s3->rrec.length)
        return 0; /* silently discard */
hbtype = *p++;
n2s(p, payload);
if (1 + 2 + payload + 16 > s->s3->rrec.length)
        return 0; /* silently discard per RFC 6520 sec. 4 */
pl = p;

Why does the heartbeat request even contain the length of the heartbeat block? We know the length of the SSL record!

(Not even bothering with the whole problem that the heartbeat thing is ridiculous - there are already ways of keeping connections alive at the TCP level - why does every layer of the protocol need it's own keepalive).

"known for 2 years"

No, no, this has been the code part of the stable release of OpenSSL for 2 years. The bug has only been known by non-blackhats for up to a few weeks.

Yes, the heartbeat exploit popped up just recently.
But the bug which forces users to keep data in freed buffers has been known for at least 4 years. Tedunangst calls it "exploit mitigation countermeasures" ...

Read Ted Unangst's analysis. You don't have to do anything special to trigger the bug when using a normal malloc rather than OpenSSL's broken approach. OpenBSD's approach protects you more but any malloc would have surfaced the error:

This bug would have been utterly trivial to detect when introduced had the OpenSSL developers bothered testing with a normal malloc (not even a security focused malloc, just one that frees memory every now and again).

The problem is the OpenSSL code was freeing a buffer and then immediately re-allocating it to read data from. The OpenSSL team got lucky and it worked when the buffer was the right size.

I think this Ted fellow linked from the summary makes a good case against it being "reasonable" at the end of his second post:

This bug would have been utterly trivial to detect when introduced had the OpenSSL developers bothered testing with a normal malloc (not even a security focused malloc, just one that frees memory every now and again). Instead, it lay dormant for years until I went looking for a way to disable their Heartbleed accelerating custom allocator.

Building exploit mitigations isn't easy. It's difficult because the attackers are relentlessly clever. And it's aggravating because there's so much shitty software that doesn't run properly even when it's not under attack, meaning that many mitigations cannot be fully enabled. But it's absolutely infuriating when developers of security sensitive software are actively thwarting those efforts by using the world's most exploitable allocation policy and then not even testing that one can disable it.

in light of this analysis: http://www.tedunangst.com/flak... i'm inclined to agree with Theo on this one...

De Raadt wrote "OpenSSL is not developed by a responsible team".

On the contrary, I believe it was developed by a responsible team, that unfortunately made an error.

Most everyone have made errors, even if most go unnoticed and are essentially harmless. This one appears different, but I don't think it justifies De Raadt's moronic comment.

Not so sure they're responsible.

Did you read this?

This bug would have been utterly trivial to detect when introduced had the OpenSSL developers bothered testing with a normal malloc (not even a security focused malloc, just one that frees memory every now and again). Instead, it lay dormant for years until I went looking for a way to disable their Heartbleed accelerating custom allocator.

Building exploit mitigations isn’t easy. It’s difficult because the attackers are relentlessly clever. And it’s aggravating because there’s so much shitty software that doesn’t run properly even when it’s not under attack, meaning that many mitigations cannot be fully enabled. But it’s absolutely infuriating when developers of security sensitive software are actively thwarting those efforts by using the world’s most exploitable allocation policy and then not even testing that one can disable it.

The OpenSSL team doesn't fully test their product.

That's pretty much as good an example of incompetence that you can probably find.

Oh, and read this: http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

In effect at some points OpenSSL does:

        free (rec); ...
        rec = malloc (...);

and assumes that rec is the same.

Eeew,

heartbleed vs malloc.conf

and

analysis of openssl freelist reuse. Short articles with a lot of good information.

heartbleed vs malloc.conf

and

analysis of openssl freelist reuse. Short articles with a lot of good information.