[931] in linux-security and linux-alert archive
Re: [linux-security] about in.identd
daemon@ATHENA.MIT.EDU (Brian Mitchell)
Thu Jul 18 21:25:17 1996
Date: Thu, 18 Jul 1996 09:42:04 -0400 (EDT)
From: Brian Mitchell <brian@saturn.net>
To: "Alexander O. Yuriev" <alex@bach.cis.temple.edu>
cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199607171817.OAA11808@bach.cis.temple.edu>
On Wed, 17 Jul 1996, Alexander O. Yuriev wrote:
[Mod: Quoting trimmed. --Jeff.]
> A remote system can ask ident to return a string identifing a user owner of
> a connection. For example, lets say that an attacker connects to a service
> running with a super-user priviledge (it just binds a port below 1024). This
> service sends a request to ID a user to ident running on a remote machine.
> If that ident is used to penetrate a system, there is nothing to prevent
> an it from returning not 'mickeymouse' but 'micketmouse......' where .... is
> an image of the machine code to be executed. If a program requring the ID
> was designed to trust the response of a remote ident server ("Gee, it is the
> *ident* server, why not to trust it?!?!?!" ) then it probably did not expect
> anything like a bomb-code being returned.
The rfc specifies the maximum length for ident responses is 512 bytes, so
I don't see how machine code would do anything of any use, barring
overflows which should not happen, since it should read no more than 512
bytes, and the buffer it should read into should be atleast 512 bytes.
Of course, things that should happen often do not happen. Do you have any
examples of programs that don't handle in.identd queries well?
Brian Mitchell brian@saturn.net
"I never give them hell. I just tell the truth and they think it's hell"
- H. Truman
