Slashdot Mirror

Lame reply to self but, yeah, according to the most basic static analysis tools, it was broken in 2012
http://www.viva64.com/en/b/018...
and still broken in 2013
http://www.viva64.com/en/b/025...

If your implementation language is C, you can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds.

Or the compiler might helpfully optimize out your buffer clear : http://www.viva64.com/en/d/020...
Or in general: http://www.viva64.com/en/b/017...

There's just a ton of landmines to avoid while coding in C. Including the tools themselves.

If your implementation language is C, you can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds.

Or the compiler might helpfully optimize out your buffer clear : http://www.viva64.com/en/d/020...
Or in general: http://www.viva64.com/en/b/017...

There's just a ton of landmines to avoid while coding in C. Including the tools themselves.

WTF?!?

WTF indeed.

There seems to be a major trend towards making compilers create code that is as different as possible from what the programmer wrote without being so different that the programmer actually notices. One might assume it's a secret NSA plot to defeat security measures in all software everywhere. You know, if one was incredibly paranoid, that is.

It's hard to say whether this is justified behavior. As an example, consider this code from a link an AC posted:

int
crypto_pk_private_sign_digest(....)
{
char digest[DIGEST_LEN]; ....
memset(digest, 0, sizeof(digest));
return r;
}

Exploit mitigation code like this is a case of writing code which we expect to never have any effect, just in case we're wrong and it does have an effect. Then the compiler comes along and decides for itself that the code we wrote will never have any effect and removes it. It's kind of hard to blame it for noticing the uselessness of the operation when we ourselves expected the code to likely have no effect when we wrote it, but then, the whole reason we wrote it is because we thought we might be wrong. Should the compiler then assume that we might be wrong as well, and that we might access that memory using a different pointer?

Does it make sense to compile with optimization enabled when, by including things like the memset() call to clear memory we're finished using, we clearly have goals other than optimization?

The article mentions the fix being the use of a different function which won't be optimized away, but I wonder if even that is a legitimate fix. Our "digest" array is just another variable that the compiler is free to do whatever it wants with in the name of optimization. If it will make the program run faster, it's free to make two copies of it. Then our new never-optimized-away function will end up erasing only one copy of the variable.

So problem here isn't the use of memset() rather than some other function. The problem is that we're asking the compiler to create code that doesn't match what we've written. It should be no surprise then when it goes ahead and does that. Thus, I don't think it's correct to claim that the error here is the failure to use the correct function to clear the memory. I think the error is in asking the compiler to generate code that isn't identical to the source code.

The core of the problem is that C isn't a language that allows us to clearly tell the compiler exactly what we want to happen. Without bounds checking on pointer use, every pointer is effectively a pointer to all memory. Thus, when a pointer falls out of scope, it doesn't mean anything. That memory can still be accessed via any other pointer anywhere in the program. If C enforced bounds checking, such that accessing the data in "digest" via any other pointer was impossible, then the compiler could safely work under the assumption that once "digest" falls out of scope, the data it points to will never be accessed again, and thus removing the memset() call would be a safe thing to do since it truly would have no effect.

It really seems ridiculous when you think about it. Compilers assume that bounds on pointers will be respected, yet make no attempt whatsoever to enforce those bounds, essentially guaranteeing that they will not be respected since programmers are imperfect.

Consider what the compiler will do when it encounters code like this:

int a[4];
int b[4];
int c[4];
b[-1] = 0;

Despite the obvious error in the above code, GCC will compile it without error. It will then perform optimizations that assume that neither a[] nor c[] have been affected by the assignment to b[]. It seems rather ridiculous that anyone is expected to create secure software in such an environment. Either the compiler should enforce bounds checking, or it should assume that any pointer operation ca

http://www.viva64.com/en/b/017...

Since you seem a bit combative about this.

Code analysis from the Toyota sudden acceleration case: http://www.viva64.com/en/a/0083/
If the code is as horrible as described in the article, and can bug out during normal operation, it is not too far of a stretch to assume that feeding it noise on the CAN bus will induce unwanted behavior.

Also, with dynamic brake control where brake pressure is individually adjusted to maximise grip during cornering/braking (trail braking), a poorly designed brake controller may also have issues and decrease brake pressure in unwanted ways when it is being fed crap CAN frames.

Note that a CAN frame only has 15 bits of CRC, making it feasible to get a false positive on the CRC check on a 500Kbit bus with lots of traffic, thus having random data frames enter the controller code.

Those are my arguments. If you do not agree, I think we would all appreciate if you provide more counter arguments than "nope. Try again.".

I wouldn't be so sure that programming wasn't the source of the problem. There's been a lot of work to understand the ECU on the Camry and it is beginning to look like some severe bugs lurk within: http://www.viva64.com/en/a/0083/