(not an) innfeed vulnerability

Russ Allbery rra at stanford.edu
Thu Apr 12 20:23:15 UTC 2001

Enrique A Sanchez Montellano <enrique.sanchez at defcom.com> writes:

> Ok here is the example, the only thing that is required is that root
> runs innfeed as a cron job or manually, wich is done by some
> administrators ...

What administrators?  Neither of those actions makes any sense.  innfeed
is meant to be run as the news user, and if you run it as root you can
cause all sorts of permissions problems later for versions of innfeed that
are running as news.

Anyway, yes, INN installs a bunch of binaries owned by news.news, and if
you routinely execute those binaries as root, someone with access to the
news account may be able to trojan binaries to obtain root.  Personally, I
think this sort of thing is basic systems administration, but if you think
it might be helpful, we could put a warning in INSTALL about this.  In
general, no part of the news subsystem should ever be run by root, and in
a default installation none of the INN binary directories are on root's

INSTALL already sort of talks about this, but I suppose it could be made

> nahual at shell:~$ id
> uid=1001(nahual) gid=100(users) groups=100(users),13(news)

Yes, you're in the news group.  If you're in the news group, you can
obtain news UID on versions of INN prior to INN 2.3.  I agree with that
part, but that's not what your advisory said (among other things, it
didn't note that this is fixed in INN 2.3).

>> Furthermore, you can only get news UID if you already have news GID:

> Yeah but that is an escalation of priviledges even if its not root

I agree.  This part is fixed in INN 2.3 (ever since INN 2.3.0).  I don't
consider this particularly important since this has been somewhat widely
known for a long time, and the news group generally only contains trusted
users.  But if you feel like it's worth an advisory against INN 2.2, I
won't argue with you about that part.

> I'm calling startinnfeed, I have tried this with 2.3.1, startinnfeed is
> 4550 owner root group news so I can still call that instead of innfeed
> since its news.news 500 on a secure manner, startinnfeed does a
> setuid(news) and in there is where i can then gain news uid.

Show me.  In INN 2.3.1, startinnfeed contains the following code:

    /* Convert NEWSUSER and NEWSGRP to a UID and GID.  getpwnam() and
       getgrnam() don't set errno normally, so don't print strerror() on
       failure; it probably contains garbage.*/
    pwd = getpwnam(NEWSUSER);
    if (!pwd) {
        syslog(L_FATAL, "getpwnam(%s) failed", NEWSUSER);
    news_uid = pwd->pw_uid;
    /* ... */

    /* Exit if run by another user. */
    if (getuid() != news_uid) {
        syslog(L_FATAL, "ran by UID %d, who isn't %s (%d)", getuid(),
               NEWSUSER, news_uid);

right at the beginning.  It won't run at all if you're not already the
news user.

If you want to issue a security advisory that says that under INN 2.2, any
user in GID news can obtain UID news, I'll attest to the accuracy of that
comment (at least from what I remember of what startinnfeed looked like
then).  I don't consider that to be a particularly interesting hole, but
some people might.  The fix is to upgrade to INN 2.3 or make sure that the
news user is the only member of the news group.

I still haven't seen evidence of a security hole other than news UID from
news GID for INN 2.2, or any security hole at all in current versions of
INN.  Maybe I'm still missing something, but I don't know what it might

Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

More information about the inn-bugs mailing list