ANNOUNCE: Nagios Looking Glass 1.0.0#PRE is here!

[Hans Spaans]

On Thu, Dec 28, 2006 at 06:58:38PM +0000, Andy Shellam (Mailing Lists) wrote:
> Hi Robert,

Hi Andy,

I'm reading your responses and from others, but I'm under impression
that you're trying to fight symptoms instead of really focus your
energy on the real problem. I see that you try to learn and improve
and I think its worth the time to get the discussion going again, but
in a direction we all might benefit from.

Also if you think I'm intrusive or dominant or arrogant. My apologies
in advance to you all, but its not to troll or something like that.

> Thanks for your description below but I'm still struggling to come to 
> terms with how NLG can be used to attack another site.
> Firstly, my understanding of an XSS attack is of the following:
> 
> - Client requests a page (eg. www.yahoo.com)
> - Hacker strips the response packets off the wire and replaces them with 
> packets that have come from (eg. www.google.co.uk)
> - Client receives www.google.co.uk as a result of hacker's actions

This it not really XSS, but more like DNS-spoofing and some wicked
redirection box. But don't focus on XSS right now, but on what Hans
Wolters and others where talking about. It will make thing much easier.

> Sure, this is a problem in sites with login/sensitive details stored in 
> cookies etc, which is over any HTTP connection.

What is the problem really? Is has nothing todo with login or
sensitive data, but with checking you data and keeping a careful eye
on data. So to keep it simple, data should be sanitized always to make
sure its in the bounderies as you would expect it and it need to be.

But a lot of people also make an incorrect assumption here. They
belief that by checking if a variable is an integer at the start of
the function that everything is good. No way, in the most extreme form
you need to sanitize your data after every operation on it, but that
would be too much. But instead of checking everyhing again everytime
you can also write your function in a way that you cover every outcome
or path you funtion can and should take. A litte C-example below is an
exampe of this.

int foobar ( int i )
{
  if ( i > 0 )
	  if ( i < 100 )
		  return 0;
		else
		  return 1;
	else
	  return 1;
}

I must say that you're on the right path by saying things like we
check if its an integer or else we fix it to zero. But I leave it up
to you right know to decide if this is enough, but I think you know
the answer already ;-)

> If this understanding is correct, is it Google's problem that a hacker 
> is sending it's website in place of a different site?  It's a public 
> site after all that anyone (including hackers) can access.
> Now if the client receives bad data from NLG - the data is only "bad" in 
> the sense that the server list will be empty, or will be reset to the 
> default (filter/group 0.)  Dependent on the attack source, it may even 
> only be part of the template (as the full template is requested in 3 
> parts.)  How is this a security risk?

You're saying something interesting and that is that everyone can
access it. This means the good, the bad and the idiots who think they
have found undocumented features and start using it. And here comes
the bad part, they start complaining when you fixed a bug and there
application stops working. So they stick with the old version, because
that one works. This is one to remember, because most software
currently arround already depends on code that goes back say 10 or 20
years. Imagion people using your code and the results when it seems
your code contains some serious flaws. And I'm not trying to scare
you, but it happens everyday and you should be aware of it.

> Also if the hacker strips the HTTP request from the client 
> (www.yahoo.co.uk) and instead sends it to my webserver, it'll return an 
> error code as it doesn't proxy - again where's the security risk?

This is a good question and do you remember what I said about making
sure your code can handle any situation? And I think you're starting
to see the point.

> Sorry if I'm way off, I'll happily work with anyone who wants to offer 
> their support to make NLG "more secure" - but I still maintain the only 
> additional check necessary is that "fid" and "gid" (GET variables) are 
> integers - if they're not, reset them both to 0 (or throw an error if 
> filter/group 0 don't exist.)  This will be implemented in 1.0.0.

To be honest you have a couple of few good points here. And I would
say may sure 1.0.0 works correct and skip the robustness to a later
version. I think that you have enough work on your hands to make sure
the application works correct and that you can rewrite some parts
afterwards to give the application more reliable and robust.

And on your question about support for making NLG more secure, I think
you see that its not really about fancy words or manpower. Its more of
thinking of what you need and its bounderies, but also building the
mousetrap. It gives others less room to poke in your application by
feeding it wicked data.

I must btw say that this is no garantee that your application can't be
abused, because sometimes there are design flaws or just logical
issues. But hopefully you then will laugh about those issues and see
them as challanges.

> In actual fact the poller already does this: (in "server/s3_poller.php", 
> line 63 - settype($FilterToApply, "integer") and also line 73.)
> Therefore if the variable is non-integer, it will be forced to 0.  The 
> only one thing to do is check that the filter/group exists, and perform 
> the same check on the client-side.

As a last statement, don't see this as a personal attack. It isn't and
love to see your response and your progress.

Cheers,

Hans

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null