“AV is my single biggest impediment to shipping a secure browser.”
twitter.com
twitter.com
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.
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.
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.
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.
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.
Examples?
> 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.
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.
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.
bug bounties
- increasing code that runs with elevated privileges in a system
- running untested, buggy parsing code with elevated privileges in the system
- inject ROP gadgets in every process in the system
- isolating your code's components to contain the risk of vulnerabilities in your own code
So to get past that premise, you have to remove the "broken" part before the method of injection matters.
https://googleprojectzero.blogspot.com/2016/06/how-to-compro...
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.
The browser does this, the AV does not, so yeah, no AV devs seems to know about security.
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.
A deep hook API would be wonderful for spyware.
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.)
But I'm commenting to ask you to expand on
> "There are a handful of AV contenders for that."
Could you be pleaded to drop some names?
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.
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).
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.
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.
https://movietvtechgeeks.com/microsoft-antivirus-cant-defend...
Basically as a evolution of MinWin, there is now a micro-kernel for security critical code sandboxed via HyperV.
"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.
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.
It wasn't just IE though, Netscape had plenty of points to exploit.
- 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.
Justin Schuh is the Chrome browser security tech lead*
https://news.ycombinator.com/item?id=6166731
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."
https://twitter.com/aprilmpls/status/804361653420691456
=====
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.
https://twitter.com/taviso/status/803714407763062784
https://twitter.com/VessOnSecurity/status/804298404763463680
=====
OK, I think this is the original Twitter thread:
https://twitter.com/taviso/status/799747942441586688
Some intermediary followup:
I see the attack surface tweet, but where are the vulnerabilities he found?
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.
These AV products patch our binaries all over the place such that changing any browser internals that happen to be targeted by AV will cause crashes.
Perhaps clearly communicating this fact to users and updating your software as you see fit will swing the needle in your favor.
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."
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.
It's a shitty situation all around.
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...
> 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?
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.
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.
(I used to work in security)
"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?
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.
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))
"Skype for Business" is the successor for Lync, at least in our org. I haven't heard of Communicator before, though.
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(
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.
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.
That is the way on mainframes for a long time, exists on iOS, Android and Windows Phone, is being pushed on macOS and Windows.
I don't want apps reading all over my HD.
Doesn't sound like much of a downside to me.
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.
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.
> its very rare to see an AV compromised
https://twitter.com/taviso/status/732365178872856577 https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...
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.
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.
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.
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.
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?
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.
Is it availble as a setting , for those of us without AV ?
[0]: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...
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.
I believe it's not as easy on Windows for a process to protect itself against DLL injection.
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.
So thanks for forcing me to update myself.
That's not a poor man's solution. That's how Valgrind's leak checker works (AFAIK).
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...
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.
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.
* http://scarybeastsecurity.blogspot.co.uk/2016/11/0day-exploi... (https://news.ycombinator.com/item?id=12951503)
> 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]
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.
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.
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.
-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
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.
AV will not save you from a determined attacker. It's a vaccination, not a magical cure.
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.
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.
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.
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.
Tavis Ormandy: "Kinda like how a lightbulb that sets things on fire is still high quality, so long as you only measure lumens?"
Vess: "It's certainly of better quality than a lightbulb that doesn't light the room at all."
I think I know which lightbulb I would prefer.
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.
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.
[1] - https://bugs.chromium.org/p/project-zero/issues/detail?id=82...
[2] - https://googleprojectzero.blogspot.com/2016/06/a-year-of-win...
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.
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.
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.
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.
"You misunderstand your own ignorance".I can't imagine saying something like "You misunderstand your own ignorance" to someone at say, an industry conference.
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.
Exactly. It was not even a debate --- it's downright refusal.
Check out issues reported by taviso on Google Zero: https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...
Examples: https://bugs.chromium.org/p/project-zero/issues/detail?id=67... or https://bugs.chromium.org/p/project-zero/issues/detail?id=77... or https://bugs.chromium.org/p/project-zero/issues/detail?id=70...
Nor, for that matter, is silently disabling other, better security products, which seems to be standard practice these days.
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.
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.
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.
If you're really concerned, whitelist.
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.
So many years joking about Windows users to nowadays suggest this as way to install software.
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.
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.
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.
Defender because it's pretty much built-in so there's little reason not to. Before defender, none.
> Do you run AV on Linux and Mac in the background
Nooooope.
I'm entirely on windows by the way, same with family, friends generally.
List of them was in this old comment:
https://news.ycombinator.com/item?id=9962444
Note: Illinois Browser Operating System (IBOS) and OP2 definitely worth looking up.
AV software nowadays is as hostile as the threats they are supposed to be preventing.
https://news.ycombinator.com/newpoll
HN has quite a few not-so-discoverable features:
Perhaps it's possible to build an OS that runs apps in a more 'sandboxed' fashion, with clean, secure APIs to the OS?
Like iOS/Android, but without the business restrictions of App Store?
Apps installed on Mac or Win can pretty much do anything they please.
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?
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.
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)
But Mac/Win are 99% of consumer desktops, so it's up to them to make the change.
All I can do is get some popcorn and dream of knowing who's right.
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.
If you want to not be infected don't use windows or other systems with prolific AV vendors.
It used to be great but I think the last stats I saw showed it at about 50% success rate. ESET is excellent.
This is not a "the truth must be somewhere in the middle both sides are super great" narrative.
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.
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.
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.
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.
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.
Who could possibly find such an argument convincing?
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.