Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think the interesting thing here is the shift from the target - the "best" target used to be compromising the OS, so OS's made moves to protect themselves from programs running as unprivileged users. Now, it's trivial to wipe an OS and restore from a backup. The real value is the things people store on a computer, which are usually going to be accessible via a user account.

One trivial solution would be OS level automatic versioning of files (ala Dropbox or Sparkleshare) - the original files would be written to location that is read only to the user and only accessible via the OS, hence, backups could always be restored from it, but never destroyed without admin rights.

Of course, with people having great internet and whatnot, an automatic cloud based solution would be much more likely and useful.

I think with Windows 8.1 and onwards, Microsoft are automatically doing this by setting up the "Documents" type folders in SkyDrive - a great think moving forward.

Backups are, obviously, a much better solution but require extra storage and usually cost money.

So there might be a niche for a freeware product that runs as an admin that automatically versions files - perhaps even as simple as having an admin-owned .git repo for the Documents folder.

The worrying thing about this attack is that targeting user data is trivial on all OSs, because of the way we think about privileges - it could be done to us Linux users through something nasty in our shell rc using GPG or whatever. There is no need to compromise anything.



I think the interesting thing here is the shift from the target - the "best" target used to be compromising the OS, so OS's made moves to protect themselves from programs running as unprivileged users. Now, it's trivial to wipe an OS and restore from a backup. The real value is the things people store on a computer, which are usually going to be accessible via a user account.

You make an excellent point, but there is a second and perhaps even more sinister side to it. Encrypting your data and holding it hostage is one thing, but even if you have indestructible backups, there are probably still many sensitive pieces of information that can be acquired by a blackmailer with only user-level privileges: bank details, company trade secrets, personal mail/photos/videos, etc.

Having a back-up of these is important, but probably so is ensuring that they aren't distributed to people they shouldn't be. This requires a very different model of access control and user/application privileges, and unfortunately I don't think any mainstream OS is even close to solving this one yet.


> This requires a very different model of access control and user/application privileges, and unfortunately I don't think any mainstream OS is even close to solving this one yet.

I'm not sure it does require a different model of access control. It just requires people to actually use the access control mechanisms that exist already.

You should not access banking details or any other sensitive information in the same user-level context as you use to generally browse the internet. The privileges needed for each task ("browse the internet" vs. "check bank statements") should be different. I personally have a separate user account on my machine set up specifically for "sensitive" tasks.

Separation of data access via privileges is nothing revolutionary, nor is it something that can't be done on any modern OS. Unfortunately, online services are still behind. For example, I would probably switch to an online banking provider that let me create one account for viewing balances and another for transferring cash. But these services will get there in time.

User education is a different story.


Your proposal is OK if accessing sensitive information is something you only do occasionally, but it's not very practical to switch users completely if you deal with sensitive information often, which many people do.

On the other hand, if only explicitly authorised applications can create outbound Internet connections at all, and if applications like browsers and e-mail clients need explicit permission to read a general user file (as opposed to, say, accessing their own designated configuration or data files), then you significantly decrease the degree of vulnerability a user has to data leakage attacks (among other types).


Check out qubes os if you don't want to trust your kernel to enforce your mandatory access controls (you DO only allow certain applications/users/groups/roles/OS's/Hypervisors/etc... to do certain things, DON'T YOU??). Xen is a smaller attack surface, and depending on how much of a pain in the ass you consider having all of your files stolen and deleted being, there are many options for locking it down quite a lot. XSM-Flask if you are too paranoid, Hypersafe for control flow attacks + invariant violation detection tools for non-control data attacks over nested hypervisors if you are resolute.


>Your proposal is OK if accessing sensitive information is something you only do occasionally, but it's not very practical to switch users completely if you deal with sensitive information often, which many people do.

    $ sudo -u banking gnucash &
    $ firefox &
Done. My banking files and my Firefox session are now separated.


Interestingly, you may have just fucked yourself, because the sudo session is maintained whilst launching Firefox.

If we create a script 1:

   #!/bin/sh
   echo "I'm doing something secure"
And then script 2:

   #!/bin/sh
   echo "I'm doing something insecure".
   sudo echo "I'm doing something malicious".
Then run:

  $ sudo ./script1.sh; ./script2.sh

Looks like Firefox has access to your banking user :)


Not if sudo is set to only allow gnucash! :-)


And for the 99.7% of users in the real world who drive their computers using a GUI and not a command line? Or those who do use a command line but aren't sufficiently competent with system administration to reliably get sudo-based access control right every time?


What about photos? I could see ransomware being very successful just demanding payment to avoid making a bunch of your personal photos publicly available on the internet. They may not be sensitive per se, but they're still likely not something you want out there publicly. Ditto for email, chat messages, etc., etc.


Well actually, looks like we're getting there.

The problem is seemingly solved by OS X app sandbox and Mac App Store review process (the sandbox alone is not enough, because it allows to declare 'exceptions' like full disk access, so human reviewers are needed to watch out for those).

The sandbox may occasionally be causing some pain (in fact, would be very painful if I had to support OS X 10.7), but at the same time my app can no longer access any user data that the user hasn't explicitly whitelisted, which is a good thing.

Windows Metro apps also live in a sandbox, but they are sort of a different platform (no access to the file system at all, as far as I know). Over time, I can see them gaining some access to a subset of the file system, perhaps via SkyDrive.


> Backups are, obviously, a much better solution but require extra storage and usually cost money.

And the virus will encrypt anything writable, so the backup needs to be "pull", if the infected machine is the one doing backups and has write access to a non-cold-storage backup location it will may encrypt the backup itself.


Solved this problem at my startup Nuevo Cloud.. the filesystem is copy-on-write, including deletions.. In the settings you can control how long to keep the copy-on-write log, and then you can jump to any second within the log.

So even if this virus encrypted your backup on Nuevo Cloud, you can just pull up the snapshot from a second before the infection, and restore your files.


I do something similar. I keep all my files on an external HD drive. Only thing on my pc are the programs I need.

My impending move to Tails OS is also timely considering this new virus. We just spent two days dealing with this after an exec launched one of these and encrypted a bunch of files on one of our servers. This, after two emails warning about it.


Yup, this is basically what I was thinking - the daemon would run as a system user (e.g. root or something that could access user files) would "commit" the changes on write, pulling from the user's files, creating a read-only copy.

Obviously there are of course issues running stuff like this as root - if the daemon was compromised in any way it's game over.


[deleted]


Yes, the service doesn't have a 'space limit' setting.. So it's essentially infinite storage. It is deduplicated, so there is some savings there.. And the log only saves your changes.. So the space used would be 100% + % changed during period - % duplicated

We are working on a 'space limit' setting (should be finished shortly).. But if that were enabled, and you exceeded it, you would just get a write error when new data is written.. It wouldn't delete the log.. So if that setting were finished, an you got this virus, the virus might get a write error halfway through.. But your old versions would still be safe.


The only virus I ever got was the SevenDust 666 virus on Mac OS 8. An infected machine would have a "666" extension that couldn't be deleted (it would instantly replace itself) and then start losing files. So losing files as a target has been around for many years.

The interesting change to me is that now viruses have been effectively monetized.


Not such a new change, for it's been known since at least 1989: https://en.wikipedia.org/wiki/AIDS_(trojan_horse)


So in other words, nothing ever changes, everything has always been terrible.


> the original files would be written to location that is read only to the user and only accessible via the OS

A versioning filesystem looks much cleaner than a different location. Maybe we should start using those again. (Is there any candidate for ext5 already?)

And yes, partitioning the data permissions for the same user is a much needed change. Nobody got a solution for that yet, and there are lots of people trying. Apple, for example, is just giving up on iOS; Google has a subpar solution on Android that does not actually work on practice (the cyanomod people did improved it a bit) but is the closest we have from something viable.


Yep, if this could exist at file-system level it would be wonderful. What candidates actually exist for this and are in a usable state? BTRFS? ZFS?


Been using NILFS2 for 3 years now. Works great, performance is decent. It lacks extended attributes and ACLs, but the automatic snaptshot part is worth it.


This opened my eyes, thanks. I'll see how to set up backups that I can create but not delete.


BackupPC[1] does this by using pull technique to backup your data.

[1]: http://backuppc.sourceforge.net/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: