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.
