[14182] in bugtraq
Re: Potential security problem with mtr
daemon@ATHENA.MIT.EDU (LaMont Jones)
Tue Mar 7 07:37:54 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <7957.952114343.1@cranston.fc.hp.com>
Message-Id: <20000303201224.D0A5918726@security.hp.com>
Date: Fri, 3 Mar 2000 13:12:24 -0700
Reply-To: LaMont Jones <lamont@SECURITY.HP.COM>
From: LaMont Jones <lamont@SECURITY.HP.COM>
X-To: Viktor Fougstedt <viktor@dtek.chalmers.se>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Fri, 03 Mar 2000 16:42:24 +0100."
<Pine.GSO.4.10.10002142004440.13991-100000@demen.dtek.chalmers.se>
> Since the saved uid survives across fork() and exec(), any buffer
> overrun or similar bug in mtr is just as bad as if mtr had never done
> the seteuid() at all.
Saved-uid should get dropped on exec(), shouldn't it?
> The mtr code uses setuid() on HPUX, which according to the comments in
> the mtr code doesn't have the seteuid() call. It does seteuid() on all
> other systems though. It is unclear why the mtr authors favoured
> seteuid() before setuid() on platforms that have it.
Just FYI, HP-UX has setresuid() which allows you to change any
of the 3. Hence, seteuid() could be written (since days long
gone by) as 'setresuid(-1,uid,-1)'. Now, as to _why_ they chose
to add a setregid() system call, instead of making it a libc stub
to setresgid(), I still don't understand...
lamont
