Openwall Project   /home  Owl  JtR  Pro  crypt  pam_passwdqc  tcb  phpass  scanlogd  popa3d  msulogin  /  Linux  BIND  /  advisories  presentations  /  services  donations  /  wordlists  passwords  /  news  community  lists  wiki  CVSweb  mirrors  signatures
bringing security into open environments
 
Password Recovery Resources on the Net
[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]
Date: Wed, 10 Dec 2008 15:53:47 +0100
From: Andreas Ericsson <ae@....se>
To: Eygene Ryabinkin <rea-sec@...elabs.ru>
CC: oss-security@...ts.openwall.com, jlieskov@...hat.com, 
 coley@...re.org
Subject: Re: CVE Request (nagios)

Eygene Ryabinkin wrote:
> Andreas, good day.
> 
> Will you be able to clarify two things.
> 
> Mon, Dec 08, 2008 at 05:19:52PM +0300, Eygene Ryabinkin wrote:
>> So
>>   http://nagios.cvs.sourceforge.net/viewvc/nagios/nagios/base/commands.c?r1=1.109&r2=1.110&view=patch
>> just completely closes the processing of these commands from the
>> Nagios side.  May be this was the fix for the case when the evil
>> contents from the command file were still floating around but the
>> upgraded Nagios won't process them because they could go from the
>> previous successful attack but are lying unprocessed?
> 
> Do you think it is really so?
> 

Umm... I can't parse the above paragraph. In short though, the removed
commands are removed *from the cgi's* because it's far too dangerous
to allow such things over the web. Nagios will still process them if
they are submitted to the command-pipe, but the CGI's can no longer
write such commands to said pipe.

>>> It is a bit strange that it was done after 3.0.5 (CSRF was documented in
>>> 3.0.5 release notes), but...  By the way, entry for CVE-2008-5028 speaks
>>> about 3.0.5 as about the vulnerable to the CSRF and it is inconsistent
>>> with the release notes at
>>>   http://www.nagios.org/development/history/nagios-3x.php.
>> So I feel the the CSRF was "somehow closed" in 3.0.5 and CVE entry may
>> need fixing.  The remains from this bug that could migrate from 3.0.5 to
>> 3.0.6 (but not in the functional sense, only via the unprocessed command
>> file) were "fixed" in 3.0.6.
> 
> CVE-2008-5028 really speaks about 3.0.5 as about vulnerable to CSRF.  At
> least CHANGE_ commands were closed in 3.0.5 and were (presumably)
> additionally closed at the Nagios server side in 3.0.6.  So either 3.0.6
> is vulnerable too, 3.0.5 is not vulnerable to CSRF or I am missing
> something.  What to choose?
> 

3.0.5 is vulnerable to CSRF. 3.0.6 (which adds in-form session tokens to
cmd.cgi, which processes all commands from the web-forms), is not vulnerable
to CSRF.

3.0.5 fixes the authorization bypass discussed in CVE-2008-5027, where an
authenticated user can submit commands he/she was not supposed to be able
to submit. However, by blocking the CHANGE_ set of commands, the worst-case
impact of the CSRF was drastically reduced, and the change to blocking those
commands was also a part of 3.0.5.

I'm afraid Ethan (the Nagios maintainer) got it wrong in the changelog,
which is why, I presume, there's so much confusion right now.

I wrote the patches for it though, so I think it's safe to say I know what
patch (and version) fixed what.

-- 
Andreas Ericsson                   andreas.ericsson@....se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux