We Left Clojure. Here's 5 Things I'll Miss.

By Max Veytsman | November 07, 2016 on Clojure, Programming, Ruby

On October 11th, Appcanary relied on about 8,500 lines of clojure code. On the 12th we were down to zero. We replaced it by adding another 5,700 lines of Ruby to our codebase. Phill will be discussing why we left, and what we learned both here and at this year’s RubyConf. For now, I want to talk about what I’ll miss.

1) The joy of Lisp

XKCD #297

There’s something magical about writing lisp. Alan Kay called it the greatest single programming language ever devised. Paul Graham called it a secret weapon. You can find tens of thousands of words on the elegant, mind-expanding powers of lisp1. I don’t think my version of the Lisp wizardry blog post would be particularly original or unique, so if you want to know more about the agony and ecstasy of wielding parenthesis, read Paul Graham.

What’s great about Clojure is that while Ruby might be an acceptable lisp, and lisp might not be an acceptable lisp, Clojure is a more than acceptable lisp. If we avoid the minefield of type systems, Clojure addresses the other 4 problems Steve Yegge discusses in the previous link2.

2) Immutability

The core data structures in clojure are immutable. If I define car to be "a dirty van", nothing can ever change that. I can name some other thing car later, but anything referencing that first car will always be referencing "a dirty van".

This is great for a host of reasons. For one, you get parallelization for free — since nothing will mutate your collection, mapping or reducing some function over it can be hadooped out to as many clouds as you want without changing your algorithms.

It’s also much easier to can reason about your code. There’s a famous quote by Larry Wall:

[Perl] would prefer that you stayed out of its living room because you weren’t invited, not because it has a shotgun.

He was talking about private methods, but the same is true for mutability in most languages. You call some method and who knows if it mutated a value you were using? You would prefer it not to, but you have no shotgun, and frankly it’s so easy to mutate state without even knowing that you are. Consider Python:

str1 = "My name "
str2 = str1
str1 += "is Max"
print str1
# "My name is Max"
print str2
# "My name"

list1 = [1, 2, 3]
list2 = list1
list1 += [4, 5]
print list1
# [1, 2, 3, 4, 5]
print list2
# [1, 2, 3, 4, 5]

Calling += on a string returned a new one, while calling += on a list mutated it in place! I have to remember which types are mutable, and whether += will give me a new object or mutate the existing one depending on its type. Who knows what might happen when you start passing your variables by reference to somewhere else?

Not having the choice to mutate state is as liberating as getting rid of your Facebook account.

3) Data first programming

Walking away from object-oriented languages is very freeing.

I want to design a model for the game of poker. I start by listing the nouns3: “card”, “deck”, “hand”, “player”, “dealer”, etc. Then I think of the verbs, “deal”, “bet”, “fold”, etc.

Now what? Here’s a typical StackOverflow question demonstrating the confusion that comes with designing like this. Is the dealer a kind of player or a separate class? If players have hands of cards, how does the deck keep track of what cards are left?

At the end of the day, the work of programming a poker game is codifying all of the actual rules of the game, and these will end up in a Game singleton that does most of the work anyway.

If you start by thinking about data and the functions that operate on it, there’s a natural way to solve hard problems from the top-down, which lets you quickly iterate your design (see below). You have some data structure that represents the game state, a structure representing possible actions a player can take, and a function to transform a game state and an action into the next game state. That function encodes the actual rules of poker (defined in lots of other, smaller functions).

I find this style of programming very natural and satisfying. Of course, you can do this in any language; but I find Clojure draws me towards it, while OO languages push me away from it.

4) Unit Testing

The majority of your code is made up of pure functions. A pure function is one which always gives the same output for a given input — doesn’t that sound easy to test? Instead of setting up test harnesses databases and mocks, you just write tests for your functions.

Testing the edges of your code that talk to the outside world requires mocking, of course, and integration testing is never trivial. But the first thing you want to test is the super-complicated piece of business logic deep in your codebase. The business logic your business depends on, like for instance computing whether your version of OpenSSL is vulnerable to HeartBleed.

Clojure pushes you to make that bit of code a pure function that’s testable without setting up complicated state.

5) Refactoring

Here’s a typical clojure function

(defn foo [a b]
  ;; some code here
  (let [c (some-function a b)]
    ;; a ton of 
    ;; complicated code here

In lisp-speak, a parenthesized block is called a “form”. The foo form is the outer form, and it contains the let form, which ostensibly contains other forms that do complicated things.

I know that all the complicated code inside of the let form isn’t going to mutate any state, and that it’s only dependent on the a and b variables. This means that refactoring this code out into its own functions is as trivial as selecting everything between two matching parentheses and cutting and pasting it out. If you have an editor that supports paredit-style navigation of lisp forms, you can rearrange code at lightning speed.

  1. My favourite essay of this ilk is Mark Tarver’s melancholy The Bipolar Lisp Programmer. He describes lisp as a language designed by and for brilliant failures. Back in university, I ate this shit up. My grades were obvious evidence of half the requirement of being a lisp programmer. 

  2. I’m aware that clojure’s gensym does not a hygenic macro system make. But, if you have strong opinions on hygenic macros as they relate to acceptable lisps, this article might not be for you. 

  3. For the record, I know that this isn’t the “right” way to design OO programs, but the fact that I have to acknowledge this proves my point. 

The Mirai Botnet is Proof the Security Industry is Broken

By Max Veytsman | October 31, 2016 on security, mirai, botnet

Last Friday, my workday was rudely interrupted because I couldn’t access Github. To add insult to injury I couldn’t even complain about it on Twitter. I tried to drown my sorrows by listening to moody Leonard Cohen songs on Spotify, but alas…

You’ve probably heard of this. Huge tracts of the Internet were down because the DNS provider Dyn faced a massive Denial of Service attack from the Mirai botnet, which takes advantage of Internet of Things devices like cameras and DVRs.

So, what’s new about Mirai?

I’ve written about 1988’s Morris worm, and I wanted to dig into the source of the Mirai botnet (helpfully published by the author) to see how far we’ve come along in the past 28 years.

Can you guess how Mirai spreads?

Was there new zeroday in the devices? Hey, maybe there was an old, unpatched vulnerability hanging — who has time to apply software updates to their toaster? Maybe it was HeartBleed 👻?


Mirai does one, and only one thing in order to break into new devices: it cycles through a bunch of default username/password combinations over telnet, like “admin/admin” and “root/realtek”. For a laugh, “mother/fucker” is in there too.

Default credentials. Over telnet. That’s how you get hundreds of thousands of devices. The Morris worm from 1988 tried a dictionary password attack too, but only after its buffer overflow and sendmail backdoor exploits failed.

Oh, and Morris’ password dictionary was larger, too.

How do we keep getting this wrong?

Around the world, we spend $75 billion a year on information security. And for what, when we keep getting such basic things wrong? Suppose I waved a magic wand and cut the worldwide security budget in half. Would things really be that much worse? The security industry is addicted to selling expensive complicated products instead of doing the basics well.

I was at a security conference the other week, and there was yet another crop of cyberapocalypse talks. The Internet of Things is a garbage fire. Industrial control systems are going to get us all killed. Users are clicking phishing links like sheep. We’re all doomed. And somehow, it’s always the fault of shitty programmers or dumb users. Let’s all laugh at their fails.

It’s all bullshit.

We sell biometric authentication systems to people who need a good password manager. We sell live threat attribution intelligence with colorful maps to people who need to practice configuration management. We sell advanced in-cpu sandbox endpoint protection to people who need to institute a patching program. There’s a reason why security practitioners get such a kick out of ThreatButt.

There are lots of real, important, conceptually difficult problems in security. We don’t really know how to write secure code, and it’s all too easy to get socially engineered. But, right now, the vast majority of threats can be thwarted by the basics:

  1. Keep your systems patched
  2. Keep your systems properly configured.
  3. Make sure you have strong passwords and two factor authentication.

Do the basics first. The basics matter. Then you can focus on the Sisyphean tasks that remain. Instead, here we are selling fancy bullshit and barely making any progress in 28 years. Lots of money in it, though.

Paying the Bills

Surprise, I also sell a security product! But I will say this: Appcanary isn’t going to protect you from shipping millions of internet-accessible cameras with the same password. We won’t even protect you from having your DNS provider DoSed.

The major botnet of 2016 is simpler than the botnet of 1988. There’s something wrong in how we do security, and at Appcanary, we think it’s a complete lack of focus on the basics.

The highest value, easiest thing you can do to improve your security is patch known vulnerabilities. Most breaches come from years-old vulnerabilities.

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!

A tale of two worms, three vulnerabilities, and one National Security Agency

By Max Veytsman | August 24, 2016 on vihkal, security

Paranoia is natural for security practitioners.

Hacking can feel like being initiated into a secret society of wizards. Once you’re in, you get access to an addictive drug that gives you super powers. But there are other wizards out there; some are good but many practice black magic. And the NSA’s school of the dark arts has a seemingly unlimited budget.

It’s natural to get a little paranoid. Experience shows you that with the right incantation you can turn crashes into working exploits. It follows that every time your computer crashes there could be someone in the shadows, chanting the right incantation. The paranoia can be all-consuming; just because you’re paranoid doesn’t mean they’re not out to get you.

In October 2013, a well known computer security expert named Dragos Ruiu came out with a story. He found that his computers had been behaving oddly, and that the symptoms he was seeing were impossible to eradicate. This was some kind of worm, since the behavior would replicate across air gapped computers in his lab. He theorized that he was infected with a super advanced piece of malware that lived in the BIOS and could spread by sending ultrasonic frequencies from speaker to microphone, undetectable to the human ear. It looked like the work of the NSA or someone equally omnipotent. He dubbed it badBIOS.

Everything Dragos claimed badBIOS could do is at least possible, and most security folks know this. Malware in the BIOS is feasible, and beyond being a research topic, it’s something we know the NSA does. In fact, because of the hype, many people developed ultrasound networking libraries just to demonstrate how viable it is.

Dragos Ruiu imaged his computer and made a lot of data available to the community for peer review, but unfortunately no credible researcher1 has publicly confirmed his findings. Maybe there was something going on. Maybe he was seeing patterns in the noise. Either way, it says something about the world today that when you’re a security expert and your computer starts behaving weirdly, the obvious culprit is the NSA.

It made me think of a different worm, from a more innocent time.

Morris Worm

The Morris Worm

It’s November 2nd 1988, almost exactly 25 years before badBIOS became a hashtag. Robert Tappan Morris, a graduate student at Cornell, executes some code he’d been working on and goes to dinner. The aftermath was a self-replicating computer worm that infected 10% of the Internet2 at the time — a whopping 6,000 computers!

Morris claimed that he wrote his program to map the size of the Internet. And indeed, each infection would send a byte to a machine in Berkeley (hiding the trail to Morris, in Cornell, as the author). Unfortunately, there was a bug that caused it to propagate too aggressively: it infected the same computer multiple times, which resulted in a denial of service attack across the whole Internet. Furthermore, the code to report infections had a bug in it. It tried to send a UDP packet over a TCP socket, making it useless for reporting the Internet’s size.

An alternative explanation is that Morris was trying to bring to wider attention some long-standing bugs in the Internet. As Morris’ friend and future co-founder put it, in classic pg3 style:

Mr. Graham, who has known the younger Mr. Morris for several years, compared his exploit to that of Mathias Rust, the young German who flew light plane through Soviet air defenses in May 1987 and landed in Moscow.

“It’s as if Mathias Rust had not just flown into Red Square, but built himself a stealth bomber by hand and then flown into Red Square,” he said.

What did the Morris Worm actually do?

The Morris Worm4 exploited three separate vulnerabilities. It guessed passwords for rsh/rexec, it exploited a debug-mode backdoor in sendmail and it used “one very neat trick”. I’ll go over each of these in detail, and you can find an archive (decompiled and commented) of the code for yourself here.

1. Rsh and Rexec

rsh and rexec are remote shell protocols from the BSD era that are almost unused today (since supplanted by ssh). rsh can allow passwordless authentication if coming from a “trusted” host, which it determines via a list of addresses stored in a global /etc/hosts.equiv or per-user .rhosts file. When an rsh request comes from a user of a trusted machine, access is automatically granted. The worm used this to propagate, searching those two files — as well as the .forward file, which back then was used to forward your mail around the Internet — for trusted hosts.

Even in 1988, people knew that leaving rsh open on an untrusted network like the Internet was a Bad Idea, and so the worm also propagated via rexec. Now, rexec uses password authentication, but Morris made an intelligent assumption: people tend to reuse passwords. Back then, /etc/passwd used to5 store everyone’s encrypted passwords. The worm shipped with an optimized implementation of crypt and a dictionary, and went to town. Once it cracked a password, it tried it against all the likely hosts it could find.

2. Sendmail’s Backdoor

In the absence of any friendly hosts, the Morris Worm would then exploit a backdoor in Sendmail. You see, Sendmail had a “debug” mode that allowed anyone to route an email to any process, including the shell! Ironically, this was apparently deliberate:

Eric Allman, a computer programmer who designed the mail program that Morris exploited, said yesterday that he created the back door to allow him to fine tune the program on a machine that an overzealous administrator would not give him access to. He said he forgot to remove the entry point before the program was widely distributed in 1985.

(This wasn’t even the first Sendmail backdoor. Sendmail used to ship with “wizard mode”, where sending the strings “WIZ” and “SHELL” gave you a root shell. By the time that Morris was writing his worm, wizard mode was disabled almost everywhere.)

If you’re wondering how sendmail could have backdoors like this, it seems that it was somewhat well known. This quote from a mail by Paul Vixie summarizes the situation.

From: [email protected] (Paul Vixie)
Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards
Subject: Re: a holiday gift from Robert "wormer" Morris
Message-ID: <[email protected]>
Date: 6 Nov 88 19:36:10 GMT
References: <[email protected]> <[email protected]>
Distribution: na
Organization: DEC Western Research Lab
Lines: 15

# the hole [in sendmail] was so obvious that i surmise that Morris
# was not the only one to discover it.  perhaps other less
# reproductively minded arpanetters have been having a field
# 'day' ever since this bsd release happened. 

I've known about it for a long time.  I thought it was common knowledge
and that the Internet was just a darned polite place.  (I think it _was_
common knowledge among the people who like to diddle the sendmail source.)

The bug in fingerd was a big surprise, though.  Overwriting a stack frame
on a remote machine with executable code is One Very Neat Trick.
Paul Vixie
Work:    [email protected]    decwrl!vixie    +1 415 853 6600
Play:    [email protected]     vixie!paul      +1 415 864 7013

The Internet was a polite place, indeed.

3. One Very Neat Trick

The Very Neat Trick that Vixie was talking about is the now-standard stack buffer overflow. It’s fascinating to read contemporary accounts that marvel at the cleverness of a class of bugs that are now ubiquitous — although, for me at least, they still haven’t lost their magic6.

Here’s the main routine from the fingerd of that era:

main(argc, argv)
    char *argv[];
    register char *sp;
    char line[512];
    struct sockaddr_in sin;
    int i, p[2], pid, status;
    FILE *fp;
    char *av[4];

    i = sizeof (sin);
    if (getpeername(0, &sin, &i) < 0)
        fatal(argv[0], "getpeername");
    line[0] = '\0';
    sp = line;
    // ... snip ...
    // build sp into arguments for finger 
    // and call /usr/ucb/finger via execv before
    // putchar'ing the result back to stdout

If you have experience with reading C code,7 you may have spotted the vulnerability. gets(line) reads STDIN and puts the contents into a 512 byte buffer. This means that sending more than 512 bytes will overwrite the stack with an attacker-controlled value.

The worm sent 536 bytes of data, which overwrote the stack frame of the main function. This allowed Morris to overwrite the pointer to where main is returning to. He set that pointer to be within the 536 byte buffer he sent over the network. The beginning of the buffer contained shellcode that called /bin/sh. Game over.


Robert Tappan Morris was convicted and sentenced to three years probation, 400 hours of community service and a $10,050 fine (about $20,000 in today’s dollars) plus the cost of his supervision. He then went on to co-found a little startup called Viaweb. You may have heard the rest of that story. Today, Morris is a tenured professor at the Computer Science and Artificial Intelligence Laboratory at MIT and is one of the leaders of the Parallel and Distributed Systems Groups.

Why did the paranoia around badBIOS make me think of the Morris Worm? If you read contemporary articles about the Morris Worm, they’ll sometimes mention, but never emphasize, who Robert Morris’s father was. The elder Robert Morris just happened to be a computer security expert. While the young Robert Morris was writing his worm, Robert Morris Sr. was serving as Chief Scientist at the NSA’s National Computer Security Center!

The Internet grew up a lot since 1988, and not just in size. In 2013, your computer acting strangely is obviously a NSA-written malware that lives in your BIOS and propagates over sound waves imperceptible to the human ear. In 1988, son of an NSA security executive infects 10% of the Internet with a worm that uses an exotic new exploitation technique called a buffer overflow and… nothing.

Just to be clear, I’m not alleging any conspiracy between father and son, besides perhaps father making some calls after son’s arrest. While the Morris worm was likely the first malicious use, buffer overflows were understood as a problem before 1988, if not widely. The way the media narrative handled the NSA connection in 1988 just says a lot about how the world of the Internet changed in 25 years.

As for Dragos Ruiu, he’s been quiet about badBIOS since 2013. I’m not sure what he’s doing these days besides CanSecWest, but in my heart of hearts, I like to picture him playing the saxophone amidst the detritus of his torn up apartment.

Paying the Bills

We’re trying our best, but we’ll only be able to blog about a minuscule percentage of the world’s vulnerabilities. And starting with 1988 means we have a lot of catching up to do. How will you ever find about the ones that actually affect you?

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. One of the things I wish that the security industry would do less of is blind appeals to authority, and I hate that I made one here. Unfortunately, I don’t have the skills or time to make my own analysis of Ruiu’s data, so I just have to trust the Thought Leaders on this one.  

  2. The 60,000 computer-strong Internet was of course one of many networks at the time. The Internet was the one that was global and used TCP/IP — the Internet protocols. Therein lies the pedant’s case against the AP’s capitalization of the word “Internet”. 

  3. Disclosure time: years after giving that quote, Paul Graham and Robert Morris went on to found Y Combinator along with Jessica Livingston and Trevor Blackwell. YC in turn is an investor in Appcanary. Robert Morris and I have never met, though we did once meet with Paul Graham.  

  4. My favourite paper on the analysis of the worm is With Microscope and Tweezers from MIT’s Eichin and Rochlis. They spend a page passionately arguing that it’s a virus by using a complicated appeal to the difference between lytic and lysogenic viruses with references to three separate biology textbooks! 

  5. I assumed that /etc/shadow came about as a consequence of the Morris Worm, but it seems that it was originally implemented in SunOS earlier in the 80’s, and then took 2 years after the Morris Worm to make it into BSD. 

  6. Exploits really are magic, and it goes without saying that exploit users have chosen the Left-Hand Path to wizardhood. If the cover of SICP is to be believed, the Right-Hand Path is available through careful study of functional programming and Lisps. Perhaps this is the true reason why Morris and Graham were such effective collaborators. 

  7. On the other hand, this C code is over 30 years old. When I ran it through the gcc on my machine,I was very happy to see that it complained bitterly but still compiled it. One exercise for the reader is finding where the network operation actually happens. main takes input and output from STDIN/STDOUT, but there’s an uninitialized struct sockaddr_in sin that we call getpeername on. How is a network socket piped to standard input/output and who is initializing the sin struct? I actually haven’t been able to figure this part out. If you know, please tell me! The full code listing is here

    Update 08/29/2016 Dave Vandervies emailed me with an explanation!

    fingerd was meant to be run from inetd (see here), which sets up the network connection and invokes the actual server process with its stdin and stdout attached to the network socket.

    As for the getpeername, the address is an out parameter; this call looks up the peer address of stdin (fd 0), and will fail (and fingerd will error out on that) if it isn’t a socket (see here). Since the actual address doesn’t get used, that appears to be the purpose of the call here.

Making Appcanary easier to use

By Max Veytsman | July 14, 2016 on Announcements, Product

I’m excited to announce that we’ve added two features that make Appcanary a heck of a lot easier to use!

Add monitors by uploading a file

Our Monitor API is great if you want to track a set of Linux packages or your Gemfile. We give you a dashboard showing which packages are vulnerable, and email you whenever new vulnerabilities that affect you come out. However, there’s always a bunch of setup to get a new API going.

With that in mind, we made the interface a lot more user friendly! You can now upload a file to watch directly through the website. Just go to add monitors to be able to upload a file directly. Monitors support Ruby’s Gemfile.lock, /var/lib/dpkg/status for Ubuntu and Debian, and the output of rpm -qa for Centos and Amazon Linux!

Automatically upgrade vulnerable packages

A few of our customers told us that knowing about vulnerabilities is nice, but you know what would be great? If we could somehow patch them automatically. We thought about it and said, sure, why not!

If you have the Appcanary agent installed on an Ubuntu server, and you’re running the latest version, you can run

appcanary upgrade

in order to install updates for any packages we know to be vulnerable.

You can also run

appcanary upgrade -dry-run

in order to see what the agent will do, without it actually touching your system.

Now you can manage vulnerabilities, learn about new ones that affect you, and apply patches, all through Appcanary!

If you haven’t tried us yet

Stay on top of the security vulnerabilities that affect you, today.

Appcanary, monitors your apps and servers, and notifies you whenever a new vulnerability is discovered in a package you rely on. And now it will help you patch vulnerable packages as well.

Sign up today!

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…