When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspxDavid LeBlanc and I (and a bunch of others) just had a little email exchange about some fascinating integer overflow vulnerabilities in gcc .
Long story made short: the code you add to detect integer overflows might actually be removed by the compileren-USTelligent Evolution Platform Developer Build (Build: 5.6.50428.7875)re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8373079Wed, 09 Apr 2008 22:17:34 GMT91d46819-8472-40ad-a661-2c78acb4018c:8373079Kurisu<p>Let me state once more that the issue you're talking about has nothing to do with integer overflows. It's about pointer arithmetic. If mean that the value of &quot;len&quot; is the result of an integer overflow, you're checking in the wrong place anyway. You can't detect an integer overflow after it happened because it causes undefined behaviour. You can at best prevent a buffer overflow (or out-of-bounds read rather) here but only if you do it correctly something the example code clearly doesn't do. The two problems are certainly similar but are technically very different because integer arithmetic and pointer arithmetic follow different rules.</p>
<p>You can easily find discussions, tutorials and even C code online explaining how you avoid integer overflows, if you can't or don't want deduce this yourself from the C standard.</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8373079" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8372853Wed, 09 Apr 2008 20:44:01 GMT91d46819-8472-40ad-a661-2c78acb4018c:8372853Kurisu<p>I don't know every word of C standard by heart but I have the draft in</p>
<p>plain text format around and I'm not too proud to (re-)verify assumptions</p>
<p>when I come across something that I'm not sure about.</p>
<p>I think C and common misconceptions of C are such a huge topic, you could</p>
<p>easily write a book about it. This specific issue is just the tip of the</p>
<p>iceberg. I'm not sure whether anyone would actually read such a book though.</p>
<p>The audience which could actually benefit the most from it would probably</p>
<p>consider it incredibly boring (&quot;TLDR&quot;) but I find it difficult to compress</p>
<p>this into a few lines or even a short essay. Everyone who likes to consider</p>
<p>himself a serious C programmer should at the very least read comp.lang.c.</p>
<p>Writing correct code in C is difficult and be very hard. Then again, C</p>
<p>is likely the most challenged and discussed language. Others have many</p>
<p>pitfalls too but most languages are not wide-spread or mostly used by</p>
<p>experts that are aware of them. Then there are languages which are a pure</p>
<p>mess in and out, even worse than C but nobody really cares because experts</p>
<p>avoid them like the plague whereas skript kiddies and such do not care</p>
<p>the least about the flaws.</p>
<p>A central problem of C might be that it's misunderstood as being a portable</p>
<p>high-level assembler. In fact, people who are familiar with assembly</p>
<p>programming will have little problems getting started with C because pointers</p>
<p>are not hard to grasp when you have a good idea how they could be implemented</p>
<p>in assembly language. The problems start when people generalize from examples.</p>
<p>This isn't C-specific at all, it happens in real-life all the time, invalid</p>
<p>reverse deduction that is. Everyone with basic education in logic knows that</p>
<p>&quot;works here for me&quot; does not prove anything. You can of course use examples in</p>
<p>proofs but only in certain ways.</p>
<p>Don't misunderstand but it's fairly irrelevant how competent people consider</p>
<p>themselves to be:</p>
<p><a rel="nofollow" target="_new" href="http://education.guardian.co.uk/egweekly/story/0,5500,1208584,00.html">http://education.guardian.co.uk/egweekly/story/0,5500,1208584,00.html</a></p>
<p>That's why we have tests in school, driving licences, certificates and what</p>
<p>not. Otherwise everyone could go around and simply claim being expert at some</p>
<p>topic. Some people who are doing this are obviously lying, others are obviously</p>
<p>incapable to recognize their own incompetence and there is some middle ground,</p>
<p>basically people overestimating their own competence.</p>
<p>I don't doubt that you're a pretty decent coder but you should ask yourself</p>
<p>&quot;In which way?&quot;. Maybe you're really good at turning ideas into algorithms</p>
<p>and/or implementing them but are you as good when it comes to correctness</p>
<p>of your code? Some people may not be very creative but they are good at</p>
<p>writing correct code. Both kinds of people are certainly decent coders,</p>
<p>except that they have different strengths and flaws. That's also why</p>
<p>developing software in a team with people of diverse skills is highly</p>
<p>benefitial. Nobody is perfect in everything. If a team is too homogenous</p>
<p>with respect to their skills, that might reduce conflicts but it also means</p>
<p>that mostly &quot;throughput&quot; will benefit and code quality won't, it might</p>
<p>actually degrade by emphasizing the common weaknesses.</p>
<p>Mixing C and C++ isn't a good idea. C isn't a strict subset of C++ and it's</p>
<p>obviously difficult to remember which features are common and which aren't.</p>
<p>Whenever I read &quot;C/C++&quot;, I'd like to barf. It's a fair bet that most people</p>
<p>lumping them together have little clue about either. I don't code in C++.</p>
<p>I could care less about C++.</p>
<p>Regarding the specific issue again, GCC isn't the only C compiler which behaves</p>
<p>this way. So anything but adding diagnostic messages or warnings, would be</p>
<p>absolutely counter-productive.</p>
<p>The C standard tells you what you can legally expect and what you cannot. &nbsp;What</p>
<p>you are calling &quot;defensive code&quot; is simply nonsense. Anyone who is crying for</p>
<p>security should first make sure they are using the right tool and using it</p>
<p>correctly. Someone who doesn't master a tool, can hardly expect security,</p>
<p>especially if we're talking about a fairly low-level tool. I hope I don't need</p>
<p>to explain this with an automobile analogy. Let this be common-sense, please.</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8372853" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8372758Wed, 09 Apr 2008 20:04:42 GMT91d46819-8472-40ad-a661-2c78acb4018c:8372758bcthanks<p>I use something like this:</p>
<p>if ((len &lt; 0) || (len &gt;= size_of_buffer_in_bytes)) { /* overflow */ }</p>
<p>And often I spot-check the executable to make sure the check actually works, by intentionally causing an overflow. That verifies the 'if' as well as whatever action is supoose to happen inside the 'if'</p>
<p>(That is a basic testing requirement. Never assume the compiler - or anything else - is not buggy!)</p>
<p>And yes, that code might be slower than just checking for wraparound. But IMO it has distinct advantages:</p>
<p>1. it makes clear it is explicitly bounds-checking the len. Less experienced programmers may not understand what &quot;len + buf &lt; buf&quot; means. Or they might cut-and-paste the C code into another language that has different semantics.</p>
<p>Sure, it would be great if everyone is skilled. But reality is people are not and many people do not care enough to learn. Security related code by nature is not executed except under unusual circumstances (ie, an attack), so normal testing will not detect the problem.</p>
<p>2. If the 32-bit code is ported to a world where ints are 64-bit, that wraparound check *may* not detect an overflow past the end of the code.</p>
<p>Howard, you should know that software development is a learning process; now you've learned that compilers optimize away code in ways you didn't expect. Unfortunately, that might mean you have to audit previously written code for that situation (I hope somebody does!). That is no different than what other people have done in response to buggy Windows code; or buggy tools from many vendors; or mitigation for specific attacks.</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8372758" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8370433Wed, 09 Apr 2008 02:40:39 GMT91d46819-8472-40ad-a661-2c78acb4018c:8370433Michael Howard<p>Kurisu - so do you know the C spec inside and out? I certainly do not, and I'd consider myself a pretty decent C and C++ coder. If I add defensive code I expect it to stay there!</p>
<div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8370433" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8369047Tue, 08 Apr 2008 16:29:14 GMT91d46819-8472-40ad-a661-2c78acb4018c:8369047Kurisu<p>I suggest reading the C standard. Carefully.</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8369047" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8367384Tue, 08 Apr 2008 05:53:41 GMT91d46819-8472-40ad-a661-2c78acb4018c:8367384Michael Howard<p>Kurisu, so how do you propose folks defend against int overflow vulns?</p>
<div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8367384" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8366610Tue, 08 Apr 2008 00:50:38 GMT91d46819-8472-40ad-a661-2c78acb4018c:8366610Bertrand Le Roy<p>Commenters above: where did you see Howard or David claiming to have discovered that?? Anyway, it is known and not fixed? Even worse.</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8366610" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8366170Mon, 07 Apr 2008 21:52:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:8366170HM<p>Hi, back in 2003 we found a serious bug in JDK 1.4.2ś System.arraycopy() routine. &nbsp; Using this routine a few thousand times in one session would break its logic so that only part of the source array would get copied over to the destination array. &nbsp;Turned out that Hotspotś optimized C++ array copy code was buggy. Once the Hotspot compiler identified this routine as a &#168;hotspot&quot; for optimization, it would replace the original code with the optimized, yet buggy, C++ code.</p>
<p>Java folks will know that this is one of the core routines in the JDK. When we contacted Sun, they told us not to rely on any claims made by their APIs.</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8366170" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8364841Mon, 07 Apr 2008 12:38:17 GMT91d46819-8472-40ad-a661-2c78acb4018c:8364841Kurisu<p>There is nothing to fix in GCC. This isn't a bug in GCC. C isn't assembler and it's not defined by common-sense but an international standard. If you read the C standard, you'll realize that the so-called &quot;security&quot; overflow checks exhibit *undefined behaviour*. Also the use of &quot;int&quot; and mention of &quot;integer overflow&quot; is really a red herring in the US-CERT publication because that's not the issue at all.</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8364841" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8363368Sun, 06 Apr 2008 19:23:53 GMT91d46819-8472-40ad-a661-2c78acb4018c:8363368Bob<p><a rel="nofollow" target="_new" href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763">http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763</a></p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8363368" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8363043Sun, 06 Apr 2008 16:48:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:8363043some1<p>Yeah, thanks for discovering this &quot;new&quot; bug:</p>
<p><a rel="nofollow" target="_new" href="http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg01297.html">http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg01297.html</a></p>
<p><a rel="nofollow" target="_new" href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27180">http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27180</a></p>
<p><a rel="nofollow" target="_new" href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763">http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763</a></p>
<p>;-)</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8363043" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8362985Sun, 06 Apr 2008 16:06:19 GMT91d46819-8472-40ad-a661-2c78acb4018c:8362985markus<p>Actually I think this has been know for some time by now. The GCC team said its fixed but it is apparently not fixed... I think they are too slow :/</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8362985" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8362813Sun, 06 Apr 2008 14:04:21 GMT91d46819-8472-40ad-a661-2c78acb4018c:8362813Andreas<p>This particular gcc vulnerability has been known for years, and the gcc developers are not very forthcoming in fixing it, claiming that the current gcc behaviour is standards-compliant.</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8362813" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8362263Sun, 06 Apr 2008 08:17:13 GMT91d46819-8472-40ad-a661-2c78acb4018c:8362263Someone<p>It's an old story....look at <a rel="nofollow" target="_new" href="http://blog.fefe.de/?ts=babc3ebb">http://blog.fefe.de/?ts=babc3ebb</a> There it was published in April 2006!</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8362263" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8362145Sun, 06 Apr 2008 06:44:48 GMT91d46819-8472-40ad-a661-2c78acb4018c:8362145Errrmmm...<p>...known issue? See (e.g.):</p>
<p><a rel="nofollow" target="_new" href="http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg01297.html">http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg01297.html</a></p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8362145" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8362144Sun, 06 Apr 2008 06:43:18 GMT91d46819-8472-40ad-a661-2c78acb4018c:8362144Errrmmm...<p>...known issue. See (e.g.):</p>
<p><a rel="nofollow" target="_new" href="http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg01297.html">http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg01297.html</a></p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8362144" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8362039Sun, 06 Apr 2008 05:09:15 GMT91d46819-8472-40ad-a661-2c78acb4018c:8362039Kid Icarus<p>I was under the impression that Felix von Leitner tried to get this fixed two years ago. <a rel="nofollow" target="_new" href="http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg01297.html">http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg01297.html</a> </p>
<p>So why are people only talking about it just now?</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8362039" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8361579Sun, 06 Apr 2008 00:58:14 GMT91d46819-8472-40ad-a661-2c78acb4018c:8361579jf<p>talk to v-fefe about this stuff if you havent already.</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8361579" width="1" height="1">re: When adding security bugs to your code is not your fault!http://blogs.msdn.com/b/michael_howard/archive/2008/04/04/when-adding-security-bugs-to-your-code-is-not-your-fault.aspx#8358943Sat, 05 Apr 2008 03:52:31 GMT91d46819-8472-40ad-a661-2c78acb4018c:8358943Chris<p>I would say there is a quite a few more of these types of bugs on the way. Compilers are always pushing the optimization edge whenever possible. &nbsp;So this bug does not surprise me. It just helps to further make the point that binary analysis is extremely important and still relevant. Pure source code analysis will never be enough on compiled languages.</p><div style="clear:both;"></div><img src="http://blogs.msdn.com/aggbug.aspx?PostID=8358943" width="1" height="1">