Newest innd 2.2.2, probably the most popular usenet news server (as well as previous versions) contain remotely exploitable, trivial on-stack buffer overflow in control articles handler. Offending piece of code (in innd/art.c, function ARTcancelverify): if (!EQ(local, p)) { files = NULL; (void)sprintf(buff, "\"%.50s\" wants to cancel %s by \"%.50s\"", p, MessageID, local); ARTlog(Data, ART_REJECT, buff); } Where buff (local stack buffer) is SMBUF bytes long (it means, 256 bytes), but MessageID can be up to 1000 almost bytes long. This code is reached when cancel request is sent to special newsgroup (called 'control'), and cancel request contains valid Message-ID, but From/Sender fields are different in cancel request and in original posting. How to exploit it? It could be a problem for script kiddies, as Message-ID is strictly checked for non-printable characters etc. But hey, Message-ID can be used only as a padding, and then we can overwrite return address with From/Sender address of cancel post! This field is not verified in any fascist way. Shellcode? Can be placed anywhere, quite big portions of cancel post are lying in the accessible memory when overflow happens. Sample input ("LONGBUFFER" = around 500-600 bytes of AAAs..., has to be the same every time): -- input - 201 XXX InterNetNews NNRP server INN 2.2 23-Oct-1998 ready (posting ok) mode reader group pl.test post Message-ID: From: Sender: Newsgroups: pl.test testing . <- single dot, comment to avoid mail transfer problems group control post Message-ID: Approved: From: Sender: Control: cancel Subject: cmsg cancel Newsgroups: control Damn, cancel it. . <- single dot quit -- EOF -- If innd/nnrp is running under debugger like strace, you'll see that child process responsible for request handling dies with SIGSEGV. Nice. _______________________________________________________ Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security] [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};: =-----=> God is real, unless declared integer. <=-----=