Vulnerabilities I Have Known and Loved #1: Symantec's Bad Week

By Max Veytsman | July 07, 2016 on vihkal, security

tl;dr: If you use software with “Symantec” or “Norton” somewhere in its name, stop what you’re doing and upgrade.

Back in my security consulting days, a mentor taught me One Weird Trick to increase conversions on your phishing campaign. It goes like this: set up an email server, get as many employee addresses you can find, and spoof a mass message that reads:

Hello this is your boss.

I’m going to fire someone next week and you get to vote on who! To get your arch-nemisis fired, please log into this website that looks exactly like our company portal, but has one character in the domain name mispelled.

Thanks, Your Boss.

Then you sit back and count how many people fell for it.

The executive who hired you is happy because they get to demonstrate the value of increasing their security budget. The consultancy you work for is happy, because they get to upsell a bunch of “security awareness training”.

Soon, you’ll be spending three days telling your victims about the importance of that little green lock in their browser’s address bar (but only when it’s in the right place!) and that they should never ever click on links, never open attachments, and if at all possible, stop using computers altogether. Everybody wins.

Obviously, everyone at this stage wants to increase the conversion rate1 of these phishing emails. This is where The One Weird Trick comes in: after you send out your first campaign, you craft another one. Before you know it, everyone on your list receives a helpful tip from the IT Helpdesk:


We’ve heard reports of a phishing campaign being waged against us. Don’t open those emails! It’s critically important that you reset your password to protect against those evil hackers who tried to phish us.

Click here to do it!

It turns out that round two gets way more clicks than round one. Most people will figure out that email #1 is a little fishy. Email #2 manages to reaffirm that, and so they dutifully click, like lambs to slaughter.

This is the phishing equivalent of the Double Tap. No, not the one from Zombieland. The Double Tap I’m talking about is a controversial military technique where after attacking a target, you follow up by sending another missile at the first responders. You do some damage, and then attack the response to that damage.

Symantec is Having a Bad Week

Last week Tavis Ormandy dropped 8 vulns against every single Symantec/Norton antivirus product. Judging by the press, things are not looking good for them.

You can find a writeup up on the Google Project Zero blog, and the issues for all 8 vulnerabilities can be found here. They’re all remotely exploitable,2 and they all should give an attacker remote code execution as root/SYSTEM (and in ring 0 for one of them to boot!)

If you’re using a Symantec product I can’t stress this enough: stop what you’re doing and upgrade.

These vulnerabilities reminded me of phishing and the Double Tap for two reasons. First, every one of these vulns can be exploited by just sending an email. Since the product is an antivirus, so it’s going to scan every file that touches your disk and every email you get for viruses. You don’t have to get your target to click a link or even open the message you sent — Symantec will happily try to parse every email you receive.

Second, the stack overflow in Symantec’s PowerPoint parser depends on a Double Tap-like attack! This parser is used to extract metadata and macros from PowerPoint decks (and presumably scan them for known malware) by exposing an I/O abstraction layer — which it then caches for performance. Tavis found that he could get that cache into a misaligned state, which resulted in the stack buffer overflow.

This vulnerable codepath is in something called “Bloodhound Heuristics”, which Symantec promotes as a more advanced set of malware detection checks. Since they’re not always run, you’d think that the vulnerability wouldn’t be very exploitable. And yet, it can be targetted every time! Under the default configuration, the system dynamically decides which set of checks to run. All Tavis had to do was try a bunch of known PowerPoint malware, see which one triggered the automatic mode to turn on “Bloodhound Heuristics,” and put his payload into them.

The exploit pretends to be a certain kind of known malware in order to trigger some special aggressive checks, which are the exploit’s true target. The Double Tap!

Vulnerability Management

While the above vulnerability is pretty cool, the Symantec bugs that are most interesting to us at Appcanary are CVE-2016-2207 and CVE-2016-2211.

Symantec was shipping its product with out of date versions of libmspack and unrarsrc. Out of date versions that have dozens of known vulnerabilities with public exploits! All Tavis had to do was download public exploits for these known vulnerabilities, and he had an attack against Symantec.

Ironically, Symantec sells a product called Enterprise Vulnerability Management! This is a hard problem for everyone. At Appcanary, we’re working on solving it.


Do you have suggestions for vulnerabilities you’d like me to write about? You can let me know at [email protected].

Paying the Bills

One quarter of the critical vulnerabilities found in Symantec’s products last week were there because they relied on out-of-date libraries with known security holes.

Our product, Appcanary, monitors your apps and servers, and notifies you whenever a new vulnerability is discovered in a package you rely on.

Sign up today!

  1. You know, it’s interesting that before I became the CEO of a startup, the only time I thought about “conversion rates” of emails in my career was when I was involved in phishing campaigns. 

  2. I’m going to well-actually myself here so you don’t have to. Tavis gives a clear path to exploit for 6 of the 8. Of the two that are left, one is a lack of bounds checking on an array index, and the other is an integer overflow bug. I’m going to go out on a limb and say I think both can lead to code execution. I can’t fault the researcher for not going further though; after you find the first 6 remote code executions, you stop feeling the need to keep proving the point…