Hacker News Reader

Comment by cypherpunks01 | Hacker News Reader

"Because Symantec uses a filter driver to intercept all system I/O, just emailing a file to a victim or sending them a link to an exploit is enough to trigger it - the victim does not need to open the file or interact with it in anyway."

That seems big. Is there any precedent on AV software vulnerabilities of this scope?

View on HN

Worse than that. Apparently,Tavis emailed the exploit to Symantec in a password protected zip file. He included the password in the body of the email. The email server, running Symantec, grabbed the password out of the email, decrypted the zip file, and upon reading the exploit code, crashed itself.

That's a hell of a proof-of-concept.

It wasn't intentional. This was alluded to in Tavis's previous exploit.

But that being said, it's hilarious.

Seriously? That's incredible. I'm not sure if I should be impressed that doing so worked, or saddened by the fact that it ACTUALLY WORKED...

It's hilariously ironic. They're in the business of scanning things which smart people want them not to. How does someone send them something they really shouldn't scan?

I very much started reading your post as a comedic sci-fi ending to the story.. but now I am actually not sure. It would be quite creative to think of that scenario! Did this happen?

I'm afraid this did actually happen[1].

[1]: https://bugs.chromium.org/p/project-zero/issues/detail?id=82...

This is just an assumption

I do not see any indication in the link you posted. Am I missing something?

> I think Symantec's mail server guessed the password "infected" and crashed (this password is commonly used among antivirus vendors to exchange samples), because they asked if they had missed a report I sent.

At least they eat their own dog food.

At the end of the day, we all pivot back to our own solutions when it appears we're almost out of runway.

Nice to see that even security researchers can't be bothered to PGP encrypt their messages then.

Why should they? Signing, maybe; encrypting, superfluous and risky in this context (if the other party won't accept or read encrypted mail).

Perhaps because they are discussing critical system vulnerabilities, some of which would be disastrous if they got into the 'wrong' hands before they were patched?

And, from Symantec's own page: Symantec strongly recommends using encrypted email for reporting vulnerability information

Yes, I believe there are several precedents. Tavis has found remote code execution exploits in Sophos[1] and TrendMicro[2] products too.

Continuous protection by nature opens up an enormous attack surface, and AV vendors' seem in no way up to the challenge. For this reason, in my company, security policy is to use only what's built in to each O/S.

[1] http://www.pcworld.com/article/2013580/researcher-finds-crit... [2] http://arstechnica.co.uk/security/2016/01/google-security-re...

That's a progressive stance that few organizations have the balls to implement.

In one case, a contractural compliance thing required that we have AV be present. We complied, but disabled the filter driver and let it scan nothing. ;)

I'm sure your legal team was thrilled when you approached them with that, haha.

We're small enough not to have a legal team yet. But if we did, this is not something I'd be overruled on easily. The technical issues seem pretty clear cut, and if you have a written policy in place (and it was there before anything bad happened) I can't see how it's a genuine risk. It was also no problem for our ISO27001.

If you're using Windows, does Microsoft Security Essentials (or whatever its current name is) not qualify?

Project Zero has uncovered a similar issue in ESET a year ago:

http://googleprojectzero.blogspot.ch/2015/06/analysis-and-ex...

Reply on news.ycombinator.com