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.sanchezat_private> 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 GID. 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 overflows. 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. > ---innfeed-overflow.patch--- > 210c210 > < vsprintf (buffer,fmt,ap) ; > --- > > vsnprintf (buffer,512,fmt,ap) ; > ---innfeed-overflow.patch--- 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 (rraat_private) <http://www.eyrie.org/~eagle/>
This archive was generated by hypermail 2b30 : Thu Apr 19 2001 - 20:47:58 PDT