How can your software fail?

If you think that coding in a memory and type safe language would protect your software against security bugs, well, you’re not seeing the whole picture. But let’s start from the very beginning: languages like C and C++ are known to allow out-of-bounds accesses to memory (using a simple out-of-bound array index, for example). Some people even use this “feature” to do some nasty tricks, like passing an array pointer pointing to the n-th element to a function and then accessing it using negative indexes in the callee. OMG.

Out-of-bound accesses to memory is the easiest way to buffer overflow exploits, think about NULL terminated array of chars (which represents a string in C), what happens if your logic doesn’t stop at the 0x00 (blame wordpress) element? If you know a little bit about how the “C function call convention” works low level (in ASM code) you would realize that writing stuff outside variables boundaries causes indefinite results, one of those is rewriting the return address of the function, which is saved on the stack along with other information (such as local variables and function arguments, which are local variables too).

Theoretically this is not possible with higher level languages that do memory bounds checking or on systems where some exotic technique is used to mitigate the issue. Well, anything the computer runs is at some point, ASM code (which turns to be a simple mapping between a mnemonical string and a bunch of nonsensical (:D) bits). So what you’re doing is just moving the matter down the queue, which means trusting your high level language interpreter. If a security flaw is discovered in say, Python or Java, this can potentially affect any application using the given language.

I do agree that this is much better, from an engineering POV, because the issue is limited to a single piece of code, to a library rather than to several potential spots in your application.
Anyway, this is not really the point of my today’s blog post and I apologize for this. The point here is: using memory and type safe languages doesn’t cover you from as dangerous as the ones above bugs. File access race condition (TOCTOU), unsafe temporary files creation, weak input validation, XSS, SQL injection, taint propagation issues. So, if your software has to guarantee a certain security level, or if you take privacy to hearth, or you just have to run it inside a privileged environment (or with privileged permissions). Just think about all this twice, and start doing a security review of your code.


About lxnay

the creator of Sabayon Linux, Entropy Package Manager {Eit, Equo, Rigo}, Molecule release media buildsystem, Matter Portage buildbot/tinderbox and only God knows what else...

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

hello, twitter

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 583 other followers

%d bloggers like this: