This is the exploit equivalent of that guy who played the perfect game (2008)

http://www.matasano.com/log/1032/this-new-vulnerability-dowds-inhuman-flash-exploit/

by req2 • 17 years ago

71 33 17 years ago

Someone makes an argument against checking malloc, talking about the overhead it adds.

Does anyone have a problem with using a malloc wrapper?

  void *Malloc(size_t size) {
    void *r = malloc(size);

    if(r == NULL)
      /* do things to quit the app */

    return r;
  }

edit: yay for " " code blocks. Hacker News++

edit again: I wasn't clear. I meant overhead in terms of lines of code it added. I'm asking if it makes sense to wrap it up in a nice upper-case call that just terminates the program if the worst happens.

gchpaco3• 17 years ago

People who claim that they can't afford the overhead of error checking their instructions are high. There are no realistic situation in which getting the wrong answer fast is better than the right answer one clock cycle slower, especially with the heavily pipelined architectures we have today.

tedunangst4• 17 years ago

If you think extra branches don't affect the performance of heavily pipelined architectures, I have some Pentium 4s I'd like to sell you. :)

Right idea, wrong proof.

jacquesm3• 17 years ago

Checking your return values is pretty essential stuff. The error in this case was not checking that malloc could return null and then not to abort.

So, if you call malloc and do not check the return value (and abort if it is NULL) then you end up using the 'null' pointer. Normally this will cause your application to crash since a null pointer can not be dereferenced. But if the null pointer is used with an offset and that offset is under the control of the attacker then suddenly you can access pretty much all of memory. (of course, if the pointer would have been valid and you can combine it with arbitrary input you can STILL access all of memory but it is a lot harder to figure out where you are pointing, a null pointer literally contains '0' so all you have to do is figure out where you want to be, not where the pointer is pointing, you already know that).

The overhead of checking what malloc returns you is trivial compared to what malloc does internally so I wouldn't worry about that at all.

jacquesm3• 17 years ago

Well, if you want to avoid the call overhead do it with an 'inline', that way there is no overhead at all.

ars• 17 years ago

The CPU is so much faster than memory that the time needed for checking if malloc succeeded is basically unmeasurable.

I assume that after you malloc that you'll put something in it. Copying that data to memory takes so much longer than checking if the return value == NULL that it's a joke to care.

BTW The info was interesting, but I don't care for the style of writing.

tedunangst4• 17 years ago

In the case of a browser plugin, I'd be quite annoyed if an out of memory condition in the plugin caused my whole browser to quit. I'd experience something beyond annoyance if printing caused my word processor to quit without saving. The never fail malloc wrapper makes sense for some programs, but not for others where better, context sensitive recovery is possible.

dbenamy3• 17 years ago

In the context of a browser plugin, "quit" could just mean to stop executing and throw up an error message. It doesn't necessarily mean to end the whole process (browser).

ianbishop• 17 years ago

From my understanding, his problem was that the malloc wrapper being used not only checked but also returned -1 if it was null (I assume some other arbitrary number otherwise) which would add extra computation time.

Out of curiosity, I have always used assert to do malloc null checks. I realize it is just a macro which gives a conditional to exit but is at all hindering in terms of performance?

eg:

  void *Malloc(size_t size) {

    void *r = malloc(size);
    assert(r != null);

    return r;
  }

dbenamy3• 17 years ago

That's probably the same as the non-assert check EXCEPT that release builds might disable assertions and then you're in trouble.

ori_b• 17 years ago

the problem is that assert is defined so that if NDEBUG is defined, it's a no-op.

I'd use an explicit check and an abort() call.

ERG• 17 years ago

I took 15-213 at CMU. The moment I saw that code block I knew that's where you came from. One of the best clases I've taken there.

Good old csapp.c http://www.ece.cmu.edu/~ece845/sp02/csapp.c

alexgartrell3• 17 years ago

We actually have very mixed feelings about csapp.c. Students don't seem to understand that you should quit the whole program just because one thread fails. Especially in servers (like proxy lab :))

Still, an awesome class!

lallysingh• 17 years ago

Two things:

1) It's a memory allocation, scanning data structures, possibly involving some thread-locking or even a system call. A single check is cheap. If you want to keep the CPU happy the 99% of the time, put the most likely case first, so the CPU doesn't have to jump. Speculation should help mitigate the rest.

2) A good reason why operator new() throws by default.

jcl• 17 years ago

It's my understanding that this won't work exactly as you'd expect under Linux. If you try to allocate more memory than is available, Linux can return a non-NULL pointer and hope that you don't try to use it:

http://alanreviewblog.blogspot.com/2009/02/turning-off-over-...

_cbsz• 17 years ago

Am I on Reddit? Seriously, what's with the headline?

mikeryan• 17 years ago

This is a dupe and over a year old

http://news.ycombinator.com/item?id=164725

req2• 17 years ago

Apologies. I'm new to using searchyc and didn't expect it to miss the URL.

http://searchyc.com/submissions/http%253A%252F%252Fwww.matas...

This is the exploit equivalent of that guy who played the perfect game (2008)

Related Stories