22 ms·

How to get root on Ubuntu 20.04 by pretending nobody’s /home

Arnavion 6y ago
I didn't see it mentioned in the article, so just to clarify, this was fixed with https://ubuntu.com/security/notices/USN-4616-1 https://ubuntu.com/security/notices/USN-4616-1
- SiVal 6y ago
  How can you tell if an Ubuntu 20.04 server has this fix?
  - severino 6y ago
    You can use "apt-cache policy", for example. This way you can see the current installed version of a package in your system, and also if there's a newer version you can install (the candidate). $ apt-cache policy accountsservice accountsservice: Installed: 0.6.40-2ubuntu11.6 Candidate: 0.6.40-2ubuntu11.6 If the installed version reported by the utility is the version that Ubuntu states the problem has been fixed for your release, then presumably your system is safe (for this bug).
  - Forbo 6y ago
    The article states that server isn't affected, because it requires access to a graphical desktop session. Edit with direct quote from the article: > Disclaimer: For someone to exploit this vulnerability, they need access to the graphical desktop session of the system, so this issue affects desktop users only. Am I wrong?
    - hitpointdrew 6y ago
      Only if the server has no GUI installed. I worked a place where the Network Admin, had a bunch of older RedHat servers with GUI's. I had to become the "bad guy" because on the newer boxes I was in charge of I refused to install a GUI, a bunch of devs pissed and moaned because they couldn't use xterm to connect to the new servers. It was pretty backwards place.
      - freedomben 6y ago
        At the risk of igniting an irrelevant flame war, this is one of the primary reasons why I use Vim and only Vim as my IDE. I don't have to care about lack of graphical environments ;-)
        jdhawk 6y ago
        side note, long time - and still current vim developer who also uses JetBrains IDE products... I'd pay similar money to have a similarly robust VIM plugin from a supported vendor with great support and sane keybindings OOTB. man, its easy to get spoiled with tons of ram and a great IDE.
        freedomben 6y ago
        Yes, I don't know if anybody will ever see this, but I agree! I would gladly pay similar for a robust VIM plugin setup that gave me similar features on a range of languages.
      - tinco 6y ago
        We run some machine learning systems on Ubuntu server, and it's really easy to accidentily install the full desktop environment while installing random graphics driver related packages. While figuring out how to set things up (before I formalized in an ansible script) one of the servers ended up with the desktop packages installed. Weird to look at the IPMI overview and between all the white on black kernel log outputs suddenly seeing a full Ubuntu desktop boot screen.
    - zeta0134 6y ago
      It's somewhat common to install a graphical environment on server machines, particularly if they need to run certain (Oracle) enterprise software, for which GUI tools are either the only option, or by far the most expected and documented solution. Of course in theory you could install the bare minimum to run the utility using X-forwarding, in practice anyone doing this usually installs a full environment because it's much simpler to manage. Plus, there are a few admins out there who simply prefer to use VNC over a straight terminal. I'm not here to judge; while this is uncommon, it's certainly not unheard of. Personally I would rather not have that much attack surface on my servers, but there are a few legitimate use cases here and there.
      - Twirrim 6y ago
        > It's somewhat common to install a graphical environment on server machines It's really not that common. Yes there's the odd cases of servers that use enterprise software that have to have GUIs, but most linux boxes run headless. GUIs are just a waste of processing power and resources for the large majority of the things that servers are used for. That said, I'm not happy that Canonical are entirely discounting the possibility that customers will have desktop environments installed on servers. It's not common, but it does happen.
        dannyw 6y ago
        One thing to note is that depending on how your network is structured and firewalled, if _one_ server has a graphical env of some sort (maybe a ML/image processing server that has graphical environments installed)... root access could be nasty nonetheless. I never install GUIs on my servers, but when deploying a image processing server, while installing another package to debug CUDA/drivers, I've unintentionally added a full windowing system without realising it.
        woodson 6y ago
        Unfortunately, nvidia-settings requires xorg to be installed and running (even when run in cli mode), and it's pretty much the only way to control fan speeds on consumer GPUs.
  - Denvercoder9 6y ago
    Check if the installed version is equal to or higher than one of the listed fixed versions. Likely it isn't even installed on a server edition.
  - e12e 6y ago
    Assuming the server can reach the normal apt repos - you could: sudo apt update; apt list upgradable And grep for this package. Otherwise sudo apt update /usr/lib/update-notifier/apt-check --human-readable Will list number of pending security updates. (part of update-notifier-common, and in task:server along with various desktop-tasks) Beyond that, you might want to look at https://vuls.io https://vuls.io or other auditing packages. Or perhaps: sudo snap install cvescan cvescan Seems it could use some exposure - I wasn't aware of it: https://github.com/canonical/sec-cvescan https://github.com/canonical/sec-cvescan
s_gourichon 6y ago
Excellent job Of research and presentation!
WayToDoor 6y ago
Very good writeup. It's amusing that Ubuntu didn't double check in the user creation tool to ensure there was in fact no current administrator account. Sounds like a fun day to me.
- _kst_ 6y ago
  An administrator account, in this context, is one that's a member of the "sudo" group. It's perfectly ordinary for more than one account to be a member of that group.
javajosh 6y ago
Fascinating. This exploit doesn't feel like something someone would just stumble upon. Is the main value of this work to reduce the price of an exploit on the black market? Of interest to me is that this exploit, although patched, is probably still valuable since not everyone patches their system. EDIT: Oops, I didn't read the deep dive section, and I guess he says how he stumbled upon it. My bad!
- MauranKilom 6y ago
  He literally describes at the end of the post how he stumbled upon it...
ajsnigrutin 6y ago
What the hell does accuntservice do, and why does ubuntu need a dedicated service for that? To clarify, do we really need a service (and an unsafe, exploitable one), to do something, we've been doing without it for years on all other distros.
- npsimons 6y ago
  I actually got a decent answer to this, from what appears to be a developer working on something in the FreeDesktop.org ecosystem: > Way better for writing gui apps against instead of wrapping suid binaries and parsing strings horribly. I would call that a laudable goal. Just seems like the design needs a deep security review.
- ecnahc515 6y ago
  The unsafeness here was GDM, not accountservice.
mehrdadn 6y ago
> It turns out that Ubuntu uses a modified version of accountsservice that includes some extra code that doesn’t exist in the upstream version maintained by freedesktop. I guess next time people ask why I like a distro like Arch that doesn't insert its own junk into upstream code over Debian/Ubuntu/et al, I'll have a new example handy to cite.
- symlinkk 6y ago
  Yeah I hate it when distros do this. Does Debian actually change upstream significantly? I thought they kept things fairly vanilla. I know Fedora patched in VAAPI support on Firefox before it was merged into the Mozilla codebase. I can’t think of a worse piece of software to patch, the last thing I want to be running untested code on is my web browser.
  - jasonjayr 6y ago
    Most of the Debian changes I've seen consist of changing default paths to match Debian's standards, backporting security changes (esp if a version bump changes functionality), and support 'conf.d' directories so packages can drop-in configuration files, and remove them easily.
    - ClumsyPilot 6y ago
      > "backporting security changes (esp if a version bump changes functionality" Thats not a trivial matter, its a potential source of many issues
      - marcosdumay 6y ago
        It's also a source of many solutions. There are really no perfect option here. Upstream and distro developers have different goals, and it's up to you to decide what you should adopt.
        jhardy54 6y ago
denysvitali 6y ago
Article well written and noteworthy exploit explanation. Bravo! 10/10
usr1106 6y ago
I like slim Linux machines and I several times considered to remove or at least disable accountservice. I has never been clear to me why you need such service as long as /etc/passwd is world readable. So from this article I learn * calling mount during installation(?) when there is no user. Makes no sense to have the daemon running later * providing a user icon. Exactly the type of functionality I like to throw out * providing a user specific language setting. I can see that this is useful for some users So how is dropping privileges done correctly to avoid getting killed by the user? Running as another user is one way, but I guess that is not always feasible if you want the daemon provide services for the user. On the other hand accountservice is there for multiple (human) users. So as which of them is it running? Not at a machine right now...
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- mehrdadn 6y ago
  > So how is dropping privileges done correctly to avoid getting killed by the user? I was wondering this too. What is the way to "correctly" drop privileges? Is it even possible to drop privileges within a process in a way that's immune to this?
  - jontro 6y ago
    I guess you could fork first?
    - jasonjayr 6y ago
      Fork then handle child/exec error codes appropriately.
      - usr1106 6y ago
        Right, if the child runs as the user, the parent still running as root can reliably handle the situation that the user killed the child. Don't remember having seen that. Well, sshd does it, but for more obvious reasons than handling signals.
hanemile 6y ago
Wonderful write-up, great step by step descripting and some more insights on the underlying problems. There should me more write-ups structured like this!
Quarrel 6y ago
Without taking anything away from this, as a general rule, if you have physical access to the machine, it can almost definitely be compromised. The flaw here involves access to the GUI, which in most cases implies that they have physical access. (and in most cases would imply it is "their" machine in any event)
- aftbit 6y ago
  Generally agreed. This specific issue seems most likely to be a problem in a computer lab environment, where you'd likely be detected if you tried to take the case off the machine, but might be able to get away with anything that looks like normal computer use behavior.
- woofie11 6y ago
  No. That's not a general rule. Many universities have computer labs. The computers are in a locked cabinet, with a keyboard, mouse, and monitor exposed. For that matter, many shopping malls have information kiosks, retail stores have demo laptops, banks have ATM machines, airlines have automatic check-ins, etc. If you're typing away, no one will care. If you're opening up the device with a crowbar, or even screw driver, you'd better have a nice orange high-viz uniform, lanyard, and clipboard. Without those, security will drag you awat.
  - exabrial 6y ago
    I'm not sure if you were trying to prove his point, but you did
    - woofie11 6y ago
      I'm pretty sure I know what constitutes a proof, and that wasn't it. The core reason this did not constitute a proof is because physical security people misapply lessons from that domain to digital, and software engineers misapply lessons from digital to physical. In the virtual world, I'm open to 7 billion potential attackers. In the physical world, I'm open to a few. That leads to very different security practices. If I leave my front door unlocked for a week, the security risk is minimal where I live. Casual security is good enough. If I leave my computer with even a pretty obscure vulnerability connected to the internet for 5 minutes, odds are pretty good it will be compromised. Clipboards+lanyard+high viz vest is imperfect security (and I chose the example deliberately to illustrate that), but it is good enough security to practically prevent physical compromises in most instances. I won't run a military base that way, or a HIPAA-compliant data system, but it's good enough for 95% of uses, including, for example, a university physics department's research data system. Even a military base doesn't have perfect security; a well-resourced attacker can compromise it. In contrast, in the virtual world, I want cryptographic protocols where I can prove perfect security, at least given a relatively small set of assumptions.
cpgxiii 6y ago
it strikes me that the serious bug here is the design of GDM to check accounts-daemon for existing accounts, and if that check times out, start account creation. Regardless of the nominal protections afforded by the system, if you rely on a daemon that accepts unprivileged user input to provide security-critical answers, and fail open if it doesn't respond, that's a bad idea.
- effie 6y ago
  Agreed, login manager should be saner (less relying on other processes) than that. Also, the very existence of accounts-daemon concept seems to be a mistake from the security and simplicity point of view.
- a-dub 6y ago
  yup. think it's fine to have a service that manages accounts, but a timeout in contacting it resulting in the start of a process that creates users (with privileges) is definitely no good. would be interesting to understand how it happened. is it a straight up bug? is it some sort of fallback in gdm to work around non-responsive account-service (potentially on new machines)? is it some sort of backwards compatibility thing? i can't imagine that it was coded that way intentionally, would be interesting to understand how it ended up that way...
- steerablesafe 6y ago
  Maybe GDM shouldn't even have the privilege to create a new account in the first place. Couldn't every privileged operation be requested through accounts-daemon?
benlivengood 6y ago
The first documentation I could find about accounts-daemon by googling is this: https://utcc.utoronto.ca/~cks/space/blog/linux/UbuntuAccountsServiceProblems https://utcc.utoronto.ca/~cks/space/blog/linux/UbuntuAccount... Not reassuring.
- npsimons 6y ago
  In my over twenty years of using Linux, this is the first I had heard of "accounts-daemon", and I'm the kind of nerd who browses repositories for fun, looking for new and interesting packages. So I googled "accounts-daemon", and these are the titles for the first three results: 1. "What does accounts-daemon actually do?" 2. "Should I disable accounts-daemon?" 3. "Process accounts-daemon taking 100% of CPU." Not reassuring indeed.
  - jasonjayr 6y ago
    It's from the freedesktop folks. (Like systemd, dbus, pulseaudio, and all sorts of other services to make linux more 'desktop' friendly)
    - npsimons 6y ago
      Yeah, that's a windmill I've given up tilting at. And it has gotten better, but mostly through painful learning experiences like this one. But some days I wonder if I'd just be better off moving to OpenBSD or heck Plan 9 or Inferno.
      - 35fbe7d3d5b9 6y ago
        > OpenBSD Use a Thinkpad that's not too new? OK without 802.11ac and Bluetooth? Come take a dip, the water is just fine.
        mrguyorama 6y ago
        Wait, why can't OpenBSD handle Bluetooth? Is it just that the same chip is used for both wireless protocols and it doesn't support them yet?
hyperion2010 6y ago
Well this vindicates my years of keeping policykit and all that other nonsense off my systems (sadly haven't found a way to zap dbus). The less code you have the less opportunities there are to screw something up.
- fs2 6y ago
  Exactly, I'm running fine without Pulseaudio, Policykit and SystemD. Good old sysv init scripts always work, less complexity means less chance for bugs creeping in.
RickJWagner 6y ago
Wow. Well written and easy to understand. I hope Ubuntu gets right on that one.
segmondy 6y ago
What's amusing is that this is a classic 30+yrs old "sym link" exploit. Interesting how classic most of the exploits coming up are, almost like the current generation don't know the lessons of the past ...
- gizmo686 6y ago
  Its not quite a classic synlink exploit. Normally, the purpose of a symlink exploit is to get a privledged process to leak information about a file you don't have access to. Here, as the article mentions, part of the attack relies on the fact that the privledged process goes out of its way to defend against such an attack. As far as I can tell, the symlink is not even nessasary. You should be able to get the same effect by making 1TB big. Using sparse files, you don't even need much disk space.
stormbrew 6y ago
While the DoS of accounts-daemon is bad, it seems like the real problem here is that gdm3 running with broken/absent/etc. accounts-daemon will believe there are no accounts even though there may be? Surely this is extremely trusting behaviour on gdm3's part and should also be fixed? But all the updated versions are for accounts-version, not gdm3. Do they change the 'default' response somehow?
- sce 6y ago
  Looks like it's fixed upstream https://gitlab.gnome.org/GNOME/gdm/-/issues/642 https://gitlab.gnome.org/GNOME/gdm/-/issues/642
  - stormbrew 6y ago
    Ah, cool. That's good. CVE for that appears to be https://nvd.nist.gov/vuln/detail/CVE-2020-16125 https://nvd.nist.gov/vuln/detail/CVE-2020-16125 and fixed in 3.36.2 or 3.38.2..
glglwty 6y ago
> [...] gdm3 thinks that there are zero user accounts and it launches gnome-initial-setup. What if the root user intentionally deleted all non-root users? GDM would just let anyone creates an user with wheel?
- nexuist 6y ago
  The root user obviously counts as a user account, otherwise you would be prompted to make a new account on every startup if you hadn't made any other accounts. The reason why it thinks there are zero accounts in this instance is because you've just killed the service daemon that would provide that number, so no number is received through the DBus call.
trilinearnz 6y ago
Slightly offtopic, but a common exploit(?) I frequently see with Linux desktop environments is a few seconds where the user's live desktop is displayed after resuming from standby, before the logon screen comes up. Not exactly a case of obtaining control of one's computer, but could be effectively used through repetition to transcribe any sensitive content that may have been onscreen. It always struck me as a very strange phenomenon to occur given the apparent security superiority of Linux in contrast to Windows. Perhaps that's an antiquated notion now, given modern distros that prioritise form-over-function more than they used to?
- nexuist 6y ago
  This actually used to be a common problem I would have on macOS, especially when docked to an external display. I wonder if these problems are connected somehow.
  - saagarjha 6y ago
    I think it’s just a fundamental problem of running a program that is essentially like any other that covers the screen.
    - trilinearnz 6y ago
      I can see how that could come about (lumping window manager concerns all into the one bucket), but to me it's security implications make a good case for re-architecting this part of the system. I.e. having a separate part of the OS which marshals access to the visible desktop when transitioning between ACPI states. For hardware-accelerated compositing situations, it might have something to do with unnecessarily long / out-of order retention of the GPU frame buffer, which I could conceive of as being dismissed as inconsequential in most circumstances.
- unethical_ban 6y ago
  It is entirely off-topic, and I have observed exactly the same phenomenon. I have also felt the same reaction - "Isn't Linux \"better\" "? I have a 20.04 thinkpad that I rarely use for reasons (partly that it doesn't come out of suspend most of the time, forcing a hard reboot) but I remember this being a problem back when my Ubuntu install was functional :)
gbrown_ 6y ago
Not sure why this wasn't a dupe of my submission [1] submitted ~8 hours earlier? Oh well. [1] https://news.ycombinator.com/item?id=25046588 https://news.ycombinator.com/item?id=25046588
vlovich123 6y ago
Can anyone help me understand this part? > Dropping privileges means that the daemon temporarily forfeits its root privileges, adopting instead the lower privileges of the user. Ironically, that’s intended to be a security precaution, the goal of which is to protect the daemon from a malicious user who does something like symlinking their .pam_environment to /etc/shadow, which is a highly sensitive file that standard users aren’t allowed to read. Unfortunately, when done incorrectly, it also grants the user permission to send the daemon signals, which is why we’re able to send accounts-daemon a SIGSEGV. What’s the recommended way to drop permissions while blocking the ability to kill the process (sure you can mask off SIGSEGV but SIGKILL isn’t maskable)? Also, the wording makes it sound like you can re-acquire the original permissions which I thought is impossible. Isn’t dropping permissions a one-way operation? I would have thought there was some usage of fork here but the usage of `pidof` and 1 result in the write up would imply no forking. Maybe a link to the source here would be sufficient for me (I don’t see one in the article or in the thread here).
- vlovich123 6y ago
  Answering my own question. Found the bug report: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1900255 https://bugs.launchpad.net/ubuntu/+source/accountsservice/+b... Accountservice is actually changing its user ID rather than dropping capabilities which is where my confusion came from. It looks like there’s magic in the kernel to allow a process to switch back to the original user & some nuance about some ways of switching allowing you to send signals while other ways make your process act like a semi-hybrid of two user accounts (I.e. it technically looks owned by your user but you still don’t have permissions to do things with it). Security issues always lie in these kind of weird nuances.
gorgoiler 6y ago
More unwanted complexity in the base system :( I wish I had a Linux distro that split the OS from the userland more neatly. I want to boot into something minimal and static, and then add complexity from there. Maybe logging in to a local container instead of the actual OS? Linux as an easily extendable building filled with rooms and workshops and entertainment areas, rather than Linux as a mere desktop.
- LambdaComplex 6y ago
  Maybe look into Qubes OS? I've never used it, but the concept sounds kinda like what you're describing: "a security-focused desktop operating system that aims to provide security through isolation. Virtualization is performed by Xen, and user environments can be based on Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems." (from Wikipedia)
- jdally987 6y ago
  NixOS, my friend. NixOS. I still can't believe it's not more widely used (and I only started using linux full-time earlier this year). It confines the entire (non-user) filetree into the read-only /nix directory, and manages every single component of the OS through Nix, the package manager - and I guess nix-daemon in the case of NixOS specifically - 100% declaratively. You define the entire thing through a single configuration.nix file. You can even do crazy stuff like erasing the root upon each reboot, leaving only /nix and /home if you wanted, and I think I remember in the article I was reading about it that it can mount everything on a tmpfs or something like that, so you have a perfectly "clean" root tree every time you restart the computer (as /nix is stateless, it's guaranteed not to change except when rebuilding the system configuration). The point of nixos is really the declarative aspect, with "splitting" the OS being more of a secondary benefit, but for your case, you might like the whole declarative builds thing in general to accomplish that.
  - AnIdiotOnTheNet 6y ago
    > NixOS, my friend. NixOS. Is there an option that doesn't require everyone who uses it to learn an entirely new language?
quotemstr 6y ago
The real problem is here: > It uses D-Bus to ask accounts-daemon how many users there are, but since accounts-daemon is unresponsive, the D-Bus method call fails due to a timeout. (In my testing, the timeout took around 20 seconds.) Due to the timeout error, the code does not set the value of priv->have_existing_user_accounts. Unfortunately, the default value of priv->have_existing_user_accounts is false, not true, so now gdm3 thinks that there are zero user accounts and it launches gnome-initial-setup. I am sick and tired of programs trying to continue onward somehow after encountering "impossible" error conditions or tripping over arbitrary timeouts. Failing fast when something looks funny is essential to the creation of a secure system. When you write something like the gdm3 code above --- which, when it runs into trouble, clears any ambient error and pretends that the system has no current users --- you may think you're doing the user a favor by continuing to operate, but what you're doing is in fact willfully entering some unknowable and unexplored region of the system's state space, usually one full of dragons and anthrax. What you want to do instead is just die when something goes wrong. gdm3 should respond to a failure to contact org.freedesktop.Accounts with either a hard lockup or a forced restart of the gdm3 daemon.
- lovehashbrowns 6y ago
  The usage for code that I currently write is internal and it’s made with usability in mind, so I am guilty of coding stuff like this on occasion. By that I mean that my code, under certain circumstances, assumes the best and continues moving forward. I do this for a specific reason: I don’t want my team to get pinged with a support request for something trivial. So this type of bug is a huge eye opener for me. I still want to strike a balance between usability and clarity, but this story makes me want to review a lot of the code I’ve written. None of it is mission critical and on this level, luckily.
  - quotemstr 6y ago
    I've found that I spend more time debugging arcane horrible things that go wrong as downstream consequences of recovery paths than I do debugging straightforward and obvious problem reports that come from hard assertion failures and failing fast.
arthurcolle 6y ago
What a cute little exploit, just lurking there in the wilderness waiting to make some friends
choeger 6y ago
I think there is a large part of that story missing. If the accounts daemon drops privileges for reading from the user's home, how can it ever get back to its normal state? How could two users run the same operation concurrently? Normally that privilege dropping should happen after forking, right? And if it does the parent process should respond to gdm's inquiry. That being said, the initial settings thing is probably good for a few more escalations as its usecase does not seem to fit the standard security measures very well.
- kevsim 6y ago
  I believe with seteuid the process can temporarily assume the uid of the user in question and later restore the original uid.
- jwilk 6y ago
  From the setresuid(2) man page: > An unprivileged process may change its real UID, effective UID, and saved set‐user‐ID, each to one of: the current real UID, the current effective UID or the current saved set‐user‐ID. accountsservice did something like setresuid(uid, uid, -1), which set both real and effective UIDs, but kept saved set‐user‐ID as root, so that it could re-gain root privileges later. Setting EUID was the correct course of action; but setting real UID let the unprivileged user kill the process.
  - steerablesafe 6y ago
    Would it have been possible to attach a debugger to accountsservice in this state and execute arbitrary code, including re-gaining root privileges?
    - jwilk 6y ago
      Very good question. :-) No, you can't use ptrace(2) on a process that has changed its EUID. For details, see PR_SET_DUMPABLE in the prctl(2) man page.
      - 6y ago
Uhrheber 6y ago
Seems that Mint also inherited this vulnerability.
admax88q 6y ago
I honestly have no faith in multi user linux. I would never give someone I didn't trust an unprivileged account on my system, nor physical access to my device. There are so few multi user machines in existence that I doubt this mode of usage will ever get enough attention to be even moderately secure.
- pantalaimon 6y ago
  machines in universities are typically multi user
  - aflag 6y ago
    The students are also trusted, or at least accountable. It's very different than a random stranger. That said, I wouldn't store anything truly private in a shared box like that, specially in the university, where the boxes are likely to be maintained by inexperienced undergrads.
    - pantalaimon 6y ago
      > The students are also trusted That is a tall bet :D If anyone is going to try out crazy stuff for the sake of curiosity/pranks, it would be students.
- seanwilson 6y ago
  > I doubt this mode of usage will ever get enough attention to be even moderately secure. Don't shared web hosts count?
- eqvinox 6y ago
  All nontrivial multi-user installations I'm aware of (universities, corporate, ... make it a dozen I've had to deal with) have one thing in common: none of them use things like accountsservice, policykit et al. Any extra plumbing, if necessary, is done through PAM one way or another.
- andyroid 6y ago
  Pretty much all servers I’ve ever worked with was multi-user. What’s even the alternative? A single account shared by all admins? That sounds like a nightmare from both a security and an auditing perspective.
AlphaGeekZulu 6y ago
There is a lot of discussion in this thread about the involved components, technical details of the exploit, the guilt of specific distributions and patch policies. However, the underlying core problem of the vulnerability is absolutely independent of any specific component, vendor, product or policy. The core problem are developers not thinking their stuff out. Reading from a file is an absolutely non trivial task, million things can go wrong and the responsible developer has to foresee and handle them all in a generic sane way. Maybe do not read until EOF, if you never expect more than a few bytes? Read the file async with a timeout? Taint the input? Do not put the system in a dependent, unsecure state before success of the operation. Expect stuff to fail and code accordingly! Think like a hacker and try to hack your own code. And do this for any single line of your code. I learned to introspect my code in this way as a byproduct of learning Rust. It began with Rust's strict type system, which forced me to carefully consider each and every value and variable and how I toss them around and how and where and how long I am going to access them in my code. It continued with the error handling policies of Rust in a similar way. The learning curve of Rust was steep for me and coding the first months was tedious. But once I got the hang of it, I started to love it. Fighting the compiler, I have to go through every aspect of my code in a super careful way over and over again and once the compiler gives the Go, I feel love and appreciation for my code - as if I crafted something special, that was approved by the master. Code no longer was for me something thrown into the editor as fast as possible with just the effort to make it run somehow reliably. I felt now, as if my code was a piece of art, well thought out and beautifully crafted, made to serve for many years, like a musical instrument. In other words, Rust was changing the appreciation of my own work and gently shoved me to a more careful approach of coding. At some point in development I go through my code to do some manual formatting, you know, aesthetic stuff like indenting to make the code look more beautiful (in a human way, not a linter's way). Like a last polish. And on this run, I look at my code as a hacker. How would I crack it? How would it handle that and that exception? I try to think really evil. I think many programmers shy away of this step, because it can mean a lot, a lot of new work. And this is where Zero Days as the one described in the thread originate.
gcbirzan 6y ago
What I find amusing is that the code for reading that .pam_environment file is broken: https://git.launchpad.net/ubuntu/+source/accountsservice/tree/debian/patches/0010-set-language.patch?h=ubuntu/focal-updates&id=e0347185d4c5554b026c13ccca691577c239afd5#n387 https://git.launchpad.net/ubuntu/+source/accountsservice/tre... Basically, if the LANG and LC_ALL appear are across two 50 byte regions of the file, it'll fail to find them.
- asddubs 6y ago
  it would be 50 byte regions of any given line, right?
  - gcbirzan 6y ago
    They don't even take that into account, which is another issue. They just look for those two strings in any 50 byte block, so if you have FOO=LANG\n that'll count as having LANG set.
- GoblinSlayer 6y ago
  fgets reads a line, not 50 chars
  - eMSF 6y ago
    fgets reads until the next newline character, or at most size-1 characters. For arbitrary inputs, a loop like that sets ret to TRUE if the given prefix (i.e. LANG) is found at the beginning of any line, i.e. starting at the first column – or for longer lines, if it is found starting at the 50th column (or 99th column, etc.) I don't know enough of the format of the .pam_environment file to tell whether that may lead to unexpected results.
zecg 6y ago
The first I do on a new Ubuntu install is apt install ubuntu-unity-desktop instead of gnome and choose lightdm instead of gdm.
deleted 6y ago
[deleted]
deepender99 6y ago
That's Why GUI is always hackable, vulnerability are always there hidden in 01 logic !!
boogies 6y ago
Nit: isn’t > Armed with accounts-daemon’s PID, you can use kill to send the SIGSTOP signal what `pkill` is for?
franky_g 6y ago
Congratulations and well done for finding this bug, you deserve a virtual medal of some sort..
varispeed 6y ago
This reminds me when I figured out how to get into a desktop from a locked Windows machine (can't remember which one, maybe 95). It was my "party trick" for a while and friends thought I am a hacker. Then I learned this was commonly known and later nobody believed me I found it on my own.
- devenblake 6y ago
  What trick did you use?
  - varispeed 6y ago
    I can't remember exact details, but I was able to open help from the locked screen and then from help I was able to launch the explorer. I think it was similar to this: https://i.imgur.com/rG0p0b2.gif https://i.imgur.com/rG0p0b2.gif
blindm 6y ago
Is it me or does a blogpost saying that in order to get root I enter a bunch of commands in my terminal seem a bit aloof?
T3RMINATED 6y ago
I've been doing this for about 2 years now... your not the first.
hedora 6y ago
Modern Linux kernel APIs are asynchronous spaghetti. Someone realized blocking userspace could be a performance issue (you need to spawn a thread to invoke the kernel API if you want to stay responsive while the kernel does stuff), and that using the setuid bit in large daemons is dangerous (they had already decided to abandon the unix way, where there are small binaries, and each does one thing well). The solution was to make everything asynchronous without providing proper barrier operations, expose it via local network daemons, and to layer a new permissions system atop it. To see why this makes things hard, consider using modprobe to load a hardware driver. It has to detect and initialize hardware, and this can take some time. That happens in the background, so you need to be able to ask the driver if the hardware has “settled” before proceeding. Otherwise, you can’t differentiate between “zero wifi cards” and “wifi card is almost ready”. That’s probably fixable, but hardware isn’t attached to a flat bus. What if the wifi is on a usb bus that’s initializing? What if it’s plugged into a usb hub that’s initializing? The “solution” is to double down on the problem: Introduce an event bus that anything can talk to, and have it asynchronously forward messages between processes and the kernel. It eventually tells userspace when new hardware arrives, but that creates a new problem. How long should the startup scripts wait to start things like ntp and nfs clients? You can’t interaxt safely with the filesystem until those daemons are ready. What about X11? Locking users out when there’s no video card is bad. So is dropping to a text prompt for a few seconds. Anyway, it’s clear this was never thought through to a clean solution. Clean solutions exist in other systems, of course, but not here. Before systemd became the spearhead of this train wreck, people frequently complained about dbus (the subject of this article) for exactly these reasons. So, it’s not surprising there are security holes like this. We’re currently in a situation where Linux’s userspace has reimplemented unix permissions in a way that only a few understand, and manages a sprawling multi-process asynchronous state machine on top of that. The authors of this mess didn’t bother to write manpages for the underlying daemons, so the inner workings of this stuff is extremely obscure and unvetted. Worse, it has hooks into everything in the Linux desktop, and has been spreading like cancer for over a decade.
e12e 6y ago
Nice write-up. Might be even easier to just use pkill accounts-daemon and gnome-session-quit: pkill -SIGSTOP accounts-daemon && nohup bash -c "sleep 5s; pkill -SIGSEGV accounts-daemon; pkill -SIGCONT accounts-daemon" & gnome-session-quit I think that should be equivalent, but haven't tried (my desktop is patched).
yrro 6y ago
Hm. If a user can send signals to accounts-daemon then can they ptrace(2) it and take over the system that way?
- YtvwlD 6y ago
  No, you can't attach to processes (that are not child-processes of yours) with the default Ubuntu configuration.
  - yrro 6y ago
    Oh yeah, that's Yama's ptrace_scope isn't it...
fuzxi 6y ago
>The next step is to send a SIGSTOP signal to accounts-daemon to stop it from thrashing that CPU core. But to do that, you first need to know accounts-daemon’s process identifier (PID). Or just 'pkill -SIGSTOP accounts-daemon'. pkill matches by process name.
known 6y ago
accounts-daemon.service is a potential security risk. It is part of AccountsService, which allows programs to get and manipulate user account information. I can’t think of a good reason to allow this kind of behind-my-back operations, so I mask it. sudo systemctl stop accounts-daemon.service && sudo systemctl disable accounts-daemon.service https://www.linux.com/topic/desktop/cleaning-your-linux-startup-process/ https://www.linux.com/topic/desktop/cleaning-your-linux-star...
kazinator 6y ago
> Send accounts-daemon a SIGSEGV signal, which will make it crash. Shouldn't that be a root process to which a non-root process cannot send signals? Unix Basics 101
mleonhard 6y ago
The root cause is a very common bug: treating no response as an empty response. It's usually caused by missing or bad error handling. Some libraries and RPC APIs make it impossible to differentiate between the two cases. I've recently learned a lot of Rust. Rust's std::result::Result type [1] helps avoid this error. I think it is superior to the error handling facilities in other languages: - C: errno, boolean return values, `null` - C++: exceptions, errno, boolean return values, `null`; std::expected<T,E> is being developed - Java: exceptions, `null`, Optional<T> - Golang: `nil`, `error`, `if err != nil { return nil, err }` boilerplate - Javascript: `undefined`, exceptions, futures - Python: exceptions, `None`, boolean return values - Swift: exceptions, `nil`, `try?`, optional values - Dart: exceptions, futures, `null` Would it be worthwhile to create Result-like error handling libraries for the major languages? [1]: https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...

I didn't see it mentioned in the article, so just to clarify, this was fixed with https://ubuntu.com/security/notices/USN-4616-1 https://ubuntu.com/security/notices/USN-4616-1

SiVal 6y ago
How can you tell if an Ubuntu 20.04 server has this fix?
- severino 6y ago
  You can use "apt-cache policy", for example. This way you can see the current installed version of a package in your system, and also if there's a newer version you can install (the candidate). $ apt-cache policy accountsservice accountsservice: Installed: 0.6.40-2ubuntu11.6 Candidate: 0.6.40-2ubuntu11.6 If the installed version reported by the utility is the version that Ubuntu states the problem has been fixed for your release, then presumably your system is safe (for this bug).
- Forbo 6y ago
  The article states that server isn't affected, because it requires access to a graphical desktop session. Edit with direct quote from the article: > Disclaimer: For someone to exploit this vulnerability, they need access to the graphical desktop session of the system, so this issue affects desktop users only. Am I wrong?
  - hitpointdrew 6y ago
    Only if the server has no GUI installed. I worked a place where the Network Admin, had a bunch of older RedHat servers with GUI's. I had to become the "bad guy" because on the newer boxes I was in charge of I refused to install a GUI, a bunch of devs pissed and moaned because they couldn't use xterm to connect to the new servers. It was pretty backwards place.
    - freedomben 6y ago
      At the risk of igniting an irrelevant flame war, this is one of the primary reasons why I use Vim and only Vim as my IDE. I don't have to care about lack of graphical environments ;-)
      - jdhawk 6y ago
        side note, long time - and still current vim developer who also uses JetBrains IDE products... I'd pay similar money to have a similarly robust VIM plugin from a supported vendor with great support and sane keybindings OOTB. man, its easy to get spoiled with tons of ram and a great IDE.
        freedomben 6y ago
        Yes, I don't know if anybody will ever see this, but I agree! I would gladly pay similar for a robust VIM plugin setup that gave me similar features on a range of languages.
    - tinco 6y ago
      We run some machine learning systems on Ubuntu server, and it's really easy to accidentily install the full desktop environment while installing random graphics driver related packages. While figuring out how to set things up (before I formalized in an ansible script) one of the servers ended up with the desktop packages installed. Weird to look at the IPMI overview and between all the white on black kernel log outputs suddenly seeing a full Ubuntu desktop boot screen.
  - zeta0134 6y ago
    It's somewhat common to install a graphical environment on server machines, particularly if they need to run certain (Oracle) enterprise software, for which GUI tools are either the only option, or by far the most expected and documented solution. Of course in theory you could install the bare minimum to run the utility using X-forwarding, in practice anyone doing this usually installs a full environment because it's much simpler to manage. Plus, there are a few admins out there who simply prefer to use VNC over a straight terminal. I'm not here to judge; while this is uncommon, it's certainly not unheard of. Personally I would rather not have that much attack surface on my servers, but there are a few legitimate use cases here and there.
    - Twirrim 6y ago
      > It's somewhat common to install a graphical environment on server machines It's really not that common. Yes there's the odd cases of servers that use enterprise software that have to have GUIs, but most linux boxes run headless. GUIs are just a waste of processing power and resources for the large majority of the things that servers are used for. That said, I'm not happy that Canonical are entirely discounting the possibility that customers will have desktop environments installed on servers. It's not common, but it does happen.
      - dannyw 6y ago
        One thing to note is that depending on how your network is structured and firewalled, if _one_ server has a graphical env of some sort (maybe a ML/image processing server that has graphical environments installed)... root access could be nasty nonetheless. I never install GUIs on my servers, but when deploying a image processing server, while installing another package to debug CUDA/drivers, I've unintentionally added a full windowing system without realising it.
        woodson 6y ago
        Unfortunately, nvidia-settings requires xorg to be installed and running (even when run in cli mode), and it's pretty much the only way to control fan speeds on consumer GPUs.
- Denvercoder9 6y ago
  Check if the installed version is equal to or higher than one of the listed fixed versions. Likely it isn't even installed on a server edition.
- e12e 6y ago
  Assuming the server can reach the normal apt repos - you could: sudo apt update; apt list upgradable And grep for this package. Otherwise sudo apt update /usr/lib/update-notifier/apt-check --human-readable Will list number of pending security updates. (part of update-notifier-common, and in task:server along with various desktop-tasks) Beyond that, you might want to look at https://vuls.io https://vuls.io or other auditing packages. Or perhaps: sudo snap install cvescan cvescan Seems it could use some exposure - I wasn't aware of it: https://github.com/canonical/sec-cvescan https://github.com/canonical/sec-cvescan

s_gourichon 6y ago

Excellent job Of research and presentation!

WayToDoor 6y ago

Very good writeup. It's amusing that Ubuntu didn't double check in the user creation tool to ensure there was in fact no current administrator account. Sounds like a fun day to me.

_kst_ 6y ago
An administrator account, in this context, is one that's a member of the "sudo" group. It's perfectly ordinary for more than one account to be a member of that group.

javajosh 6y ago

Fascinating. This exploit doesn't feel like something someone would just stumble upon. Is the main value of this work to reduce the price of an exploit on the black market? Of interest to me is that this exploit, although patched, is probably still valuable since not everyone patches their system. EDIT: Oops, I didn't read the deep dive section, and I guess he says how he stumbled upon it. My bad!

MauranKilom 6y ago
He literally describes at the end of the post how he stumbled upon it...

ajsnigrutin 6y ago

What the hell does accuntservice do, and why does ubuntu need a dedicated service for that? To clarify, do we really need a service (and an unsafe, exploitable one), to do something, we've been doing without it for years on all other distros.

npsimons 6y ago
I actually got a decent answer to this, from what appears to be a developer working on something in the FreeDesktop.org ecosystem: > Way better for writing gui apps against instead of wrapping suid binaries and parsing strings horribly. I would call that a laudable goal. Just seems like the design needs a deep security review.
ecnahc515 6y ago
The unsafeness here was GDM, not accountservice.

mehrdadn 6y ago

> It turns out that Ubuntu uses a modified version of accountsservice that includes some extra code that doesn’t exist in the upstream version maintained by freedesktop. I guess next time people ask why I like a distro like Arch that doesn't insert its own junk into upstream code over Debian/Ubuntu/et al, I'll have a new example handy to cite.

symlinkk 6y ago
Yeah I hate it when distros do this. Does Debian actually change upstream significantly? I thought they kept things fairly vanilla. I know Fedora patched in VAAPI support on Firefox before it was merged into the Mozilla codebase. I can’t think of a worse piece of software to patch, the last thing I want to be running untested code on is my web browser.
- jasonjayr 6y ago
  Most of the Debian changes I've seen consist of changing default paths to match Debian's standards, backporting security changes (esp if a version bump changes functionality), and support 'conf.d' directories so packages can drop-in configuration files, and remove them easily.
  - ClumsyPilot 6y ago
    > "backporting security changes (esp if a version bump changes functionality" Thats not a trivial matter, its a potential source of many issues
    - marcosdumay 6y ago
      It's also a source of many solutions. There are really no perfect option here. Upstream and distro developers have different goals, and it's up to you to decide what you should adopt.
      - jhardy54 6y ago

denysvitali 6y ago

Article well written and noteworthy exploit explanation. Bravo! 10/10

usr1106 6y ago

I like slim Linux machines and I several times considered to remove or at least disable accountservice. I has never been clear to me why you need such service as long as /etc/passwd is world readable. So from this article I learn * calling mount during installation(?) when there is no user. Makes no sense to have the daemon running later * providing a user icon. Exactly the type of functionality I like to throw out * providing a user specific language setting. I can see that this is useful for some users So how is dropping privileges done correctly to avoid getting killed by the user? Running as another user is one way, but I guess that is not always feasible if you want the daemon provide services for the user. On the other hand accountservice is there for multiple (human) users. So as which of them is it running? Not at a machine right now...

deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
mehrdadn 6y ago
> So how is dropping privileges done correctly to avoid getting killed by the user? I was wondering this too. What is the way to "correctly" drop privileges? Is it even possible to drop privileges within a process in a way that's immune to this?
- jontro 6y ago
  I guess you could fork first?
  - jasonjayr 6y ago
    Fork then handle child/exec error codes appropriately.
    - usr1106 6y ago
      Right, if the child runs as the user, the parent still running as root can reliably handle the situation that the user killed the child. Don't remember having seen that. Well, sshd does it, but for more obvious reasons than handling signals.

hanemile 6y ago

Wonderful write-up, great step by step descripting and some more insights on the underlying problems. There should me more write-ups structured like this!

Quarrel 6y ago

Without taking anything away from this, as a general rule, if you have physical access to the machine, it can almost definitely be compromised. The flaw here involves access to the GUI, which in most cases implies that they have physical access. (and in most cases would imply it is "their" machine in any event)

aftbit 6y ago
Generally agreed. This specific issue seems most likely to be a problem in a computer lab environment, where you'd likely be detected if you tried to take the case off the machine, but might be able to get away with anything that looks like normal computer use behavior.
woofie11 6y ago
No. That's not a general rule. Many universities have computer labs. The computers are in a locked cabinet, with a keyboard, mouse, and monitor exposed. For that matter, many shopping malls have information kiosks, retail stores have demo laptops, banks have ATM machines, airlines have automatic check-ins, etc. If you're typing away, no one will care. If you're opening up the device with a crowbar, or even screw driver, you'd better have a nice orange high-viz uniform, lanyard, and clipboard. Without those, security will drag you awat.
- exabrial 6y ago
  I'm not sure if you were trying to prove his point, but you did
  - woofie11 6y ago
    I'm pretty sure I know what constitutes a proof, and that wasn't it. The core reason this did not constitute a proof is because physical security people misapply lessons from that domain to digital, and software engineers misapply lessons from digital to physical. In the virtual world, I'm open to 7 billion potential attackers. In the physical world, I'm open to a few. That leads to very different security practices. If I leave my front door unlocked for a week, the security risk is minimal where I live. Casual security is good enough. If I leave my computer with even a pretty obscure vulnerability connected to the internet for 5 minutes, odds are pretty good it will be compromised. Clipboards+lanyard+high viz vest is imperfect security (and I chose the example deliberately to illustrate that), but it is good enough security to practically prevent physical compromises in most instances. I won't run a military base that way, or a HIPAA-compliant data system, but it's good enough for 95% of uses, including, for example, a university physics department's research data system. Even a military base doesn't have perfect security; a well-resourced attacker can compromise it. In contrast, in the virtual world, I want cryptographic protocols where I can prove perfect security, at least given a relatively small set of assumptions.

cpgxiii 6y ago

it strikes me that the serious bug here is the design of GDM to check accounts-daemon for existing accounts, and if that check times out, start account creation. Regardless of the nominal protections afforded by the system, if you rely on a daemon that accepts unprivileged user input to provide security-critical answers, and fail open if it doesn't respond, that's a bad idea.

effie 6y ago
Agreed, login manager should be saner (less relying on other processes) than that. Also, the very existence of accounts-daemon concept seems to be a mistake from the security and simplicity point of view.
a-dub 6y ago
yup. think it's fine to have a service that manages accounts, but a timeout in contacting it resulting in the start of a process that creates users (with privileges) is definitely no good. would be interesting to understand how it happened. is it a straight up bug? is it some sort of fallback in gdm to work around non-responsive account-service (potentially on new machines)? is it some sort of backwards compatibility thing? i can't imagine that it was coded that way intentionally, would be interesting to understand how it ended up that way...
steerablesafe 6y ago
Maybe GDM shouldn't even have the privilege to create a new account in the first place. Couldn't every privileged operation be requested through accounts-daemon?

benlivengood 6y ago

The first documentation I could find about accounts-daemon by googling is this: https://utcc.utoronto.ca/~cks/space/blog/linux/UbuntuAccountsServiceProblems https://utcc.utoronto.ca/~cks/space/blog/linux/UbuntuAccount... Not reassuring.

npsimons 6y ago
In my over twenty years of using Linux, this is the first I had heard of "accounts-daemon", and I'm the kind of nerd who browses repositories for fun, looking for new and interesting packages. So I googled "accounts-daemon", and these are the titles for the first three results: 1. "What does accounts-daemon actually do?" 2. "Should I disable accounts-daemon?" 3. "Process accounts-daemon taking 100% of CPU." Not reassuring indeed.
- jasonjayr 6y ago
  It's from the freedesktop folks. (Like systemd, dbus, pulseaudio, and all sorts of other services to make linux more 'desktop' friendly)
  - npsimons 6y ago
    Yeah, that's a windmill I've given up tilting at. And it has gotten better, but mostly through painful learning experiences like this one. But some days I wonder if I'd just be better off moving to OpenBSD or heck Plan 9 or Inferno.
    - 35fbe7d3d5b9 6y ago
      > OpenBSD Use a Thinkpad that's not too new? OK without 802.11ac and Bluetooth? Come take a dip, the water is just fine.
      - mrguyorama 6y ago
        Wait, why can't OpenBSD handle Bluetooth? Is it just that the same chip is used for both wireless protocols and it doesn't support them yet?

hyperion2010 6y ago

Well this vindicates my years of keeping policykit and all that other nonsense off my systems (sadly haven't found a way to zap dbus). The less code you have the less opportunities there are to screw something up.

fs2 6y ago
Exactly, I'm running fine without Pulseaudio, Policykit and SystemD. Good old sysv init scripts always work, less complexity means less chance for bugs creeping in.

RickJWagner 6y ago

Wow. Well written and easy to understand. I hope Ubuntu gets right on that one.

segmondy 6y ago

What's amusing is that this is a classic 30+yrs old "sym link" exploit. Interesting how classic most of the exploits coming up are, almost like the current generation don't know the lessons of the past ...

gizmo686 6y ago
Its not quite a classic synlink exploit. Normally, the purpose of a symlink exploit is to get a privledged process to leak information about a file you don't have access to. Here, as the article mentions, part of the attack relies on the fact that the privledged process goes out of its way to defend against such an attack. As far as I can tell, the symlink is not even nessasary. You should be able to get the same effect by making 1TB big. Using sparse files, you don't even need much disk space.

stormbrew 6y ago

While the DoS of accounts-daemon is bad, it seems like the real problem here is that gdm3 running with broken/absent/etc. accounts-daemon will believe there are no accounts even though there may be? Surely this is extremely trusting behaviour on gdm3's part and should also be fixed? But all the updated versions are for accounts-version, not gdm3. Do they change the 'default' response somehow?

sce 6y ago
Looks like it's fixed upstream https://gitlab.gnome.org/GNOME/gdm/-/issues/642 https://gitlab.gnome.org/GNOME/gdm/-/issues/642
- stormbrew 6y ago
  Ah, cool. That's good. CVE for that appears to be https://nvd.nist.gov/vuln/detail/CVE-2020-16125 https://nvd.nist.gov/vuln/detail/CVE-2020-16125 and fixed in 3.36.2 or 3.38.2..

glglwty 6y ago

> [...] gdm3 thinks that there are zero user accounts and it launches gnome-initial-setup. What if the root user intentionally deleted all non-root users? GDM would just let anyone creates an user with wheel?

nexuist 6y ago
The root user obviously counts as a user account, otherwise you would be prompted to make a new account on every startup if you hadn't made any other accounts. The reason why it thinks there are zero accounts in this instance is because you've just killed the service daemon that would provide that number, so no number is received through the DBus call.

trilinearnz 6y ago

Slightly offtopic, but a common exploit(?) I frequently see with Linux desktop environments is a few seconds where the user's live desktop is displayed after resuming from standby, before the logon screen comes up. Not exactly a case of obtaining control of one's computer, but could be effectively used through repetition to transcribe any sensitive content that may have been onscreen. It always struck me as a very strange phenomenon to occur given the apparent security superiority of Linux in contrast to Windows. Perhaps that's an antiquated notion now, given modern distros that prioritise form-over-function more than they used to?

nexuist 6y ago
This actually used to be a common problem I would have on macOS, especially when docked to an external display. I wonder if these problems are connected somehow.
- saagarjha 6y ago
  I think it’s just a fundamental problem of running a program that is essentially like any other that covers the screen.
  - trilinearnz 6y ago
    I can see how that could come about (lumping window manager concerns all into the one bucket), but to me it's security implications make a good case for re-architecting this part of the system. I.e. having a separate part of the OS which marshals access to the visible desktop when transitioning between ACPI states. For hardware-accelerated compositing situations, it might have something to do with unnecessarily long / out-of order retention of the GPU frame buffer, which I could conceive of as being dismissed as inconsequential in most circumstances.
unethical_ban 6y ago
It is entirely off-topic, and I have observed exactly the same phenomenon. I have also felt the same reaction - "Isn't Linux \"better\" "? I have a 20.04 thinkpad that I rarely use for reasons (partly that it doesn't come out of suspend most of the time, forcing a hard reboot) but I remember this being a problem back when my Ubuntu install was functional :)

gbrown_ 6y ago

Not sure why this wasn't a dupe of my submission [1] submitted ~8 hours earlier? Oh well. [1] https://news.ycombinator.com/item?id=25046588 https://news.ycombinator.com/item?id=25046588

vlovich123 6y ago

Can anyone help me understand this part? > Dropping privileges means that the daemon temporarily forfeits its root privileges, adopting instead the lower privileges of the user. Ironically, that’s intended to be a security precaution, the goal of which is to protect the daemon from a malicious user who does something like symlinking their .pam_environment to /etc/shadow, which is a highly sensitive file that standard users aren’t allowed to read. Unfortunately, when done incorrectly, it also grants the user permission to send the daemon signals, which is why we’re able to send accounts-daemon a SIGSEGV. What’s the recommended way to drop permissions while blocking the ability to kill the process (sure you can mask off SIGSEGV but SIGKILL isn’t maskable)? Also, the wording makes it sound like you can re-acquire the original permissions which I thought is impossible. Isn’t dropping permissions a one-way operation? I would have thought there was some usage of fork here but the usage of `pidof` and 1 result in the write up would imply no forking. Maybe a link to the source here would be sufficient for me (I don’t see one in the article or in the thread here).

vlovich123 6y ago
Answering my own question. Found the bug report: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1900255 https://bugs.launchpad.net/ubuntu/+source/accountsservice/+b... Accountservice is actually changing its user ID rather than dropping capabilities which is where my confusion came from. It looks like there’s magic in the kernel to allow a process to switch back to the original user & some nuance about some ways of switching allowing you to send signals while other ways make your process act like a semi-hybrid of two user accounts (I.e. it technically looks owned by your user but you still don’t have permissions to do things with it). Security issues always lie in these kind of weird nuances.

gorgoiler 6y ago

More unwanted complexity in the base system :( I wish I had a Linux distro that split the OS from the userland more neatly. I want to boot into something minimal and static, and then add complexity from there. Maybe logging in to a local container instead of the actual OS? Linux as an easily extendable building filled with rooms and workshops and entertainment areas, rather than Linux as a mere desktop.

LambdaComplex 6y ago
Maybe look into Qubes OS? I've never used it, but the concept sounds kinda like what you're describing: "a security-focused desktop operating system that aims to provide security through isolation. Virtualization is performed by Xen, and user environments can be based on Fedora, Debian, Whonix, and Microsoft Windows, among other operating systems." (from Wikipedia)
jdally987 6y ago
NixOS, my friend. NixOS. I still can't believe it's not more widely used (and I only started using linux full-time earlier this year). It confines the entire (non-user) filetree into the read-only /nix directory, and manages every single component of the OS through Nix, the package manager - and I guess nix-daemon in the case of NixOS specifically - 100% declaratively. You define the entire thing through a single configuration.nix file. You can even do crazy stuff like erasing the root upon each reboot, leaving only /nix and /home if you wanted, and I think I remember in the article I was reading about it that it can mount everything on a tmpfs or something like that, so you have a perfectly "clean" root tree every time you restart the computer (as /nix is stateless, it's guaranteed not to change except when rebuilding the system configuration). The point of nixos is really the declarative aspect, with "splitting" the OS being more of a secondary benefit, but for your case, you might like the whole declarative builds thing in general to accomplish that.
- AnIdiotOnTheNet 6y ago
  > NixOS, my friend. NixOS. Is there an option that doesn't require everyone who uses it to learn an entirely new language?

quotemstr 6y ago

The real problem is here: > It uses D-Bus to ask accounts-daemon how many users there are, but since accounts-daemon is unresponsive, the D-Bus method call fails due to a timeout. (In my testing, the timeout took around 20 seconds.) Due to the timeout error, the code does not set the value of priv->have_existing_user_accounts. Unfortunately, the default value of priv->have_existing_user_accounts is false, not true, so now gdm3 thinks that there are zero user accounts and it launches gnome-initial-setup. I am sick and tired of programs trying to continue onward somehow after encountering "impossible" error conditions or tripping over arbitrary timeouts. Failing fast when something looks funny is essential to the creation of a secure system. When you write something like the gdm3 code above --- which, when it runs into trouble, clears any ambient error and pretends that the system has no current users --- you may think you're doing the user a favor by continuing to operate, but what you're doing is in fact willfully entering some unknowable and unexplored region of the system's state space, usually one full of dragons and anthrax. What you want to do instead is just die when something goes wrong. gdm3 should respond to a failure to contact org.freedesktop.Accounts with either a hard lockup or a forced restart of the gdm3 daemon.

lovehashbrowns 6y ago
The usage for code that I currently write is internal and it’s made with usability in mind, so I am guilty of coding stuff like this on occasion. By that I mean that my code, under certain circumstances, assumes the best and continues moving forward. I do this for a specific reason: I don’t want my team to get pinged with a support request for something trivial. So this type of bug is a huge eye opener for me. I still want to strike a balance between usability and clarity, but this story makes me want to review a lot of the code I’ve written. None of it is mission critical and on this level, luckily.
- quotemstr 6y ago
  I've found that I spend more time debugging arcane horrible things that go wrong as downstream consequences of recovery paths than I do debugging straightforward and obvious problem reports that come from hard assertion failures and failing fast.

arthurcolle 6y ago

What a cute little exploit, just lurking there in the wilderness waiting to make some friends

choeger 6y ago

I think there is a large part of that story missing. If the accounts daemon drops privileges for reading from the user's home, how can it ever get back to its normal state? How could two users run the same operation concurrently? Normally that privilege dropping should happen after forking, right? And if it does the parent process should respond to gdm's inquiry. That being said, the initial settings thing is probably good for a few more escalations as its usecase does not seem to fit the standard security measures very well.

kevsim 6y ago
I believe with seteuid the process can temporarily assume the uid of the user in question and later restore the original uid.
jwilk 6y ago
From the setresuid(2) man page: > An unprivileged process may change its real UID, effective UID, and saved set‐user‐ID, each to one of: the current real UID, the current effective UID or the current saved set‐user‐ID. accountsservice did something like setresuid(uid, uid, -1), which set both real and effective UIDs, but kept saved set‐user‐ID as root, so that it could re-gain root privileges later. Setting EUID was the correct course of action; but setting real UID let the unprivileged user kill the process.
- steerablesafe 6y ago
  Would it have been possible to attach a debugger to accountsservice in this state and execute arbitrary code, including re-gaining root privileges?
  - jwilk 6y ago
    Very good question. :-) No, you can't use ptrace(2) on a process that has changed its EUID. For details, see PR_SET_DUMPABLE in the prctl(2) man page.
    - 6y ago

Uhrheber 6y ago

Seems that Mint also inherited this vulnerability.

admax88q 6y ago

I honestly have no faith in multi user linux. I would never give someone I didn't trust an unprivileged account on my system, nor physical access to my device. There are so few multi user machines in existence that I doubt this mode of usage will ever get enough attention to be even moderately secure.

pantalaimon 6y ago
machines in universities are typically multi user
- aflag 6y ago
  The students are also trusted, or at least accountable. It's very different than a random stranger. That said, I wouldn't store anything truly private in a shared box like that, specially in the university, where the boxes are likely to be maintained by inexperienced undergrads.
  - pantalaimon 6y ago
    > The students are also trusted That is a tall bet :D If anyone is going to try out crazy stuff for the sake of curiosity/pranks, it would be students.
seanwilson 6y ago
> I doubt this mode of usage will ever get enough attention to be even moderately secure. Don't shared web hosts count?
eqvinox 6y ago
All nontrivial multi-user installations I'm aware of (universities, corporate, ... make it a dozen I've had to deal with) have one thing in common: none of them use things like accountsservice, policykit et al. Any extra plumbing, if necessary, is done through PAM one way or another.
andyroid 6y ago
Pretty much all servers I’ve ever worked with was multi-user. What’s even the alternative? A single account shared by all admins? That sounds like a nightmare from both a security and an auditing perspective.

AlphaGeekZulu 6y ago

There is a lot of discussion in this thread about the involved components, technical details of the exploit, the guilt of specific distributions and patch policies. However, the underlying core problem of the vulnerability is absolutely independent of any specific component, vendor, product or policy. The core problem are developers not thinking their stuff out. Reading from a file is an absolutely non trivial task, million things can go wrong and the responsible developer has to foresee and handle them all in a generic sane way. Maybe do not read until EOF, if you never expect more than a few bytes? Read the file async with a timeout? Taint the input? Do not put the system in a dependent, unsecure state before success of the operation. Expect stuff to fail and code accordingly! Think like a hacker and try to hack your own code. And do this for any single line of your code. I learned to introspect my code in this way as a byproduct of learning Rust. It began with Rust's strict type system, which forced me to carefully consider each and every value and variable and how I toss them around and how and where and how long I am going to access them in my code. It continued with the error handling policies of Rust in a similar way. The learning curve of Rust was steep for me and coding the first months was tedious. But once I got the hang of it, I started to love it. Fighting the compiler, I have to go through every aspect of my code in a super careful way over and over again and once the compiler gives the Go, I feel love and appreciation for my code - as if I crafted something special, that was approved by the master. Code no longer was for me something thrown into the editor as fast as possible with just the effort to make it run somehow reliably. I felt now, as if my code was a piece of art, well thought out and beautifully crafted, made to serve for many years, like a musical instrument. In other words, Rust was changing the appreciation of my own work and gently shoved me to a more careful approach of coding. At some point in development I go through my code to do some manual formatting, you know, aesthetic stuff like indenting to make the code look more beautiful (in a human way, not a linter's way). Like a last polish. And on this run, I look at my code as a hacker. How would I crack it? How would it handle that and that exception? I try to think really evil. I think many programmers shy away of this step, because it can mean a lot, a lot of new work. And this is where Zero Days as the one described in the thread originate.

gcbirzan 6y ago

What I find amusing is that the code for reading that .pam_environment file is broken: https://git.launchpad.net/ubuntu/+source/accountsservice/tree/debian/patches/0010-set-language.patch?h=ubuntu/focal-updates&id=e0347185d4c5554b026c13ccca691577c239afd5#n387 https://git.launchpad.net/ubuntu/+source/accountsservice/tre... Basically, if the LANG and LC_ALL appear are across two 50 byte regions of the file, it'll fail to find them.

asddubs 6y ago
it would be 50 byte regions of any given line, right?
- gcbirzan 6y ago
  They don't even take that into account, which is another issue. They just look for those two strings in any 50 byte block, so if you have FOO=LANG\n that'll count as having LANG set.
GoblinSlayer 6y ago
fgets reads a line, not 50 chars
- eMSF 6y ago
  fgets reads until the next newline character, or at most size-1 characters. For arbitrary inputs, a loop like that sets ret to TRUE if the given prefix (i.e. LANG) is found at the beginning of any line, i.e. starting at the first column – or for longer lines, if it is found starting at the 50th column (or 99th column, etc.) I don't know enough of the format of the .pam_environment file to tell whether that may lead to unexpected results.

zecg 6y ago

The first I do on a new Ubuntu install is apt install ubuntu-unity-desktop instead of gnome and choose lightdm instead of gdm.

deleted 6y ago

[deleted]

deepender99 6y ago

That's Why GUI is always hackable, vulnerability are always there hidden in 01 logic !!

boogies 6y ago

Nit: isn’t > Armed with accounts-daemon’s PID, you can use kill to send the SIGSTOP signal what `pkill` is for?

franky_g 6y ago

Congratulations and well done for finding this bug, you deserve a virtual medal of some sort..

varispeed 6y ago

This reminds me when I figured out how to get into a desktop from a locked Windows machine (can't remember which one, maybe 95). It was my "party trick" for a while and friends thought I am a hacker. Then I learned this was commonly known and later nobody believed me I found it on my own.

devenblake 6y ago
What trick did you use?
- varispeed 6y ago
  I can't remember exact details, but I was able to open help from the locked screen and then from help I was able to launch the explorer. I think it was similar to this: https://i.imgur.com/rG0p0b2.gif https://i.imgur.com/rG0p0b2.gif

blindm 6y ago

Is it me or does a blogpost saying that in order to get root I enter a bunch of commands in my terminal seem a bit aloof?

T3RMINATED 6y ago

I've been doing this for about 2 years now... your not the first.

hedora 6y ago

Modern Linux kernel APIs are asynchronous spaghetti. Someone realized blocking userspace could be a performance issue (you need to spawn a thread to invoke the kernel API if you want to stay responsive while the kernel does stuff), and that using the setuid bit in large daemons is dangerous (they had already decided to abandon the unix way, where there are small binaries, and each does one thing well). The solution was to make everything asynchronous without providing proper barrier operations, expose it via local network daemons, and to layer a new permissions system atop it. To see why this makes things hard, consider using modprobe to load a hardware driver. It has to detect and initialize hardware, and this can take some time. That happens in the background, so you need to be able to ask the driver if the hardware has “settled” before proceeding. Otherwise, you can’t differentiate between “zero wifi cards” and “wifi card is almost ready”. That’s probably fixable, but hardware isn’t attached to a flat bus. What if the wifi is on a usb bus that’s initializing? What if it’s plugged into a usb hub that’s initializing? The “solution” is to double down on the problem: Introduce an event bus that anything can talk to, and have it asynchronously forward messages between processes and the kernel. It eventually tells userspace when new hardware arrives, but that creates a new problem. How long should the startup scripts wait to start things like ntp and nfs clients? You can’t interaxt safely with the filesystem until those daemons are ready. What about X11? Locking users out when there’s no video card is bad. So is dropping to a text prompt for a few seconds. Anyway, it’s clear this was never thought through to a clean solution. Clean solutions exist in other systems, of course, but not here. Before systemd became the spearhead of this train wreck, people frequently complained about dbus (the subject of this article) for exactly these reasons. So, it’s not surprising there are security holes like this. We’re currently in a situation where Linux’s userspace has reimplemented unix permissions in a way that only a few understand, and manages a sprawling multi-process asynchronous state machine on top of that. The authors of this mess didn’t bother to write manpages for the underlying daemons, so the inner workings of this stuff is extremely obscure and unvetted. Worse, it has hooks into everything in the Linux desktop, and has been spreading like cancer for over a decade.

e12e 6y ago

Nice write-up. Might be even easier to just use pkill accounts-daemon and gnome-session-quit: pkill -SIGSTOP accounts-daemon && nohup bash -c "sleep 5s; pkill -SIGSEGV accounts-daemon; pkill -SIGCONT accounts-daemon" & gnome-session-quit I think that should be equivalent, but haven't tried (my desktop is patched).

yrro 6y ago

Hm. If a user can send signals to accounts-daemon then can they ptrace(2) it and take over the system that way?

YtvwlD 6y ago
No, you can't attach to processes (that are not child-processes of yours) with the default Ubuntu configuration.
- yrro 6y ago
  Oh yeah, that's Yama's ptrace_scope isn't it...

fuzxi 6y ago

>The next step is to send a SIGSTOP signal to accounts-daemon to stop it from thrashing that CPU core. But to do that, you first need to know accounts-daemon’s process identifier (PID). Or just 'pkill -SIGSTOP accounts-daemon'. pkill matches by process name.

known 6y ago

accounts-daemon.service is a potential security risk. It is part of AccountsService, which allows programs to get and manipulate user account information. I can’t think of a good reason to allow this kind of behind-my-back operations, so I mask it. sudo systemctl stop accounts-daemon.service && sudo systemctl disable accounts-daemon.service https://www.linux.com/topic/desktop/cleaning-your-linux-startup-process/ https://www.linux.com/topic/desktop/cleaning-your-linux-star...

kazinator 6y ago

> Send accounts-daemon a SIGSEGV signal, which will make it crash. Shouldn't that be a root process to which a non-root process cannot send signals? Unix Basics 101

mleonhard 6y ago

The root cause is a very common bug: treating no response as an empty response. It's usually caused by missing or bad error handling. Some libraries and RPC APIs make it impossible to differentiate between the two cases. I've recently learned a lot of Rust. Rust's std::result::Result type [1] helps avoid this error. I think it is superior to the error handling facilities in other languages: - C: errno, boolean return values, `null` - C++: exceptions, errno, boolean return values, `null`; std::expected<T,E> is being developed - Java: exceptions, `null`, Optional<T> - Golang: `nil`, `error`, `if err != nil { return nil, err }` boilerplate - Javascript: `undefined`, exceptions, futures - Python: exceptions, `None`, boolean return values - Swift: exceptions, `nil`, `try?`, optional values - Dart: exceptions, futures, `null` Would it be worthwhile to create Result-like error handling libraries for the major languages? [1]: https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...