SystemsSec 2018W Lecture 4

Notes

Today we discussed passwd as a way of touching on a number of security topics

passwd

• the linux program for modifying a user password
• seems like a simple program, but has a number of features that could present a security concern.
• where are they stored?
• used to be in one file, including the hashed passwords (/etc/passwd)
• problem is that data in that if attackers can read the hashes, the hash can be cracked.
• on more modern systems, this is split into /etc/passwd and /etc/shadow
• root owns the file
• in order to modify the password, the program needs root privileges in the classic model
  • this gives the program the ability to modify any file on the system

the setuid bit

• every process has a user id (uid) and a group id (gid). Every file has bits that set the permissions for the users and groups associated with it.
• in addition to the classic read, write and execute (rwx) for the uid and gid, there are also setuid and setgid (s) bits
• without the set bit, when a new process is created, execv loads the new process, but the uid and gid don't change.
• setuid bit allows the new process to be created with a new uid (effective uid). It runs with the privileges associated with the new uid.

if a process has an effective uid of root, it can do basically anything to the system (the all powerful root model)

for a program like passwd, it may seem very simple, but it does lots of things, including things that might make the system vulnerable to attack.

• attack?
  • the chroot option lets you change the etc/passwd for a subdirectory
  • by using a symlink to a different file, you could take control of the system

in general, flexibility is the enemy of security

• more functionality means more corner cases, and more things that you haven't thought about.

how could we make the process less dangerous?

could we run it without full root privileges?

we are going to have this binary. It will have root privileges, it will have full control.

• how to we protect ourselves? what measures can we take?
  • limit the scope of our mistakes
    • limit the time that you have the dangerous privileges
    • limit the privileges
    • ideally audit to make sure that the privileges were used appropriately.

Just knowing about basic mechanisms, what could we do?

• separate the part of the program that needs privileges from the parts that don't.
• analyzing user input is the most dangerous part, and should be separated as much as possible from parts of the program with powerful privileges
  • malicious input attacks

passwd is one of the simplest examples, and it touched on a number of topis:

• access control
• (least) privilege (time and space)
  • for passwd, this can be a problem because there is a file with everyone's password information. In order to change this file, you need root privileges.
    • Could you change that basic premise? You would have to split it out so that everyone had there own separate passwd files. This could cause problems for legacy software, and

could even open up other potential security vulnerabilities.

• unsanitized input
  • not all input is trusted. This what programs do: they process data.
• trust
  • trust is hard.
  • in computer security, trusted means that if it betrays you, it can hurt you.
  • trust can be limited.
  • like with people, applications should behave differently towards trusted and untrusted inputs
• kernel mechanisms
  • the setuid bit
  • if you have privileges, they were usually granted by the kernel
• other attacks
  • breaking the hash

Similar problems

• What other command line tools have similar security issues?
  • anything with the setuid bit, executables that run as other users.
• what binaries have setuid root?
  • mount
  • fuse
  • cron
    • for scheduling tasks.
  • sudo
  • ping

Determining access by users and groups is coarse.

• root is a collection of privileges
  • could we have a subset of these privileges?
• capabilities
  • a different way of thinking about access control
  • you can drop capabilities that you don't need.
  • however, some capabilities are still very powerful, i.e. modify files or modify devices
• there are more complex mechanism for access control and privileges, but they often aren't used. In order for something to be used effectively, it needs to be understandable to

people using it. Simple mechanisms remain widely used.

Exercises

Two exercises will be posted:

• Write your own version of passwd
  • any language
  • setuid root and change password
  • think through the features and the implementation, and she security issues that arise.
  • process input carefully and drop unnecessary privilegs.
  • for the write up, not looking for documentation about perfectly working code. what went wrong, what paths did you take, what issues did you have, what did you learn?
• What privileges are required for networking?
  • what operations require higher privileges.
  • at first distinction, it may seems simple (users can use the network, root can modify)
    • however it is more complex. Can an application set up connection to a new wifi access point?

If you have any ideas for exercises, feel free to discuss them in slack