About Me

Wei Wang

Wei Wang

Read More

Feeds & Podcasts

Blogs

Meet the Bloggers

Archive

Tags

#SecChat $1 million guarantee 12 Scams of Christmas access to live fraud resolution agents Acquisition Alex Thurber Android antivirus Apple botnet Channel Partners cloud security Compliance Consumer counter identity theft credit card fraud and protection credit fraud alerts credit monitoring credit monitoring and resolution critical infrastructure Cyber Security Mom cyberbullying Cybercrime cybermom data breach data center data center security Data Protection Dave DeWalt DLP Email & Web Security embedded encryption Endpoint Protection enterprise facebook fake anti-virus software Family Safety Friday Security Highlights global threat intelligence google government Hacktivism how to talk to kids how to talk to teens identity fraud identity fraud scams identity protection identity protection $1 million guarantee identity protection fraud identity protection surveillance identity surveillance identity theft identity theft expert identity theft fraud identity theft protection identity theft protection product Identity thieves and cybercriminals intel iphone kids online behavior lost wallet protection malware McAfee McAfee Channel McAfee Family Protection McAfee Identity Protection McAfee Initiative to Fight Cybercrime McAfee Labs McAfee security products Mid-Market Mobile mobile malware mobile security monitor credit and personal information Network Security online personal data protection online safety Operation Aurora PCI personal identity theft fraud personal information loss personal information protection phishing privacy proactive identity protection proactive identity surveillance Public Sector restore credit and personal identity Risk and Compliance scam scams scareware security smartphones social media social networking social networks spam Stuxnet twitter vulnerability Web 2.0 work with victim restore identity

McAfee Labs :

Two new Linux kernel vulnerabilities discovered & patched

Tuesday, June 24, 2008 at 11:49am by Wei Wang
Wei Wang

Avert Labs recently discovered and reported a couple of Linux Kernel vulnerabilities, all of which have been patched by linux kernel maintainers.

The first one is BER Decoding Remote vulnerability (CVE-2008-1673) . This vulnerability was patched by the Linux dev team on 9th June 2008.

This vulnerability is a kernel heap overflow in CIFS module and ip_nat_snmp_basic module. It’s possible to reach the exploitable condition on 64bit platform. Though its hard to trigger a kernel heap overflow in 32bits platform, it’s still possible to crash the Linux box. We strongly recommend users to update to the following kernel versions:

Linux kernel 2.6.25 .5
Linux kernel 2.6.26-rc5-git1
Linux kernel 2.4.36.6

Some vendors have mistakenly marked this as a vulnerability exploitable only in the local network. A correction for them, this vulnerability is remotely exploitable. We contacted one such security service providers who had mentioned this issue as exploitable over the ‘local network’ only and got this response:

“According to our information the ASN.1 decoding vulnerability exists within the modules handling CIFS and SNMP traffic. These are both protocols which we think should be firewalled off the Internet via common “best practices”, thus we set the attack vector to “local network” only.”

I don’t really agree with this approach, anything that is firewallable is locally exploitable then? In fact I would rather say that it is remote vulnerabilities like these that need firewall policies to be enabled and not the other way round. I would love to hear opinions from others on this issue.

BTW our McAfee Network Security Platform (formerly IntruShield) has already been updated with content to protect against this vulnerability.

The other issue was found by Brandon Edwards which is another interesting issue in DCCP, it is a local privilege escalation vulnerability (CVE-2008-2358). The vulnerability (supposedly) only exists in 2.6.17, 2.6.18, and 2.6.19 due to boundary checks in the upstream kernel versions. It is non-trivial to exploit this vulnerability.

Bookmark and Share

Submit your own comments / message for this post

Your email is never published nor shared. Required fields are marked *

 

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comments (2)

  • g33kwatch June 25, 2008 12:28PM

    Good to see some interesting vulnerability discussion here. I agree with Wei Wang and Dustin on such issues. It’s ridiculous to even think that a security vendor could be so lame as to downplay a remote kernel issue with this justification.

    kudos to Avert on pointing this issue and discussing this with the community!

    Reply
  • Dustin D. Trammell June 25, 2008 8:20AM

    I completely agree, vendors shouldn’t be classifying vulnerability properties based on what “should” be “best practice”, but rather something more quantifiable, such as the actual properties of the vulnerabilities, the conditions required to trigger the bug, etc., or potentially even default configuration. The latter is a little questionable itself, because if one Linux distro ships with a default firewall configuration that does in fact restrict SMB and SNMP to the local subnet, and a second doesn’t restrict this traffic at all, you then have two different exploitation “range” metrics for the exact same vulnerability. In my opinion, this type of information should be completely ignored when rating a vulnerability for risk and impact. If it’s actively exploitable by sending packets to the box, it’s remote. Note, this is not an argument for classifying file format vulnerabilities as remote just because you can send the file via e-mail, or FTP, or some other network transport. Unless you can send the bad file directly to the box and the action of doing so actively triggers the bug, that’s NOT remote; the user still has to open the file, or some other action must cause it to be processed to trigger the bug. Unfortunately a lot of vendors have recently started classifying such bugs as remote when they really should be classified as local.

    Reply