Hacker News Reader

Comment by Bartweiss | Hacker News Reader

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.

View on HN

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

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

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

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.

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

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

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.

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.

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.

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.

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.

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

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.

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?

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

Reply on news.ycombinator.com