6 ms·

LD_PRELOAD isn't a particularly new attack vector... and it is limited to the permissions of the user it is being run as. So it still needs an unpatched privile

LD_PRELOAD isn't a particularly new attack vector... and it is limited to the permissions of the user it is being run as. So it still needs an unpatched privilege excalation to do any real harm

ninkendo 4y ago
> So it still needs an unpatched privilege excalation to do any real harm https://xkcd.com/1200 https://xkcd.com/1200 All the important stuff you’d need to ruin someone’s life only needs their user account anyway, why is it such a relief if someone doesn’t get root access?
- rascul 4y ago
  Yes, but somehow it affects all processes and installs a rootkit. That's going to need more than an unprivileged user account's access to the system. It's not clear from the article how that access is gained. > Instead of being a standalone executable file that is run to infect a machine, it is a shared object (SO) library that is loaded into all running processes using LD_PRELOAD (T1574.006), and parasitically infects the machine. Once it has infected all the running processes, it provides the threat actor with rootkit functionality, the ability to harvest credentials, and remote access capability.
- _abox 4y ago
  Except they can't really do that. The key there is the person's password manager as most of the things mentioned there are online. The user account should just unlock the desktop. My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking). And I don't keep important things logged in. But xkcd in this case also forgets that the reason for the admin accounts being separate is that most of the usual activity running in the user context means that malware runs in that context too. So it has a much harder time to obtain true persistence and undetectability like this exploit does.
  - lvass 4y ago
    >The key there is the person's password manager as most of the things mentioned there are online Are you sure your passwords/session data can't be exfiltrated by other means, e.g. your .mozilla/.chromium? >My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking) Going by KeepassXC docs, the database is encrypted with an HMAC challenge response, changing only on DB save. But if you have the ability to copy the database file and the HMAC response in the same point of time as this malware does, the yubikey part is useless. What password manager are you using?
    - pxc 4y ago
      How would a GPG-based password manager fare here, assuming it's using a Yubikey the same way?
      - lvass 4y ago
        AFAICT, the strength of both TOTP and public key protocols over fixed-response mechanisms depends on actually having two distinct parties, otherwise you're just adding keys that can likely be all exfiltrated by the same threat. I can see the yubikey being more meaningful if you're storing the passwords in a server whose security you trust more than your desktop, but having an infected desktop is still very bad.
    - GekkePrutser 4y ago
      > Going by KeepassXC docs, the database is encrypted with an HMAC challenge response, changing only on DB save. But if you have the ability to copy the database file and the HMAC response in the same point of time as this malware does, the yubikey part is useless. What password manager are you using? I use a GPG-based password manager (pass) so this is not the case. Each password is encrypted individually using the GPG key in the yubikey. I hate keepass (I have to use it at work because they're stupid). I recently wrote a whole essay on why KeePass is so behind the times to our leadership, I hope they will finally go for something that actually has centralised management and auditing. We've seen teams that have used the keepass filename as master password for example and we have no way to prevent this kind of thing. I also use Fido2 where possible which is even better of course. And yes stuff can be exfiltrated but websites such as facebook, dropbox etc are pretty well defended against session cookie theft these days. I'm just saying there is still a very good reason for the admin account to be boxed off, despite the XKCD makes it seem useless.
- Karellen 4y ago
  Because it only ruins the one person's life whose account got hacked. All the other users on the system are unaffected. Also, if it just ruins a user account, you can simply delete that user's $HOME and restore their account from backups. If it elevates to root, you have to reformat the system and reinstall the whole OS from scratch (and hope it didn't patch the BIOS and/or hard disk firmware), and then reinstall all the user accounts from backups. Even if it's a single-user system, the non-root case is a lot less work to fix.
  - 323 4y ago
    What other users? Pretty much all today's systems, either personal or server, are single user.
    - SoftTalker 4y ago
      "Real People" users yes, now that most "systems" are containers or VMs, the number of users that are real people might be one or even often zero. But most linux services run under their own user identities, so even in that case you will likely have several if not dozens of users on a typical server, the idea being that if the "nginx" user is compromised, the "postgres" user is still safe. Also why it was a bad idea to have services running as "root" (or "system") as was more common a decade or two ago.
    - Karellen 4y ago
      Plenty of households have lots of people using their own phone for social media and other consumption, but a shared laptop for times when a phone just isn't enough. Not everyone can afford a laptop per family member.
- elesiuta 4y ago
  And it isn't too difficult for something to elevate itself to root anyways. It could just include a basic key-logger which would work on most systems and wait for your password. Unless you're on Wayland, you can see for yourself by typing `xinput list` and `xinput test <id>` using the id of your keyboard. edit: and another comment linked to a blog post which also explains how this specific malware gains root https://www.intezer.com/blog/research/new-linux-threat-symbiote/ https://www.intezer.com/blog/research/new-linux-threat-symbi...
  - dark-star 4y ago
    Yes, this is the part you mean, right? > This process requires that the SO has the setuid permission flag set. so you don't just have to download a binary file and somehow set LD_PRELOAD for that user, you also have to set the SUID bit on that binary file, which by itself only root can do...

LD_PRELOAD isn't a particularly new attack vector... and it is limited to the permissions of the user it is being run as. So it still needs an unpatched privilege excalation to do any real harm

ninkendo 4y ago

> So it still needs an unpatched privilege excalation to do any real harm https://xkcd.com/1200 https://xkcd.com/1200 All the important stuff you’d need to ruin someone’s life only needs their user account anyway, why is it such a relief if someone doesn’t get root access?

rascul 4y ago
Yes, but somehow it affects all processes and installs a rootkit. That's going to need more than an unprivileged user account's access to the system. It's not clear from the article how that access is gained. > Instead of being a standalone executable file that is run to infect a machine, it is a shared object (SO) library that is loaded into all running processes using LD_PRELOAD (T1574.006), and parasitically infects the machine. Once it has infected all the running processes, it provides the threat actor with rootkit functionality, the ability to harvest credentials, and remote access capability.
_abox 4y ago
Except they can't really do that. The key there is the person's password manager as most of the things mentioned there are online. The user account should just unlock the desktop. My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking). And I don't keep important things logged in. But xkcd in this case also forgets that the reason for the admin accounts being separate is that most of the usual activity running in the user context means that malware runs in that context too. So it has a much harder time to obtain true persistence and undetectability like this exploit does.
- lvass 4y ago
  >The key there is the person's password manager as most of the things mentioned there are online Are you sure your passwords/session data can't be exfiltrated by other means, e.g. your .mozilla/.chromium? >My password manager requires my yubikey to be present, it's pincode to be entered and it to be touched for every use (to avoid remote hijacking) Going by KeepassXC docs, the database is encrypted with an HMAC challenge response, changing only on DB save. But if you have the ability to copy the database file and the HMAC response in the same point of time as this malware does, the yubikey part is useless. What password manager are you using?
  - pxc 4y ago
    How would a GPG-based password manager fare here, assuming it's using a Yubikey the same way?
    - lvass 4y ago
      AFAICT, the strength of both TOTP and public key protocols over fixed-response mechanisms depends on actually having two distinct parties, otherwise you're just adding keys that can likely be all exfiltrated by the same threat. I can see the yubikey being more meaningful if you're storing the passwords in a server whose security you trust more than your desktop, but having an infected desktop is still very bad.
  - GekkePrutser 4y ago
    > Going by KeepassXC docs, the database is encrypted with an HMAC challenge response, changing only on DB save. But if you have the ability to copy the database file and the HMAC response in the same point of time as this malware does, the yubikey part is useless. What password manager are you using? I use a GPG-based password manager (pass) so this is not the case. Each password is encrypted individually using the GPG key in the yubikey. I hate keepass (I have to use it at work because they're stupid). I recently wrote a whole essay on why KeePass is so behind the times to our leadership, I hope they will finally go for something that actually has centralised management and auditing. We've seen teams that have used the keepass filename as master password for example and we have no way to prevent this kind of thing. I also use Fido2 where possible which is even better of course. And yes stuff can be exfiltrated but websites such as facebook, dropbox etc are pretty well defended against session cookie theft these days. I'm just saying there is still a very good reason for the admin account to be boxed off, despite the XKCD makes it seem useless.
Karellen 4y ago
Because it only ruins the one person's life whose account got hacked. All the other users on the system are unaffected. Also, if it just ruins a user account, you can simply delete that user's $HOME and restore their account from backups. If it elevates to root, you have to reformat the system and reinstall the whole OS from scratch (and hope it didn't patch the BIOS and/or hard disk firmware), and then reinstall all the user accounts from backups. Even if it's a single-user system, the non-root case is a lot less work to fix.
- 323 4y ago
  What other users? Pretty much all today's systems, either personal or server, are single user.
  - SoftTalker 4y ago
    "Real People" users yes, now that most "systems" are containers or VMs, the number of users that are real people might be one or even often zero. But most linux services run under their own user identities, so even in that case you will likely have several if not dozens of users on a typical server, the idea being that if the "nginx" user is compromised, the "postgres" user is still safe. Also why it was a bad idea to have services running as "root" (or "system") as was more common a decade or two ago.
  - Karellen 4y ago
    Plenty of households have lots of people using their own phone for social media and other consumption, but a shared laptop for times when a phone just isn't enough. Not everyone can afford a laptop per family member.
elesiuta 4y ago
And it isn't too difficult for something to elevate itself to root anyways. It could just include a basic key-logger which would work on most systems and wait for your password. Unless you're on Wayland, you can see for yourself by typing `xinput list` and `xinput test <id>` using the id of your keyboard. edit: and another comment linked to a blog post which also explains how this specific malware gains root https://www.intezer.com/blog/research/new-linux-threat-symbiote/ https://www.intezer.com/blog/research/new-linux-threat-symbi...
- dark-star 4y ago
  Yes, this is the part you mean, right? > This process requires that the SO has the setuid permission flag set. so you don't just have to download a binary file and somehow set LD_PRELOAD for that user, you also have to set the SUID bit on that binary file, which by itself only root can do...