Being Sneaky in C

Re:Being Sneaky in C by thaumaturgy on Friday June 12, 2015 @02:57PM (#9707867)

OpenBSD specifically modified malloc() a few years ago to prevent this sort of sneakiness (http://www.tw.openbsd.org/papers/eurobsdcon2009/otto-malloc.... [pdf]). So they route their malloc() calls through mmap() which returns randomized pages, and free() immediately returns memory to the kernel rather than leaving it mapped in the current process.

I'd be surprised if these changes haven't made it into FreeBSD, but afaik Linux doesn't work this way (by default, anyway).

[ Parent | on HN ]

Re:Being Sneaky in C by kayamon on Friday June 12, 2015 @03:01PM (#9707887)

I tested it on Ubuntu 14.04 x64, and the problem occurs there.

And of course, some programs use replacements like dlmalloc and do all their own allocation management anyway.

[ Parent | on HN ]

Re:Being Sneaky in C by thaumaturgy on Friday June 12, 2015 @03:11PM (#9707941)

> And of course, some programs use replacements like dlmalloc and do all their own allocation management anyway.

Yeah. I wrote my own allocator in C++ a long time ago. I wouldn't be surprised if there weren't quite a few other bits of software out there doing the same thing.

[ Parent | on HN ]

Re:Being Sneaky in C by kayamon on Friday June 12, 2015 @03:20PM (#9707994)

Wasn't Heartbleed due to exactly that - using their own local allocator instead of calling malloc/free?

[ Parent | on HN ]

Re:Being Sneaky in C by thaumaturgy on Friday June 12, 2015 @03:36PM (#9708079)

Partly. They were using their own allocator (openssl_malloc()), but even then they would've been OK if it weren't for the OBO error elsewhere in the heartbeat implementation. If they were using an OS-supplied malloc() instead of openssl_malloc(), the bug would've still been exploitable on some operating systems, but not others.

Either way, "don't write your own allocator" is a good lesson to learn.

Unless, of course, you're doing it for fun. In which case, efficient heap management really is a neat exercise.

[ Parent | on HN ]

Re:Being Sneaky in C by ikeboy on Friday June 12, 2015 @03:31PM (#9708054)

Heartbleed was due to not checking the bounds.

https://www.openssl.org/news/secadv_20140407.txt

https://xkcd.com/1354/

[ Parent | on HN ]

Re:Being Sneaky in C by kazinator on Friday June 12, 2015 @03:02PM (#9707892)

If your claim is that OpenBSD routes every call to malloc/free through mmap/munmap, it is simply not believable.

Do you have a URL to a git ... hahaha, pardon me, CVS repo?

[ Parent | on HN ]

Re:Being Sneaky in C by marios on Friday June 12, 2015 @03:16PM (#9707967)

http://bxr.su/OpenBSD/lib/libc/stdlib/malloc.c#omalloc ^Not the CVS repo, but close enough for those who want to check OpenBSD's malloc implementation. The malloc.conf manpage is also an interesting read : http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/...

And some context around malloc and the various techniques OpenBSD implements to make exploitation of bugs more difficult: http://www.openbsd.org/papers/dev-sw-hostile-env.html

The tl;dr is : if your code compiles and runs on OpenBSD, chances are it will fine on other Unices. The opposite is not necessarily true though.

[ Parent | on HN ]

Re:Being Sneaky in C by comex on Friday June 12, 2015 @04:08PM (#9708220)

I don't think that source refutes the parent's point: only large allocations go directly to mmap/munmap as opposed to being cached. Of course, there are other anti-exploitation measures too...

[ Parent | on HN ]

Re:Being Sneaky in C by icebraining on Friday June 12, 2015 @03:18PM (#9707976)

Here's the CVS repo: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib...

[ Parent | on HN ]

Re:Being Sneaky in C by kayamon on Friday June 12, 2015 @03:05PM (#9707916)

Well you could read the paper he just linked to.

[ Parent | on HN ]