COMMAND
C-Kermit,
SYSTEMS AFFECTED
RedHat 6.2
PROBLEM
Stan Bubrouski found following bugs in RedHat 6.2 distribution:
1) C-Kermit package on the Powertools CD is installed as
/usr/bin/kermit and is sgid uucp. Unfortunately it contains
several serious buffer overflows which can be used by regular
users to execute commands as group uucp. Original bugzilla
with full details can be found at: [Bug 12750] New - Lack of
bounds checking in slrn-0.9.6.2-4 Sun May 28 20:37:19 2000.
2) In netscape communicator/navigator 4.x on all platforms (UNIX,
Linux,Windows...etc...) A users security preferences console
opened when you select security info in the Communcator->tools
menu (in other menus or may have other names in other versions)
or by pressing the security button on the Navigation toolbar.
The little security console that allows a user to modify
certificate and encryption and passwords and other security
information is nothing more than specially handled HTML forms
that are submitted to netscape's internal-parser. It appears
there is no restriction on the use of these forms in web pages
so it may be potentially possible to change a users security
prefernces with a simple HTML form in a webpage. If all the
correct parameters are not supplied to the internal-parser
netscape crashes 100% of the time on all platforms. This is at
least a simple DoS attack web pages can use. Original report
with specific details: [Bug 11725] New - Netscape security
preferences can be modified by webpages? Sun May 28 21:27:23
2000
3) The diskcheck package which is included on the Red Hat 6.2
Powertools CD has an easily exploited race condition in which
it creates a file in /tmp/diskusagealert.txt.$$. It is
installed in /etc/cron.hourly and therefor is run one time
every hour making it easy to exploit as the name can be
predicted and the time the file will be created is always
predictable as well. It will gladly follow symlinks and
destroy any file on any mounted filesystem. Bad bad diskcheck.
It is fixed in the latest release of rawhide. Original post
and more details: [Bug 11724] New - tempfile has easily
guessed name and follows symlinks Sun May 28 20:53:15 2000
4) The CERT advisory about kerberos problems as well as other
advisories make reference to a denial of service attack caused
by ksu but give no details and Stan has not seen the details
posted anywhere. He reported this to the kerberos team and
they acknowledged the problem and Stan believes it is fixed in
the next release of kerberos, but anyway since he never spread
the word about this problem and reported it originally as a
kernel bug the details never spread and thus it's been kept
quiet. Anyway here are the details, in kerberos 1.1.1 and
prior versions if ksu is installed suid-root (it has to be to
work!) a regular can lock up the system by executing ksu with
an argv[0] of around 100k. For example:
[root@king src]# doexec ksu `perl -e'print "A" x 100000;'`
is all it takes. After typing that when prompted for a passwd
just hit return and kaboom the system locks up entirely (linux
does anyway, dunno about others yet, as I said this has gone
largely unnoticed.) Original post and many more details:
[Bug 11107] New - ksu can lock up 2.3.99-pre5 kernel (can be
done by regular users) Sun May 14 19:14:22 2000
5) The default config for the mgetty packages that come with Red
Hat 6.2 specifically mgetty-sendfax open up another security
hole involving a race condition. By default the directory
/var/spool/fax/outgoing is created world writeable. By
default whenever faxrunqd is run (by root of course) a file
named /var/spool/fax/outgoing/.last_run is created and wouldn't
you know it follows symlinks so a user can make a symlink from
that file to any file on any mounted filesystem and faxrunqd
will gladly destroy the file for you! Original report with
details and examples: [Bug 11874] New - Mgetty packages
default config is a security threat Fri Jun 2 18:47:14 2000
6) The gkermit package that comes with Red Hat 6.2 (yes by the
same great programmers that brought you the C-Kermit
vulnerability mentioned above) is sgid uucp even though it was
not intented to be by the people who programmed it. This means
that any file writeable by group uucp is can be overwritten
using gkermit's logging feature which allows users to specify
a log for debug info to be sent to. It also means that any
files that are readable by group uucp can be sent to another
gkermit this meaning anyone can read files like
/etc/uucp/passwd etc. This is because gkermit was not
programmed to be sgid and thus has no permissions handling,
i.e. never drops permissions before reading/writing to files.
Original report (note the date it was reported June 2nd) with
details and examples: [Bug 11870] New - Gkermit can read or
write to any file writable by group uucp Fri Jun 2 18:05:01
2000
7) The slrn package contains numerous unchecked buffers, most are
harmless because they have to be done by the user executing
slrn themself and since it is not suid or sgid on Red Hat
those pose no real threat. The slrnpull program is owned by
user news and group news and is set-group-id news however it
is not executable/readable/writable by regular users so there
is no potential for regular users to use NNTPSERVER to gain
elevated privilages. There is however potential buffer
overflows in both slrn and slrnpull that Stan came across when
looking over the code including one where large group names
could overflow a fixed buffer in both slrn and slrnpull thus
allowing a remote nntp server to execute arbitrary commands as
the uid of the person who is using those programs at the time.
Details and a patch Stan submitted which fixed the problem for
him (though could be improved some) can be found at: [Bug
12750] Changed - Lack of bounds checking in slrn-0.9.6.2-4 Tue
Jun 20 00:54:32 2000
8) Red Hat 6.2 ships with a working implimentation of the scheme
programming langauge and in the umb-scheme package there is a
scheme library installed /usr/lib/umb-scheme/slib which is
made up of several files containing Lisp/Scheme code. Two of
the files were accidently left mode 666 so when installed they
are world-writable thus allowing regular users to modify those
parts of the library and could be used to possibly gain some
elevated privilages if a user changes those files and root
happens to use them in a program they are developing. The
threat is minor but you never know... Original post and couple
more details: [Bug 11871] New - Incorrect permissions on
files Fri Jun 2 18:15:23 2000
9) There is a dumb little DoS against in.xfingerd which is part
of the openldap package. in.xfingerd is a finger daemon that
runs on port 79 and handles finger requests using an ldap
database of user information. Any query containing a comma,
no matter where it is or how many there are in.xfingerd will
crash with signal 11 segmentation fault. This is fixed in
rawhide openldap packages. Original post and more details:
[Bug 11111] New - in.xfingerd crashes when recieving commas(,)
Mon May 22 14:52:58 2000
10) The Washington University imapd is vulnerable to a denial of
service attack which can be performed by a regular mail user,
no other access to the system is required. imapd allows
wild-cards like "*" to be used when listing files because of
this an a user can do something like this:
* OK linux.local IMAP4rev1 v12.264 server ready
x login sb testpass
x OK LOGIN completed
x list "" /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*
[I diconnected without logging out]
even after disconnecting imapd process continues to run eating
up CPU trying to parse the wildcards which means it traverses
the entire filesystem several times before it finishes although
on tested system Stan left it going for two hours and it never
appeared to finish. Regardless this causes a more severe
problem. If a user does the above enough times (around 30 of
those processes on my machine) then connecting to imapd results
like this:
[root@king /root]# telnet linux 143
Trying 192.168.0.3...
telnet: Unable to connect to remote host: Connection refused
so clearly all those processes are too much and imapd will
disallow connections until some of them are killed. This is
an easy to exploit DoS against imapd. Orignal details and
exploit can be found: [Bug 11052] New - IMAP: NEW DoS + remote
listing of all files on server 2000-04-25 11:21:34
11) There is a game named xconq that installs two files in
/usr/games which are sgid games. The problem is that cconq
and xconq both contain buffer overflows and literally lack
bounds-checking virtually anywhere. For example look at the
number of functions used for strings handling that lack
bounds-checking (keeping in mind the programmer did hardly any
bounds-checking in general anyway):
function name | number of times it is used in xconq/cconq code
-----------------------------------------------------------
strcpy 161
strncpy 15
strcat 336
strncat 4
vsprintf 22
vsnprintf 0
sprintf 493
snprintf 0
The little chart right there should make clear the problem
xconq has. Here is an example of why it is so easy for regular
users to gain ability to execute commands as group games:
cmdline.c: if (!empty_string(getenv("USER"))) {
cmdline.c: strcpy(default_player_spec, getenv("USER"));
cmdline.c: } else if (!empty_string(getenv("DISPLAY"))) {
cmdline.c: strcat(default_player_spec, getenv("DISPLAY"));
Mistakes like this were made throughout the code and thus the
sgid bit should be removed from /usr/games/xconq and
/usr/games/cconq
12) The eSound library which comes with the esound packages is
used by programs like gnome to handle sound and such. The
problem is that esound creates a dir in the /tmp directory
named .esd which is worldwritable/readable/executable and in
that dir it creates a socket named socket. The problem is that
/tmp/.esd is a symlink to another directory esd will follow the
symlink and create the file named socket in whatever dir the
symlink points to. Users could make a link so that it creates
the socket in /etc/cron.hourly or in some place which it could
conflict with another app that creates a socket with that name
...etc... not good.
SOLUTION
Most of these might be or it is fixed show check above URLs.