Hacker News new | ask | show | jobs
by seba_dos1 43 days ago
Anyone who sees Copy Fail and chooses to focus on the way the example exploit happens to gain root is just showing how unimaginative they are.

In the pre-container hype era, the sysadmin where I used to work gave us write access to nginx.conf on work machines to facilitate development. I used it in pair with an XSLT template to gain root access, so I could install things without having to go through the sysadmin - all thanks to a single config file for a webserver and without relying on any kind of security bugs in there. This vulnerability makes all sorts of stuff that were supposed to be shared read-only with the container actually sorta writable, so the blast radius is going to be enormous in many contexts, even when not as universally trivially exploitable as with the "su" example.
1 comments
e12e 43 days ago
Wait nginx ran as root?
link
seba_dos1 43 days ago
It's usually launched as root and then drops its privileges for its workers. Unless... ;)
link
Apes 43 days ago
If you have write access to nginx.conf, you can set "user root root;"
link
adamsb6 43 days ago
Long ago in Linux if you wanted to listen on a privileged port (< 1024) you had to do so as root.
link
Apes 43 days ago
If you're connecting to a host on a port < 1024, then you know a SysAdmin must have set it up, and it must be trustworthy. It was a simpler time.
link
wahern 42 days ago
It's more that Unix systems were timesharing systems, any user could run a daemon, but you didn't want users to have the ability to grab a port used by system services, not just because they could impersonate a system service on the network, but also because then you couldn't trust localhost services, either, as well as it just being a PITA. This is still true today; though vanishingly few Linux systems are multi-tenant, it's still common to implicitly trust a local service.
link
tingletech 42 days ago
is that no longer true?
link
bhaney 42 days ago
No, now you have the option of using CAP_NET_BIND_SERVICE
link
63stack 42 days ago
There is also net.ipv4.ip_unprivileged_port_start
link
jcgl 42 days ago
If the application supports it, there’s also systemd socket activation (or traditional inetd sorta stuff too if that fits)
link
jcgl 39 days ago
Forgot to mention: you can use systemd-socket-proxyd to bridge to an application that doesn't support socket activation too: https://www.man7.org/linux/man-pages/man8/systemd-socket-pro...
link