exploited, as with poorly validated input or a buffer overflow, anything the attacker
does will have root permissions.
This is not strictly limited to programs running as root. Any program runs with the
permissions of the program’s owner. If any program owner has permissions to access
any resource on a system, an exploit of that program can give an attacker access to
that resource. These types of attacks can lead to a
privilege escalation
: a user gets
access to something they shouldn’t have access to in the normal state of affairs within
the system.
This particular issue could be alleviated, at least to a degree, by requiring authentica‐
tion within the application. At least, that’s a hurdle for an attacker to clear before just
exploiting a program—they would have to circumvent the authentication either by a
direct attack or by acquiring or guessing a password. Sometimes the best we can hope
for is to make getting access an annoyance.
Local Vulnerabilities
Local vulnerabilities
require some level of access to the system. The object of a local
vulnerability is not to gain access. Access needs to have already been obtained before
a local vulnerability can be exploited. The idea of exploiting a local vulnerability is
often to gain access to something the attacker doesn’t otherwise have access to.
The thing about local vulnerabilities is that they can occur in any program on a sys‐
tem. This includes running services—programs that are running in the background
without direct user interaction and often called
daemons
—as well as any other pro‐
gram that a user can get access to. A program like
passwd
is setuid to allow any user
to run it and get temporary root privileges. This is necessary because changing a
user’s password requires changes to a file that only root can write to. If I wanted to
change my password, I could run
passwd
, but because the password database has to
be changed, the
passwd
program needs to have root privileges to write to the needed
file. If there were a vulnerability in the
passwd
program, that program would be run‐
ning temporarily as root, which means any exploit may be running with root permis‐
sions.
A program that has the setuid bit set starts up as the user that owns
the file. Normally, the user that owns a file would be root because
there are some functions users need to be able to perform that
require root privileges, like changing their own password. How‐
ever, a setuid program can be for any user. No matter the user that
started the program, when it’s running, it will appear as though the
owner of program on disk is running the program.
