Using /proc

[mynameistmp]

For those of you who don't know, /proc is a filesystem that acts as a sort of representation of the kernel's live process table. Many commonly used linux tools are just programs that extract/represent data found in /proc (you can cut out uname -a  as a middleman just by doing cat /proc/version). Anyways, I'm going to attempt to show off a few neat things you can do with your own friendly neighbourhood /proc.

In /proc is a directory for every PID you've got running on the system. If you're interested in a particular process, explore the directory corresponding to its PID in /proc. Take init (PID 1) for example:

root@tmp:/proc/1# ls -l
total 0
-r--r--r--  1 root root 0 2005-06-24 00:43 cmdline
lrwxrwxrwx  1 root root 0 2005-06-24 00:43 cwd -> //
-r--------  1 root root 0 2005-06-24 00:43 environ
lrwxrwxrwx  1 root root 0 2005-06-24 00:43 exe -> /sbin/init*
dr-x------  2 root root 0 2005-06-24 00:43 fd/
-r--r--r--  1 root root 0 2005-06-24 00:43 maps
-rw-------  1 root root 0 2005-06-24 00:43 mem
-r--r--r--  1 root root 0 2005-06-24 00:43 mounts
lrwxrwxrwx  1 root root 0 2005-06-24 00:43 root -> //
-r--r--r--  1 root root 0 2005-06-24 00:43 stat
-r--r--r--  1 root root 0 2005-06-24 00:43 statm
-r--r--r--  1 root root 0 2005-06-24 00:43 status

exe is a symlink pointing to the full path to the binary that was called. cwd points to the current working directory of the process. The cmdline file contains the command line as it was originally called, and environ contains all of the processes environment information. All of this data is delimited by NULL characters, so you'll want to run it through some sort of a filter in order to make it manageable:

root@tmp:/proc/1# cat environ | tr '\0' '\n'
HOME=/
TERM=linux
BOOT_IMAGE=linux

This kind of data can be extremely useful when investigating rogue processes.

One interesting aspect of /proc that most users don't utilize is kcore:

root@tmp:/proc# ls -l kcore
-r--------  1 root root 279457792 2005-06-24 00:33 kcore

From this you can tell that this machine has ~256 MB of RAM installed (279457795/1024/1024). This is the system memory and some interesting data tends to wind up cached here. Try messing around with strings / grep and see what you can come up with. See if you can find your root password in there somewhere. If you can, odds are some miscreant can.

Finally, a little tip for you security buffs. Typically a rootkit will alter your ps command in order to malform its output in an attempt to hide any malicious processes. Well, one quick and easy way around this method is comparing your /proc contents to the output of your ps command:

root@tmp:/proc/1# ls -d /proc/* | grep [0-9] | wc -l ; ps ax | wc -l
74
74

It is much more difficult (and rare) for a hacker to change the output of /proc, which makes this a very convenient/effective method.

Enjoy ;P

[iago]

Yeah, I use /proc all the time, I always forget "uname -a" and go straight to "cat /proc/version" :)

The thing about finding your root password is that, if a user can access that file, they already have root on your system.  If you're smart and use unique root passwords, there's no problem at that point.  It's already Game Over. 

And incidentally, I didn't find my root password in it.  Go me! :)

[Newby]

Wow. Great read tmp. Didn't know that about kcore.

I'm tempted to sticky this! :p

EDIT -- I did find my root password. Bah.

[mynameistmp]

The thing about finding your root password is that, if a user can access that file, they already have root on your system.

If a user needs higher priviliges it is popular for admins to give them an entry in /etc/sudoers as opposed to giving out the system password. This results in many users having certain escalated priviliges without ever having the system password.  Scouring data caches like kcore for sensitive data is one method of circumventing that level of control.

[iago]

The thing about finding your root password is that, if a user can access that file, they already have root on your system.

If a user needs higher priviliges it is popular for admins to give them an entry in /etc/sudoers as opposed to giving out the system password. This results in many users having certain escalated priviliges without ever having the system password.  Scouring data caches like kcore for sensitive data is one method of circumventing that level of control.

Generally with sudo, they're either limited by program or they have full control.  I don't think there's any other way to limit them, but feel free to correct me there. 

If they have full sudo control, then it's easy: "sudo passwd root " or "sudo su".  Game over.

If they are limited to certain programs, it's doubtful that they will have access to "cat" (or any other editor).  But, if they DO have access to a file viewer, they can view /etc/shadow and begin bruteforcing.  You're right, if they have sudo access to cat it would be easier to check the kernel memory, but I don't think this is a situation that comes up so much.

Plus, users with sudo tend to be trusted anyways.

[Newby]

Yeah, you can limit what they do.

While they may be trusted, a friend of theirs (who somehow managed to get their password) may be a malicious little fuck who would love to see his friend lose sudo access and damage as much stuff as possible.

[mynameistmp]

When people start building more complex sudo configuration files using things like Runas_Alias and User_Alias I find them giving access to all sorts of things, especially editors. I suppose the thought is it's easier than just creating groups then using chmod on the appropriate configuration files.  There are many more security flaws inherent in giving sudo access to text editors, I was just pointing out one relevant to /proc that I figured most users here wouldn't know about.

[iago]

If you give them access to any text editor at root level, it's game over. 

But yeah, I know what you mean :P