[29276] in bugtraq
Re: QPopper 4.0.x buffer overflow vulnerability
daemon@ATHENA.MIT.EDU (Florian Heinz)
Wed Mar 12 12:52:01 2003
Date: Wed, 12 Mar 2003 10:55:34 +0100
From: Florian Heinz <heinz@cronon-ag.de>
To: Torsten Mueller <torsten@archesoft.de>
Message-ID: <20030312095534.GB20261@dereference.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3E6EFEE9.E9CF821@archesoft.de>
On Wed, Mar 12, 2003 at 10:33:29AM +0100, Torsten Mueller wrote:
>
>
> Florian Heinz schrieb:
> >
> > Hello,
> >
> > Under certain conditions it is possible to execute arbitrary code using
> > a buffer overflow in the recent qpopper.
> >
> > You need a valid username/password-combination and code is (depending on
> > the setup) usually executed with the user's uid and gid mail.
> >
> ...
> >
> > This is the short version. An enhanced version with error-checking,
> > bufsize- and return-address autodetection can be found on
> > http://nstx.dereference.de/snippets/qex.c
> >
> > Feedback is welcome.
>
> ... and here it comes ;-)
>
> I tested http://nstx.dereference.de/snippets/qex.c
> against 3 selfcompiled qpopper4.0.4 on 3 different machines.
>
> I can confirm, that on one machine "it worked", i got
> a shell.
Nice ;)
> More interesting for me is of course, if you can provide
> a patch against 4.0.4 to close this vulnerability.
As said, just make sure the buffer is null-terminated in Qvsnprintf().
Randall Gellens quickly reacted and released qpopper-4.0.5rc2, which
also contains a fix for this issue.
I also managed to modify a popper-binary with hexedit to use the
libc-vsnprintf instead of the Qvsnprintf provided, which solved that
problem, too, but this was merely for fun and testing, this could probably
cause other inconsistencies ;)
