Re: Multiple Vendor "talkd" user validation fault.

[Mike Scher <mscher () neohapsis com>]

On 3 Apr 2002, Tekno pHReak wrote:
[...]
> Their exist a flaw within the "talkd" which allows anyone masquerade as
> anyone else either remotely or within the confines of the system. This
> is due to the lack of user validation by the "talkd"  for incoming
> "talk" requests. This may be a catalyist for social engineering which
> can lead to the revealing of private or sensitive information from other
> users.
[...]

Ah, talk request spoofing.

This very problem was discussed way back in 1996 on Best Of Security
(BoS). It's good to see people are still talking about the problem and
proving it IS an issue.

I suppose the sad part of it all is that this problem was discussed,
shrugged off, and more or less ignored for so long that it's resurfaced,
complete with a new tool to exploit it.  Kudos to Teknophreak for bringing
it to light again, and for the publication of the spoofer, since that may
hammer the issue home.

A copy of the informative 1996 posting by Rombout de Backer (r () idb nl) is
at: http://www.tao.ca/writing/archives/security/0214.html

A cleaner copy, from a repost to the OpenBSD lists, is at:
http://www.monkey.org/openbsd/archive/tech/9604/msg00010.html


de Backer also posted a one-liner proof-of-concept change to the talk from
NetKit-B-0.05, and there were modified ytalk clients floating around with
command-line options for spoofing by the end of April, 1996.  Any
suggested fixes to talk will only work locally, where the daemon can do
some checking; any remote fixes really depend on changing the protocol or
migrating to a safer (or explicitly untrusted) chat system.  AUTH lookups
(as suggested in the de Backer post) don't really cut it:  n/talk are UDP
protocols.

      -M

-- 
      Michael Brian Scher                        mscher () neohapsis com
                   Mailaise: n, ('mail-aze).  See Outlook.