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.

Also, most software doesn't declare that it's making your system more secure.

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.

    bug bounties

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.

https://lolware.net/2012/12/12/uvscan.html

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.

> For most people, yes it does.

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.

No, you're wrong, and like Vess, you're deflecting the issue. Lack of hooks into anything in the system is completely orthogonal to:

- 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

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:

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.

I think the premise is that broken AV doing nothing would be better than broken AV injecting itself into the browser.

So to get past that premise, you have to remove the "broken" part before the method of injection matters.

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."

Could you be pleaded to drop some names?

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.

A deep hook API would be wonderful for spyware.

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.

I retract; you aren't deflecting the issue, you have no idea what the issue is.

Most software you use doesn't inject shoddy, high-risk code into nearly every running process on your system and the kernel, though.

... and on top of it, most software doesn't claim to make things safer while demonstrably making them worse

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.

> @VessOnSecurity whines about a lack of hooks

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.

AV hasn't been about "blacklist the bad executables" for a long, long time.

This is an interesting point. Could AV become obsolete in the future, provided the security of OSes becomes good enough?

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.

> not only they can be bypassed almost trivially,

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.

MS seems to think so, they have been pushing their own security product in Win8+

https://movietvtechgeeks.com/microsoft-antivirus-cant-defend...

Since XP / Vista, actually. Windows 8 is when they integrated Microsoft Security Essentials into Windows Defender as a full OS component.

https://en.wikipedia.org/wiki/Microsoft_Security_Essentials

Also on Win 10 Anniversary onwards they are pushing more sandboxing in form of device guard and secure kernel.

Basically as a evolution of MinWin, there is now a micro-kernel for security critical code sandboxed via HyperV.

AV is already obsolete as far as I can tell.

AV was obsolete 15 years ago at least.

iOS does reasonably well

> through their inaction

"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.

Yea, that is what Vess worked on back in the late 1990s, dating back to the WordBasic days.

I think tax filing software are a similar story.