5222817 2000-06-23 03:26 /155 rader/ Postmaster
Mottagare: Bugtraq (import) <11395>
Ärende: Re: rh 6.2 - gid compromises, etc [+ MORE!!!]
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Message-ID: <20000622064042.29536.qmail@securityfocus.com>
Date: Thu, 22 Jun 2000 06:40:42 -0000
Reply-To: Stan Bubrouski <satan@FASTDIAL.NET>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Stan Bubrouski <satan@FASTDIAL.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.21.0006211209500.22969-100000@nimue.tpi.pl>
Ya know the sad thing is I pointed out these problems in
bugzilla posts the gkermit being sgid uucp I reported
two+ weeks ago. No response. My description of the
gkermit bug which I reported couple weeks ago can be
found here:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11870
The slrn problem I attempted to fix around three weeks
ago, I submitted a patch to the maintainer, no response
however. On June 20th I reported the slrn problems on
bugzilla and submitted a rough patch to fix a few problems
including the slrnpull one along with potential remote
overflows if group names excede certain lengths. Check
out my bugzilla post for more detailed info and usable
patch:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=12750
While we're on the subject, I might as well mention a couple
other things I've posted to red hat's bugzilla in the past
few weeks/months that haven't trickled there way into here
yet.
The C-Kermit package that comes on the Powertools CD with
Red Hat 6.2 is installed sgid uucp as well and contains
a plethera of unchecked buffers than can be used to run
commands as gid uucp. Details can be found here:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11723
Another package that shipped with Red Hat 6.2 that has
some trouble is diskcheck. Diskcheck is a program that
run hourly by cron that creates an e-mail message in
/tmp with a warning about drives over 90% full, and if
a drive is 90% full it sends the message. Unfortunately
the name is too predictable and because the file is created
hourly regardless of how much disk space is left there is
a race condition that allows any file on any mounted
filesystem to be overwritten. This is fixed in latest
rawhide release. Details can be found here:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11723
The Mgetty-sendfax package has a symlink problem as well.
When faxrunqd is run it creates a file named .last_run
in the world-writable /var/spool/fax/outgoing directory
and wouldn't you know it follows symlinks and gladly
smashes any file you feel like smashing. More details
can be found at:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11874
More about mentioned kerberos problems. A while ago I
reported a DoS in ksu to the kerberos team, and I'm
assuming it is now fixed because it did appear in the
CERT advisory I think, either way here's a clear
picture of how to exploit it:
# doexec ksu `perl -e'print "A" x 100000;'`
that's it. If ksu is suid on your system (this was
tested only krb5-1.1.1) then you may be vulnerable.
When using the packages provided with redhat linux
6.2 the above froze my machine and even sysreq keys
to sync drives and unmount do not work. More details:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11107
Want more? I've got more!!! Gnome uses eSound for
sound stuff, at least newest versions do, anyway,
the eSound library creates a directory in /tmp named
.esd which is of course Mode: (0777/drwxrwxrwx) and
creates a socket named socket in /tmp/.esd and keep
in mind this occurs each time gnome is run. So
what's the problem? If /tmp/.esd is a symlink, esound
will gladly create socket wherever the symlink points
to like / or /etc/cron.daily or any other place your
creative mind can come up with. Could be a problem if
it is created where another program looks for a socket
named socket as well. Nifty eh? Yeah I know not really.
Want even MOOOOOORE? Ok...on to the famed imapd (by famed
I refer to its lack of security and maintainers carefree
attitude towards NOT using bounds-checking though this
problem is unrelated.) I found a remote DoS against imapd
that can be done by regular mail users. Here's a session:
* OK linux.local IMAP4rev1 v12.264 server ready
x login sb testpass
x OK LOGIN completed
x list ""
/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*
/*
[I diconnected without logging out]
Because imap can take literally hours to process long
queries like that the session continues even after I
disconnect.
root console on linux *45* minutes later!!!:
[root@linux /root]# ps aux | grep imapd
sb 1213 92.0 2.7 2740 1256 ? R 17:56 45:06 imapd
On my machine, after 30 of those processes were running this
is what I got when I tried to connect to my imapd:
[root@king /root]# telnet linux 143
Trying 192.168.0.3...
telnet: Unable to connect to remote host: Connection refused
imapd refuses to accept connections and thus the DoS is
affective. I reported this to redhat 2 months ago and
no response to my post so for details and cheesy exploit
check out:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11052
Ok now want some final food for thought? Netscape
Communicator and Navigator security preferences are
really just simple html forms that get submitted to an
internal parser. What nobody seems to recognize is that
there is nothing preventing a webpage from including
such a form that when submitted could change a user's
security preferences. If all the correct fields are
not present on one of these forms netscape will crash
100% of the time when a form is submitted to it's
internal parser so in the very least it gives fresh
new series of DoS attacks against netscape browsers on
ALL platforms, windows and unix/linux alike. More
details here:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11725
Minor probs:
top program that ships with redhat has some buffer
overflows most notably huge HOME variable will crash
it upon startup. No harm since it's not suid or sgid.
tcp_wrappers has buffer overflow when argv[0] is big
and may have another potential overflow (would be more
serious) in code dealing with hosts and users more info
plus crappy patches can be found at:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11881
It's 3am I'm tired, if I remember any more stuff I'll post
later on. If this comes out incoherent or messy I'm sorry.
-Stan Bubrouski
complaints, comments, gripes, I hate/love you's
to: satan@fastdial.net
(stan + a = satan)
(5222817) ------------------------------------------
5224246 2000-06-23 23:53 /103 rader/ Postmaster
Mottagare: Bugtraq (import) <11406>
Ärende: Re: rh 6.2 - gid compromises, etc
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Message-ID: <20000623043035.17666.qmail@securityfocus.com>
Date: Fri, 23 Jun 2000 04:30:35 -0000
Reply-To: Stan Bubrouski <satan@FASTDIAL.NET>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Stan Bubrouski <satan@FASTDIAL.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.21.0006211209500.22969-100000@nimue.tpi.pl>
Couple things I forget to say but should have:
#1
The slrnpull overflow in NNTPSERVER is harmless
in RedHat 6.2 because it's permissions are
[root@king srpms]# l /usr/bin/slrnpull
-rwxr-s--- 1 news news 50684 Jun 10 18:39 /usr/bin/slrnpull
Regular users cannot execute slrnpull therefore there
is no vulnerability in that regard, though as I stated
before there other problems in the slrnpull code when
it downloads/spools groups.
#2
slocate. I'm not sure what you meant by:
>- slocate - custom input file can be specified using
LOCATE_PATH;
> due to almost no input validation, it's
possible to
> supply many different input patterns, some of
them will
> cause potentially exploitable SEGVs; please
review this
> code. Ah, forgotten, gid slocate can be used to
> access slocate database in unrestricted mode
(every
> file in filesystem indexed, including eg.
/root,
> web scripts etc),
Yes slocate is sgid slocate and slocate database does
contain all files in the filesystem BUT it does consider
permissions when outputting location of files for instance:
As root:
[root@king /]# locate nt_hash
/root/nt_hash.txt
[root@king /]# ls -ald /root
drwxr-x--- 55 root root 4096 Jun 22 01:59 /root
[root@king /]# l -d /root/nt_hash.txt
-rw-r--r-- 1 root root 16379 Jun 12 1999 /root/nt_hash.txt
[root@king /]# locate nt_hash
/root/nt_hash.txt
[root@king /]#
Ok root can view files in /root, but now try as regular
user:
[user@king beta]$ ls -al /root
ls: /root: Permission denied
[user@king beta]$ locate nt_hash
[user@king beta]$
As you can see it will not list all files to regular users,
it obeys permissions. The above example is from a default
Red Hat install.
Secondly you claim that LOCATE_PATH is not properly parsed?
It is parsed using parse_decode_path() the same function
that parses input from the command line. Secondly you claim
this variable can be used to cause segfaults and gain
privilages? That doesn't seem true to me. In fact look
these lines and judge for yourself:
UID = getuid();
GID = getgid();
parse_decode_path(SLOCATEDB);
parse_decode_path(getenv("LOCATE_PATH"));
Those lines of code are run before any other command line
options etc, are checked and because privs are dropped at
this point I don't see how you can say anything can be
exploited to gain privilages of slocate group. Can you
clarify? Also there is consistant bounds-checking/mallocing
throughout the source and I did a quick scan of relevent
code and didn't see anything potentially dangerous. The
only thing I did notice is that if argv[0] is simply a
slash (/) and no other arguments are sent to the program
it will cause a for loop to continuously print " " to the
screen, and that in itself poses no probs. Only crashes I
could cause were in malloc functions and they all seemed
harmless. If you disagree I'd love some details, I have
plenty of free time ;-)
-Stan Bubrouski
comments, complaints, gripes, insults, compliments,
blackmail threats, unkind/kind remarks to:
satan@fastdial.net
(5224246) ------------------------------------------