11 ms·

Abusing Ubuntu 24.04 features for root privilege escalation

189 points by saltypal 2y ago

schoen 2y ago
I wonder if there's a tool to create dependency graphs for these dbus and polkit interactions, ideally to better audit those that seem to cross interesting trust boundaries.
fred_is_fred 2y ago
That was a great read. The way the author builds the exploit, brick by brick, is well done and not all all obvious or clear. Each step by itself is somewhat concerning but there's no Eureka! moment until very late.
BonusPlay 2y ago
Linux Local Privilege Escalation, but the attacker has to be in sudo group in the first place. Great read, but this feels like academic research. Technically correct, but impractical at best.
- rlpb 2y ago
  To expand on this: if the user is in the sudo group, they have explicit permission to execute anything they like as root. If someone wants a user to not be able to do this, they don't put that user in the sudo group. As far as I can tell from the write-up, if you remove a user from the sudo group because you don't want them to have that privilege then this "exploit" won't work. The bugs found look correct and have security implications, but what is demonstrated is therefore not really "root privilege escalation" since it applies only to users who already have that privilege.
  - LeifCarrotson 2y ago
    They can execute anything they like as root... by entering their password. This post shows a way that clever code can execute anything it likes as root without knowing the user's password. That seems pretty significant to me.
    - akira2501 2y ago
      Using print server vulnerabilities to gain local privilege escalation is reminiscent of Windows 95. The year of "Linux on the Desktop," I guess.
      - Yasuraka 2y ago
        In fact it's also reminiscent of Windows 11.
    - rlpb 2y ago
      > They can execute anything they like as root... by entering their password. If it has control of your user account, then it can just arrange to wrap your shell prompt and wait for you to sudo something else. The sudo password prompt in its default arrangement doesn't really provide much security there and isn't expected to.
      - withinboredom 2y ago
        On a server, you may be waiting months for that human to login and use sudo. Maybe even years.
        rlpb 2y ago
        That's not really relevant nowadays. Most attacks are done indiscriminately and en-masse, so an attacker wouldn't have to wait very long in practice. Only in "advanced persistent thread" territory is your point really relevant, but the attack I describe is much more widely applicable. Having to wait a while is therefore not in any way a mitigation. In practice then, one cannot assume any security from sudo requiring a password. https://en.wikipedia.org/wiki/Advanced_persistent_threat https://en.wikipedia.org/wiki/Advanced_persistent_threat
        chmod775 2y ago
        On a properly configured server you'll be waiting forever, because the users actually running the applications on that server aren't the same users who have privileges to make changes to the system or have access to stuff like sudo. So if you take over the nginx/postgres/whatever user, you're not really going to get anywhere. On the other hand you probably don't need to. Those users already expose all the juicy data on the server. You don't gain much from obtaining root anyways, except better persistence. This attack might be more interesting when chained with some other exploit that gains access to a users system via their e-mail client or browser. In other words nice if you're NSO Group making exploits for targeting individuals, but not that useful if you're trying to make a botnet.
- nneonneo 2y ago
  To be precise: you don't need to be in the sudo group, but in the lpadmin group. I'm not familiar with how Ubuntu groups are set up, but I guess it's likely that lpadmin is only granted to administrators by default. That said, I'm guessing people aren't expecting lpadmin to mean a full privilege escalation to root. There are two bugs here: one in cups, which allows it to chmod anything 777 (doesn't properly check for symlinks, or for the failure of bind), and one in wpa_supplicant, which lets it load arbitrary .so files as root. However, I suspect that even if these bugs are fixed, having access to lpadmin will still be a powerful enough primitive to escalate to root given the rather sizable attack surface of cups.
  - justmarc 2y ago
    It became crystal clear that cups is a can of worms, and it would be prudent to completely replace it with with a new solution built from the ground up, ideally using modern tools and standards.
    - cherryteastain 2y ago
      And that new solution will have only 70% of cups' features 15 years in with tons of gotchas in everyday use cases, like wayland
      - pzmarzly 2y ago
        > new solution will have only 70% of cups' features 15 years Which sounds fine? Most people don't want LPT printers support, they want AirPrint and WSD to just work.
        ale42 2y ago
        How many percent is "most" people? What about enterprise users with complex setups/requirements, will they be supported or out-of-luck? Typically you'll have print servers with centralized authentication, possibly logging/auditing/billing, any this might depend on "the" component they'll leave out in the new product because, well, most people don't care about it...
- dTal 2y ago
  If that is your attitude, why bother with the sudo group at all? Just run as root. (For what it's worth, I think most people would not lose much security from running as root, and the obsession with sudo is so much security theater, for exactly this sort of reason.)
  - nneonneo 2y ago
    Honestly, sudo’s value is really sanity, not security. The first time you use certain flavors of sudo, you get a nice little message which reminds you why sudo exists: We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. Realistically, sudo exists to remind a user of these points. That is: by needing to type “sudo” before a command, you’re being reminded to pay closer attention that you’re not violating another user’s privacy or doing something that’s going to break your system.
    - SoftTalker 2y ago
      Sudo is so commonly used especially on developer machines that I think it is used reflexively without any thought at at all. It should not be, but that's a different issue. It amazes me the amount of open-source projects that want to be installed with "sudo" when there is no reason they should not be able to be built and used entirely from within the developer's home directory. I know more than one person who starts a shell session with "sudo -i" and then just works as root because typing "sudo" all the time is an annoyance.
      - pxc 2y ago
        I wonder if this comes from the how some developers view ops knowledge and tasks as merely ancillary to their interests and work. For me, Linux was a hobby prior to and separately from programming. In the tutorials and documentation I read, every command was explained in detail and it was emphasized to me that I should never run a command that I don't fully understand. All instructions to elevate privileges were accompanied with advice about being careful running commands as root because root's privileges are especially dangerous. I was interested in those warnings, and took them seriously, because I wanted to master what I was learning. What I was learning, though, explicitly included Linux/Unix norms like security 'best practices'. Developer documentation doesn't usually concern itself with Linux/Unix norms the way that tutorials for Linux hobbyists and novice sysadmins do. At the same time, the developers reading it might be perfectly dedicated to mastery, but just not really see what is considered proper usage by sysadmins (let alone the considerations that inform the boundaries of such propriety) to on-topic for what they're studying/exploring/playing with. Diving into those details might not be 'patt of the fun' for them. What such a developer learns about sudo is mostly going to come from shallow pattern recognition: sudo is a button to slap when something doesn't work the first time, and maybe it has something to do with permissions. But I think that comes from the mode of engagement, especially at the time of learning sudo, more than the mere frequency of use. I use sudo several times every day (including sometimes interactive sessions like you mention, with -i or -s), but I am careful to limit my usage to cases where it's really required. I'm not perfect about that; occasionally I run `sudo du` when `du` would suffice because I pulled something out of my shell history when I happened to be running it from / or whatever. But I certainly don't run it reflexively or thoughtlessly.
samlinnfer 2y ago
24.04 also ships with a footgun that keeps PasswordAuthentication enabled even if you edit /etc/ssh/sshd_config. It adds a /etc/ssh/sshd_config.d/50-cloud-init.conf that force overrides any PasswordAuthentication settings you have configured in /etc/ssh/sshd_config. See here: https://news.ycombinator.com/item?id=42133181 https://news.ycombinator.com/item?id=42133181
- MortyWaves 2y ago
  Now I definitely feel glad that I decided on moving back to Debian for servers.
  - gazunklenut 2y ago
    Pretty sure this exists on Debian too
    - poizan42 2y ago
      Nope, not on my system: https://i.imgur.com/1qCLXXZ.png https://i.imgur.com/1qCLXXZ.png
      - HumanOstrich 2y ago
        Great, now you can start putting your customizations in that directory instead of the OS-managed /etc/ssh/sshd_config blob. That's why the `.d/` convention exists.
        normie3000 2y ago
        What does .d imply?
        HumanOstrich 2y ago
        I had to look up the info because I wasn't sure really, so I appreciate the direct question. It means 'directory' or 'conf.d pattern'. So you have your config file, and the config directory that contains "parts" of the config to be merged with the main one to provide customizations/overrides.
sheerun 2y ago
The only feedback I get when installing d-spy is "Uses System Services", and "Uses Session Services", which means nothing to me as a user, and yet it allows program to enumerate all programs I use and as it turns out even hack my computer. Other platforms solved this with something like "developer mode", iOS, Android, Meta, etc. I shouldn't be able to install this app without confirming developer-mode-only permissions. As for this particular app it is offline, yes, but dbus allows for cross-app communication, so no more
- nneonneo 2y ago
  You’re running desktop Linux - your whole system is permanently in “developer mode”. That’s kind of the point? Windows and macOS don’t have “developer mode” either, at least not to the extent seen in the mobile OSes. They’re very different models of computing.
  - Vilian 2y ago
    The only way to not be in "developer mode" is to install something like fedora atomic, then everything is harder lol
deleted 2y ago
[deleted]
sylware 2y ago
It is time to stop that: there is no "security", this is a fantasy which does not exist. Nowadays, anybody saying otherwise is trying to sell you something. The only real security is to protect basic users from themselves, namely breaking their systems. That's it. (rm -Rf /)
trod1234 2y ago
Not surprising, Ubuntu has suffered a wide array of issues going all the way back to their releases following 18.04 LTS. D-BUS has long been targeted by attackers for the exact reasons the author goes into (its fairly common knowledge in some circles). Not just because of the difference in security contexts but also because of the lack of visibility on these channels with OOB configurations for logging/monitoring. D-BUS Activation has also been targeted before, many times for its ability to effectively re-parent a process under different pids/names/users, and hiding that process is usually not that hard using a simple mount bind on the associated /proc/pid and mounts directory post exploitation. With the poisoning of the Ubuntu repository (with fixup scripts to re-enable snap), their security posture became untenable, but has only gotten worse over time.

189 points by saltypal 2y ago

I wonder if there's a tool to create dependency graphs for these dbus and polkit interactions, ideally to better audit those that seem to cross interesting trust boundaries.

fred_is_fred 2y ago

That was a great read. The way the author builds the exploit, brick by brick, is well done and not all all obvious or clear. Each step by itself is somewhat concerning but there's no Eureka! moment until very late.

BonusPlay 2y ago

Linux Local Privilege Escalation, but the attacker has to be in sudo group in the first place. Great read, but this feels like academic research. Technically correct, but impractical at best.

rlpb 2y ago
To expand on this: if the user is in the sudo group, they have explicit permission to execute anything they like as root. If someone wants a user to not be able to do this, they don't put that user in the sudo group. As far as I can tell from the write-up, if you remove a user from the sudo group because you don't want them to have that privilege then this "exploit" won't work. The bugs found look correct and have security implications, but what is demonstrated is therefore not really "root privilege escalation" since it applies only to users who already have that privilege.
- LeifCarrotson 2y ago
  They can execute anything they like as root... by entering their password. This post shows a way that clever code can execute anything it likes as root without knowing the user's password. That seems pretty significant to me.
  - akira2501 2y ago
    Using print server vulnerabilities to gain local privilege escalation is reminiscent of Windows 95. The year of "Linux on the Desktop," I guess.
    - Yasuraka 2y ago
      In fact it's also reminiscent of Windows 11.
  - rlpb 2y ago
    > They can execute anything they like as root... by entering their password. If it has control of your user account, then it can just arrange to wrap your shell prompt and wait for you to sudo something else. The sudo password prompt in its default arrangement doesn't really provide much security there and isn't expected to.
    - withinboredom 2y ago
      On a server, you may be waiting months for that human to login and use sudo. Maybe even years.
      - rlpb 2y ago
        That's not really relevant nowadays. Most attacks are done indiscriminately and en-masse, so an attacker wouldn't have to wait very long in practice. Only in "advanced persistent thread" territory is your point really relevant, but the attack I describe is much more widely applicable. Having to wait a while is therefore not in any way a mitigation. In practice then, one cannot assume any security from sudo requiring a password. https://en.wikipedia.org/wiki/Advanced_persistent_threat https://en.wikipedia.org/wiki/Advanced_persistent_threat
      - chmod775 2y ago
        On a properly configured server you'll be waiting forever, because the users actually running the applications on that server aren't the same users who have privileges to make changes to the system or have access to stuff like sudo. So if you take over the nginx/postgres/whatever user, you're not really going to get anywhere. On the other hand you probably don't need to. Those users already expose all the juicy data on the server. You don't gain much from obtaining root anyways, except better persistence. This attack might be more interesting when chained with some other exploit that gains access to a users system via their e-mail client or browser. In other words nice if you're NSO Group making exploits for targeting individuals, but not that useful if you're trying to make a botnet.
nneonneo 2y ago
To be precise: you don't need to be in the sudo group, but in the lpadmin group. I'm not familiar with how Ubuntu groups are set up, but I guess it's likely that lpadmin is only granted to administrators by default. That said, I'm guessing people aren't expecting lpadmin to mean a full privilege escalation to root. There are two bugs here: one in cups, which allows it to chmod anything 777 (doesn't properly check for symlinks, or for the failure of bind), and one in wpa_supplicant, which lets it load arbitrary .so files as root. However, I suspect that even if these bugs are fixed, having access to lpadmin will still be a powerful enough primitive to escalate to root given the rather sizable attack surface of cups.
- justmarc 2y ago
  It became crystal clear that cups is a can of worms, and it would be prudent to completely replace it with with a new solution built from the ground up, ideally using modern tools and standards.
  - cherryteastain 2y ago
    And that new solution will have only 70% of cups' features 15 years in with tons of gotchas in everyday use cases, like wayland
    - pzmarzly 2y ago
      > new solution will have only 70% of cups' features 15 years Which sounds fine? Most people don't want LPT printers support, they want AirPrint and WSD to just work.
      - ale42 2y ago
        How many percent is "most" people? What about enterprise users with complex setups/requirements, will they be supported or out-of-luck? Typically you'll have print servers with centralized authentication, possibly logging/auditing/billing, any this might depend on "the" component they'll leave out in the new product because, well, most people don't care about it...
dTal 2y ago
If that is your attitude, why bother with the sudo group at all? Just run as root. (For what it's worth, I think most people would not lose much security from running as root, and the obsession with sudo is so much security theater, for exactly this sort of reason.)
- nneonneo 2y ago
  Honestly, sudo’s value is really sanity, not security. The first time you use certain flavors of sudo, you get a nice little message which reminds you why sudo exists: We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. Realistically, sudo exists to remind a user of these points. That is: by needing to type “sudo” before a command, you’re being reminded to pay closer attention that you’re not violating another user’s privacy or doing something that’s going to break your system.
  - SoftTalker 2y ago
    Sudo is so commonly used especially on developer machines that I think it is used reflexively without any thought at at all. It should not be, but that's a different issue. It amazes me the amount of open-source projects that want to be installed with "sudo" when there is no reason they should not be able to be built and used entirely from within the developer's home directory. I know more than one person who starts a shell session with "sudo -i" and then just works as root because typing "sudo" all the time is an annoyance.
    - pxc 2y ago
      I wonder if this comes from the how some developers view ops knowledge and tasks as merely ancillary to their interests and work. For me, Linux was a hobby prior to and separately from programming. In the tutorials and documentation I read, every command was explained in detail and it was emphasized to me that I should never run a command that I don't fully understand. All instructions to elevate privileges were accompanied with advice about being careful running commands as root because root's privileges are especially dangerous. I was interested in those warnings, and took them seriously, because I wanted to master what I was learning. What I was learning, though, explicitly included Linux/Unix norms like security 'best practices'. Developer documentation doesn't usually concern itself with Linux/Unix norms the way that tutorials for Linux hobbyists and novice sysadmins do. At the same time, the developers reading it might be perfectly dedicated to mastery, but just not really see what is considered proper usage by sysadmins (let alone the considerations that inform the boundaries of such propriety) to on-topic for what they're studying/exploring/playing with. Diving into those details might not be 'patt of the fun' for them. What such a developer learns about sudo is mostly going to come from shallow pattern recognition: sudo is a button to slap when something doesn't work the first time, and maybe it has something to do with permissions. But I think that comes from the mode of engagement, especially at the time of learning sudo, more than the mere frequency of use. I use sudo several times every day (including sometimes interactive sessions like you mention, with -i or -s), but I am careful to limit my usage to cases where it's really required. I'm not perfect about that; occasionally I run `sudo du` when `du` would suffice because I pulled something out of my shell history when I happened to be running it from / or whatever. But I certainly don't run it reflexively or thoughtlessly.

samlinnfer 2y ago

24.04 also ships with a footgun that keeps PasswordAuthentication enabled even if you edit /etc/ssh/sshd_config. It adds a /etc/ssh/sshd_config.d/50-cloud-init.conf that force overrides any PasswordAuthentication settings you have configured in /etc/ssh/sshd_config. See here: https://news.ycombinator.com/item?id=42133181 https://news.ycombinator.com/item?id=42133181

MortyWaves 2y ago
Now I definitely feel glad that I decided on moving back to Debian for servers.
- gazunklenut 2y ago
  Pretty sure this exists on Debian too
  - poizan42 2y ago
    Nope, not on my system: https://i.imgur.com/1qCLXXZ.png https://i.imgur.com/1qCLXXZ.png
    - HumanOstrich 2y ago
      Great, now you can start putting your customizations in that directory instead of the OS-managed /etc/ssh/sshd_config blob. That's why the `.d/` convention exists.
      - normie3000 2y ago
        What does .d imply?
        HumanOstrich 2y ago
        I had to look up the info because I wasn't sure really, so I appreciate the direct question. It means 'directory' or 'conf.d pattern'. So you have your config file, and the config directory that contains "parts" of the config to be merged with the main one to provide customizations/overrides.

sheerun 2y ago

The only feedback I get when installing d-spy is "Uses System Services", and "Uses Session Services", which means nothing to me as a user, and yet it allows program to enumerate all programs I use and as it turns out even hack my computer. Other platforms solved this with something like "developer mode", iOS, Android, Meta, etc. I shouldn't be able to install this app without confirming developer-mode-only permissions. As for this particular app it is offline, yes, but dbus allows for cross-app communication, so no more

nneonneo 2y ago
You’re running desktop Linux - your whole system is permanently in “developer mode”. That’s kind of the point? Windows and macOS don’t have “developer mode” either, at least not to the extent seen in the mobile OSes. They’re very different models of computing.
- Vilian 2y ago
  The only way to not be in "developer mode" is to install something like fedora atomic, then everything is harder lol

deleted 2y ago

[deleted]

sylware 2y ago

It is time to stop that: there is no "security", this is a fantasy which does not exist. Nowadays, anybody saying otherwise is trying to sell you something. The only real security is to protect basic users from themselves, namely breaking their systems. That's it. (rm -Rf /)

trod1234 2y ago

Not surprising, Ubuntu has suffered a wide array of issues going all the way back to their releases following 18.04 LTS. D-BUS has long been targeted by attackers for the exact reasons the author goes into (its fairly common knowledge in some circles). Not just because of the difference in security contexts but also because of the lack of visibility on these channels with OOB configurations for logging/monitoring. D-BUS Activation has also been targeted before, many times for its ability to effectively re-parent a process under different pids/names/users, and hiding that process is usually not that hard using a simple mount bind on the associated /proc/pid and mounts directory post exploitation. With the poisoning of the Ubuntu repository (with fixup scripts to re-enable snap), their security posture became untenable, but has only gotten worse over time.