Re: rh 6.2 - gid compromises, etc

2000-06-23T00:00:00
ID SECURITYVULNS:DOC:376
Type securityvulns
Reporter Securityvulns
Modified 2000-06-23T00:00:00

Description

>- 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