Slashdot Mirror


Google Found Disastrous Symantec and Norton Vulnerabilities That Are 'As Bad As It Gets' (fortune.com)

Google's Project Zero team has discovered a heap of critical vulnerabilities in Symantec and Norton security products. The flaws, the team says, allow hackers to completely compromise people's machines by simply sending them malicious self-replicating code through unopened emails or un-clicked links. According to a Fortune report, the vulnerabilities affect millions of people who run the company's endpoint security and antivirus software -- all 17 enterprise products (Symantec brand) and eight consumer and small business products (Norton brand). Dan Goodin, reporting for Ars Technica:The flaws reside in the engine the products use to reverse the compression tools malware developers use to conceal their malicious payloads. The unpackers work by parsing code contained in files before they're allowed to be downloaded or executed. Because Symantec runs the unpackers directly in the operating system kernel, errors can allow attackers to gain complete control over the vulnerable machine. Tavis Ormandy, a researcher with Google's Project Zero, said a better design would be for unpackers to run in a security "sandbox," which isolates untrusted code from sensitive parts of an operating system.

2 of 113 comments (clear)

  1. Re:yet more poor design. by SharpFang · · Score: 5, Insightful

    They need to hijack all network and file operations, so they do need hooks in the kernel. But these should be minimal, passing the data down to a sandbox without even peeking inside. The fact data that is *expected to be malicious* is allowed to interact directly with kernel level code is definitely FUBAR.

    --
    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
  2. Re:yet more poor design. by bravecanadian · · Score: 4, Insightful

    They need to hijack all network and file operations, so they do need hooks in the kernel. But these should be minimal, passing the data down to a sandbox without even peeking inside. The fact data that is *expected to be malicious* is allowed to interact directly with kernel level code is definitely FUBAR.

    That is a good point.

    Obviously they do need to be in the kernel to check the operations, but the way you have broken it down makes a lot more sense than actually parsing items that are suspected of being malicious in kernel mode.

    Pretty sad when convenience trumps security even in a security product.