<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>Random Hacks: Tag Security</title>
    <link>http://www.randomhacks.net/articles/tag/Security?tag=Security</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>Technology and Other Fun Stuff</description>
    <item>
      <title>Remote root holes reported as &amp;quot;denial of service&amp;quot;</title>
      <description>&lt;p&gt;Via &lt;a href="http://lwn.net/Articles/330866/"&gt;LWN&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;If you&amp;#8217;re a Linux system administrator, you shouldn&amp;#8217;t put your faith in security advisories. The &lt;a href="http://kernelbof.blogspot.com/2009/04/kernel-memory-corruptions-are-not-just.html"&gt;kernelbof&lt;/a&gt; blog accuses Linux distributors of being too quick to label security bugs as &amp;#8220;denial of service&amp;#8221; attacks:&lt;/p&gt;

&lt;blockquote&gt;
I&amp;#8217;m wondering why kernel developers (or vendors?) continue to claim that kernel memory corruption are just Denial of Service. Most of the times they _are_ exploitable.
&lt;/blockquote&gt;

&lt;p&gt;As an example, the author quotes &lt;a href="http://www.ubuntu.com/usn/usn-751-1"&gt;Ubuntu Security Notice 751&lt;/a&gt;:&lt;/p&gt;

&lt;blockquote&gt;The SCTP stack did not correctly validate FORWARD-TSN packets. A remote attacker could send specially crafted SCTP traffic causing a system crash, &lt;strong&gt;leading to a denial of service.&lt;/strong&gt;&lt;/blockquote&gt;

&lt;p&gt;(Emphasis added.)&lt;/p&gt;

&lt;p&gt;The author claims, however, to have created an exploit for this bug. He says his exploit allows a remote attacker to gain root access, often on the first attempt. If this is true, it would give him a quick way to gain control over any Linux system which has a process listening to an SCTP socket.&lt;/p&gt;

&lt;p&gt;Ubuntu&amp;#8217;s security team is not doing system administrators any favors by labeling memory corruption as &amp;#8220;denial of service&amp;#8221; attacks. If you can corrupt memory, there are some terrifyingly clever ways to run code. And marking memory as non-executable won&amp;#8217;t necessarily protect you.&lt;/p&gt;

&lt;p&gt;If you administer a Linux system, you should probably aim to patch alleged &amp;#8220;denial of service&amp;#8221; bugs as quickly as you can.&lt;/p&gt;</description>
      <pubDate>Thu, 30 Apr 2009 12:57:00 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:c25e2eee-9864-43d8-8b0b-6b0c0a4af6b1</guid>
      <author>Eric Kidd</author>
      <link>http://www.randomhacks.net/articles/2009/04/30/remote-root-holes-reported-as-denial-of-service</link>
      <category>Linux</category>
      <category>Security</category>
      <trackback:ping>http://www.randomhacks.net/articles/trackback/609</trackback:ping>
    </item>
    <item>
      <title>Yet Another PHP Security Hole</title>
      <description>    &lt;p&gt;&lt;a href='http://news.com.com/2100-1001-945480.html'&gt;A new security
    problem&lt;/a&gt; has been discovered in PHP 4.2.x.  This is not the &lt;a href='http://news.com.com/2100-1001-847092.html'&gt;first&lt;/a&gt; major hole
    in PHP, and it probably won't be the last.&lt;/p&gt;

    &lt;p&gt;Even if your PHP runtime is secure, it's &lt;a href='http://old.lwn.net/2001/0704/a/study-in-scarlet.php3'&gt;really
    hard&lt;/a&gt; to write secure PHP scripts.  There's so many things that can
    go wrong--malicious users setting "internal" global variables, &lt;a href='http://www.phpadvisory.com/advisories/view.phtml?ID=7'&gt;SQL
    injection&lt;/a&gt; attacks, ".inc" files containing passwords, and a whole
    host of other all-to-common bugs.&lt;/p&gt;

    &lt;p&gt;Just say no.&lt;/p&gt;</description>
      <pubDate>Mon, 22 Jul 2002 00:00:00 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:08169500-de0a-445f-9d5d-4e24aa591107</guid>
      <author>Eric</author>
      <link>http://www.randomhacks.net/articles/2002/07/22/yet-another-php-hole</link>
      <category>Security</category>
      <trackback:ping>http://www.randomhacks.net/articles/trackback/14</trackback:ping>
    </item>
  </channel>
</rss>

