<story><title>Massive Number of Vulnerabilities Found in X.Org</title><url>http://lists.x.org/archives/xorg-devel/2013-May/036276.html</url></story><parent_chain><item><author>tptacek</author><text>The only reason this isn&apos;t worth a freakout is that nobody running Linux in a graphical desktop configuration could ever have assumed that the machine was multiuser-safe to begin with. The reality is probably that no Linux (or FreeBSD) system in any configuration is secure from an attacker that can run native code in an unprivileged process. But with X11 running, you never had a chance.&lt;p&gt;I&apos;m always amused by the dismissive tone programmers take to findings like this --- &quot;oh, any thoughtful C programmer could avoid these problems&quot;. No, they can&apos;t. How many billions of dollars does it take to prove this point? The very best secure programmers in the world, building C (and C++) codebases from scratch specifically to address these problems, almost invariably fail to do so: memory corruption bugs get found in these systems just like they do in &apos;90s-vintage X11 code.&lt;p&gt;C is my very favorite language and I&apos;m not saying people shouldn&apos;t use it (well... they should avoid it, actually), but people should work in it with their eyes open.</text></item><item><author>asveikau</author><text>The fact that one must watch out for integer overflow on a buffer size calculation for malloc, realloc, etc. should be no surprise to a thoughtful C programmer. It sounds like somebody just did an audit of an old code base looking for bad patterns and this is what came out of it. It sounds like great work on the part of the people doing audits/fixes but I&apos;m not sure it&apos;s freakout material (&quot;massive&quot; seems a bit sensationalist).</text></item></parent_chain><comment><author>thrownaway2424</author><text>At no time has there ever been a Linux kernel release with no local root exploits. There have been periods of uncertainty when we didn&apos;t know the exact exploit but we always find out eventually.  Keep this in mind whenever you think about Linux security.</text></comment>
<story><title>Massive Number of Vulnerabilities Found in X.Org</title><url>http://lists.x.org/archives/xorg-devel/2013-May/036276.html</url></story><parent_chain><item><author>tptacek</author><text>The only reason this isn&apos;t worth a freakout is that nobody running Linux in a graphical desktop configuration could ever have assumed that the machine was multiuser-safe to begin with. The reality is probably that no Linux (or FreeBSD) system in any configuration is secure from an attacker that can run native code in an unprivileged process. But with X11 running, you never had a chance.&lt;p&gt;I&apos;m always amused by the dismissive tone programmers take to findings like this --- &quot;oh, any thoughtful C programmer could avoid these problems&quot;. No, they can&apos;t. How many billions of dollars does it take to prove this point? The very best secure programmers in the world, building C (and C++) codebases from scratch specifically to address these problems, almost invariably fail to do so: memory corruption bugs get found in these systems just like they do in &apos;90s-vintage X11 code.&lt;p&gt;C is my very favorite language and I&apos;m not saying people shouldn&apos;t use it (well... they should avoid it, actually), but people should work in it with their eyes open.</text></item><item><author>asveikau</author><text>The fact that one must watch out for integer overflow on a buffer size calculation for malloc, realloc, etc. should be no surprise to a thoughtful C programmer. It sounds like somebody just did an audit of an old code base looking for bad patterns and this is what came out of it. It sounds like great work on the part of the people doing audits/fixes but I&apos;m not sure it&apos;s freakout material (&quot;massive&quot; seems a bit sensationalist).</text></item></parent_chain><comment><author>asveikau</author><text>Did I say avoid the problems? I&apos;m pretty sure I said that the problems are not surprising. And, to add to that: I think it&apos;s especially not surprising in an older code base from an era in which this was less common knowledge. New code bases are of course not infallible but awareness of this is a higher priority than it used to be.&lt;p&gt;I think it&apos;s also interesting that issues like this sometimes remain in libraries because people think the caller should figure out overflow. From a casual read of the announcement it looks like they took a better approach in some areas, i.e. the library assumes the worst of the caller. I&apos;m reminded of something I read a few years back about the OpenBSD folks adding more overflow checks to calloc which does multiplication. It&apos;s nice when you can catch it in a library rather than pushing decisions to the caller.</text></comment>