FS#62114 - [makepkg] is vulnerable to sudo caching attacks, and also it should use sudo in a safer way than now
Attached to Project:
Pacman
Opened by Andrew Kotsyuba (avallac_h) - Friday, 22 March 2019, 12:51 GMT
Last edited by Allan McRae (Allan) - Friday, 22 March 2019, 22:19 GMT
Opened by Andrew Kotsyuba (avallac_h) - Friday, 22 March 2019, 12:51 GMT
Last edited by Allan McRae (Allan) - Friday, 22 March 2019, 22:19 GMT
|
Details
I asked Allan McRae about this last week, but..
Summary and Info: Currently, makepkg doesn't perform any checks to find whether it runs on tty with active sudo session or not. Due to the fact that many users use default sudo configuration, it could be dangerous to run makepkg with cached sudo credentials. It is possible to run any command with a privilege escalation to the local root directly from the build scripts of the project you building. Attached patch shows how, in my opinion, makepkg should handle sudo sessions. References: * Sudo caching attack technique https://attack.mitre.org/techniques/T1206/ * Sudo man-page https://www.sudo.ws/man/1.8.2/sudo.man.html * Attack example using AUR helper's sudo loop (how practically sudo loop will be dangerous?) https://old.reddit.com/r/archlinux/comments/b0m6q8/everything_is_wrong_with_aur_helpers/ej18q0e/ Steps to Reproduce: 1. Using active sudo session. 1.1. Run 'sudo -l' to ensure that current user can run any command with sudo and sudo timestamp_timeout is greater than 0. 1.2. Run 'sudo -v', enter the password. 1.3. Try to build package using attached PKGBUILD. 2. Using makepkg -s. 2.1. Run 'sudo -l' to ensure that current user can run any command with sudo and sudo timestamp_timeout is greater than 0. 2.2. Uncomment depends= section in attached PKGBUILD. 2.3. Ensure that you don't have 'virtualbox-sdk' package installed or modify PKGBUILD by adding any package that doesn't installed on current host to depends. 2.4. Try to build package with 'makepkg --syncdeps' |
v5.1.3.makepkg.safesudo.patch
This task depends upon
Either configure sudo to run only the commands you want or set the timeout to immediate. This "bug" is a choice the administrator makes for the convenience of sudo.
Or don't have sudo installed and makepkg will use su.
We should not drop privileges when the administrator has specifically not asked for it.
Not saying it may not make sense to add this, its just not much of a security patch but a protection from _accidentally_ hazardous sudo calls in the buildchain underneath.
Also, makepkg only runs 'pacman' with elevated permissions. I'd say that's a feature, and one that reduces the attack surface. One might argue that it's more of a risk that we rely on a PATH lookup for pacman. We might also consider marking the 'run_pacman' function (and others?) as readonly in makepkg to avoid malicious PKGBUILDs from altering that behavior.
sudo can be configured to cache things, and cached sudo can be used by anything. This is hardly makepkg specific, I don't see why makepkg should add special handling for this administrator choice. (Every script or binary you install using makepkg, could *also* include attempts to run with sudo, like, well, just like the MITRE link you provided.)
Just don't build malware using makepkg -- do your due diligence and check the PKGBUILD for strange calls to sudo, and don't build surprising/unknown software, or you are far more likely to build a package that contains binaries with cleverly disguised backdoors than one with usually-very-easy-to-grep uses of sudo.
You could also go one step further and build in a makechrootpkg container, that doesn't have sudo available by default and can only execute pacman (which means malware would need to be targeted specifically at Arch and also contain a container privilege escape), or in a full VM. Although this still does not mean you can trust the compiled output of unknown code which you trust that little. But it does mean that your $HOME data is protected from imminent attack, and only becomes vulnerable once you run the packaged software, rather than immediately when you try to build it.
Either way, this is a much more robust separation of privileges than trying to nail the door shut on sudo which already has its own safeguards built into /etc/sudoers.
Allan McRae (Allan) wrote:
> This "bug" is a choice the administrator makes for the convenience of sudo.
But makepkg encourages this behavior. Shouldn't it at least warn about active sudo session? This will stop many people from doing dangerous things. Perhaps this will also cause some of them to configure sudo properly.
Dave Reisner (falconindy) wrote:
> Also, makepkg only runs 'pacman' with elevated permissions.
I think this is the main problem here (with that "only").
Since systemd is a mandatory part of Arch, maybe it's time to add some build isolation features to makepkg itself. Possible options:
* systemd dymanic users: systemd-run -p DynamicUser=yes -E HOME=$builddir
* chroot build: systemd-nspawn with --bind-ro
I know that I can use makepkg in that way by myself, but in this case all sense of options like '--syncdeps' is lost.
Also, I'm unsure about it, but maybe there's any way to use PolicyKit to allow makepkg call pacman. Could this be an alternative to sudo?
P.S. I almost completely agree with what Eli Schwartz (eschwartz) said.
BTW mentioning systemd DynamicUsers means you've drunk the pikaur kool-aid. makepkg has supported being run as sudo -u builduser makepkg, since day one, and does not need over-engineered init-specific service manager geared methodologies in order to perform its intended interactive use (which is not "run it as a service").
tl;dr pikaur as an AUR helper is a really bad example to draw inspiration from.
I wouldn't want to prioritize it over sudo, because I'd guess most people are more familiar with and have a better sudoers config than a polkit config.