[924] in linux-security and linux-alert archive
[linux-security] about in.identd
daemon@ATHENA.MIT.EDU (Alexander O. Yuriev)
Wed Jul 17 14:45:55 1996
To: linux-security@tarsier.cv.nrao.edu
Date: Wed, 17 Jul 1996 14:17:02 -0400
From: "Alexander O. Yuriev" <alex@bach.cis.temple.edu>
Hello,
This is an explanation of one of the ways such attack can be
performed.
First of all, this is *not* an attack against the in.identd! This is
an attack against the *protocol* used by identd. As Matt Bishop said once
the easiest way to discover security problem is to look at the manual pages
of your Unix box paying attantion to words "should" "never" "must not" "will
not".
The ident protocol simply returns an owner of a connection
originated on a remote machine. Another name for this protocol is auth.
auth 113/tcp ident # User Verification
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.
Best wishes,
Alex
