[11344] in bugtraq

home help back first fref pref prev next nref lref last post

Re: [jen@ettnet.se: sdtcm_convert]

daemon@ATHENA.MIT.EDU (Joel Eriksson)
Wed Aug 11 01:50:26 1999

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id:  <19990810190212.A21892@hades.chaoz.org>
Date:         Tue, 10 Aug 1999 19:02:13 +0200
Reply-To: Joel Eriksson <jen@ETTNET.SE>
From: Joel Eriksson <jen@ETTNET.SE>
X-To:         Topher Hughes <thughes@cisco.com>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <37B046ED.A5694E6B@cisco.com>; from Topher Hughes on Tue, Aug 10,
              1999 at 10:36:13AM -0500

On Tue, Aug 10, 1999 at 10:36:13AM -0500, Topher Hughes wrote:
> at some point in time in the past either 1)netscape, 2) a patch or 3)me
> set the set-gid bit on the /usr/spool/calendar directory. this
> effectively stops it - the created files are all in the daemon group.
>
> *shrug* as soon as I figure out why that bit is set, I'll probably post
> what fixed it.

Ehrm, the SGID bit is set on the system I'm on too, I think it's the
default. :-) That does not affect the bug though.

Try: ln -s /filetocreate /usr/spool/calendar/.lock.<hostname>

Several people have pointed out that Solaris 7 is not vulnerable,
since the directory is only writeable to user and group daemon.

One post also told me that he tested the bug on a Solaris 2.6 x86
system, where the link was deleted before creation of the file. Maybe
Suns security guru Casper Dik could tell the rest of Bugtraq which
patches there are for Solaris 2.6 that fixes this bug? :-)

I don't know what patches are installed on the system where I found
the bug, but both the race that let a user chown/chmod a file (since
I saw in the truss-output that fchmod() and fchown() was used on the
open filedescriptor instead) and the buffer overflow in the -d command
line argument was fixed.

--
Joel Eriksson                                           jen@ettnet.se
Security Consultant

home help back first fref pref prev next nref lref last post