3 ms·

Impact: local users on the system, including dummy service users like 'nobody', can perform actions on a running Mozilla VPN daemon via D-Bus, including activat

by Aachen 3y ago

Impact: local users on the system, including dummy service users like 'nobody', can perform actions on a running Mozilla VPN daemon via D-Bus, including activating the VPN with a server of the attacker's choice, deactivating the VPN, obtaining log files to see when the user historically activated the VPN, and clearing log files So you need to have a local shell on the system of the user you want to attack. Not cool, it violates permission boundaries that are there for a reason, but the headline sounded to me like a remote authentication bypass (I'm not into the whole D-Bus/Polkit thing) which this is not

pjmlp 3y ago
This is a great attack vector on corporations that use shared servers for their users.
- makkes 3y ago
  I don't think they would be running the Mozilla VPN client on those servers, though.
lapinot 3y ago
Local unprivileged shell is not an unreasonable thing to get on linux since most people are building random software regularly. Among the things i know i should be doing but i don't: using a dedicated user for building everything; sandboxing the build process using some bwrap/container.
- insanitybit 3y ago
  Privesc is also trivial on desktop linux :P so if your barrier is "but I'm an unprivileged user" it's likely not enough. You need a proper sandbox if you want to make escalation difficult. ex: Desktop Linux's running X have a trivial escalation path; any program can read all keystrokes across all users. You type your sudo password in, you're screwed. Or if the attacker is running as your user they can just modify your bashrc, aliases, etc, to do a whole bunch of things - like having `sudo` go to an attacker controlled binary - that one will work on the server, too! So yeah sandboxing builds is super important because "unprivileged users" are almost always one trivial step away from full root.
  - tedunangst 3y ago
    There's no reason for your build user to require access to X.
    - bravetraveler 3y ago
      Or even most (all) namespaces of the host! Beyond just minding privileges of the user, building in a container/chroot/etc is nice from a cleanliness/repeatability perspective. For those interested in the Fedora packaging ecosystem -- look into fedpkg and mock https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/ https://docs.fedoraproject.org/en-US/package-maintainers/Pac...

by Aachen 3y ago

pjmlp 3y ago

This is a great attack vector on corporations that use shared servers for their users.

makkes 3y ago
I don't think they would be running the Mozilla VPN client on those servers, though.

lapinot 3y ago

Local unprivileged shell is not an unreasonable thing to get on linux since most people are building random software regularly. Among the things i know i should be doing but i don't: using a dedicated user for building everything; sandboxing the build process using some bwrap/container.

insanitybit 3y ago
Privesc is also trivial on desktop linux :P so if your barrier is "but I'm an unprivileged user" it's likely not enough. You need a proper sandbox if you want to make escalation difficult. ex: Desktop Linux's running X have a trivial escalation path; any program can read all keystrokes across all users. You type your sudo password in, you're screwed. Or if the attacker is running as your user they can just modify your bashrc, aliases, etc, to do a whole bunch of things - like having `sudo` go to an attacker controlled binary - that one will work on the server, too! So yeah sandboxing builds is super important because "unprivileged users" are almost always one trivial step away from full root.
- tedunangst 3y ago
  There's no reason for your build user to require access to X.
  - bravetraveler 3y ago
    Or even most (all) namespaces of the host! Beyond just minding privileges of the user, building in a container/chroot/etc is nice from a cleanliness/repeatability perspective. For those interested in the Fedora packaging ecosystem -- look into fedpkg and mock https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/ https://docs.fedoraproject.org/en-US/package-maintainers/Pac...