Overeager Compilers Can Open Security Holes In Your Code

← Back to Stories (view on slashdot.org)

Overeager Compilers Can Open Security Holes In Your Code

Posted by Soulskill on Friday June 20, 2014 @08:00AM from the i-blame-the-schools dept.

jfruh writes: "Creators of compilers are in an arms race to improve performance. But according to a presentation at this week's annual USENIX conference, those performance boosts can undermine your code's security. For instance, a compiler might find a subroutine that checks a huge bound of memory beyond what's allocated to the program, decide it's an error, and eliminate it from the compiled machine code — even though it's a necessary defense against buffer overflow attacks."

9 of 199 comments (clear)

Min score:

Reason:

Sort:

old news from decades ago by iggymanz · 2014-06-20 08:02 · Score: 4, Insightful

well known for decades that optimizing compilers can produce bugs, security holes, code that doesn't work at all, etc.
1. Re:old news from decades ago by NoNonAlphaCharsHere · 2014-06-20 08:13 · Score: 5, Insightful
  
  That's why I always use a pessimizing compiler.
2. Re:old news from decades ago by KiloByte · 2014-06-20 08:37 · Score: 5, Insightful
  
  Or rather, that optimizing compilers can expose bugs in buggy code that weren't revealed by naive translation.
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
3. Re:old news from decades ago by Marillion · 2014-06-20 08:45 · Score: 4, Insightful
  
  Right. The other part of the issue is why didn't anyone write a test to verify that the buffer overflow detection code actually detects when you overflow buffers?
  
  --
  This is a boring sig
Unsable Code, again by Anonymous Coward · 2014-06-20 08:03 · Score: 5, Informative

This is just as poorly written up as last time. These are truly bugs in the programs using undefined parts of the language. It's silly to blame the compiler.
UNISEX conference by Mdk754 · 2014-06-20 08:04 · Score: 5, Funny

Wow, you know you're ready to go home when it's Friday afternoon and you read:

But according to a presentation at this week's annual UNISEX conference
Bad summary is bad by werepants · 2014-06-20 08:07 · Score: 4, Informative

This is not really about the existence of bad compiler optimization - it is about a tool called Stack that can be used to detect this, which is known as "unstable" code, and has been used to find lots of vulnerabilities already.
Old news by Anonymous Coward · 2014-06-20 08:10 · Score: 4, Informative

I know that at least GCC will get rid of overflow checks if they rely on checking the value after overflow (without any warning), because C defines that overflow on signed integers is undefined. This is even documented. If anything is declared by the language specification as being undefined, expect trouble.
Functionally correct, but insecure by Smerta · 2014-06-20 08:35 · Score: 5, Insightful

The classic example of a compiler interfering with intention, opening security holes, is failure to wipe memory.
On a typical embedded system - if there is such a thing (no virtual memory, no paging, no L3 cache, no "secure memory" or vault or whatnot) - you might declare some local (stack-based) storage for plaintext, keys, etc. Then you do your business in the routine, and you return.
The problem is that even though the stack frame has been "destroyed" upon return, the contents of the stack frame are still in memory, they're just not easily accessible. But any college freshman studying computer architecture knows how to get to this memory.
So the routine is modified to wipe the local variables (e.g. array of uint8_t holding a key or whatever...) The problem is that the compiler is smart, and sees that no one reads back from the array after the wiping, so it decides that the observable behavior won't be affected if the wiping operation is elided.
My making these local variables volatile, the compiler will not optimize away the wiping operations.
The point is simply that there are plenty of ways code can be completely "correct" from a functional perspective, but nonetheless terribly insecure. And often the same source code, compiled with different optimization options, has different vulnerabilities.