Hi! it seems the security people must work 24/7 these days. Yesterday http://www.cert.org/advisories/CA-2001-07.html was published with respect to a "glob" vulnerability in ftpd. While the *BSD people already made some announcements, SuSE did not send out an announcement, yet. (Nothing popped up at wu-ftpd.org, too) For the ntp-vulnerability at least a "shut id down alert" was sent out soon. Therefore I decided to play safe and disabled ftpd yesterday evening... Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke@aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
Hi!
it seems the security people must work 24/7 these days.
Yesterday http://www.cert.org/advisories/CA-2001-07.html was published with respect to a "glob" vulnerability in ftpd.
While the *BSD people already made some announcements, SuSE did not send out an announcement, yet. (Nothing popped up at wu-ftpd.org, too) Maybe because its especially a *BSD problem? Even we need time (> 0) to review code when it comes to CERT reports etc. As far as we are through it seems
On Wed, 11 Apr 2001, Lutz Jaenicke wrote: that a) glibc is not affected by that glob() implementation fault and b) the port of the OBSD 2.7 ftpd we are using is not affected. I don't know about the other ftpd's. Other vendors are examining their code too, btw. Fast shots won't help. Sebastian -- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~
On Wed, Apr 11, 2001 at 12:14:19PM +0200, Sebastian Krahmer wrote:
Yesterday http://www.cert.org/advisories/CA-2001-07.html was published with respect to a "glob" vulnerability in ftpd.
While the *BSD people already made some announcements, SuSE did not send out an announcement, yet. (Nothing popped up at wu-ftpd.org, too) Maybe because its especially a *BSD problem?
That may be true. For (understandable) reasons the description in the advisory is a bit vague, so even though I had a glance over the source I didn't know what to look for in detail.
Even we need time (> 0) to review code when it comes to CERT reports etc. As far as we are through it seems that
a) glibc is not affected by that glob() implementation fault and b) the port of the OBSD 2.7 ftpd we are using is not affected.
I don't know about the other ftpd's.
Other vendors are examining their code too, btw. Fast shots won't help.
I totally agree. Your statement however does already quite help in understanding what is going on. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke@aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
Dear list, I am having a weird problem on my cleanly installed and updated SuSE 7.1 system: when I log in as root on tty1, and give the command w or who, it doesn't show the root login at tty1L i.e. when this is the only logged in process it seems like noone is actually logged in at all. Does anyone have any ideas on what could cause this, and how to fix it? I'd like to be aware of root logins on my system... Cheers, Yuri. -------------------------------------------------------------------------- Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
On Wed, Apr 11, 2001 at 12:14 +0200, Sebastian Krahmer wrote:
On Wed, 11 Apr 2001, Lutz Jaenicke wrote:
it seems the security people must work 24/7 these days.
Yesterday http://www.cert.org/advisories/CA-2001-07.html was published with respect to a "glob" vulnerability in ftpd.
And the topic has been discussed for several days now. It's just that CERT released the advisory yesterday ...
While the *BSD people already made some announcements, SuSE did not send out an announcement, yet. (Nothing popped up at wu-ftpd.org, too) Maybe because its especially a *BSD problem?
Huh? How is it BSD specific? It's a simple "whenever I send expensive requests to the server the server suddenly gets busy". It's the "I can put down the machine with a fork() loop" kind of pseudo exploits. The ftpd "problem" is that the server accepts wildcards for its LIST command variants. Two (three) solutions have been outlined: - DJB refuses to implement this kind of functionality in his server software and asks the client(s) to achieve the same goal by using elementary operations like "cd" and "ls" instead of expecting "ls */*/*/*" to work - Any software can be run in restricted login / group capabilities, under control / influence of ulimit(2) type wrappers, etc. Have a look at the daemontools package (again it's DJB software) or their PAM counterparts (something I'm not as familiar with). The third way is what you actually talk about but is what maybe cannot be considered the real solution to the problem: - Libraries providing globbing services (I understand it's "just" expanding wildcards) can obey arbitrary limits in their operation. The problem here is that you either take the limits out of the administrators' reach (by hardcoding any value the programmer thought of but the admin isn't going to accept) or that you have to provide these knobs up into the application -- where they can be enforced by the above other means as well.
a) glibc is not affected by that glob() implementation fault and b) the port of the OBSD 2.7 ftpd we are using is not affected.
I still don't think that it's a program author's fault but more of an administrator's (read: pilot's) error. Apply resource constraints to your services. You have to do so anyway to not suffer too much from possible programming errors as well as DoS attacks. Why not apply them too for "valid" but yet too costly requests? It's plain selfdefence by using regular tools from your existing workbench / toolbox. :) Of course I'm interested in learning what obvious facts I've been overlooking when thinking that this neither is a DoS specific to BSD nor any new problem at all and can be solved by tools already in existence and used anyway. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
On Wed, 11 Apr 2001, Gerhard Sittig wrote:
Huh? How is it BSD specific? It's a simple "whenever I send expensive requests to the server the server suddenly gets busy". It's the "I can put down the machine with a fork() loop" kind of pseudo exploits. The ftpd "problem" is that the server accepts wildcards for its LIST command variants.
Please note: this is _not_ a resource exhaustion attack. The "File Globbing Vulnerability" in question is a buffer overflow attack potentially leading to code execution (Solaris - heap overflow, HPUX - stack overflow), not the similar DOS attacks that have been known for a while now (CERT CA-2001-07 mentions this in the overview). The short version is that certain assumptions about buffer length are made based on limitations on user input and when the glob expansion is done the total length may be greater than the buffer allocated based on those assumptions. Interesting delivery method, but after that it's a straight up buffer overflow with all that implies in terms of a remote take over of the box. The discussion of defenses against resource exhaustion was technically accurate and is helpful for the resource exhaustion attack, but this is a different vulnerability. -- Jonathan Conway The thing about Unix is that all the hoops are rise@knavery.net flaming, so at least you know where they are...
On Wed, Apr 11, 2001 at 12:14 +0200, Sebastian Krahmer wrote:
On Wed, 11 Apr 2001, Lutz Jaenicke wrote:
it seems the security people must work 24/7 these days.
Yesterday http://www.cert.org/advisories/CA-2001-07.html was published with respect to a "glob" vulnerability in ftpd.
And the topic has been discussed for several days now. It's just that CERT released the advisory yesterday ...
While the *BSD people already made some announcements, SuSE did not send out an announcement, yet. (Nothing popped up at wu-ftpd.org, too) Maybe because its especially a *BSD problem?
Huh? How is it BSD specific? It's a simple "whenever I send expensive requests to the server the server suddenly gets busy". It's the "I can put down the machine with a fork() loop" kind of pseudo exploits. The ftpd "problem" is that the server accepts wildcards for its LIST command variants. Huhu? We talk about remotely exploitable bufferoverflows, and in fact only BSD versions of glob() are affected. I don't know about ftpd's such as wu.ftp etc etc. It was claimed that they also contain overflows. The suse standard ftpd (which is derived from OBSD's) is believed to be secure (for
On Wed, 11 Apr 2001, Gerhard Sittig wrote: that specific glob() overflow).
I still don't think that it's a program author's fault but more of an administrator's (read: pilot's) error. Apply resource constraints to your services. You have to do so anyway to not suffer too much from possible programming errors as well as DoS attacks. Why not apply them too for "valid" but yet too costly requests? It's plain selfdefence by using regular tools from your existing workbench / toolbox. :)
Seems we talk about different bugs/admin erros. An overflow in the software is not admins fault. :) regards, Sebastian -- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@suse.de - SuSE Security Team ~
On Thu, Apr 12, 2001 at 14:26 +0200, Sebastian Krahmer wrote:
[ ... me (Gerhard) wonders what the problem actually is :) ... ]
Huhu? We talk about remotely exploitable bufferoverflows, and in fact only BSD versions of glob() are affected. [ ... ] Seems we talk about different bugs/admin erros. An overflow in the software is not admins fault. :)
OK, I got it. Buffer overflows definitely are different from starving due to expensive requests. Thank you for correcting my thinking simple ... virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
participants (6)
-
Gerhard Sittig -
Lutz Jaenicke -
rise -
Sebastian Krahmer -
Thomas Michael Wanka -
Yuri Robbers