Using the Environment

[mynameistmp]

I know that bash environment guides and tutorials are a dime a dozen, but I decided to make a to-the-point post about a few tips most of you newer guys should learn from the start, and throw in a few tricks some of you novice guys might not know yet. I'll try to keep this as brief as possible, but it's going to be fairly lengthy.

First of all, if you're operating a terminal as a regular user you might be jealous because root gets fancy colour coded output. This one's a quick and easy fix. All you have to do is edit your PS1 (system prompt) env variable:

export PS1=`echo -ne "\033[0;34m\u@\h:\033[0;36m\w\033[0;34m\$\033[0;37m "`

I wrapped the escape sequences in bold (\u -- username, \w -- working directory), the rest are ANSI escape sequences interpreted as colour codes. For the sake of brevity I'm not going to explain everything here, but here's a guide to the various colour codes here: http://www.linuxgazette.com/issue65/padala.html. Mess around with it to get the colour scheme you want.

Many people know that the PATH env variable stores the various directories to be scanned for scripts/executables to be executed, and MANPATH for man files, etc. Many people, however, overlook the CDPATH env variable. Try:

export CDPATH=.:~

Now whenever you do a cd <directory> it'll automatically search your home directory, so you don't have to prefix with ~/. Fool around with this a bit. You can add as many directories as you want, just delimit them with :. Note that as root you should be weary of editing your PATH env variable. If you add a directory writable to other users, they can add binaries that will be mistaken by you as typical programs and executed inadvertently as root.

We all know that ~/.bash_history stores everything interpreted by your bash shell. So you need to be careful if you're ever using shells to log into other services. If you enter some sensitive data (password) accidentally on the command line without realizing it before carriage returning it's possible the evil admin (or perhaps some other user!) will stumble upon your precious password when checking out your .bash_history, you'll probably want to erase it. Well, .bash_history is written everytime you log out, so doing rm .bash_history now isn't going to work. What you can do is this:

export HISTSIZE=0

This will completely clear your .bash_history file, and will write an empty file when you log out. Note: You could have logged out, logged back in, and rm .bash_history, but this trick is more convenient and the other way still leaves an rm command in your .bash_history and you might not want your admin to know you're deleting logs.

A system admin will typically use the w command (or some alternate method) in order to see who is logged into the server. Sometimes people will remotely login, execute a few commands, then just forget about their terminal, leaving it idle. Or perhaps they're using the system to run their irc client. If the person has gone out for the day and their client has terminated for whatever reason their connection will also idle. If you, as the admin, don't like hosting all of these idle users try this:

export TMOUT=600

This will make it so that bash automatically logs out any user who hasn't produced input for 10 minutes. Adjust the time (in seconds) as necessary. 

Let's say you're logged into an X session and you want to run a binary with root priviliges that outputs to a GUI. Let's also say it's unsafe to suid the program, and you don't want to add support for sudo on the system for security reasons. Try this series of commands:

sh-3.00$ set | grep DISPLAY
DISPLAY=:0.0
sh-3.00$ xhost +
access control disabled, clients can connect from any host
sh-3.00$ su -
Password:
root@tmp:~# export DISPLAY=:0.0
root@tmp:~# ethereal

Anything that uses xlib to draw to an X session that is executed as root on that command line will be drawn to display :0.0. Note that there are security issues inherent in this as well. xhost is used to control the ACLs that filter access to your X server. If you disable them, anyone able to connect to your X server will be able to output to your display. You may want to research how to limit acess to your X server via xhost.


Typically ps aux is more practical than regular old ps. Or maybe ls -a is preferred to ls. Getting tired of typing ps aux every time ? Set an alias:

sh-3.00$ cat << EOF > ~/.bashrc
> alias ps='ps aux'
> EOF
sh-3.00$ bash -ic ps | grep xterm
tmp       2659  0.0  0.8  5736 2304 tty1     S    Jul15   0:00 xterm -title Terminal
tmp       3909  0.0  1.3  5972 3464 tty1     S    02:22   0:00 xterm -title Terminal
tmp       3978  0.0  0.2  1688  600 pts/3    S+   02:28   0:00 grep xterm

Another use of environment variables is storing shellcode. Perhaps you've found a buffer overflow, but there isn't enough room in the buffer for your NOP sled and the lengthy bind shellcode you picked up off of metasploit. Pack a NOP sled and your shellcode into your env variable then use the address of the env variable to overwrite the return address on the stack instead of all of your shellcode:

export SHELLCODE=`perl -e 'print "\x90"x200;'``cat shellcode`

Here's a quick little program in C that'll output the address of the env variable holding the shellcode:

Code Select Expand


#include <stdlib.h>

int main(int argc, char *argv[]) {
char *addr = getenv(argv[1]);
printf("\n%p\n", addr);
return 0;
}


Find the address of our shellcode and overwrite the stack's return address with our SHELLCODE env variable:

sh-3.00$ getenv SHELLCODE
SHELLCODE is located at 0xbffff892
sh-3.00$ ./vulnprog `perl -e 'print "\x92\xf8\xff\xbf"x10;'`

That's enough for now. bash when run as a login shell reads from /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profile in that order (assuming they exist). For any other kind of shell it reads from ~/.bashrc. So, if you want to make any of these env variables permanent, set them in the appropriate file for your shell.

[Newby]

Good read. :)

[Ergot]

First of all, if you're operating a terminal as a regular user you might be jealous because root gets fancy colour coded output. This one's a quick and easy fix. All you have to do is edit your PS1 (system prompt) env variable:

No :( I'm jealous because root doesn't get colors and regular users do :(

[iago]

First of all, if you're operating a terminal as a regular user you might be jealous because root gets fancy colour coded output. This one's a quick and easy fix. All you have to do is edit your PS1 (system prompt) env variable:

No :( I'm jealous because root doesn't get colors and regular users do :(

"su -l" will do that.