Security issue

[Andreas Ericsson]

Arno Lehmann wrote:
> Hi,
> 
> 07.11.2008 09:33, Andreas Ericsson wrote:
>> Arno Lehmann wrote:
>>> Hi,
>>>
>>> 06.11.2008 12:45, Andreas Ericsson wrote:
>>> ...
>>>> A couple of things to note:
>>>> * Information disclosure is not possible. No remote user can see
>>>>   anything from your authentication-protected Nagios servers.
>>> I'm not sure this is correct... see what all the web 2.0 stuff is 
>>> about - javascript executes http queries, captures the output, and 
>>> does something with it.
>>>
>> No. Javascript and flash are
> 
> Let me add one word here: "theoretically".
> 
> There have been many security issues in browsers already, and it's 
> probably not unlikely there will be more.
> 
> Of course, that's not exactly Nagios' problem. Still, if the Nagios 
> CGIs can be improved to make such an exploit less likely, the required 
> work will be well invested.
> 
>> protected by the same-site policy
>> (according to Tim Starling of the wikimedia foundation, who brought
>> this to some nagios-developer's attention), so they can't be made
>> to send stuff from nagios-server.example.com to evilsite.com.
>>
>>> I guess it's possible for a javascript in Dr. Evils pages to get the 
>>> cgi output without actually displaying it, and to forward the 
>>> information collected to Dr. Evils web server.
>> Yes, but only from CGI's running on evilsite.com. Otherwise javascript
>> kiddies would be billionaires from ripping people off through online
>> banking or whatever.
> 
> They do, don't they?
> 
> Or, at least, they try, and only the ones who are well beyond the 
> kiddie stage are successful - but still the problem exists.
> 
>>> Don't ask for a sample exploit, please.
>>>
>> Well, if you can think one up, you'll have discovered a fundamental
>> problem in how javascript works (it will be browser-dependant) and
>> should definitely report it to the developers of that browser.
> 
> Sure... unfortunately, discovering such things is well beyond my 
> capabilities.
> 
>>>> * Invalid commands read from the FIFO are always dropped flat by
>>>>   Nagios.
>>>> * Since commands must be valid, it's not very easy to submit a
>>>>   command that has all the information required. Social engineering
>>>>   is required.
>>>> * You *will* notice if this happens to you, since you all of a
>>>>   sudden will end up with cmd.cgi (not in a frame either) saying
>>>>   "Command submitted successfully" or some such.
>>> See above - AJAXified web pages probably can prevent this.
>>>
>> Nopes. You see above ;-)
> 
> Nopes^2 - it's probably possible ;-)
> 
> But, just to prevent this discussion from going on eternally - the 
> current fixes seem to be an important step towards a more secure web 
> interface, and try if you might, there's no cure against browser 
> defects possible inside Nagios' cgis - I'm aware of that.
> 

There is, actually. One could add a session token to each and every page
and pass it on to every page leading away from it. However, that means
users would need to first create the session token and then never using
two browser-windows, or typing a direct url manually, or...

I know of one webbased application that does this. It sits in a bank.
It's akin to using chaining block cipher mode, where the old key is
always part of the new one. It's a very cumbersome way of working that
imposes many restrictions on the user.

For those that absolutely must have security on this level, the
form_session.[ch] files can actually do that. It would require some
patching of the cgi's though (primarily the *_CGI macros need to be
converted to run a function that returns the url to the desired cgi
concatenated with the session token from the current page).

Ofcourse, such a scheme breaks down horribly when using framed pages
(links in a different frame can't know what the current session state
key is) and it won't work with the autoreloading as it's implemented
today.

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/