I'm leaning towards the browser vendors on this one, AV software has been sloppy and has been known to enlarge the attack surface area. Here's an example from earlier this year.
@VessOnSecurity whines about a lack of hooks for AV to hang on in Google Chrome, but kind of laughs at the hooks that Microsoft Office offers (we didn't need them anyway, we read before Office opens the file, etc.) That cavalier attitude makes me uncomfortable.
It also seemed pretty dubious that Vess kept hammering the "insecure because we lack hooks" point, while skipping the repeatedly-raised issue that AV itself is usually full of shoddy, high-risk code. A couple of the most-used AV products are infamous for not just using dirty access, but being so poorly-executed that the AV is what enables escalation in the first place.
Most of the software you use is complete and utter shit full of shoddy, high-risk code. Do we need to bring that up every time when we are talking about something specific?
The lack of hooks into the browser is brought up because without them AV has to do these weird things to scan the content browsers are happily loading from untrusted sources. If you use an AV product that scans network activities that is.
> Most of the software you use is complete and utter shit full of shoddy, high-risk code. Do we need to bring that up every time when we are talking about something specific?
Most software doesn't run with full system privileges, go out of its way to interact with malicious content, and inject itself all over the system. The difference between AV and any other shitty software is that AV is massively more useful and abundant as attack surface.
The hooks into the browser are nothing. It isn't the hooking, though that's not great. Imagine Chrome provided an API. OK, so now the AV listens to the API. It sees you open some file in the browser that's XML - it parses the XML. It gets exploited, trivially, because many vendors explicitly disable security features like stack cookies. Now the attacker went from a sandboxed environment to a full system privileges process.
So because of a future possibility of exploit, don't do anything which is one cause of the existing argument.
I suggest you uninstall Chrome if that is your view, it too will lead to a full system compromise in the future, I mean it will in the future yet again.
> Most software doesn't run with full system privileges
For most people, yes it does.
> go out of its way to interact with malicious content
Your browser also does.
> difference between AV and any other shitty software is that AV is massively more useful and abundant as attack surface.
The browser pretty much wins here too.
But no, it's AV vendors fault your browser is such a risk.
> I suggest you uninstall Chrome if that is your view, it too will lead to a full system compromise in the future, I mean it will in the future yet again.
Chrome developers take active measures (sandboxing, research, patching, bug bounties) to secure their browser. They have done amazing work and really, in my mind, pushed some solid technology that we've all benefited from (seccomp, as an example).
AV has gone out of its way to disable modern security technologies like ASLR/Stack Cookies.
There is no comparison here in terms of effort to avoid exploitation. As Justin said - find me a single AV that sandboxes its parsers.
> For most people, yes it does.
Even if this were true, and it is not, Chrome doesn't - it runs in a sandbox. Therefor a compromise of an AV is not just a jump to Admin but a jump out of the sandbox.
> The browser pretty much wins here too.
Not really. The majority of attack surface in a browser like Chrome is isolated and hardened. Web browsers avoid malicious content where possible. AV goes out of its way to interact with malicious content.
> But no, it's AV vendors fault your browser is such a risk.
It's AV vendors fault that they avoid writing secure software. And, yeah actually, it is AV vendors fault that the browser is vulnerable when the browser takes every step to stay secure and AV vendors shit all over that.
How about just responding to reports? I've re-reported this to McAfee every year and originally blogged it on a much earlier version something like 2005.
So many responses here, but mostly: "Most software doesn't run with full system privileges", "For most people, yes it does."
That's not even a little true. Even inexperienced Windows users have to click that little "permission to make changes" button, and sometimes "run as administrator". Winamp, Solitaire, and all your other random not-totally-secure programs don't offer kernel access to whoever compromises them. AV is a singularly good source of privilege escalation attacks for exactly that reason.
> I suggest you uninstall Chrome if that is your view, it too will lead to a full system compromise in the future, I mean it will in the future yet again.
> The browser pretty much wins here too.
Chrome is tightly sandboxed; any exploit in Chrome is very unlikely to compromise your OS.
AV has to do what it does to inject itself between the internet and the browser because the browser provides no better way to work with it. If there was a better way and AV continued to do these things, complaining that AV is doing these things would be valid.
Those are separate issues: security experts would worry less about AV software hooking things if the AV developers were demonstrably following secure coding practices. Instead, they're generally shipping 90s-style C code and not following good practice like using sandboxing or other defense in depth measures, which is how you get things like a single exploit in a format decoder granting kernel access:
Contrast with the kind of exploit chains usually required on securely-designed systems like iOS or modern apps like Chrome where they need to chain multiple exploits together to escape from the sandbox before being able to attack something else. The AV industry has earned that bad reputation by generally being unwilling to spend the money needed to apply modern practice.
Yep, this is it. AV is fundamentally a security product. If my music player is insecure, it's still playing music and I'll lose that feature by uninstalling it. If my AV is insecure, there's really no downside to uninstalling it.
But to be very clear, the core complaint isn't the injection.
It's that AV - basically all AV - is buggy and insecure in totally unrelated, internal ways. It does shockingly dangerous and irresponsible things like leaving exposed debug frameworks on a program with kernel access.
So my concern about AV's browser injection isn't "they should interface better". It's "this is shamefully bad and dangerous software that I want to uninstall, so it should stay out of my browser". Fixing that isn't a problem for Chrome devs, it's about making a product safe enough to contemplate interfacing with. (There are a handful of AV contenders for that, and I don't object to them.)
I've hated AV products for decades for being intrusive, cumbersome, slow and often nagware. Thanks to this post, I can now add "insecure" to my list of reasons.
But I'm commenting to ask you to expand on
> "There are a handful of AV contenders for that."
It is the injection preventing code checking. You are missing a majority of the point. Even if it 'worked' it still prevents a more elegant, efficient, and effective process of sandboxing and self checks.
The problem is there isn't a better way. A browser should be fully secure without needing some specific third party tool watching over its shoulder.
But let's say that you come up with some "deep hook" API that could give AV vendors a better way to look over the browser's shoulder. You can't provide the hook API and magically only hand it to trustworthy AV vendors: a "deep hook" API increases the overall API surface of the application and you have to treat it and secure it and maintain it like any other third-party accessible API, including assuming that it could be misused by untrustworthy third-parties.
The AV could do things better even without hooks. I don't know about ALSR, however dropping privileges when scanning a file that the user opened is pretty much a given in a security system.
The browser does this, the AV does not, so yeah, no AV devs seems to know about security.
Yes, this. Most software is crappy, and much if it is insecure, but most of it adds value somewhere.
If my music player compromises my computer, at least it plays music the rest of the time. If my antivirus compromises my computer... well, adding security was its only job. I'm happy to criticize shoddy code when it causes the product to fail at its sole purpose.
I think that "Antivirus" arrived as a bandaid during the decades when security was taken seriously by some consumers but not by the OS/app software vendors. It started out as "inspect the system for signatures of malicious executables" and evolved to include "clever active mechanisms to avoid infection."
I think that there should be no need for the "active mechanisms to avoid infection" part and that is ultimately the responsibility of the OS/app vendors.
Unfortunately, through their inaction, OS/app vendors have allowed an industry to arrive. This industry will be reluctant to forfeit their position. Clearly if they think they're entitled to some consideration in the browser design, they will not go away without a fight.
'Bandaid' is going easy on them - what AV is selling is an antipattern. "Blacklist the bad executables" is so obviously ineffective and ultimately infeasible compared to "whitelist the good executables"
I'm no fan of AV (I think they've totally failed to improve quality for decades, and now live off of fear-mongering) and not an expert but that seems too harsh.
At the time this arrangement was designed, getting any kind of automatic software update was unusual, let alone regular updates or communication back to the update system. It's hard to imagine an AV doing this successfully at the time. What if the user installs a new version of a program and you have no internet connection? Ask them? Do you trust their answer? At the same time, the number of unique new viruses was substantially smaller and slower-spreading so easier to "detect" (it was never clear to me how much "detection" really happened vs pure signature matching).
It's shameful that OS security updates still aren't applied automatically and AV was useful when viruses were simple.
However, AV vendors started pushing heuristics that look for things like contacting IRC servers. Any application that moves large amounts of data around will run into hash collisions and developers have to run around asking to be added to a whitelist.
These heuristics do not scale and mislead consumers into thinking that their computer is safe because it has antivirus. In reality, we need to re-architect operating systems to be safer.
AVs have been obsolete in every way imaginable when it comes to offense. As another comment said, they're less effective than band-aids - not only they can be bypassed almost trivially, they increase attack surface.
Sounds almost crazy but I agree as I saw some 17y.o. students I taught who created a simple, autoupdating undetected .exe trojan in autohotkey in an evening or so.
I haven't installed an antivirus program since Microsoft released their Security Essentials / Windows Defender pairing in Vista. I think we're already there -- it's just taking time to reverse the years of beating the antivirus drum into the common perception.
"Their"... Was there some other vendor worse than Microsoft? It has seemed sane to attempt to avoid infection on every other platform I have used in the last 15 years or so.
Microsoft had the biggest market share, and a near monopoly on unskilled users who don't understand the consequences of their actions. Other operating systems didn't have much better security, but they were less attractive to malware authors.
Now the mobile systems are the mass market thing. AV never took off because the sand boxing and app vetting, while not perfect, is more effective than AV ever was.
Though I must say, Microsoft did create a mess with its office macros and handling of file extensions. For a while they were certainly guilty of offering an environment that made it tough for the layman to know the manner in which something would open.
Well, allowing script to run in email, and insult to injury, running them in "local" (ie full privileges) security zone didn't help... not locking down the filesystem and jet (which has fs access) active-x controls earlier on from browser (and flash, ugh) access were significant.
It wasn't just IE though, Netscape had plenty of points to exploit.
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.
Everything electric in your house can start a fire, yet I imagine you don't live like an Amish person. You make a rational gamble with yourself to allow this tech and deal with extremely rare edge cases because of the greater utility this technology gives you.
Vess's point is that yes you can find defects in AV, but that doesn't invalidate AV the same way finding defects in the linux kernel or openssl doesn't mean we'll stop using linux or ssl.
Also, if you look at some of Tavis's work you'll find scary things like buffer overflows but also disclaimer comments on how tough it would be to actually exploit it due to OS-level protections or other protections. I'm fairly certain we haven't seen any in-the-wild exploits that actually compromise AV. If it was practical to do, it would be the defacto exploit considering you get to take down the gatekeeper and get to run your code at the same time.
I think a lot of people interpret Tavis's work in a hysterical manner and it leads to thinking about tossing out the baby with the bathwater. I also think there's a pretty major disconnect between devs and everyday end user habits. Sure, you can live without AV, probably, but get rid of it wholesales at every Fortune 500 company or in a major city and then tell me how you think things will play out. I imagine not well regardless of how 'more secure' Chrome or Firefox can be made.
I think you may be going too far the other direction, WRT "[you'll] also [find] disclaimer comments on how tough it would be to actually exploit" - there have been several findings that were quite bad even without being properly weaponized. [1][2]
The remark about wholly getting rid of AV is also at least partially disingenuous, since I think most (all?) of those advocating it were suggesting that the built-in protections of Windows Defender/MSE were sufficient for most use cases.
You're distorting the argument. Yes, it's all tradeoffs. Almost all of us would trade less light in a room against a likelihood of our house burning down.
Pretty much the same deal with antivirus.
To fully appreciate what security people are saying about antivirus, you have to understand that contrary to appearances, there is no baby in this bathwater.
I think you're missing the point by looking at the false extreme that Vess offers.
A more realistic example would be a lightbulb that is known to catch fire vs a lightbulb that is dimmer than most. As you know basically everyone has chosen the dimmer lightbulb over the brighter one, except in special scenarios (movie set lighting, etc).
Travis is just arguing that most people don't need the super bright light bulb that's gonna catch fire (buggy and badly audited AV software) because windows defender + {bignamebrowserofyourchoice} will be good enough to satisfy 90% of people.
> I'm fairly certain we haven't seen any in-the-wild exploits that actually compromise AV. If it was practical to do, it would be the defacto exploit considering you get to take down the gatekeeper and get to run your code at the same time.
We have, a number of times and it is practical to do. At least it was on Windows several times in the past.
Some AV vendors have in the past chosen to use such bad practices as hooking the SSDT. This has ended hilariously bad for them when they left their own simple vulnerabilities behind them. Suddenly you have the whole kernel because the AV vendor did something astonishingly amateurish in their code.
AV is also the biggest impediment to shipping a stable browser. I'll be spending some quality time next quarter adding mitigations to Firefox to prevent AV software injecting code into our process.
You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write antivirus software without security holes.
He's not wrong, most traditional AV is complete hacked-up shit. Some of the "Next-Generation" AV(I think they are trying to rebrand this as Endpoint IPS too) like Cylance, CrowdStrike, Webroot are better in that they do a lot less crap on the endpoints to begin with, so there is less to screw up.
It appears there is some history with this Vess character being wrong and particularly obstinate about his position too. So while we all jumped into this conversation without that background, I'm not surprised that these developers are being harsh with him. He seems to have made a long-term habit of ignoring the crux of their argument (which is a super strong argument IMO) and continues to put forth his own ignorant views.
You can’t make a polite argument in 140 characters.
I’ve been myself involved in such twitter fights before, with people with whom I normally talk completely differently, but it’s impossible to be polite on twitter, stay within 140 chars per tweet, and answer within of a few minutes.
Are the AV vendor's code having the same problems that the old version of the file command had that lead to a rewrite on OpenBSD[1]? It seems that way with not doing the fuzzing of inputs comment, or is there a second problem because its the browser?
AV vendors are even worse, they don't just play fast and loose with incoming files they also fuck up other processes in the system, bundle de-secured versions of other software (e.g. Chrome) or enable security holes (remotely accessible local debuggers) by default.
In Firefox, we've had a number of security issues created by AV. They tend to run as root, patch up our dynamic libraries in-memory, play man-in-the-middle on the network layer, deactivate security updates, rewrite security certificates, block entire processes at every disk access, ....
Some of these practices might make sense if they had the resources to actually follow the update trains (in my experience, they don't, so Bad Consequences ensue). Some, I suspect, are due to them working in secrecy out of fear from other AV vendors – so much secrecy that we actually don't know what kind of APIs they need for their code to work more cleanly. Some suggest that they simply don't care about killing the performance of the entire browser. And I have seen at least one bug that showed a complete misunderstanding of how SSL works.
I hear that the situation is improving. But for the moment, I'm not a big fan of reading crash reports and cleaning up after messes left by AV software.
Yep. I got the feeling that Vess was hammering the browser hooks issue because it's the only one where blame can be shared outside of the AV vendor. Handing out privilege escalation and sandbox escape from your own crappy code isn't something that can be blamed on a shortage of external support.
Nor, for that matter, is silently disabling other, better security products, which seems to be standard practice these days.
Well, some people fuzzed file intensively (I was one of them). I won't claim it's bug-free, but I'd say it's probably pretty hard to find a memory corruption vuln in file these days.
Nothing like that happened for most AV software (with probably the exception of clamav).
But yeah, the situation is similar: Whenever you have a C software that parses lots of complex binary formats you have lots of potential for memory corruption.
A little bit off topic. Which AV do you use on Windows? Do you run AV on Linux and Mac in the background, just like most people run on Windows?
There is relatively less malware which target Mac or Linux. So it generally doesn't affect them so often as it happens on Windows. But if any of you can recommend a good lightweight AV for Mac and Linux, it will be great.
I don't. Haven't for, I don't know, 15 years? Before that I tended to do passive scans a few times a year, and I never had any viruses so I don't even bother now.
Here's a secret: You don't need AV on Windows if you're remotely tech savvy, and it doesn't mean you need to be paranoid about what you download either, only use some common sense.
The AV's I've come in contact with (friends, family, work) are worse than the viruses they purport to defend against anyway. Just the other day the IT department installed some undisableable Webroot extension in Chrome that injects some godawful green checkmarks throughout Google Search's HTML. That's a virus to me.
webroot is quite decent but I definitely don't enable the browser extensions, at best they just slow down browsing, at worst...eh. It also does another "funny" thing, basically whenever it meets a process it does not like, it starts dumping hundreds of MBs of data into its ProgramData folder, and I wonder, how are you gonna upload all that stuff with my 0.5Mbps tx speed ? :)
Windows 10 with an user account, and Hyper-V sandboxing.
For UNIX, always keep everything updated, run whatever sandboxing stack it is supported e.g. SELinux, AppArmor, ... with all knobs turned on, and most importantly never ever allow strange code to access your $HOME.
What use would an AV package for macOS or Linux be? The number of hostile programs for that is so short you could write it out on a napkin, and many of those have been addressed at the operating system level.
There's malware detection built into macOS, though most wouldn't realize it since almost nobody ever encounters this stuff. https://support.apple.com/en-ca/HT202234 You have to go out of your way to find, download, and force-install this.
Likewise, I'm not even sure there's actual viable Linux malware in the wild.
The biggest threats you have on Linux are with SQL injection vulnerabilities or WordPress-type installs that have bugs that allow arbitrary execution of code. No AV package will ever help you there.
Yeah, that's a terrible habit to get into and there really should be a better way of doing that.
Technically it's no different than downloading and running an unsigned installer, you're just executing arbitrary code anyway. I think the concern is these are a lot easier to intercept and hijack.
Maybe lobbying people to produce a first-class installer that's code-signed would help, but I'm not sure the open-source world wants that to become common.
I stopped using 3rd party AV ~10 years ago personally. For family and friends I used to recommend Kaspersky because it usually scores highly on tests, but now as I spend more time looking into the industry I think I'll just tell them to stick with defender and ublock, and I'll remote in whenever they install a virus.
I'm entirely on windows by the way, same with family, friends generally.
He's right about AV code being shit. He's wrong on that being biggest impediment to shipping secure browsers. CompSci already created numerous secure browsers. Chrome architecture was even a performance, not security, enhancing modification of OP Secure Browser. The problem holding back secure browsers is none of the browser companies are using the proven techniques despite a number integrating with existing code. ;)
People who think AV is good or even necessary are delusional. Never has there been software that was worse than the AVs I came in contact with. They pose more of a stability problem than malicious programs themselves.
We can call it "qubes" or "systemd with cgroups + other features" or "nixos" or "GuixSD"
Or OpenBSD with its pledge stuff and jail awesomeness
Or fedora with SELinux and default policies.
Believe me, distros are trying to do this, and honestly they're doing a pretty okay job. The kernel could help a bit more (and is starting to with namespacing)
Apple has become more restrictive about this. Out of the box, apps from unidentified developers are not allowed to run. The user has to explicitly allow them. (For macOS Sierra it has become even more cumbersome to run these: http://apple.stackexchange.com/questions/243687/allow-applic...)
I think it should work good for non-IT users. But for developers who depend on a lot of FOSS, this creates a problem. Does anybody know if Apple allows OSS developers to have free accounts on Mac Appstore?
" Out of the box, apps from unidentified developers are not allowed to run. The user has to explicitly allow them. "
I understand this, but this is an extremely low barrier - especially if the user actually wants to run the dam software they just installed, they have to 'allow it to run'.
Who's going to install software and then 'not allow it to run'?
I don't think this security feature has much effect at all.
You're making the mistake a lot of people make where you assume if one side is a thing a competing thing must be equally valid. These aren't two people that are equally well respected or with equal track records. One of them has years of experience developing secure software, the other has years of experience hacking on bullshit snake oil for the purpose of selling it to users.
This is not a "the truth must be somewhere in the middle both sides are super great" narrative.
Nope, I was just saying that I don't have anywhere near the level of knowledge to say which of either them is more right than the other. I just find it fascinating when two people who are good at what they do have a debate.
> You're making the mistake a lot of people make where you assume if one side is a thing a competing thing must be equally valid.
I am rather a "if there are two different opinions at least one side must be wrong" kind of guy and cannot even imagine how one might come up with a "the truth must be somewhere in the middle". If this were true, it would simply mean that both sides were wrong from beginning on.
There are degrees of wrongness - it's not a black-and-white thing. Suppose two people are arguing over what causes robberies in downtown Chicago: person A blames drug use, while person B thinks it's poverty. The actual truth is some sort of mix of both, along with other factors not mentioned.
> One of them has years of experience developing secure software, the other has years of experience hacking on bullshit snake oil for the purpose of selling it to users.
Google has done more to shit up the web than any other entity ever. Now I know tons of people are going to say "but Google provides fast DNS, they provide free CDN services, they provide analytics for website owners, etc." Sure they do all that, but it's because every one of those things gives them the ability to track users all over the internet.
And as long as Google is not going to take responsibility for their programs (the explicit warranty disclaimers in their EULA), anything they say about "shipping a secure browser" is bullshit. Ultimately the warranty disclaimer tells us that they don't believe that their product is secure or reliable.
>Justin Schuh is not the same as Google (even though he works there)
Does Justin Schuh write and ship a web browser that isn't Chrome?
> privacy is not the same as security.
If someone says "Here's my program, it's great, it's shiny, it's awesome, it's wonderful, it'll cure acne, and feed teh poor. But then tells me that if it does none of those things, it's not their problem." Then I'm not going to believe their blah blah blah as long as they retain their disclaimer.
If Google wants to step up and start writing checks every time a defect in their software causes someone else money, then I'll start listening and trusting their statements.
Justin Schuh is security for Chrome. If you find a software security person anywhere in the industry who believes that users are safer with Safari, Firefox, or Internet Explorer, let me know about them. "Switch to Chrome" is pretty close to the first bit of endpoint advice most security people provide in 2016.
That doesn't make Chrome the best browser or apologize for any of the things Google has done to make the web more proprietary or less reliable. But none of those things are Justin's job: Justin's job is to solve the single hardest problem in software security (securing the world's most complicated inner platform), and by pretty much all accounts anywhere, the Chrome team has done an amazing job of it.
>If you find a software security person anywhere in the industry who believes that users are safer with Safari, Firefox, or Internet Explorer, let me know about them.
This is not the same statement as "shipping a secure browser."
Also doesn't refute the reality that Google still has a disclaimer of warranty in their EULA. As such that is a specific statement that they do not believe their product to be secure.
What a head-explodey argument: for Google's security team to be taken seriously, you require that Google alter their liability posture in a way that no other software company would. The first public company to do this would face shareholder lawsuits.
Who could possibly find such an argument convincing?
> for Google's security team to be taken seriously, you require that Google alter their liability posture
If they seriously believe that they have the ability to ship a secure browser what would it matter? The other question I have is if they have this capability, why haven't they?
Here's what I believe. Google will never ship a modern, full featured, standards compliant, and secure browser. Specifically they will never ship a secure browser.
>Who could possibly find such an argument convincing?
Pretty much the entirety of the rest of trade across the entire world. When was the last time your grocery store was allowed to sell you rotten food liability free? Companies, in fact, routinely are sued and fined for fraud and false claims. Chipotle just got sued for advertising a 300 calorie burrito that wasn't 300 calories. Why should Google (and Google employees) be able to make false claims and then later insist in their EULAs that they don't actually have to abide by.
Having a secure browser doesn't protect you from people thinking that your browser is insecure and blaming you for unrelated security failures. Like, have you read /r/talesfromtechsupport or done any user-facing tech support?
Well, I see his point. 3rd Party AV vendors have hacky hooks into the kernel to do what they need to do. And at that point they become kernel-level so they are a juicy target.
Symantec and other AV vendors have had stupid flaws (someone else linked to it in the comments) that allowed remote access and privileged escalation from just knowing the host has a certain AV installed.
All AV seems hacky--except for Microsoft's own, which is what I use and suggest all my friends use rather than shelling out for those subpar products.
Case in point: After years of fruitlessly asking AV companies to stop injecting shoddy patches into their kernel, Microsoft eventually gave up and added active countermeasures which deliberately trigger a kernel panic if certain structures are tampered with. That gave AV vendors the "encouragement" required to move to the sanctioned APIs.
even ignoring the attack surface, the tools seem to always cause the same kinds of system performance degradation that actual malware does. I'd rather be occasionally hacked!
https://securityintelligence.com/news/bad-medicine-symantec-...
@VessOnSecurity whines about a lack of hooks for AV to hang on in Google Chrome, but kind of laughs at the hooks that Microsoft Office offers (we didn't need them anyway, we read before Office opens the file, etc.) That cavalier attitude makes me uncomfortable.