Matasano Chargen - Latest Comments in This New Vulnerability: Dowd’s Inhuman Flash Exploit

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

yukiclothes — Wed, 08 Jul 2009 22:42:12 -0000

Thank you, very good explanation.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

chatsohbet — Tue, 30 Jun 2009 09:23:24 -0000

SOHBET
BURSA SOHBET
ISTANBUL CHAT
ISLAMI CHAT
IZMIR CHAT
ANKARA ARKADAS
ALMANYA CHAT
TURKEY CHAT
MYNET
SITENE EKLE
VIDEO KLIP IZLE

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

John Carmack — Sun, 17 May 2009 04:13:22 -0000

You people obviously didn't read the article (or you barely know C at all). First of all, if "buf" is a buffer, buf[x] is an offset into that buffer. If buf == NULL, then buf[x] == *(x). The only way this is safe is if you absolutely KNOW that malloc() will never, ever return NULL, not even if Hell goes into an ice age. The exploit being described was possible because malloc() does return NULL.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

secgeek — Thu, 10 Jul 2008 13:05:35 -0000

the bug is nice but what i like is the analysis u posted here.i have to read it few times to get exactly wht you mean but very nice,keep up the good work!!

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

ivan — Wed, 23 Apr 2008 22:09:11 -0000

@brl: hm ok so we are thinking about the same lines then. I was specifically thinking about PKCS1 because I recently looked at it in SILC's source code and I was specifically thinking about Bleichenbacher's attack as well but since I couldn't put my finger on anything concrete where aborting on malloc() would constitute a real issue in just posted a generic comment about that thought . My hunch was that somewhere in the depths of ASN1->MP->PKCS1 operations there is a malloc() with a user-controllable size argument that could provide an oracle if malloc() aborted on failure. Even if malloc didn't abort there would be an oracle but it would be much harder to measure reliably. However, one thing is to post a random comment on blog and an entirely different thing is to actually find the attack and implement it...and that is only available to "One of God's own prototypes. Some kind of high powered mutant never even considered for mass production. Too weird to live, and too rare to die."

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

brl — Wed, 23 Apr 2008 18:32:20 -0000

If I was being sarcastic that would mean that when I was commenting on how massively amazed and astonished I was by your post last week, that I was exaggerating or that I meant it ironically or something.

That's definitely not the case and I'm becoming more and more fascinated by this idea every day.

Remember when Daniel Bleichenbacher tore OpenSSL a new one over PKCS #1 padding?

No no, the other time. Ten years ago. The PKCS1 'oracle' attack to invert RSA.

That problem was 'fixed' by kludging implementations to not leak information about the outcome of padding verification.

If something goes wrong, just fill the premaster-secret with random bytes and pretend that nothing strange is happening. This prevents an attacker from knowing if his malicious ciphertext decodes to a PKCS1 conforming message or not.

At least directly through the SSL protocol....

When invalid padding is detected during RSA decryption, the RSA module logs the failure to the internal OpenSSL error handling system. This error is never exposed to the client (for example, in an SSL protocol message), and just to be on the safe side, if the RSA decryption fails for any reason the SSL module calls shenanigans and explicitly clears this internal error log before implementing the random byte hack described above.

Hmm...

It seems that the first time a thread or process logs an error through the error API, a ~400 byte ring buffer structure is allocated with malloc().

Oh, and if that malloc() fails for some reason?

In that case, OpenSSL does something reasonable (?) and returns a reference to a single static instance of the structure. (A special bonus quirk for fans of extreme sports such as thread racing to double free).

So you can't crash the service by forcing that particular malloc() to fail, but you can later measure if the allocation occurred or not if you understand the allocation failure regime used throughout OpenSSL:

Don't crash, abort(), or exit() if malloc() fails. Just fail the current operation and all future operations until memory is available again.

I think you could build an oracle for the Bleichenbacher attack out of this behavior. An oracle that precisely detects that the problem with your message is broken padding, (and not the less useful: broken padding OR malformed plaintext).

This is the most powerful leak possible for this attack and with the Klima-Pokorny-Rosa optimizations you would only need a few thousand oracle consultations to sign or decrypt something.

It's just an idea, and I'm not claiming to have implemented the attack or anything. There would obviously be a lot of hurdles to jump over and details to hammer out in order to build a practical implementation. I've just been browsing OpenSSL looking for ways to break things with creative malicious memory exhaustion.

I don't know how you could even begin fixing bugs like this in a general way. Deciding when to run out of memory in some non-deterministic way?

This stuff is a lot more interesting to me than bickering about whether or not NULL pointer dereference bugs are commonly exploited outside of imaginationland. So sorry if I'm dragging this thread too far off topic.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Thomas Ptacek — Wed, 23 Apr 2008 09:32:28 -0000

Again, Ivan, if your answer to bad programming is "use good programming", you and I are simply on different wavelengths. I think the standard libraries need to be hardened against bad programming.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

ivan — Wed, 23 Apr 2008 03:18:26 -0000

@brl: I see with joy that you've polished your skills for sarcasm, good for you!
I don't recall making any claims about new classes of attacks nor of my three lines of code being a solution for anything else than proving the point that not having malloc() abort on failure _may_ be actually useful and desired.
I just blurted a general idea (I guess that is what a blog comment is for) of when automatically exiting on malloc failure may have security implications beyond code execution but then again I do not have any precise concrete real-world examples to show for, the only thing that came to mind as potentially relate when I posted was THC's paper on execution path timing analysis applied to OpenSSH some years ago.
I can think of other equally random and bogus possibilities to entertain you (like BIND or Apache for example) but I think you are way smarter than me for that kind of thing.
@tom: I don't stick to K&R semantics because I think they're "right", I just think that changing malloc() semantics and encouraging programmers to not do error checking and to rely on the now declared "safe" malloc will not produce more secure programs.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

brl — Tue, 22 Apr 2008 03:56:09 -0000

I think you've misinterpreted my enthusiasm a bit.

I really was sincerely blown away and amazed by the implications of what Ivan posted last week. Maybe it's old hat to everybody else here but it's honestly the first time I've ever heard the idea.

I spent the weekend thinking about what might be possible with a technique like this. Came up
with silly examples like:

What if there was a hypothetical operating system that was configured by default to set up RLIMIT_DATA to some value other than 'unlimited'. Let's call it OpenBSD.

Then suppose that this OS runs some imaginary network service that makes it almost too easy
to allocate (and free) a lot of memory in arbitrarily sized chunks. We'll name that one OpenSSH.

Now let's add a feature to our fantasy network service that performs an asymmetrical private
key operation. We can call it 'signing the key exchange with the host RSA key'.

Ok, now suppose that the RSA signing is implemented by say, an exponentiation that rakes over the
private exponent 6 bits at a time and performs a different pattern of big number multiplications (and hence allocations) depending of the value of each particular window of private key bits.

Now to _really_ stack the deck in our favour, we'll assume that during the modular exponentiation all the allocations are saved up and free()ed together at the end of the operation by releasing the BN_CTX.

Sure, it's a contrived example, but I'm just saying that it might be kind of interesting to remotely measure precisely where sbrk() is failing in a theoretical scenario like that.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Thomas Ptacek — Mon, 21 Apr 2008 23:52:38 -0000

You know, if it was directed at anyone else, I'd find the sarcasm there bracing. But having known Ivan Arce for going on 15 years now, I'm pretty sure I wouldn't be alone in being concerned about being made to look dumb for taunting him like that. =)

I admit though, I don't understand why so many smart people stick up for the K&R; malloc semantics. They suck. We have empirical proof of that: spend an afternoon taking a random sample, using only projects people have heard of. You will find three classes of codebase:

(1) Those that have given up on K&R; malloc and replaced it with a wrapper that does exactly what I advocate.

(2) Those that don't know what's wrong with K&R; malloc, pretend to check rigorously, but fail either directly or in a byzantine manner when an attacker exhausts their resources.

(3) Those that do understand what's dangerous about K&R; malloc, and therefore expend great effort to carefully check and recover from all allocation failures.

Even if I unrealistically concede that the codebases are divided evenly among the three classes --- and they are not (I've provided them in ranked order) --- that's still a failure for the K&R; semantics.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

brl — Mon, 21 Apr 2008 23:29:48 -0000

@ivan

First of all, thanks so much for sharing your discovery of an entire new class of cryptographic side channel attacks.

As far as I am aware (unless I missed something), breaking crypto with memory allocation failure is a previously unpublished result.

It's quite astonishing to learn something so interesting from a short random blog comment.

So I don't mean this too critically, but I think that your proposed countermeasure doesn't really work in the case where the allocation patterns are deterministic and repeatable. That is to say, exactly the same situations where you would expect to be able to use this attack.

It's the same if you fail immediately upon allocation or if you test everything together and then fail. In most scenarios that I can imagine, you can't even know the difference.

Either way you can easily guess the sum of the two secret lengths with a binary search, and also the exact values if you have an easy (ie: polynomial time) way to verify your guesses.

Depending on constraints for the possible secret length values, and how much control you have over allocations leading up to this situation, you might be able to also guess the secrets directly by punching appropriate sized holes in the heap and then running experiments.

Have you tried your attack against the new constant-time modular exponentiation in OpenSSL? I was instrumenting the allocations over the weekend and it seems very promising.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Thomas Ptacek — Mon, 21 Apr 2008 00:35:19 -0000

ivan --- come on! I'm not saying, "you must use super_duper_extra_safe_malloc". You're missing my point in almost every way:

* Where you say "super_duper_extra_safe_malloc", I say "malloc"

* Where you say "malloc", I say "unsafe_malloc"

* I'm not arguing that "unsafe_malloc" shouldn't be available.

Again: the default should be, fail safe.

So, your example doesn't work with libtqbfmalloc, because you misused it. Just add the token "unsafe_" to each call and you're fine.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

ivan — Sun, 20 Apr 2008 20:46:34 -0000

@tom: my code is wrong but i could do:
{
p1=malloc(secret);
p2=malloc(user_supplied);
p3=malloc(secret);
if( !p3 || !p2 || !p1) abort()
}
which I cant with TQBF's super_duper_extra_safe_malloc() that you'd like me to use.

btw, as far as I recall the debug options of phkmalloc can be used to force an abort() on ENOMEM. In fact i think that's the default behavior now.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Thomas Ptacek — Sun, 20 Apr 2008 14:06:20 -0000

@Igor --- No, I think you need to re-read the post. I'm not saying Word should crash on malloc. I'm saying that there should be two malloc interfaces: a default that fails safe, and a variant to handle the Word-like case.

This all sounds "so stupid" to you because you're not working in security. News flash: security sucks. Things would be a lot easier if innocuous programmer errors couldn't be warped into exploits.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Thomas Ptacek — Sun, 20 Apr 2008 14:02:58 -0000

@Ivan --- congratulations, you've found the one case in 1,000 that justifies "unsafe_malloc".

Think about this. You're proposing a scenario in which, failure or not, the very pattern of calls to malloc is sensitive. Your code is insecure with or without a change in the library. You think that code should simply call "malloc"? I'd rename "malloc" to "super_unsafe_side_channel_vector_malloc" for that case even if NULL pointers couldn't be offset.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Thomas Ptacek — Sun, 20 Apr 2008 14:01:02 -0000

@AB --- while I agree that kernel malloc is a different animal, I don't know that you're following my reasoning. I'm not saying that it should be impossible to check error returns from malloc. I'm saying that the default should be to end the program, rather than create possible security flaws.

Embedded systems are a practice focus for us, and I'll argue with anyone who says that embedded devs are more disciplined about allocation than application devs.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

nitro2k01 — Sun, 20 Apr 2008 13:13:43 -0000

Holy crap... That was an amazing and... entertaning read. Speaking of the Mario game... Was it an official release by Nintendo? Part of Lost Levels? Or just a hack like any other?

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

AB — Sun, 20 Apr 2008 08:17:15 -0000

"I’m being pretty unclear. What I’m advocating for is that allocation *always* be checked. What I’m arguing against is requiring programmers to remember to check. Instead, malloc should abort instead of returning NULL.

There are a vanishingly small number of cases where a typical large program might do something intelligent with a malloc failure."

It is a common situation in an embedded system. And most of the times you to handle running out of resources gracefully without aborting an entire process.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Jeremiah Blatz — Sat, 19 Apr 2008 23:29:21 -0000

@Igor, close. Word should crash and burn a few nanoseconds earlier than it otherwise would upon allocating memory for that 7th document.

Malloc bugs tend to crash when tickled non-maliciously, it's pretty much only the malicious attacks that don't crash the program. (Or, you know, do, but also run their evil exploit.) So, if malloc fails with no error handling, you're boned either way. Better to crash under both normal use and attack than to crash under normal use and run exploit code under attack.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

James — Fri, 18 Apr 2008 22:06:17 -0000

Dear Team Go Java: I suggest taking a computer science course at a reputable institution, doing some programming outside of your happy fun sandbox, and perhaps, just perhaps, trying to understand at which level the exploit functions.

Hint - It's at a lower level, you mush brained idiots.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Igor — Fri, 18 Apr 2008 21:18:00 -0000

Err... so basically you guys are saying that for example Word should just crash and burn inside of malloc() when allocating memory for that 7th document you tried to create while having another 6 unsaved documents still open?

That is SO stupid that I have no words for it.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Thomas Ptacek — Fri, 18 Apr 2008 16:13:33 -0000

No, Jim. Java gets sloppy seconds from C; if a C native extension in a Java app (say QT4J) misses a malloc check, it can lose before Java kicks in.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Jim — Fri, 18 Apr 2008 16:04:52 -0000

In the world of Java, a NullPointerException would by thrown. Go Java!

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Thomas Ptacek — Fri, 18 Apr 2008 15:34:55 -0000

But I FOUND THE PITFALL IMAGES. That was ME. ALL ME.

Re: This New Vulnerability: Dowd’s Inhuman Flash Exploit

Thomas Ptacek — Fri, 18 Apr 2008 15:34:34 -0000

We are saying that indeed. Although, we are merely saying it. Someone else actually fucking did it.