Being Sneaky in C

http://www.codersnotes.com/notes/being-sneaky-in-c

by alexggordon • 11 years ago

158 88 11 years ago

jonahx• 11 years ago

Would setting the malloc'd memory back to the original message before freeing it solve the problem?

kayamon5• 11 years ago

Yes. You could also memset any memory to zero once you're done with it, which isn't a bad idea for applications with high security requirements.

rcthompson• 11 years ago

If you're modifying memory immediately before freeing it (i.e. after the last time you read it), don't you have to be extra super careful to do so in a way that the compiler won't optimize the operation into nothingness? (I don't program in compiled languages very much, so I don't know the details about this.)

TheLoneWolfling28• 11 years ago

...Except, of course, the the compiler can and will optimize away any such memset.

Do not attempt to write secure software with C / C++. It is a Bad Idea(TM). Because what you wrote is not what gets run.

For instance: there is no way to write a portable secure memset in portable C / C++. (You can write a "secure" memset that works in all current compilers, but that is not the same thing. What doesn't get optimized now can and will be optimized tomorrow.)

pjc503• 11 years ago

For key material, you also ought to page-lock it in memory to prevent it ever being swapped out.

TheLoneWolfling28• 11 years ago

No.

The compiler would just optimize that set right back out.

thaumaturgy4• 11 years ago

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).

kayamon5• 11 years ago

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.

thaumaturgy4• 11 years ago

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.

kazinator• 11 years ago

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?

kayamon5• 11 years ago

Well you could read the paper he just linked to.

marios• 11 years ago

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.

ojn• 11 years ago

It also makes the assumption that it's a little-endian system. On a big-endian system, the high order byte of the timestamp would be modified, which would probably be too obvious.

patrickmay• 11 years ago

I like the original Ken Thompson sneakiness in C (http://electronicdesign.com/dev-tools/thompson-ritchie-and-k...):

"Also in his Turing Award lecture, he described how he had incorporated a backdoor security hole in the original UNIX C compiler. To do this, the C compiler recognized when it was recompiling itself and the UNIX login program. When it recompiled itself, it modified the compiler so the compiler backdoor was included. When it recompiled the UNIX login program, the login program would allow Thompson to always be able to log in using a fixed set of credentials."

mkehrt• 11 years ago

Original (PDF): https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

kenko• 11 years ago

That really isn't the same thing, though. That's language-agnostic conceptual sneakiness that happened to be implemented in C.

codezero• 11 years ago

The description of the bug in surveil.txt in the source archive was a bit easier for me to understand, really nifty :)

amelius• 11 years ago

Would there be a way to do this automatically? Like a "sneaky pre-compiler"?

itistoday22• 11 years ago

Looking at the source, this is where the alarm bells should go off in a reviewer's head:

    memcpy(filter->buffer, output->piu_text_utf8, sizeof(output->piu_text_utf8));

1. memcpy is less safe than memmove and strncpy. strncpy should be used.

2. The two character arrays should use the same constant in defining their length, and that constant should be used both in the struct definitions and here in the copy operation.

3. The code is written in C in spite of it being 2014 at the time.

rdc12• 11 years ago

The code is from an entry in the Underhanded C Contest, it is pretty much a given that the entries will be written in C.

itistoday22• 11 years ago

I am aware of that.

esmi• 11 years ago

"In C/C++, you can use bugs in one part of a program to cause trouble in another. That’s pretty darn underhanded."

I would argue every language has that property. But with C/C++ being so closely tied to the ABI of the machine perhaps they are more underhanded than others. But to me, this branding does feel a bit unfair.

Still, a fun contest and an interesting read.

spdionis• 11 years ago

You can always cause that kind of bug, but I would argue that C/C++ is massively more underhanded than other languages.

Being Sneaky in C

Related Stories