[12416] in bugtraq
Re: Fix for ssh-1.2.27 symlink/bind problem
daemon@ATHENA.MIT.EDU (Wietse Venema)
Wed Nov 3 15:17:41 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <19991103193908.026A145A2A@spike.porcupine.org>
Date: Wed, 3 Nov 1999 14:39:08 -0500
Reply-To: Wietse Venema <wietse@PORCUPINE.ORG>
From: Wietse Venema <wietse@PORCUPINE.ORG>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <19991029155052.C38256@bitbox.follo.net> from Eivind Eklund at
"Oct 29, 99 03:50:52 pm"
Eivind Eklund:
> On Wed, Oct 27, 1999 at 06:35:56PM -0400, Wietse Venema wrote:
> > ssh starts up with the unprivileged real UID of the user; therefore
> > setting the effective UID also to that of the user makes the process
> > memory accessible for unprivileged access. This is how any reasonable
> > UNIX system works, not just Solaris.
>
> I disagree. A reasonable system tracks whether a process has ever had
> elevated privileges, and deny access to process memory (core dumps,
> debugger attachments) if it has had.
Some people live in a dream.
There is no standard that requires that UNIX systems disallow
process memory access after privilege changes.
A security-sensitive application must be prepared to deal with the
semantics of REAL SYSTEMS that conform to standards.
To summarize this thread: there was no need to break up the ssh
client into two processes in order to prevent unprivileged access
to host keys, even on systems with standard, but imperfect, semantics.
Wietse
