check_by_ssh question

[Andreas Ericsson]

Paul L. Allen wrote:
> Andreas Ericsson writes:
> 
>> Questions about that?
> 
> OK, so somebody who can get shell as the nagios user on the monitoring
> machine can bypass things and hijack the Nagios user on monitored
> machines.  It is a vulnerability, but only if somebody can get shell
> as nagios on the monitoring machine.
Yes, and they can later elevate their privileges. Most linux users run 
one of the major distributions (like Red Hat). I still haven't seen a 
default Red Hat install without a local root exploit (usable by 'nobody').

> If nagios on the monitoring
> machine has no password the only way somebody could get shell as nagios
> is if they're already root.  
Wrong. There are also remote exploits. If you were to follow bugtraq or 
vuln-dev you wouldn't have that false sense of security.

>In which case you probably have a lot
> more to worry about than them being able to execute arbitrary commands
> *as nagios* on the monitored machines. 
You seem to think that allowing an attacker in as any other user than 
root is half OK. I don't really understand where you came up with the 
idea that there are no local privilege escalation problems, but I'd 
never hire you to run a network I was depending on.

> Unless you've done something silly,
> (like make a plugin setuid instead of using sudo or left your machine
> wide open to unprivileged users) then there's not that much damage
> somebody could do as nagios anyway. 
If you have plugins running as root (either sudo or +s), you're trying 
too hard. If you have kernel patches in place to disallow access to 
regular users to certain items, it's NOT recommended to bypass these 
with sudo and +s.

> The worst they can do is either
> fake check results or trash your nagios installation.  Well, they could
> grab /etc/passwd, but surely everyone is using shadow passwords these
> days.
Or, they could hack root using a local exploit on any of the machines in 
the network. Please don't tell me you're immune, or that you have really 
good security. That would be a lie and we both know it. Shadow passwords 
are better than 'regular' unix passwords, but nowhere near good enough. 
With shadow passwords there are a bunch of setsuid programs on the 
machine, some of which may allow local privilege escalation.

> 
>> Hmm... I think I'll start working on ssh style encryption (dsa) for 
>> nrpe, with public / private key handshake and so on. Seems a bit 
>> easier than all this hassle.
> 
> 
> The configuration for NRPE is, in my opinion, a pain in the anatomy.  Add
> to that the lack of security other than tcpwrappers (which I can't make
> use of because my boss insists on being able to monitor from his home
> cable line which gets a new IP every so often) and it's even less
> desirable.
Is he running Nagios at home? Monitoring your business network?
Now I understand where your security thinking gets warped.

> The disadvantage of NCSA is that if you have many different firewalls
> installed at clients sites and you're monitoring the clients' networks
> then they all share the same password so theoretically a malicious
> person at one client who could get root access on the firewall could
> screw up other clients' results (anyone with a rescue disk or distribution
> CD can gain root if they have physical access). 
No shit, sherlock. They can also use the init=/bin/sh boot option to 
lilo without ever touching disks of any kind.
Also, any admin on customer-network1 could submit passive check results 
for customer-network2.

> I can't think of a reason
> why anyone would want to do this, but they could. 
I can't think of a reason for people to send spam, or run DoS attacks on 
home users, but they do anyway.

> You can get around it
> by running many copies of the NCSA daemon each with a different config
> file, a different password and listening on a different port.
There you have it.

> But if you really felt an urge to start hacking around, I'd like to
> see NCSA take an optional username and the daemon take a list of
> username/password pairs. 
Rather an IP/password pair, for obvious reasons.

> Then each client could have a different username
> and password and the only (slight, improbable) security hole in NCSA
> would be plugged without having to run multiple daemons.
Unless we start thinking about buffer overflows, integer overflows, 
off-by-one bugs and other 'useful' (if you're looking to hack it) stuff, 
but I suppose you've browsed the source for it and decided there are no 
such faults in it.


-- 
Sourcerer / Andreas Ericsson
OP5 AB
+46 (0)733 709032
andreas.ericsson at op5.se


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
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