Re: r command security
From: Colin McKinnon (colin.thisisnotmysurname_at_ntlworld.deletemeunlessURaBot.com)
Date: 11/23/03
- Previous message: Dimitri Maziuk: "Re: r command security"
- In reply to: Sherman H.: "r command security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 23 Nov 2003 22:10:02 +0000
Sherman H. spilled the following:
> My write-up was to clean up trust relationships in the rhost.equiv file
> and
> stop using of r commands. Instead, I recommended using ssh. However, the
> system administrators didn't buy into this because they have to use these
> features to work on different AIX machines and request me to further
> justify.
>
Here here.
> Their questions were:
> 1. If the boundary (firewall, ports) is secure, is this still a security
> exposure?
It depends what you mean by secure. You can't prove it's secure - just that
it implements the policy and is patched up to date. As a systems
administrator I must admit to postponing security fixes in apparently
non-critical areas. I've now seen several instances where an attacker has
used a combination of apprently trivial weaknesses to make a big security
hole. (e.g. the recent Linux ptrace bug which allowed a malicious user to
get root access might seem trivial on a machine which acts say as a
webserver and is only ever logged into by root for mounting disks with
updates). If postponing fixes because they are perceived as low-risk is a
bad idea, where does that leave designing systems around insecure
protocols?
> 2. Can a non-root user use the r commands with a trust relationship to
> access other machines and gain root privileges? Since root is only
> assigned to very few admins, would this be a problem?
Yes. If you only validate on the basis of the IP address and that what the
machine at the other end states is the uid is accepted. E.g. system X goes
down by default or by design, user gets root on another system connected to
the network assigns the IP address of system X to their box, now even if
root is not allowed access via rsh, they can connect as any user they want.
Let's not assume that the users are that smart though - what if you want
different admins to manage different machines - even without assuming the
identity of a downed box, they could access accounts that they should not
be able to see.
I could go on more but what's the point. YOU KNOW ITS A BAD IDEA.
> 3. What would be the exposures if allowing root or program ids to access
> other machines without entering a password? If a trust relationship is
> approved, what would be the issue?
'trust relationship approved'? Do you mean that the systems administrator
said it was OK? You must ENFORCE the trust relationship. If I were in your
shoes, I would be tempted to ask exactly what the trust relationships are,
how often they are audited and what the results of the audit were.
> 4. They did not know how to use ssh to replace r commands.
>
Ah, the ignorance defence. And because they couldn't understand the problem,
someone attacking the network couldn't either. I'll admit that it took me a
couple of gos to understand ssh, particularly using key pairs - I think a
bit of a risk / benefit analysis is needed here; on the one hand you could
take a week out to read a book, experiment a little or you could have all
your business data handed to your competitor and deleted from your own
systems. Hmmmm.
Of course you don't need to do away with the rhosts stuff to make the
network secure, (e.g. tunnel it through a VPN which uses passphrases on SSL
certificates for endpoint authentication) but you need to do a lot of work
to ensure that nobody can open a backdoor into the network.
HTH
C.
- Previous message: Dimitri Maziuk: "Re: r command security"
- In reply to: Sherman H.: "r command security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
