For everyone else who was lost like me (mined from this comment section and some googling):
- AV: Anti-virus software
- Vess: Security, AV expert, loves AV
- Justin Schuh: Chrome dev (security-related), hates AV
- AV needs deep access to the OS, opening the door for attacks if managed poorly
- Deep OS access is often hacky (due to lack of APIs?), thus potentially unsafe
- Vess and Justin Schuh both have bad manners
Is this about right?
Also, how is AV a (direct) impediment to a shipping a safe browser? It seems to me that a browser should be mostly agnostic toward AV.
Edit: It seems like the problem is that AV tries to penetrate browsers in a similar hacky way as for the OS, resulting in similar issues.
TL;DR: AV tries to help by supervising browsers because they're allegedly not safe enough, but browsers think they're already safe and want AV to gtfo.
Edit 2: Are there any AVs that don't tamper with browsers at all? I've always been using Avast and switching off all browser-related features, but maybe there are better options.
Vess has been in the AV industry a LONG time. A really long time. So long that I don't think he's really able to see the state of the industry for what it is anymore.
In the days of windows 95/8, the desktop landscape was very different to how it is now - OSes and browsers were horribly insecure, and readily compromised with little effort. Attacks were plentiful, and infections common. AV really did add useful additional security.
These days that's less the case - an up to date windows 10 or OSX desktop is reasonably secure by default - it can still be infected, but generally not without some action taken by the user (of course there are still 0-days, but they are generally treated seriously and patched at least moderately quickly. Unauthenticated RCEs are now a rarity, thankfully).
The AV industry hasn't really caught up with the idea that the OS/apps they are messing with are now in general fairly well written and audited pieces of code, and haven't really got institutional awareness that they are making things worse, much of the time.
This is frustrating for the OS/app devs, who rightly get annoyed at having AV vendors actively removing protections built into the browser, but also I feel that the AV industry is getting defensive at the bad press generated by things like project-zero, when at least in their own minds they are trying to do something useful. Hence the heated words. ALso, infosec tends towards being a profession of heated language, a lot of the time...
He might know what AV technology is like today on a theoretical basis but he seems utterly clueless on a granular technical level.
His comment that AV is necessary today seems completely out of touch. There's two things more important than anything else these days: Keeping patched as you mention, but also never, ever giving clueless users administrator access on the machine.
I'm not sure any AV package will protect a sufficiently stupid user from a targeted spear-phishing attack, and that's the real threat to worry about.
To the last point... at least today, you can usually "fix" an infection by creating a new user, logging in as that new user, and copying over necessary files from the infected, then delete the infected profile.
On the flip side, depending on the infiltration, if it can be used to target other systems, it doesn't matter if it's escalated or not, if it can run.
Hold on, because installing AV in 1995 would not have done a whole lot more to protect you than installing in 2016 does. I was peripherally involved in the virus scene in the early 1990s --- in that I had close friends who were more than peripherally involved --- and my recollection is that AV was as much a joke then as it is now.
I had the pleasure of working for an antivirus company for a few years after they bought my firm. We were in the security group for that company. The antivirus people might as well have been in a different universe; there was no input from security whatsoever.
I think parent was talking about more fundamentally though. There were good and bad AV software back in the 1990s too. I think Vess was involved in macro viruses detection back in the 1990s.
Vess wrote quite a bit about The Dark Avenger. I'd go so far as to say they had a rivalry. (I guess I just assumed most people knew who Vess is. He was certainly a name I knew from my reckless teenage years...)
I don't know that there was ever good AV, at least not in the terms that Schuh is talking about. That's interesting about Vess, though; where did you find that out?
Yeah AV had its heyday when we didn't have 24/7 net connections (a problem all its own, i am starting to think) and "infections" happened by way of boot sectors and modified binaries.
These days however, infections happen more and more via "clever" interpreted code that can be embedded in just about anything. You best bet for killing a whole lot of crap online is basically to turn off JS.
This because http delivered JS is the best way to get past the firewall, that in turn is a blunt, but effective, way at stopping various network born crap.
There are interpreters for programs that are delivered over the network to be run locally by the unsuspecting user, in some surprising places.
For example: Here's a sound player that contains an entire 6502-based virtual machine, because the "sound file format" that it "plays" is actually an executable program. Unfortunately, the virtual machine hardware is not properly simulated, allowing the 6502 code to memory-map parts of the virtual machine manager itself using the virtual memory controller hardware and alter them.
> Essentially, a WMF file stores a list of function calls that have to be issued to the Windows Graphics Device Interface (GDI) layer to display an image on screen. Since some GDI functions accept pointers to callback functions for error handling, a WMF file may erroneously include executable code.[2]
I'm glad you clarified this, because I was confused by it. For anyone questioning AV, I'd recommend talking to someone who's worked in a service provider. That being, managing:
-Businesses that are not overly technical. Specifically, it's easy to work in a technical environment where users know better and provide an artificial shielding
-Inheriting AV solutions, and therefore working with 5-6 different vendors at any one time. It's not a matter of "get a better product"
-Businesses that consider themselves too small to implement good policies, or force users to tolerate lockdowns in any way
Anyone in that position will talk about seeing cryptolocker having walked right past well managed AV products, not just once or twice, but weekly, for the past few years.
They will also have horror stories about outages caused by AV themselves.
I have a hard time with anyone claiming to AV is an effective requirement beyond politics and insurance policies.
April King (GH:marumari) from Mozilla has chimed in agreeing with Justin: "Not speaking for my employer (@mozilla) but AV causes piles of security issues for Firefox."
Also, Vess really doesn't know his shit if he's arguing with @taviso. Incidentally, in the span of 26 hours and 37 minutes, @taviso also found massive vulns and attack surface in FProt, which Vess has advocated.
Vess is asserting that AV vendors can write their own versions of the most complicated parts of the browser & OS (including parsing & rendering HTTP/HTML/CSS/JS/PNG, JS runtime, etc), then add more code on top of that to detect bad things, and do all of this while adding no significant bugs and with tolerable performance overhead. The reality is that browsers are insanely complicated, the people working on the major browsers are extraordinarily skilled, and there is a mountain of evidence that AV vendors routinely ship software that by design exposes users to huge security risks on top of all of their bugs.
Meanwhile security by isolation is proven effective at protecting users. Two good examples are the process-per-tab isolation in Chrome and the app sandboxing on iOS. Some holes into the sandboxes are necessary (for example you need to get keyboard input in and rendered images out) but every additional hole you open adds significant risk. The downside to this approach is it reduces the market for AV and other third party utilities.
> Vess is asserting that AV vendors can write their own versions of the most complicated parts of the browser & OS (including parsing & rendering HTTP/HTML/CSS/JS/PNG, JS runtime, etc), then add more code on top of that to detect bad things, and do all of this while adding no significant bugs and with tolerable performance overhead.
Don't forget they usually try and run all of that right in the kernel, because if there's one thing you want more than hardly tested unsafe reimplementation of the most complex and dangerous parts of a browser, it's to run them in ring0.
I'm not a security expert, but always had a feeling that browsers mostly just need to sandbox websites, so websites cannot do any critical operations that would require AV supervision.
"Soft" vulnerabilies like files downloaded and executed are critical outside of the browser, and that's where AV makes sense to me. But I don't want an invasive plugin telling me "this link is safe" with a green, flashing icon.
So I've always been trying to just switch off all browser-related features of my AV, but are there AVs that are less aggressive in this matter by nature?
>are there AVs that are less aggressive in this matter by nature?
Yes, if you are on windows, just use Windows Defender (AKA Microsoft Security Essentials).
You'll read how it doesn't detect as much as the others and it doesn't have any fancy features, but all that means is that it won't have a ton of false positives (i've only ever had one false positive with it ever), it won't try to upsell you to a premium service, it can be disabled/turned-off with one click, and most importantly it won't weaken the security of your whole system.
browsers mostly just need to sandbox websites, so websites cannot do any critical operations that would require AV supervision.
That's the way it ought to work. But it's so tempting to launch stuff from the browser, from Adobe Reader to Flash to Microsoft's "protocol types" which launch apps.
The proper role of antivirus programs is as a "guard". When you download a file, a program looks at it and decides if it should be allowed in. This at least gets rid of all those attack .zip files that show up in email attachments. It also has a well-defined interface with the application.
> But it's so tempting to launch stuff from the browser, from Adobe Reader to Flash to Microsoft's "protocol types" which launch apps.
The latter (MS protocol types) is not at all MS specific.
Let's list some well known examples:
- Apple's itms "protocol", itms:xxx opens either iTunes or the App Store, also on OS X (this is how "Download from Mac App store" works)
- MS Communicator/Skype for Business (one of them is the successor of the other, I always forget which one) uses this to start conferences after you installed the respective app
- Spotify does something even worse, the client appears to launch a http server, and e.g. when you log in to facebook on your browser, it supplies the used port to their oauth redirector - which in turn gives the auth token to Spotify via calling http://localhost:xxx/yyy.
- all major mail programs use the "mailto" protocol; the OS loads the user-defined MUA with options for pre-fill (body, subject, recipient(s))
It's a Lync client, according to Wikipedia. One of the customers of my company uses it.
The amount of different apps and solutions for teleconferences is just astounding. One might think that there is a common standard or something... but no, I have at least four distinct communication apps on my Mac. m(
The whole isolation thinking is spreading "downwards".
Just look at recent hoopla in the Linux world about using "containers" on the desktop to isolate different processes from each other, and from the users files.
> Also, how is AV a (direct) impediment to a shipping a safe browser? It seems to me that a browser should be mostly agnostic toward AV.
The main problem is that AV (and some other Windows software) like to inject DLLs into every single process in the system.
The current trend in browser security is a heavy form of sandboxing, in which the sandboxed processes can only access a very limited set of system calls. For that to work, the set of system calls required by the sandboxed process must be known, which is only possible if all the code running within the sandbox comes from either the browser or the operating system itself.
However, if an arbitrary DLL is injected into the sandboxed process, running arbitrary code and attempting to call arbitrary system calls, the sandboxed process will crash, either because the sandbox mechanism kills the process when it attempts to call an unexpected system call, or because the call attempt returns an error value which the injected DLL didn't expect.
Therefore, browser vendors are unable to enable stronger forms of sandboxing, since they'll lead to crashes in the wild.
The current trend in security seems to be heavy sandboxing, period. And anything that gets in the way of said sandboxing, however benign, is considered insecure, full stop...
It's the principle of least privilege. Give apps (and websites, and even parts of core services/infrastructure and kernel code) only what they absolutely need. Every syscall you can say shouldn't ever be called is one less avenue for attack. Benign isn't good enough. You need to actively justify every privilege, and leaving a few open for "benign" reasons is bad practice.
I doubt they'd have code for that if only a small minority of users will use it. Hardening something takes a lot of effort, and it's probably not worth the work to have two different sandbox techniques just so that users without AV can have a better one.
We only way forward is proper sandboxing and not allowing any form of executables to run from $HOME, even if it means some coding patterns will no longer be as easy to implement.
Not only is LD_PRELOAD interpreted by code within the process itself (so it can easily be ignored), but also the parent process which forks the sandbox process can (and most probably does) clear all the environment variables.
I believe it's not as easy on Windows for a process to protect itself against DLL injection.
On my UNIX days I used it as poor man's solution to track memory leaks, by overriding malloc()/free(), this was done at dynamic linker level, not the process.
So I checked and apparently this no longer works since AT_SECURE exists, around 2.6.0 time frame.
It has been a while since I cared to do this on GNU/Linux, maybe around 2002.
Capsule summary of this thread: Justin Schuh finally comes out and broadcasts what security people have been telling each other for years, which is that antivirus software is one of the biggest impediments to hardening software.
Here, I'll put it more succinctly: "did you know that random antivirus vendors held a pocket veto on OS and platform security features, and that they routinely use it to make things easier for their products?"
I think by 2016 most people understand that antivirus doesn't work, and that it's installed more as a compliance and IT management check box than anything else.
I think people who have paid attention for the last couple years as Tavis Ormandy has published AV bug after AV bug have a good sense for the low software quality of AV systems, and understand how it creates new vulnerabilities on systems.
What I don't think we've seen is someone explaining that not only is AV ineffectual and unreliable, but that by dint of being installed across hundreds of thousands of machines and because of the kernel and runtime grubbing that AV requires as part of its security theater, AV makes it much harder to deploy OS and runtime countermeasures to attacks.
There was a Project Zero post on HN yesterday (someone can find it) about how Chrome wanted to do full Win32 syscall filtering for its sandbox processes, but couldn't, because Adobe and Widevine relied on some Win32 syscalls --- and so DRM not only doesn't work, and creates new vulnerabilities (cough Flash cough) but also makes it harder for Chrome to implement new security features that can eliminate whole classes of bugs.
Same deal with AV.
Justin Schuh, by the way, is one of the Chrome security leads, and is a coauthor (with Mark Dowd and John McDonald) of TAOSSA, the bible of software security.
I'm not sure who Vess is other than that he's an AV person.
JS offers a huge attack surface by itself and it's difficult to disable it as web developers are lazy and won't want to develop a website which works without it. Every time someone complains here about mandatory-JS websites they're more or less called a luddite. More and more APIs are piled on in the (foolish) quest for native-like web apps.
Plugins such as Flash, Java or various document viewers are notorious for being exploit magnets.
Let's say we manage to disable JS and plugins though. The browser is written in C++ - and please correct me if I'm wrong - not particularly modern and safety-conscious C++. I am familiar with e.g. Firefox updates and most of them contain security fixed in said code.
Underneath we have C libraries for image processing, font management, etc - it's expected that they are vulnerable.
So a browser is basically a set of sieves on top of eachother that during the best of times can go several weeks without leaking.
It doesn't seem that their biggest problem is AV, it's that their code and the code they rely on is riddled with holes.
First, this is a category error. Browsers are a significant security challenge (probably the most significant, due to the fact that the web is the industry's largest inner platform) because they do lots of things users want. Justin's job protecting Chrome is to take a product millions of people demand, and make it as secure as possible. That's not what antivirus is. The antivirus pitch is "install this thing that nobody wants, and it will keep bad things from happening".
Second: compare the cost of a Chrome exploit to that of an antivirus exploit. A reliable Chrome drive-by is into the six figures. An AV bug is a Sunday project for Tavis Ormandy.
I didn't mention antivirus quality and don't care much about the topic nowadays.
Browsers do a lot of things web developers and browser developers want, that's why they transformed into a frankenstein OS that at this point is probably impossible to secure.
I disagree that they do "a lot" of things users want. They can show web sites, more or less like 16 years ago except with more ads, animations, tracking.
They like to pretend that websites are apps, but that always fails sooner or later.
My point was: browsers are probably the number one attack vector today. It doesn't matter that it costs a lot or that antiviruses are crap at security.
Very few are likely going to get compromised through their antivirus. A whole lot will be compromised through their browsers, irrespective of the existence of antivirus. The push to web apps, insecure core OS elements and browsers guarantee this.
P.S: I don't use Chrome, so the fact that it's above avarage at security leaves me cold. I get it that it perhaps offers better protection than Firefox, but what's the point of that if everything one does is uploaded to Google anyway? From that point of view, the whole discussion is quite repugnant. Google worrying that others will install spyware on the systems that they spy on through Chrome, analytics, docs, gmail, etc.
Can we all take a minute to appreciate how shit Twitter is at consuming complex conversations like this? It's shameful when something like Imgur (as bad as it is technically) has a comment system that's light-years ahead in terms of conversation readability.
Unbelievable that so smart people prefer this medium.
At some point in the conversation they are both confused who is answering who and why. Twitter should just add a damn comment box for each Tweet and be done with this archaic sms system.
Agreed... If they'd just make it so the @replies carry the root and upstream Id's, and make some leeway into their constraints... Is anyone still using the SMS adapter to do anything but send new tweets?
Justin Schuh seems to be arguing that the issue isn't just hacky deep OS access. He's saying that AV companies follow poor security and stability practices in their software and are creating vulnerabilities.
And it's not just breaking the actual code, it's breaking the standard communications and formats that all major browsers use.
I've personally seen HSTS, HPKP, HTTP2, TLS1.3 and more all get royally fucked by various AV programs. And that's just from doing tech support for my family.
I understand that if an AV wants to protect certain aspects they need to get access to it, but using these hacks, workarounds, and more to do it is not only unprofessional but both a security and usability nightmare.
It's also why the only AV i'll ever recommend will be Windows Defender. People like to complain that it doesn't "catch as much as the others", but at least it's not actively breaking shit.
Windows would never call out a vendor in their ecosystem. It's suicide.
Browsers don't have to play by those rules. I'm basically saying they should come out and say "your av is shit".
Though obviously with better phrasing.
Browsers do have the mandate of system compatibility, but it shouldn't be to the detriment of evolving their product. I guess my strategy would be to find something to patch vs an antivirus vendor with a low install base and put the industry on notice.
Edit: Big honking popup that says "Detected Antivirus software X is modifying our software without permission. This compromises the security of your system and the stability of our software."
I think starting that war will just end up putting users (especially unknowledgable users) at greater risk.
Think about it from a layperson's perspective. A browser maker is saying that the security software isn't secure, but the maker of the security software whose entire company is formed around security says it's fine. Which would you believe if you didn't have the knowledge you have?
In the end, if browsers started this fight publicly, AV vendors might start "making" their own browsers which are horribly insecure (Comodo does exactly that already, and about a year ago they shipped it with the same-origin policy disabled [0]).
Not to mention that uninstalling/removing AV software is difficult at best and impossible at the worst (If norton is on a machine, i'm reinstalling the OS, because I don't think there's another way to get it off of there), and in some cases people have paid money for their AV through shady upsells and FUD. And they aren't going to give up their paid software (and in their heads their security) for a free browser when there are several others to choose from.
Yes, but then if AV companies build their own browsers and crash yours, you can have the government step in and prosecute them for their anti-competitive business practices.
I can't imagine any of the AV vendors getting a web browser right to the point that they'd have widespread user adoption. And from the perspective of the Firefox or Chrome or Opera, that user probably wasn't using an updated version of your browser anyway...
> Browsers don't have to play by those rules. I'm basically saying they should come out and say "your av is shit".
> Edit: Big honking popup that says "Detected Antivirus software X is modifying our software without permission. This compromises the security of your system and the stability of our software."
So you think what the world needs is an arms race of AV detection?
Chrome Dev here. Still trying, and currently failing, to ship App Container (Low Box Token) for renderer processes.
We strongly suspect AV is tampering with renderer process startup causing our attempts to set the low box token to fail (the token manipulation has to occur while the process is suspended, and we suspect AV is injecting threads at this point).
Either that or AV is just crashing the process because it does not expect its calls to fail inside the sandbox.
Very frustrating. Glad jschuh has come out and said what we all believe.
I think a rootkit and a mitmproxy with very low software quality would make it hard to ship any secure software. Now multiply that by however many antivirus suites exist. Would you type your credit card number into something running on that platform?
This is the elephant in the room. Software vendors dont want to make this APIs as they increase complexity and cost so AV vendors use hackey solutions for a lot of security related tasks. This is a classic conflict that is probably never going away.
To MS's credit, they did remove ring0 access to apps like AV and have added OS-level APIs, but the application level guys still consider that bothersome and the AV guys simple need more/better and more flexibility as threats change. The recent stuff in 8 and 10 were engineered well before we had this rash of ransomware attacks.
Also from a practical perspective, its very rare to see an AV compromised but we're constantly seeing browsers, plugins, etc compromised. Heck, Firefox just had a zero-day yesterday. I think the argument that AV makes everything worse is the more questionable claim in this discussion regardless of how much we hate the necessary evil AV is. Especially when we consider how the next-gen stuff that's almost purely heuristics will probably replace AV one day and how its much less hacky than current solutions.
Also from a practical perspective, its very rare to see an AV compromised
If by very rare, you mean, constantly, then yes. You're hearing less about this because the AV industry is fragmented, so targeting AVs is not interesting because you only reach a small percentage of people. There's less browsers and the biggest ones reach literally multiple tens of percents of internet users, which is much more interesting.
but we're constantly seeing browsers, plugins, etc compromised. Heck, Firefox just had a zero-day yesterday.
...and it was protected by its sandbox from infecting the system. (The actual exploit was a privacy unmask targeted at an older version) The same sandbox that can't be tightened due to AV. See the problem?
How many AVs were blocking the exploit faster than the browser vendor released an update, anyway?
If AV was so vulnerable, we'd see nothing but exploits in the wild going after AV. Yet we aren't seeing that anywhere.
If you read the notes you'll see scary terms like "buffer overflow" but "probably wont work on windows because windows uses /GS." I think Tavis does good work but the interpretation of his work is often hysterical. Finding an issue with AV doesn't invalidate the concept of AV. AV is just software. Bugs get found and patched like any other software. I think accepting that isn't asking too much here. Defect-free software is so far humanly impossible for non-trivial applications, let alone for complex security applications. Heck, how many security defects has the linux kernel and openssl had in the past couple years alone? Dozens, or more, and all have been weaponized and trivially exploited. Yet we still use that stuff.
Grandma's PC, the PC of a random staff person at work, etc without AV is taken down near instantly. With it, she can avoid many of these security issues. The idea that some defects means AV is without value is a fun and popular opinion with techies, but in the real wold, it does far, far more good than harm.
> If AV was so vulnerable, we'd see nothing but exploits in the wild going after AV. Yet we aren't seeing that anywhere.
That's because the Linux kernel, Chrome, Firefox, etc. are installed on hundred of millions or billions of devices. Any given piece of anti-virus is orders of magnitude less popular. Further, the route to exploitation is often more circuitous with AV
Overall, that adds up to significantly less exploitation seen in the wild.
> If you read the notes you'll see scary terms like "buffer overflow" but "probably wont work on windows because windows uses /GS."
That's not true of the one issue which mentions Windows using /GS. For that issue (814), the bug actually says "Exploitation is likely still possible on Windows, but may be more difficult as they do use /GS on that platform."
Of the other eight bugs linked, four in the link were confirmed to allow code exec as NT AUTHORITY\SYSTEM on Windows. One more is "trivially exploitable" and allows reliable control of the instruction pointer but didn't specify as what user the code is running.
and they were patched before they could be properly exploited. Its odd to expect AV to be defect free but to excuse defects in other software. I think we're holding AV up to a quality level that's unrealistic here and also dismissing its everyday benefits for average users.
I think that "Don't run several pieces of years-old third-party software with multiple publicly-known code execution vulnerabilities as root/SYSTEM on possibly malicious input" is a bare minimum requirement to demand of a piece of software whose entire purpose is to analyze untrusted data to prevent malicious code from executing on our machines.
If it's unrealistic to ask that of AV software, then I'm not sure how this works out to be an argument for AV.
The thread gives specific instances where AV has made the situation much worse for browsers, mainly by preventing them from enabling many forms of sandboxing.
- AV: Anti-virus software
- Vess: Security, AV expert, loves AV
- Justin Schuh: Chrome dev (security-related), hates AV
- AV needs deep access to the OS, opening the door for attacks if managed poorly
- Deep OS access is often hacky (due to lack of APIs?), thus potentially unsafe
- Vess and Justin Schuh both have bad manners
Is this about right?
Also, how is AV a (direct) impediment to a shipping a safe browser? It seems to me that a browser should be mostly agnostic toward AV.
Edit: It seems like the problem is that AV tries to penetrate browsers in a similar hacky way as for the OS, resulting in similar issues.
TL;DR: AV tries to help by supervising browsers because they're allegedly not safe enough, but browsers think they're already safe and want AV to gtfo.
Edit 2: Are there any AVs that don't tamper with browsers at all? I've always been using Avast and switching off all browser-related features, but maybe there are better options.