[14729] in bugtraq
Re: aaa_base still vulnerable after upgrade
daemon@ATHENA.MIT.EDU (Matthias Andree)
Mon May 1 01:09:19 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <m3itx07gyt.fsf@emma1.emma.line.org>
Date: Sat, 29 Apr 2000 23:08:42 +0200
Reply-To: Matthias Andree <ma@DT.E-TECHNIK.UNI-DORTMUND.DE>
From: Matthias Andree <ma@DT.E-TECHNIK.UNI-DORTMUND.DE>
X-To: Marc Heuse <marc@suse.de>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: marc@suse.de's message of "Sat, 29 Apr 2000 19:01:20 +0200 (MEST)"
marc@suse.de (Marc Heuse) writes:
> > Isn't it embarrassing to announce fixes which don't even touch the
> > _vulnerable_ packages?
>
> it is true that the rpm does not fix the problem. the reason: the security
> update rpm building failed for 6.2 for unknown reason, which will be
> fixed.
I don't care why it failed. Fix the REASON for the failure.
> The updates for 6.3 and 6.4 do work and fix this and another security
> problem.
> You can see that easily by a look at the filenames:
I see that the filenames are an obnoxious mess. 6.3 has "2000.1.3"
version names for a package built in April. I see that 2000 sorts BEFORE
99. This is annoying since it makes semiautomatic RPM updates from the
update directories on your servers a major hassle unless you're going to
implement AI parsers.
> > It expresses that SuSE still are not familiar with security, and they
> > do not regularly audit their programs for security issues.
>
> thank you very much, but I think it is completely the other way around.
There is no point in discussing this. One simply does not code rm -f
$DEL_FILE, but rm -f "$DEL_FILE", or better, not even mess with so much
scripts if a simple find will do (see the announcement).
Still, SuSE 6.2 has an unfixed inetd.rpm (see
http://cr.yp.to/docs/inetd.html for a working exploit). The problem has
been reported here more than once. I did not check if this affects 6.3
or 6.4 as well since I don't run those versions.
> > touch "/tmp/x /etc/rc.config"
>
> btw have you ever tried out this command? It won't work. A filename is not
> allowed to have a slash in it's name ...
That's correct, I missed that (fails with 'no such file or directory'
since there is no "/tmp/x " directory here). Still, you can delete
things in the root directory, which is NOT correct, plus, the script
will not be able to delete files the names of which (-> "no such file or
directory") contain blanks.
--
Matthias Andree
