[15432] in bugtraq
Re: rh 6.2 - gid compromises, etc
daemon@ATHENA.MIT.EDU (Stan Bubrouski)
Thu Jun 22 20:37:02 2000
Message-ID: <20000622181607.3394.qmail@securityfocus.com>
Date: Thu, 22 Jun 2000 18:16:07 -0000
Reply-To: Stan Bubrouski <satan@FASTDIAL.NET>
From: Stan Bubrouski <satan@FASTDIAL.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.21.0006211209500.22969-100000@nimue.tpi.pl>
>- slrnpull (setgid: news) - using eg. NNTPSERVER
environmental variable,
> you can cause nice SEGV... egid==news, of course. On
systems running
> innd server (and probably other newsservers as well),
group 'news' can
> be used to control content of whole spool, and to elevate
privledges,
> gaining euid news. From this point, we can simply
takeover nntp
> service.
>
> Under some conditions, inews can be used in the same way,
but bug
> is hidden a little bit deeper. I'll leave it as an
exercise to
> readers (and maintainers - please audit your code, not
only fix
> published bugs),
THIS ISN'T EVEN TRUE!!!
Might want to get your facts strait, non-privilaged users
cannot execute
slrnpull because of it's default permissions:
root@king devel]# l /usr/bin/slrnpull
-rwxr-s--- 1 news news 50684 Jun 10 18:39
/usr/bin/slrnpull
so no privilages can be gained what-so-ever in the manner of
which you
speak. And this problem (as I noted in my bug report to red
hat which has
gone unanswered) is in nntplib.c which is part of both slrn
and slrnpull
so both suffer from the overflow but since unprivilaged
users cannot gain
elevated privilages from either it's not much to be
concerned about.
There is an overflow in nntplib.c that is of concern however
which involves
group names. In certain areas of the code group names which
are larger
than NNTP_MAX_GROUP_NAME_LEN and MAX_GROUP_NAME_LEN which
are both set
to 80 by default could be able to cause buffer overflows
which could allow
a remote news server to execute arbitrary commands as the
user of slrnpull.
But again the bug in slrnpull you mention DOES NOT in any
way allow unprivilaged
users any more privilages. Did you even bother to look at
the permission on
the file? Or did you just copy my reports to red hat's
bugzilla? The problem
he reported with slrnpull is not a problem and gives no
access, therefor it
doesn't even belong in the vulnerability DB.
And gkermit, funny how your report seems to mirror my report
made a couple weeks
ago to red hat's bugzilla as well. Can't prove that and it
makes no difference
if you did, but have the heart to give credit where it is
due, because I can
tell from your report looking it over again you based it on
mine. You don't
agree with me? I couldn't give a flying fuck either way.
-Stan Bubrouski
