Innfeed Buffer Overflow
rra at stanford.edu
Thu Apr 19 06:01:25 UTC 2001
Some clarifications. This exploit will not affect most installed INN
systems, and is, in my opinion, *primarily* a documentation issue
(although there are indeed security issues, the main one of which has
already been addressed in current versions of INN).
If you have users other than the news user in the news group on a system
with INN installed, this issue affects you; read on. If you don't, this
issue does not (unless you somehow have a misinstalled startinnfeed).
Enrique A Sanchez Montellano <enrique.sanchez at DEFCOM.COM> writes:
> Defcom Labs Advisory def-2001-19
> innfeed buffer overflow
This affects versions of INN prior to INN 2.3.0. startinnfeed was
rewritten in INN 2.3.0 and will no longer execute unless run as the news
user (the only user to which it will then setuid() to), making buffer
overflows in innfeed irrelevant from a security standpoint.
This particular buffer overflow is nonetheless fixed as a quality of
implementation issue in the current CVS tree and that fix will be in the
next release (in a different way than the patch provided in this advisory,
since the change recommended in this advisory required vsnprintf).
> Due to no bounds checking on the innfeed program a buffer overflow
> occurs while using the -c flag, thus rendering complete control of the
> stack. And rendering news uid and gid.
A whole bunch of details are missing here. Let me try to fill them in:
INN installs a wrapper for innfeed that is setuid root called
startinnfeed; this wrapper raises resource limits and then immediately
calls setuid to the news user before execing innfeed. This wrapper is
installed with permissions 4710, executable by group news. This wrapper
does not have a buffer overflow exploit, but it does execute innfeed
with the provided arguments, and it's possible to overflow a buffer in
innfeed itself by passing it extremely long command-line arguments (in
all versions of INN prior to the current CVS version).
In versions of INN prior to INN 2.3.0, the wrapper was executable by
anyone in the news group, and therefore this exploit can be used to
obtain access to the news UID if one already has access to the news
Now, long-time users of INN may not be particularly surprised by this, as
INN has *always* trusted the users who are part of the news group. By
default (for quite some time; as long as I've been running news, at the
least) INN installed all of its configuration files group-writeable, with
the assumption that members of the news group are the news administrators,
who would have access to the news account anyway. Obviously, with
group-writeable configuration files, there are a wide variety of ways to
elevate news GID access to news UID access without requiring buffer
The correct fix is to not put anyone in the news group who does not also
have access to the news UID. This assumption was *not* clearly documented
in the INSTALL guide; it is now in CVS, and I appreciate this oversight
being pointed out.
INN 2.4.0 when released will probably *not* continue the policy of
installing configuration files group-writeable by default, since I don't
believe that this is the way most news servers are configured these days.
> The user then is able to gain news id, in wich he can the trojan
> binaries to gain further access to upgrade his priviledges.
There is no additional exploit that would allow one to upgrade privileges
further. The above observation simply points out that if you have access
to the news account, and if root regularly runs binaries owned by news,
you can obtain access to root.
Obviously, root should not be executing binaries owned by users other than
root, for precisely this reason. A default installation of INN does not
put any of the INN binaries on root's path, and the installation
instructions specifically recommend against running any portion of the
news system as root.
> < vsprintf (buffer,fmt,ap) ;
> > vsnprintf (buffer,512,fmt,ap) ;
This patch applies to innfeed/misc.c.
My apologies for not getting back to the original sender of this message
in time with the above additional clarifications; I was under the
impression the advisory wasn't going to be sent out until tomorrow.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers