Live data from Hacker News

Linux ransomware in the wild

forums.gentoo.org

101–110 of 112 posts

Re: Linux ransomware in the wild

#101

Earlier quoted context omitted.

I always assumed that everyone on HN would be using uMatrix. Strangely it doesn't seem very popular. I don't run JS at all except for very few webpages (think gmail log in page, etc). EDIT: Now that I think about it, I haven't really stressed how good uMatrix is. It really has changed the way I use the internet.

> It really has changed the way I use the internet. I agree so much. I cannot recommend umatrix highly enough. It has put me completely back in control of what sites can and can't do. I block everything by default except for first-party CSS and images (e.g. *.ycombinator.com when I visit news.ycombinator). It's great, and not at all as bothersome as I thought. No more HTML5 pop-ups, deceptive ads, no more auto loadin…

On my laptop, I block all images by default, while I don't on my desktop (like you, I load CSS and images there).

I find myself more and more liking to use my laptop for browsing, which makes me think I could block images by default on my desktop as well and rarely ever notice it anymore.

Re: Linux ransomware in the wild

#102
post #61
post #42

Earlier quoted context omitted.

It will come back as WebAssembly.

What makes you think that? WebAssembly will at least not be single implementation, closed-source, no-maintenance like Flash.

I am betting someone will bother to create a SWF to WebAssembly translator, maybe even Adobe.

Re: Linux ransomware in the wild

#103
post #13

Not trying to blame the user, just trying to understand: why would someone ever run a web browser as root? A text editor to edit system files, ok, but a browser?

Seeing as the user's main problem is their home directory was encrypted, the root doesn't seem like it would make any difference... Better would be easier ways to run browsers (and all applications) inside protected systems of some kind, so even if they are hacked they can't touch anything outside their own cache directory, and creating downloaded files.

You're describing a sandbox. You run the security-vulnerable routine inside a separate process and give this process the most minimal read/write-permissions that the routine can still work with.

Flash itself has been sandboxed inside Firefox's Plugin Container since forever and Firefox is getting a sandbox around tabs as we speak.

But you can break out of sandboxes. By either exploiting a bug in the OS that bypasses process permissions or by finding a hole in the sandbox that allows you to do things.

I imagine, for example, if you want to upload a file, then the tab-process has to talk to the less restricted main-Firefox-process, which has to then open up a file-chooser dialog and give control to the user.

But it could for example be possible to somehow malform this request to the main-Firefox-process, so that the file-chooser crashes and just hands over a random file, before the user has even seen the dialog. (Obviously, I'm not going to come up with an actual security vulnerability on the spot here.)

This kind of vulnerability can't be fixed with a sandbox. You need some way to upload files, for which you'll need filesystem access in some way and to pretty much the entire Home-directory.

Theoretically, you could require the user to copy the file into a separate "Upload"-directory and then only have read-permissions to that directory, but that's hardly user-friendly and would probably end up with some users keeping their entire Home-directory underneath that Upload-directory.

Re: Linux ransomware in the wild

#104

Hadn't thought of it before but it might be an idea to run my browser (Firefox, Kubuntu 17.04) under a separate user that doesn't have access to my main user files. Might be simplest to just create a user through the DE, then "su -c" from my main user to run the browser?

Uploading files would become a chore, as you'd always have to copy them over from your actual Home-directory to that Firefox-user's, but yeah, it would add another thick layer that attackers would have to get through.

Mind that Firefox is also getting sandboxed tabs as we speak, so yet another layer that attackers would have to get through, which wasn't in place at the time of this attack.

Re: Linux ransomware in the wild

#105
post #43

Earlier quoted context omitted.

Firefox has some sandboxing on Linux, though it's quite recent.

It had level 2 content sandboxing from FF54, and level 3 (which has write and read access restrictions) with FF57. https://wiki.mozilla.org/Sandbox#Current_Status https://wiki.mozilla.org/Sandbox#Content_Levels_2

Thanks. The post is more than a few months old, it predates FF 54 (released in July 2017).

Re: Linux ransomware in the wild

#106

Earlier quoted context omitted.

Even better - make sure that everything is under version control or backed up so that in such a situation you can just reinstall from scratch without introducing the possibility of "recovering" infected files.

There’s still the possibility that the infected files have been already committed to version control or backups, before it activated.

great! with version control, you can see line-by-line where that infection was added... and when it was committed. Good!

Re: Linux ransomware in the wild

#107

Hadn't thought of it before but it might be an idea to run my browser (Firefox, Kubuntu 17.04) under a separate user that doesn't have access to my main user files. Might be simplest to just create a user through the DE, then "su -c" from my main user to run the browser?

Out of the box it'll probably tell you "Client is not authorized to connect to server" if you try to run anything X11 as another user. However it should be possible to configure your system such that it doesn't like such: https://wiki.archlinux.org/index.php/xorg#X_clients_started_...

I currently run my kids browsers under my user by doing "xhost +local:; su -l -c /usr/bin/firefox $USERNAME" where USERNAME is the kids login. I may have made changes to enable that, don't recall sorry.

Re: Linux ransomware in the wild

#108

Hadn't thought of it before but it might be an idea to run my browser (Firefox, Kubuntu 17.04) under a separate user that doesn't have access to my main user files. Might be simplest to just create a user through the DE, then "su -c" from my main user to run the browser?

Uploading files would become a chore, as you'd always have to copy them over from your actual Home-directory to that Firefox-user's, but yeah, it would add another thick layer that attackers would have to get through. Mind that Firefox is also getting sandboxed tabs as we speak, so yet another layer that attackers would have to get through, which wasn't in place at the time of this attack.

Can make the user have read access to specified folders on the main user, seems easy enough.

Re: Linux ransomware in the wild

#109
post #71
post #29

Earlier quoted context omitted.

well, when wannacry was around, you could "salvage" the decryption key from an infected machine before it was rebooted. not saying your idea is bad advice but you need the full picture to counter ransomware attacks

Ironically, /dev/mem has been disabled to counter malware, otherwise you could do dd if=/dev/mem of=~/mem.img to obtain an image dump which may contain the decryption key.

You could kexec a new kernel that didn't have that restriction.

Re: Linux ransomware in the wild

#110

Earlier quoted context omitted.

Out of the box it'll probably tell you "Client is not authorized to connect to server" if you try to run anything X11 as another user. However it should be possible to configure your system such that it doesn't like such: https://wiki.archlinux.org/index.php/xorg#X_clients_started_...

I currently run my kids browsers under my user by doing "xhost +local:; su -l -c /usr/bin/firefox $USERNAME" where USERNAME is the kids login. I may have made changes to enable that, don't recall sorry.

An extra layer of protection may be offered by using the likes of xpra.

https://xpra.org/

Post reply on HN