Hacker News Reader

Comment by diebir | Hacker News Reader

This is a good illustration of why you should not install apps as administrator. Specifically, you should not install Mac OS packages, which allow for arbitrary pre- and post- install scripts to be executed as root.

Same is true for Windows and Linux.

There are privilege escalation bugs in any OS, but it is usually not a given. Throw the application into ~/Applications as a Mac bundle, worst that will happen is your account will be compromised. Much easier to detect and clean. Most trojans won't even succeed.

We are going to have these problems until the developer community realizes that executing a randomly downloaded package installer as a privileged user is giving away the keys to the kingdom.

Application stores is one solution, but really is not an open one. I'd rather see the apps distributed in a form similar to Apple app bundles, where a non-privileged user can just install the app into their home.

View on HN

I think it's a poor illustration. You could install and run this app as a regular user (and never escalate to administrator) and the app's bundled malware would still absolutely destroy anything of value on your computer.

It's the stuff inside $HOME (and $HOME/Documents) that's valuable. Not system binaries in {/bin,/sbin,/Applications} that can be re-downloaded in a second.

The problem is that any non-sandboxed app runs with the same uid and full read/write permissions to all of $HOME as well as all the other running processes, even if it only needs read/write access to $HOME/Documents/Appname/ and none of the other pids.

First, obviously you can make an account for running the untrusted software, like Bittorrent clients (which are known to carry malware frequently).

Second, most malware requires and counts on having admin privileges on target machine. The task of auditing, cleaning and finding out that malware is present is significantly easier if malware is limited to a non-privileged account. With malware running as a non-privileged user you still have to clean up and recover, but you can easily switch an account, compare, audit and trace. The anti-malware tools also still have a chance when OS is not compromised, otherwise it's all lost the moment you ran a malicious post-install script.

The more common problem, however, is a regular app install. The goal of the application packager is to make their application work first, and preserve your environment second. So, in many cases even not malware does bad things to your OS. The scripts are usually written by devs that are fairly clueless, which leads to some pretty awful stuff in them. Almost 100% of the time the install/uninstall action is not idempotent, although it should be.

What really needs to happen is a shift in a mentality that accepts the idea that apps need to be installed as an administrator (unless the apps are a part of the main OS distro).

His comment went right past you. What you care about the most on your computer is your personal data, and all of it sits under $HOME. Any script running as $USER can steal sensitive data, wipe out personal and work files, maybe even cloud storage services. None of that requires admin rights.

The only solution is sandboxing everything.

For things that are likely to carry malware, use a separate account. Probably a good idea for a Bittorent client in any case.

In practice, however, it is much easier to deal with malware if there's no admin rights. It matters even for a clueless user, since the OS mechanisms of detection can't be altered and more much so for a power user.

This specific malware installs a kernel module, as far I can tell. I am guessing it would be harder to encrypt data and not be noticed and removed quickly.

Of course, there are even more obvious reasons, like sharing a computer with... kids that tend to bring malware at every turn.

We really need to educate the devs and change the culture. There's no reason for something like a word processor and file sharing app to require full access to the system. That's why we have access controls in the first place.

> most malware requires and counts on having admin privileges on target machine.

If you really believe this, run rm -rf ~ on your computer right now. Also rm -rf /Volumes/* (on OS X) or wherever your network/external drives are mounted on your OS. Since you don't have admin privileges, nothing bad happened right? Because that is the primary goal of ransomware.

Anyway, this specific malware doesn't even attempt to acquire root; it operates entirely as your local user. And there's no installer package, so why are you complaining about them?

> Throw the application into ~/Applications as a Mac bundle, worst that will happen is your account will be compromised.

On a typical single-user setup, there's not much difference between an account compromise and a machine compromise anyway.

That is only true if you have no interest in recovery post compromise. A user level account shouldn't be able to put the system in such a state that online recovery is impossible, whereas a system level account easily can - think loadable kernel modules. Only offline recovery works once you lose trust in the kernel. That is the difference between "Alright grandma, lemme remote in" and "Sorry old lady, better start looking for the factory install CDs". Lets not even get into how screwed we are with UEFI...

If you have to wipe the user account anyway, then wiping the system at the same time hardly adds any more effort -- in fact it's probably easier. Your system files are the easiest part of your system to recover, because the originals are readily accessible from the vendor.

I guess it depends. In the grandma scenario it adds a lot more effort. A corporate laptop in a standard AD environment, no problem. In a situation where you've customized the system (custom packages, sshd.conf tuning, flags in rc/csh/sysctl/resolv/loader/randomsbinutilityinstalled2yearsago.conf) it would be a lot more work than just reinstalling the OS. Use backups you say? What if I told you that you could use the very same backups to rollback changes to the user's home directory, in 5 minutes, and not have to reimage the entire machine? I'm just saying: even on a single user setup - there is a world of difference in what options you have open to you, depending upon whether you let the malware hit ring 0 or not.

Not sure why anyone with a compromised machine would rather have the risk of a lingering backdoor just to save 1-2 hours clean formatting and reinstalling

Me neither, but there's a whole industry of software for Windows users that promises to remove malware.

Because unless an unknown method of privilege elevation was used, it doesn't make sense. Do you throw a pinch of table salt over your shoulder as well? It also has a very strong Microsoft smell to it, where instead of doing root cause analysis on why Windows is misbehaving - you just reboot and cross your fingers.

> Because unless an unknown method of privilege elevation was used

You seem to think that is unlikely. Why? New privesc bugs are found on a monthly basis in Linux and Windows. Does Grandma stay on top of kernel patches?

Nobody who does sandbox security (hint: I do sandbox security) thinks UID separation is sufficient to cordon malware anymore.

> You seem to think that is unlikely. Why?

Because of the single user pc context. I've never seen a dropper that didn't have ring 0 later pull down a payload that escalated privilege. I'm not saying that it isn't possible, but at best it is very uncommon. I understand the better safe than sorry position, but with the context in mind, what safety are you getting by just assuming UID separation failed and going through the rigmarole of reinstallation? The user data has already been exposed.

I just don't agree with the simplified decision tree of "Infected --> reinstall", which disregards your work in sandboxing. Why should I even bother with the additional complexity of capability mode in my software, if we're all just assuming our defense has no depth.

> I've never seen a dropper that didn't have ring 0 later pull down a payload that escalated privilege.

Probably because it isn't very useful to the attacker. Pwning the single user's account is sufficient. But I wouldn't bet on that being the case if it happened to me.

> what safety are you getting by just assuming UID separation failed and going through the rigmarole of reinstallation? The user data has already been exposed.

Most user data is not executable, so can probably safely be copied over. But if you don't wipe all executable software on the system it's hard to tell if some of it is still infected.

> Why should I even bother with the additional complexity of capability mode in my software, if we're all just assuming our defense has no depth.

Well, I'm talking about today's legacy desktop (and, to some extent, server) OSs, which have not prioritized user isolation because it hasn't really mattered ever since people stopped using timeshare systems.

Modern OSs that sandbox applications (e.g. ChromeOS, Android, iOS) are another story. I would expect that one Android app being malicious does not mean you have to wipe your phone, just uninstall the app. I would expect that ChromeOS can even recover from a full sandbox breakout, given secure boot.

But I don't trust Linux, Windows, or Mac OS desktops to be suitably hardened nor able to recover. And as wiping the whole system does not add very much cost over the cost of wiping the user account, it seems to me worth it to go all the way.

> Probably because it isn't very useful to the attacker.

Ring 0 is really important for building a botnet, which provides a very real incentive for the folks that actually write the droppers. Ideally (for the botnet owner) they establish persistence, then sell access by directing the bots to download additional malware under the control of botnet customers. Long story short: you don't get paid as much if you don't have ring 0.

> Most user data is not executable...

I was speaking from the perspective of the real purpose behind all this, protecting user data - and that the horse is already out of the barn. As far as cleanup, you are presupposing a loss of ring 0. If ring 0 is secure then killing all the user processes and performing a snapshot rollback of user space will definitely clear the malware.

> Well, I'm talking about today's legacy...

Ah, well then I agree. If your platform does not have user isolation, then you shouldn't rely on user isolation for security.

> And as wiping the whole system does not add very much cost...

Well we've got a catch-22. Because implementing security practices that do harden the system add a lot more cost to a hamfisted wipe. For example: On my laptop I've got five jails, a maze of netgraph nodes that result in a complex ruleset, host IPS, kerberos authentication and authorization, encrypted filesytems, close integration with TPM and various certificate based credentials. Just assuming that none of that works and doing a system wipe is a lot more work than simply popping in the latest Ubuntu dvd iso... consider the labor of rekeying alone.

So the advice to do a system wipe isn't bad, but it should be prefixed with: "If you've made no effort to secure your system and are completely relying upon the distro provider for security".

Sure, if you've set all that up and know what you're doing, then you're in a position to make your own judgment call and maybe you don't need to wipe the system. Earlier we were talking about "grandma" which I assumed was a metaphor for "person who doesn't know computers".

> Earlier we were talking about "grandma"...

Don't forget the grandson part of the metaphor, he is the one who will be making that judgement call. Do you remember how everybody would blow into the Nintendo cartridges, even after Nintendo explained why it was a bad idea? I have a feeling that helpdesk folks will continue to advise a system wipe, even if your running the latest Windows 25 with its formally proven microkernel... just to be safe.

so how do I get around this if most apps I want require this?

1. Petition vendors to stop distributing .pkg's

2. Most packages can be extracted with pkgutil and then just copied into ~/Applications.

It is infrequent that somebody needs to modify your OS and if they do, then they better explain why.

Reply on news.ycombinator.com