In message <pine.bsf.4.10.9907111649160.27818-100...@janus.syracuse.net> "Brian F. Feldman" writes: : How in the world could my inetd ident service be exploited? I just fixed : the only problematic feature, fake id, to make it not read anything but a : regular file and not let you try to use someone else's name. I can't see : any way that any part of it could be exploited...
Typically how that was exploited is as a buffer overflow on the remote side (eg there was an exploit in sendmail where the attacker would send a very long string when the ident request came accross. Sendmail would record this in a fixed length buffer on the stack, which overflowed allowing an egg to execute). The text file that you read could be used to make it easier to setup such a hostile host, since if I recall correctly, the entire EGG was printable characters. There are no limits in the size of responses for ident... Thankfully, this exploit is long since dead. However, with irc servers using it as a "honest people's lock to keep honest people honest" maybe there is something that can be done there. Also, at one time one could open the ident service port up and just sit there, never sending data. After a short period of time, all the ident server slots would be in use, and then the attacker could begin to attack the remote side in earnest (this is a reason that I had forgotten why identd was considered to be a very weak protocol). There was also some trick of using identd to scan ports (eg, connect to identd and ask for each port, in succession, since some early identds weren't selective enough about the data they returned). I also recall seeing on some of the "blacker" lists that I've bumped into instructions for using TTCP and/or half open connections to confuse identd as well. I can't find the references right now, but these may also have boiled down to the TCP SYN-class of attacks that was so popular a while ago. There is also a danger in accepting source routed packets as well (which I think we turn off at the system level by default). They could be used to figure out who other connections belonged to by disguising the source address to be one other than the originator to gain information about any user connected to your machine. Well, you did ask how it might be abused :-) Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
