[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] CVE Request - rsyslog
From:       Jan Lieskovsky <jlieskov () redhat ! com>
Date:       2008-12-08 14:53:46
Message-ID: 1228748026.3834.72.camel () dhcp-lab-164 ! englab ! brq ! redhat ! com
[Download RAW message or body]

Hello Steve,

  the following vulnerability has been recently reported
in rsyslog:

http://www.rsyslog.com/Article322.phtml

References:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508027
http://secunia.com/Advisories/32857/

Upstream patch:
http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=f0ddbed44c332391ae6d9bbf6b07e2f06c4dd676

The reporter mentions:
"The versions affected are rsyslog 3.12.1 to 3.20.0, 4.1.0 and 4.1.1.    
 The v2-stable branch is not affected."

Although the v2-stable part is missing the plugins/imgssapi,imtcp,imudp
part of the patch, the affected 'clearAllowedSenders' function can be
found in syslogd.c 

 740 static void clearAllowedSenders (struct AllowedSenders *pAllow) {

and 'isAllowedSender' function from syslogd.c also lacks the check added
by the patch:
 
   1049 /* check if  a sender is allowed. The root of the the allowed sender.
   1050  * list must be proveded by the caller. As such, this function can be
   1051  * used to check both UDP and TCP allowed sender lists.
   1052  * returns 1, if the sender is allowed, 0 otherwise.
   1053  * rgerhards, 2005-09-26
   1054  */
   1055 int isAllowedSender(struct AllowedSenders *pAllowRoot, struct sockaddr *pFrom, const \
char *pszFromHost)  1056 {
   1057         struct AllowedSenders *pAllow;
   1058 
   1059         assert(pFrom != NULL);
   1060                                   <- no "if(setAllowRoot(&pAllowRoot, pszType) != \
RS_RET_OK)" from the patch  1061         if(pAllowRoot == NULL)
   1062                 return 1; /* checking disabled, everything is valid! */

so it is highly probable, rsyslog-2.0 is also affected by this issue (checking with the \
developers yet).

Could you please allocate a new CVE id for this issue?

Thanks, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team


[prev in list] [next in list] [prev in thread] [next in thread]