Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by msmash on from the security-woes dept.

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.

80 of 113 comments (clear)

  1. yet more poor design. by Anonymous Coward · · Score: 1

    Putting anti-virus anything in a kernel is down right stupid.

    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 sunderland56 · · Score: 5, Funny

      If it wasn't in the kernel, how would it constantly suck 50% of your CPU and slow your machine to a crawl?

    3. 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.

    4. Re:yet more poor design. by Big+Hairy+Ian · · Score: 2

      I told them they should have written it in Python

      --

      Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.

    5. Re:yet more poor design. by SharpFang · · Score: 4, Informative

      The 'real kernel' still needs to pass it down into the VM from physical media for processing. And the VM would need to be supervised by the host, not just launched and forgotten - the sandboxing won't help much if the virus hijacks the sandbox, and makes it pass everything through as 'clean' regardless of the content - the host needs to constantly monitor integrity of the checking process.

      There are 'jailbreak' attacks that allow escaping VM sandbox and infecting the host, but they are difficult and rare.

      --
      45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    6. Re:yet more poor design. by Anonymous Coward · · Score: 1

      I agree that this needs to be done in some sort of sandbox. I'd disagree that it was just for convenience though. For many years people have complained about how these anti-malware products slow their machine down. Imagine taking the hit for moving between kernel space and user space and setting up a sandbox. I'm sure this was done for performance reasons and not just convenience.

    7. Re:yet more poor design. by SharpFang · · Score: 1

      Setting up a sandbox is a one-time deal on startup. Giving the process a preferential treatment in the scheduler is viable approach; another is to bypass the whole heavyweight system of accounts and authentication and carve your own sandbox from scratch, a separate, minimal subsystem of lowered privileges, a'la VM.

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

      From a security standpoint, doing those data intensive checks shouldn't be in the kernel (separation kernels were designed for this). However, having to do process swaps to do the security checks is going to raise the hit on the processor. Security will always cost something.

    9. Re:yet more poor design. by klubar · · Score: 1

      You probably need to recreate the sandbox each time (or at least at some frequency) because you can't tell if the sandbox has been corrupted by the malicious code. Trying to bypass the accounts & authentication just punches more holes in the OS.

      It's not an easy problem, especially if you are concerned about speed.

    10. Re:yet more poor design. by Bert64 · · Score: 1

      Convenience or performance...
      These security products are already bloated and slow enough as it is, if you add the extra overhead of passing the data to a sandboxed userland process for inspection it's going to make them even worse.

      But you are right, endpoint protection software violates many security best practices... Extremely complex code, dealing directly with untrusted data and running with a high privilege level.

      The only AV i run is on web and mail filtering boxes, the scanner runs under its own unprivileged user inside of a chroot, and the overhead of the setup is largely masked by the inherent network latency anyway.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    11. Re:yet more poor design. by cant_get_a_good_nick · · Score: 1

      Anyone else remember HTTP kernel modules like Tux? "hey, lets parse unfiltered unverified data in the kernel" that needed to die, and luckily enough it eventually did

    12. Re:yet more poor design. by lgw · · Score: 1

      Imagine taking the hit for moving between kernel space and user space and setting up a sandbox.

      Sandboxing can be minimal in user space, and anyway only needs to be done once. There shouldn't be any performance hit for doing the parsing work in user space - you don't have to copy the data around or anything, just arrange for the user-mode process to see the page. Latency for detection would get worse, due to the wait for the user-mode thread to notice it had work to do, but that should be sub-millisecond in a modern system.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    13. Re:yet more poor design. by K.+S.+Kyosuke · · Score: 1

      But then the security holes would go away... How would you exploit it then?

      --
      Ezekiel 23:20
    14. Re:yet more poor design. by SharpFang · · Score: 1

      Yes, unless the attacker is prepared for this. They won't attempt jailbreak if they are not aware they are on VM (plus it IS difficult), and with the right setup the kernel will pass data to VM pretty much transparently - IF the traffic is directed at the VM. Not quite the case if the traffic is directed at the host, and the kernel squeezes it into VM regardless (though still possible to do safely).

      Plus the only thing that goes back to host from the VM is display, and well-encapsulated I/O to be passed through without peeking in. Not the entire inbound network traffic, and all the data from disk. If the sandboxed filter is compromised, and can infect the stream, the host can be compromised.

      In case a mainstream antivirus implements this, the attacker will know this and may attack the sandboxed environment, never even trying to jailbreak, then just infect the pass-through data and use that to infect the host, instead of acting on it directly.

      Imagine you have a hardware firewall, and your computer plugged into it. Now the attacker takes control over the firewall's system... how secure is the computer now?

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

      Not always viable, but that point is a very weak point anyway. The host's kernel *can* pass all traffic transparently to VM and never be at risk. It just needs to be done, no challenge here.The challenge is assuring the sandboxed environment isn't hijacked - the same way currently the root's environment is being hijacked. While the hijack would be unable to escape the sanbox by itself (or at least only with great difficulty), it can infect the "clean" uplink, and infect the host with other malware (albeit on receiving user's rights, not root.)

      Currently, this is unavoidable, as the moment the malware has admin rights (moreover, KERNEL rights!) it can disable any control mechanisms and operate freely. With the VM, the host could supervise the sandbox and prevent infection of host in case the sandbox kernel is compromised. This is important, this is the real danger, and this is difficult.

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

      You MUST be monitoring the sandbox to tell if it's been corrupted by malicious code. Otherwise the whole scheme crashes and burns, as the attacker hijacks the sandbox and infects the clean uplink. And that can take a very short time, so "periodic re-creation of sandbox" is not a solution. Tight monitoring a'la running in a debugger is the way.

      Of course in case the sandbox is corrupted, it would need to be re-created, but that *hopefully* wouldn't be too frequent.

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

      From a security standpoint you shouldn't be using antivirus software for real-time scanning. These issues have been known for years and keep occurring ( https://www.blackhat.com/prese...
      http://www.pcworld.com/article...
      http://www.theinquirer.net/inq...
      https://community.sophos.com/k...
      ). Antivirus vendors have been screwing up too often - false positives (blacklisting OS files etc), being exploitable (like this), being unstable, using too much resources.

      Real time AV scanning should only be used by people who are incompetent enough to screw up their own systems (or let malware do it) more often than a AV company would. If you know what you are doing you wouldn't be using real-time AV scanning. You'd only scan certain stuff using sacrificial machines and more as a precaution and additional layer of defence.

      --
  2. directly in the operating system kernel by fustakrakich · · Score: 1

    Oy! And these people call themselves professionals!

    --
    “He’s not deformed, he’s just drunk!”
  3. How surprising by sunderland56 · · Score: 1

    A bug in Norton? Really? How surprising. That's never happened before, has it?

    1. Re:How surprising by flappinbooger · · Score: 2

      A bug in Norton? Really? How surprising. That's never happened before, has it?

      People pay for Norton products all the time but I cannot in good conscience ever recommend any product from them. I have repaired computers that were literally damaged by simply installing norton products. I could go on and on (and have, many times when appropriate) about how this software doesn't work and is literally worse than nothing - based on MY OWN personal observations, and I am NOT alone.
      But I don't go on about McAfee, I simply sum up McAfee products with one line: The only thing WORSE than any of the Norton products is anything from McAfee.
      Not even worth the breath.

      --
      Flappinbooger isn't my real name
    2. Re:How surprising by sunderland56 · · Score: 1

      So you're saying that McAfee is a killer app?

  4. How to catch fopen() without hooking kernel? by tepples · · Score: 3, Informative

    Without adding file system hooks to the kernel, how should a real-time antivirus tool trap attempts to read potentially infected files?

    Sometimes I think the PC Matic guys are right: a whitelist is a more reliable way to block malware. But a whitelist requires more diligence to maintain if you don't want to turn a PC into a game console, and diligence is something sorely lacking in the non-technical majority.

    1. Re: How to catch fopen() without hooking kernel? by DarkOx · · Score: 3, Interesting

      Well that is harder than it sounds, in practice.

      For example without additional modifications to the kernel does the scheduler know that not running your scan process essentially will cause I/O to stall for every other process?

      Microsoft very sensibly provided kernel interfaces to address these issues, and was not going to allow these vendors to hook parts of the kernel during the run up to NT 6.x. They all got their panties in a twist though and cried that it would prevent them from innovating, the result is they have to deal with all these little interaction problems themselves, its actually harder than it looks and leads to bugs, either in terms of security or emergent behaviors and performance problems.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    2. Re:How to catch fopen() without hooking kernel? by LichtSpektren · · Score: 4, Interesting

      Without adding file system hooks to the kernel, how should a real-time antivirus tool trap attempts to read potentially infected files?

      Sometimes I think the PC Matic guys are right: a whitelist is a more reliable way to block malware. But a whitelist requires more diligence to maintain if you don't want to turn a PC into a game console, and diligence is something sorely lacking in the non-technical majority.

      A whitelist is useless. It will either--as you said--just lock down the computer a la Windows RT, or it won't prevent the admin from whitelisting whatever he wants to execute or install, thus retaining the exact same threat risk as before.

      For optimal security, what one should do before executing an unknown binary is (1) first run it in a safe testing environment [e.g. a virtual machine] and carefully monitor the std streams to make sure it's not trying to do something malicious, and/or (2) use mandatory access control [e.g. SELinux, AppArmor] to profile the binary before executing it, thus ensuring that it won't be able to do anything beyond the realm of what the admin expects it to do. As additional safeguards, ALWAYS have multiple backups of important data. Also, a ZFS/btrfs snapshot would be good too.

      But all of that's for the security-conscious. 99% of the human race won't bother with any of that--and that's why Windows has an atrocious reputation for security and crapware, because the UAC introduced in Vista has just conditioned people to click through everything, and even the very best antivirus programs (to this I am counting BitDefender and Kaspersky--NOT Norton, Symantec, McAfee, or Windows Defender) don't protect against zero-days. It's still not difficult to unintentionally cultivate malware just through email attachments and web browsers.

      Linux is infinitely superior in this regard, since you have the baked-in defenses from POSIX, but also because the important Linux distros all ship with SELinux or AppArmor sandboxing the privileges of the email client and browser by default.

    3. Re: How to catch fopen() without hooking kernel? by Gr8Apes · · Score: 1

      Then you have a problem on windows unless you construct your own sandboxed IPC processes.

      --
      The cesspool just got a check and balance.
    4. Re:How to catch fopen() without hooking kernel? by tepples · · Score: 1

      But a whitelist requires more diligence to maintain if you don't want to turn a PC into a game console

      A whitelist is a gateway to an app store only system with censorship and lack of choice.

      That's sort of what I was getting at. It really depends on by whom it's managed. Some PC owners can be trusted to maintain their own whitelist; others can't.

      If by an experienced user A whitelist managed by an experienced user is highly effective, as described in an article by Roger A. Grimes and a SANS white paper. It's even better when you have a couple such users to handle application evaluation requests in a company's IT department. If by an inexperienced home PC owner A malware publisher can social engineer a user to approve malware. Some people actually prefer censorship because they don't trust themselves to perform the "vigilance" that is "the price of liberty".[1] In fact, ease of use is why game consoles are still around, as what some consider "censorship" others consider "peace of mind that I won't irreversibly break something". But a solution requires precisely defining "censorship", as malware authors would claim that they're being "censored".

      [1] Thomas U. P. Charlton. The Life of Major General James Jackson. Augusta: Randolph & Co., 1809.

    5. Re:How to catch fopen() without hooking kernel? by flappinbooger · · Score: 1

      Sometimes I think the PC Matic guys are right: a whitelist is a more reliable way to block malware. But a whitelist requires more diligence to maintain if you don't want to turn a PC into a game console, and diligence is something sorely lacking in the non-technical majority.

      Don't worry, eventually once there is a sufficiently bad "digital pearl harbor" event EVERYTHING will be on a white list, because everything will be like itunes and google play, you (we) won't be able to do nuthin' on our PC without it going through a walled garden.

      A walled garden controlled by a bureaucratic quagmire along the lines of whatever "team" brought us the 0bamacare website.

      --
      Flappinbooger isn't my real name
    6. Re:How to catch fopen() without hooking kernel? by thoromyr · · Score: 1

      "A whitelist is useless. It will either--as you said--just lock down the computer a la Windows RT, or it won't prevent the admin from whitelisting whatever he wants to execute or install, thus retaining the exact same threat risk as before."

      I wouldn't say that a white list is useless, but I'm not sure you really get the idea of white listing.

      A white list isn't to prevent execution of unknown code, it is to prevent the execution of unapproved code. And conflating the two results in mistakes of intent, purpose and deployment. For example, "decisions were made(tm)" and only applications from are allowed to be executed is a white list approach to avoiding execution of unapproved code. This may or may not result in preventing the execution of unknown code, but it *does* (unless there's a bug in the implementation) prevent execution of unapproved code.

      The reality of white listing is that you can't just white list certain executables, it doesn't scale. (Think the *many* executables inherent on a modern operating system, then consider the consequent and required updates.) One of the workable solutions is to white list based on publisher and require signed executables. This seems good at first blush, but it only works to stop yesterday's attackers (maybe).

      There are three fundamental problems: 1) the belief that you can trust the signed executables, 2) the belief that the normal and proper functioning of the executables is good, 3) the belief that the only "code" that will be executed is in those signed executables.

      Trust: basically, if I can cause a vulnerable but white listed application to execute in a certain way (say, to parse my jpg file) then I can execute arbitrary code.

      Good/Evil: the problem is that code and applications are not so easily categorized as good versus evil. A bad guy can get by quite happily with *only* Microsoft signed executables that are installed automatically with Windows. For example, need to sniff network traffic and send the packet captures out? Microsoft has you covered.

      Interpreters: as an extended carry over from the good/evil problem you get the shell and, especially, power shell. I qualify these differently because case #2 is about leveraging installed functionality. Bad guys don't need to install much of anything, they just repurpose the tools Microsoft has put in place. Here, you can execute arbitrary code of your choosing.

      A fairly typical scenario nowadays involves executing entirely in memory (e.g., using a browser to execute your javascript ddos code) or minimally touching the disk without using the file system (store powershell in the registry). White listing, in a practical deployment, does nothing against these threats. But it is *still* useful as a component. Even AV can actually be useful -- may favorite was the low-tech approach of using McAfee as a canary. It didn't protect the system at all, but when it stopped running you *knew* it was compromised and time for a rebuild. (Not that I'm advocating the exact approach, but I've known it to be used and it serves to illustrate how value can be derived.)

      So while white listing can be an important part of a security plan, only the naive or foolish will consider it to be a hurdle to a targeted attack (and increasingly these techniques are being kitted so that everyone can take advantage).

    7. Re:How to catch fopen() without hooking kernel? by Joe_Dragon · · Score: 1

      as what some consider "censorship" others consider "peace of mind that I won't irreversibly break something".

      But then why ban adult themed apps and games?

      Why ban wolf 3D just as they app store does not like the content?

      Why ban NES EMU's just because big N said to?

    8. Re:How to catch fopen() without hooking kernel? by LichtSpektren · · Score: 1

      Bingo, we have a winner. There is no difference in the way Windows and Linux handle executable from a security standpoint. If the executable is bad and you click on it you are DONE HERE in any OS. To the extent that Linux is better its better because nobody cares enough about DESKTOP Linux to write exploits for it.

      Sorry, you are manifestly and provably wrong. Windows has no equivalent function to AppArmor or SELinux to profile an executive's privileges before running it.

    9. Re:How to catch fopen() without hooking kernel? by EndlessNameless · · Score: 1

      it won't prevent the admin from whitelisting whatever he wants to execute or install

      It's not supposed to stop those things.

      A whitelisting application is only supposed to stop things that admins do not want to run. It is specifically designed for competent system administrators---not home users.

      A home user would have to delegate whitelist management, which translates to subscription security services or curated application stores in the real world.

      to profile the binary before executing it

      You're joking, right?

      Enterprise applications have hundreds of interrelated binaries, and there is generally no data available on the exact functionality of each. And large enterprises tend to run a large variety of your typical non-enterprise applications---too many to investigate individually. This is way beyond the realm of practical, even for most large businesses.

      If it's practically impossible for enterprises, smaller organizations won't have the skills and resources to do it either.

      Linux distros all ship with SELinux or AppArmor sandboxing the privileges of the email client and browser by default

      Internet Explorer ships with Protected Mode enabled, which has severely restricted privileges, and it runs perfectly fine with an unprivileged user account---which doesn't matter if a site can convince the user to disable it all. Or if it contains an exploit that escalates privileges / escapes the sandbox. Or if the user willingly downloads trojaned files.

      With most users running as admins, clicking yes to every prompt they encounter, and disabling security features to try "fixing things", there is no meaningful way to protect the system without revoking their privileges. Denying privileges to owners may be anathema here, but it's a baseline required for a secured system in the wild.

      People are uninterested in IT---until it gets in their way. If SELinux got in their way, how long do you think it would take the average idiot to hit google and figure out how to disable it? It's not hard. If they can follow instructions to muck about in the Windows registry, then they can certainly manage a single line of text at the CLI.

      This is why desktop security will always be crap except for well-managed corporate machines. There will be a handful of home machines run by security-conscious folks, and everything else will be a mess because people dislike being told they can't do something even when it's for their own good.

      --

      ---
      According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
    10. Re:How to catch fopen() without hooking kernel? by LichtSpektren · · Score: 1

      that's why Windows has an atrocious reputation for security and crapware, because the UAC introduced in Vista has just conditioned people to click through everything

      A few small points but (1) Windows has had an atrocious reputation for security and crapware well before UAC and Vista, (2) as you note UAC hasn't really done a lot to change this, and (3) this is just a repeat of ActiveX* in a lot of ways.

      Linux is infinitely superior in this regard, since you have the baked-in defenses from POSIX, but also because the important Linux distros all ship with SELinux or AppArmor sandboxing the privileges of the email client and browser by default.

      Uh, no. Chrome will happily run programs you download for you if you let it. Meanwhile, the juiciest targets for Linux right now are still servers which involve attacking things like bash and openssl. Honestly, AppArmor doesn't help much if you can still launch a separate executable. I'd say obscurity is the best defense most Linux desktop users enjoy today, not anything else.

      *And just to be clear, as much as there were a lot of vulnerabilities that allowed ActiveX controls to run regardless of security policies or whatever, the biggest reason ActiveX was and is a problem is the same reason UAC + downloading an executable is: you can't really tell anything about what a program will do and, as you say, people become conditioned to just click through everything. Really, lightweight snapshoting and a good recovery system would have done more to protect the system than an all-or-nothing barrier.

      What Linux distro ships Chrome as the default browser? None of the main ones (Ubuntu, Mint, RHEL/CentOS, [open]SUSE, Debian, Arch, Gentoo). If you install a different browser you should manually profile it in SELinux/AppArmor (it's a little tedious with the former, but the latter can do it for you almost automatically).

    11. Re:How to catch fopen() without hooking kernel? by tepples · · Score: 1

      Why ban wolf 3D just as they app store does not like the content?

      That depends on whether they banned Id's parent company Zenimax from posting it or whether they banned third parties from posting it.

      Third parties, game assets included Zenimax has sent notices of claimed infringement to those hosting source ports bundled with game asset files (such as WAD or PAK). Third parties, game assets not included App store operators want all source ports distributed to the public to be "self-contained", with the engine and game assets in one package authorized by the game assets' copyright owner. A source port with an "Open WAD..." command executes code that has been downloaded from somewhere. Zenimax The App Store Review Guidelines appear to contain what amounts to a general policy against historical fiction. The guidelines as of this writing state: "'Enemies' within the context of a game cannot solely target a specific race, culture, real government, corporation, or any other real entity." NSDAP-controlled Germany was a "real government". Like the adult case, this isn't quite as technically defensible.

      Why ban NES EMU's just because big N said to?

      Different repositories have different excuses.

      Fedora Tom Callaway explained on Fedora's legal mailing list (part 1; part 2) that Red Hat lacks the spare change to pay lawyers to defend a lawsuit. Even if it's winnable, Red Hat's financial resources are better spent elsewhere. Apple A ban on emulators probably has little to do with threats from Nintendo. In fact, Nintendo has approved classics compilations containing the free PocketNES emulator for sale on Game Boy Advance (one containing games by Atlus and another with games by Jaleco) and Nintendo DS (extras in Konami's Contra 4). The issue here is the "Open ROM..." command. App store operators want all emulators distributed to the public to be "self-contained", with the emulator and ROM in one package authorized by the ROM's copyright owner. An emulator with an "Open ROM..." command executes code that has been downloaded from somewhere.
    12. Re:How to catch fopen() without hooking kernel? by lgw · · Score: 1

      Whatever HTML you were hoping for in that post, it looks like goatse. Slashcode is terrible and especially the list tags are broken beyond belief. (Also, you just gave a detailed response to some rhetorical questions.)

      --
      Socialism: a lie told by totalitarians and believed by fools.
    13. Re: How to catch fopen() without hooking kernel? by mrprogrammerman · · Score: 1

      That's exactly how most AV engines work. They stall in the kernel to do their operations. You're right the scheduler doesn't know the relationship between the AV scanning server and the user processes and it doesn't need to. The normal rules for scheduling priorities work just fine. And regarding the kernel hooking you're talking about it's still restricted on x64 versions of Windows. Heard of patchguard. The primary reason it was needed prior to Vista was that there wasn't away to accomplish some things with the existing APIs.

    14. Re: How to catch fopen() without hooking kernel? by sjames · · Score: 1

      I don't know about Windows, but in Linux, root can set a processes priority such that other processes can only run when it is blocked (for example, when requested I/O is not available).

    15. Re:How to catch fopen() without hooking kernel? by sjames · · Score: 1

      The problem is who makes the whitelist. It is either an expert who may or may not have motives other than safety in mind (your computer isn't really yours, which might be acceptable on a corporate PC) or it is the owner, in which case they could skip the whitelist system and just run the software they want to run. If you need a whitelist to keep software from running without the user's permission, then you actually just have a UI problem that should be fixed.

  5. Re:WHO THE HELL SUBMITTED THIS? by Thud457 · · Score: 4, Informative

    details straight from Project Zero

    TIL that blogger was bought by Google in 2003...

    --

    the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff

  6. Microsoft tried to prevent this by ryanmc1 · · Score: 5, Informative

    I remember when Windows Vista came out Microsoft tried to lock down the kernel, but got sued by the above mentioned security vendors. This is what happens when you put your trust in third party vendors.

    http://www.dailytech.com/Micro...

  7. Thank God! by __aaclcg7560 · · Score: 5, Funny

    My workplace uses McAfee security products. We're safe.

    1. Re:Thank God! by Streetlight · · Score: 2

      Your forgot the sarcasm code pair.

      --
      In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
    2. Re:Thank God! by flappinbooger · · Score: 1

      My workplace uses McAfee security products. We're safe.

      run

      --
      Flappinbooger isn't my real name
    3. Re:Thank God! by __aaclcg7560 · · Score: 2

      Your forgot the sarcasm code pair.

      Nah... If system has an unfixable McAfee problem, it gets reimaged in a hurry.

    4. Re:Thank God! by jgtg32a · · Score: 1

      Even on the Internet the sarcasm in that one was obvious.

  8. Is this new, or from a few weeks ago? by Quirkz · · Score: 1

    Is this new, or from a few weeks ago? The date on TFA is from today but the description of the bug is nearly identical to stuff that hit the news stands about a month ago, even down to some identical wording. I can't tell if I need to make sure I get patched ASAP, or if this is something that's already been covered with earlier updates.

    --
    The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
    1. Re:Is this new, or from a few weeks ago? by Anonymous Coward · · Score: 1

      A patch, Symantec Endpoint Protection 12.1.6 MP5 was released yesteray.

      Acccording to https://support.symantec.com/en_US/article.INFO3801.html

      In addition to the following fixes, this release addresses the following security advisories:

      Symantec Decomposer Engine Multiple Parsing Vulnerabilities (SYM16-010)
      Symantec Endpoint Protection Manager Multiple Security Issues (SYM16-011)

  9. Waiting for Tanium's turn to be exposed by Anonymous Coward · · Score: 1

    Unencrypted shards. Who thought it would be a good idea to send "commandlets" across a network without the least bit of security? Commandlets that execute with admin privileges...

    The Air Force, that's who. They've bought into Tanium hook, line, and sinker.

  10. The Best AntiVirus Ever by EmagGeek · · Score: 1, Insightful

    The best antivirus ever is to use your fucking brain when you surf the Internet. And, if you don't have a brain, to stay OFF the fucking Internet.

    99.999% of all viruses and malware are distributed by one of these three methods:

    1) Spamming email addresses with infected links promising penile enlargement, instant riches, or notifying you of a problem with an account you don't even have at a bank you've never heard of (and yet people still fall for it)

    2) Porn sites. All of them spread viruses and malware. That is their job.

    3) "One weird trick," "You'll be shocked," "They don't want you to know," and "This simple method" spam traps on Facebook and other social media sites.

    Stop doing these three simple things, and you won't believe the results when it comes to the one weird trick the big AV makers don't want you to know about.

    1. Re:The Best AntiVirus Ever by flappinbooger · · Score: 4, Informative

      You're wrong on #2.

      Porn sites do NOT spread malware. Maybe at one time they did, but not any more.

      I have an anecdote to prove my point (this is the internet, after all)

      A guy brings in his computer it has a virus. He's sure the kid has been doing "naughty" things on it and got it infected. Digital AIDS as it were.

      I fixed the virus and did an "audit" of the PC's surfing history and searches and so on, giving me a timeline up to the point where it got infected.

      The kid was indeed surfing porn. I asked the guy when he and momma went to bed. "10:00" he said. I told him I could tell. Little Johnny was surfing for "hot milfs", "Zoo porn" and other horrible things starting at 10:30. But the virus didn't get downloaded then.

      The virus got downloaded at 7:30 in the morning when the adult got on the PC and did a google search for "TV Repair in [local town name]" and followed whatever link was there that took him to a fake antivirus driveby download.

      In other words, Bestiality? Safe. TV Repair? Not safe.

      I have other examples too, such as malicious ads on PBS kids and Drudge report and so on.

      --
      Flappinbooger isn't my real name
    2. Re:The Best AntiVirus Ever by wbr1 · · Score: 1
      Some of that is correct for joe home user. You apparently have not really seen targeted business malware. One of my clients is a moderate sized insurance firm. They get very legitimate looking and sounding emails on a daily basis that contain malware attachments. They have to use attachments every day in their normal work flow. Many of these emails are very specific, with industry knowledge, forms, and jargon that are used correctly, targeted at individuals in certain job functions using good grammar and addressing. It is very hard to spot sometimes.

      96% gets stopped by email filters. 2% gets stopped by the AV after that. Web filtering blacklists stop a few malicious links. The remaining bit is down to user diligence and training. Still they got a crypto virus last year. Damage was very limited due to good backup procedures and data segregation.

      --
      Silence is a state of mime.
    3. Re:The Best AntiVirus Ever by jgtg32a · · Score: 1

      Incorrect on porn sites, these days it is actually the Church sites you've got to be careful of.

    4. Re:The Best AntiVirus Ever by lgw · · Score: 2

      Not a surprise. I've worked with IT guys who had worked on porn sites. They're obsessive about security. Competition is so fierce that anything that would give the user the least hesitation simply isn't tolerated.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    5. Re:The Best AntiVirus Ever by R3d+M3rcury · · Score: 1

      Bestiality? Safe. TV Repair? Not safe.

      That's why, when your TV breaks, you're supposed to go buy a new one.

      I mean, really. Fixing broken stuff? Not only does it violate the warrantee, you can end up getting viruses!

    6. Re:The Best AntiVirus Ever by Tharkkun · · Score: 1

      You're wrong on #2.

      Porn sites do NOT spread malware. Maybe at one time they did, but not any more.

      I have an anecdote to prove my point (this is the internet, after all)

      A guy brings in his computer it has a virus. He's sure the kid has been doing "naughty" things on it and got it infected. Digital AIDS as it were.

      I fixed the virus and did an "audit" of the PC's surfing history and searches and so on, giving me a timeline up to the point where it got infected.

      The kid was indeed surfing porn. I asked the guy when he and momma went to bed. "10:00" he said. I told him I could tell. Little Johnny was surfing for "hot milfs", "Zoo porn" and other horrible things starting at 10:30. But the virus didn't get downloaded then.

      The virus got downloaded at 7:30 in the morning when the adult got on the PC and did a google search for "TV Repair in [local town name]" and followed whatever link was there that took him to a fake antivirus driveby download.

      In other words, Bestiality? Safe. TV Repair? Not safe.

      I have other examples too, such as malicious ads on PBS kids and Drudge report and so on.

      Yeah I hate hearing people say "Stop browsing those Porn sites." Porn sites aren't going to infect their customers who not only bring ad revenue but many times subscription revenue as well.

  11. Security vendors prevent Microsoft locking kernel? by khz6955 · · Score: 3, Informative

    ryanmc1: "I remember when Windows Vista came out Microsoft tried to lock down the kernel, but got sued by the above mentioned security vendors. This is what happens when you put your trust in third party vendors." link

    'The whole "PatchGuard" concept shows how broken Microsoft's approach to an OS has become. The whole concept is to catch changes made by programs which already have full access to kernel space. By checking every five or ten minutes for a change, no less. That's inherently a futile exercise. It may break some current exploits, but it won't break new ones. Any program that has access to kernel space can take over the machine. It could load a whole new OS if it wanted to.' link

  12. LD_PRELOAD? by Viol8 · · Score: 1

    Oh wait, this is Windows. It probably doesn't have anything like that in user space to intercept system calls.

    1. Re:LD_PRELOAD? by AndroSyn · · Score: 2

      LD_PRELOAD doesn't intercept system calls, it intercepts library calls. Some of which do wrap system calls, but LD_PRELOAD helps you ZERO if you have a statically linked executable.

      I'd imagine a lot of malware for Linux based operating systems very well might be statically linked, to avoid libc version dependencies.

    2. Re:LD_PRELOAD? by sjames · · Score: 1

      So use PTRACE.

    3. Re:LD_PRELOAD? by AndroSyn · · Score: 1

      Right, a ptrace based tool obviously is a better option, but that isn't what the original poster was talking about.

  13. But, Google's Android is clean by BoRegardless · · Score: 1

    Who's daddy do you trust?

  14. Test File from ISC by entropy01 · · Score: 1

    Internet Storm Center has a writeup and a test file you can download: https://isc.sans.edu/forums/di...

  15. Trust no one... by Anonymous Coward · · Score: 1

    Trust no one...especially Google.

  16. Re:how about.. by macs4all · · Score: 1

    it's just shit awful design.

    We're talking about Windows, right? So isn't that redundant?

  17. First NT team fought to keep things out of ring0 by Anonymous Coward · · Score: 2, Insightful

    I was working for a developer who had a few video games published by Microsoft around the time NT was shipping. The games and marketing divisions where having it out with Dave Cutler and the NT team because the NT team was fighting like hell against putting anything that wasn't absolutely necessary in ring0 ("kernel") space. (The bulk of the NT team followed Cutler from DEC and were experience server OS developers). The NT team was taking the right approach for a server but on the hardware at the time that approach killed video/sound/etc performance (but on the up side, if your video driver crashed it wouldn't blue screen your server). It was made all the more exciting b/c Cutler was known for his temper. Ultimately they ended up putting it in ring0 and making other concessions for "consumers" and things just went down hill from there.
     
    The ultimate irony is that Cutler ended up working on the HyperV implementation on the XBox One (among other things).

  18. LOL, too funny by JustAnotherOldGuy · · Score: 1, Insightful

    "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."

    Okay, now that's funny. I bet the NSA/FBI/CIA is having a fucking field day with this little flaw. Unless you can prevent everyone from sending you an email (!!) you can be compromised. And that is pretty much the whole fucking point of email: to receive an email.

    "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."

    Gee whiz, it sounds like Billy-Bob Programmer had too many tokes at lunch and forgot about the system kernel security thingy or whatever. Ooopsie.

    --
    Just cruising through this digital world at 33 1/3 rpm...
  19. Do Zip/Rar/Archive Bombs still exist? by Jonah+Hex · · Score: 1

    This got me thinking of the maliciously constructed ZIP/RAR files that would expand endlessly from a very small zip into files that were larger than any hard drive could handle, as well as make directory/file structures so deep you couldn't delete them in windows. Sure these days they are hiding malicious payloads in there as the above bugs mention, but I could see one of these being the payload for annoyance purposes if they still exist.

    --
    Horror & SciFi Erotic Nudes
  20. Re:First NT team fought to keep things out of ring by epine · · Score: 2

    Ultimately they ended up putting it in ring0 and making other concessions for "consumers" and things just went down hill from there.

    You've misused the word "ultimately" to imply a stubborn impasse ending in capitulation.

    That's not how things went. Cutler kept all that flaky shit out of ring0 long enough to get most of the bugs out of the core OS, without becoming befuddled by having so many fingers to point. The game vendors had to suck it for a while with a development model where their own bugs were obviously their own bugs. I'm sure this helped sober up some of the worst offenders immensely.

    Then when they were finally allowed into the kernel, there wasn't a lot left to blame in the kernel (their huge investment in gaining credibility in the server space absolutely depended upon a stable kernel) and by now the game vendors were a lot less cavalier with their development methods. Moreover, Microsoft probably could have kicked them back out of ring0 again, should that have become an insufferable problem.

    The ideal model would have been a tick box for the user which determined whether to kernel-load or not the video driver code. Then the astute user could play the game for a few weeks in some low-quality mode, and if it hasn't bombed out in user space, make a sane trade-off to jack performance.

    Generally, if you don't have to trust something, you won't need to trust something. Violators will be quarantined at their own expense. Repeat offenders will be tarred and feathered in the gamer forums—by the big fucking A/B smoking gun. What an absolute joy that would have been. Popcorn not included.

  21. Say hello to my little friend... IoT by WOOFYGOOFY · · Score: 1

    Let's just be clear on what happened here. A library used to defend against malware itself has a zero-day which is targetable by malware. This from an industry that has decades of programming effort to doing just one thing, and attracts some of the best of the best as developers.

    Just pointing this out explicitly for everyone who thinks that IoT won't wreak real physical harm, potentially on a on a scale previously unheard of and (as a consequence) programming same will be not be tightly regulated and licensed with fingerprints and code signing and background checks and everything else the national security state can think of. Because it will. Because, as this shows, you cannot stop malware no matter how hard you try.

    IoT is going to end programming freedom as we know it.

    And still we rush headlong into its arms.

    1. Re:Say hello to my little friend... IoT by Jeremi · · Score: 1

      IoT is going to end programming freedom as we know it.

      A more likely scenario is that IoT will end IoT as we know it.

      Once people realize that they don't really get much value out of putting their appliances on the Internet, but do risk getting hacked, the next big marketing push will be "certified air-gapped secure" appliances, aka traditional/non-IoT appliances, and the idea of IoT can join VRML, GeoCities, and DivX in the Hall of Technologies That It Turns Out Nobody Actually Wanted After All. (aka the HOTTITONAWAA).

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
  22. Re: WHO THE HELL SUBMITTED THIS? by Ambient+Sheep · · Score: 1

    ...for sure.

    Ok, so which Formula 1 driver are you?

  23. Another reason not to run Norton junk by jonwil · · Score: 2

    I have had Norton and Symantec on my own personal blacklist of entities I refuse to have anything to do ever since I installed some version of Norton Internet Security and it made my web browsing (and possibly other stuff) stop working until I completly uninstalled it.

    1. Re:Another reason not to run Norton junk by crunchygranola · · Score: 1

      I have not installed a Symantec product, or permitted a pre-installed Symantec product to remain, on any machine I control in a decade. In the five or six years before that I made several attempts to use Symantec security or utility products. They were never usable, in some cases they never worked at all. Antivirus programs that insisted on running at 95% CPU all the time if they were installed, but proved very difficult to uninstall. A backup program that did all their backups as uncompressed full image proprietary binary files, wasting huge amounts of storage (when it was not dirt cheap). Fortunately I tested the restore function before I had a need to actually restore, and it did not work on a stable system with no errors. Security products that only reported cryptic, undocumented codes, that even Googling could not explain. Embedded advertising for Symantec products making the thing you purchased into malware. The uninstallation problems also had many malware traits, one actually reinstalled itself and then demanded payment in pop-ups since I did not have an active subscription.

      Eventually I said "enough!". I do not know how Symantec got its huge name and status. Not from shipping decent products.

      --
      Second class citizen of the New Gilded Age
  24. Re:how about.. by turp182 · · Score: 1

    No, pretty much every platform, for example:
    * Symantec Endpoint (Mac, Windows, Linux, UNIX)

    I'm not sure what's missing in that example that would be in this one:
      * Symantec Scan Engine (All Platforms)

    Here's a good link:
    http://googleprojectzero.blogs...

    --
    BlameBillCosby.com
  25. AppContainer in Windows 8 and later by tepples · · Score: 1

    Windows has no equivalent function to AppArmor or SELinux to profile an executive's privileges before running it.

    Windows 8 introduces "AppContainer", which IE uses for its Enhanced Protected Mode. An AppContainer provides a capability model analogous to Android permissions. UWP applications likewise runs in an AppContainer. Google Chrome is based on Chromium, which has its own sandbox that uses AppContainer when available.

  26. They ship Firefox, not Chrom(e|ium) by tepples · · Score: 1

    What Linux distro ships Chrome as the default browser? None of the main ones (Ubuntu, Mint, RHEL/CentOS, [open]SUSE, Debian, Arch, Gentoo).

    Talk about moving the goal posts. But, AFAIK Chromium will happily do the same. But, then, I guess you'll try to claim that's not "default" too or some BS.

    It isn't default. Do any of these ship Chromium in the install image, or do they all ship Firefox?

  27. Any relation to Eugene? by abmw · · Score: 1

    " Tavis Ormandy, a researcher with Google's Project Zero," I wonder if tavis is any relation to Eugene Ormandy the great Conductor of the Philly Orchestra ???Hmmm.

  28. Elephant graveyard by ilsaloving · · Score: 1

    Symantec is the elephant graveyard of software. Any software that Symantec acquires, no matter how good it was originally, will turn to crap. We saw it with Norton Antivirus, Norton Utilities, a couple other things.

    For a while their enterprise antivirus product bucked the curve and actually did reasonably well, but I guess that was just a statistical anomaly that Symantec has since corrected.

  29. It's 1999 all over again by ebvwfbw · · Score: 1

    I thought everyone knew about not doing dumb stuff like this no later than 1999. The Unix world knew that way back in the 1980s. So I suppose Windows is still around 30 years behind.

  30. A Symantec executive says Antivirus is DEAD by iq145 · · Score: 1

    Just how thoroughly have hackers licked antivirus programs? So thoroughly that even Symantec, which essentially invented commercial antivirus, is jumping ship on the concept, the Wall Street Journal reports. Antivirus "is dead," Symantec Senior VP Brian Dye tells the paper. "We don't think of antivirus as a moneymaker in any way." Symantec's new stance, he explains, will be to assume that hackers can and will break through any antivirus protection, and to focus on containing the damage once they do. Symantec will create a response team businesses can call on if they've been hacked, intelligence briefings they can buy on specific threats, and technologies for identifying advanced malware in networks. Rivals already have similar products—as Channelnomics notes, other companies have been decrying the decline in antivirus effectiveness for years—but Symantec is hoping its conversion, even if late, can stem plummeting revenue. Dye says the company realized it was time "to get your act together and go play the game you should have been playing in the first place." http://www.newser.com/story/18... http://www.techweekeurope.co.u...