On Monday 14 January 2008 11:16:10 am Eric Rannaud wrote:
On Jan 10, 2008 10:26 PM, Ville Skyttä <ville.skytta(a)iki.fi>
wrote:
> On Saturday 05 January 2008, Kevin Fenzi wrote:
> > I find root ssh login handy for a number of reasons:
>
> [...]
>
> > - It's nice to be able to do for automated tasks (like say installing a
> > single new package on 20 machines without having to login and sudo on
> > each).
>
> "ssh -t $host sudo yum install $package" works for me...
What about (supposing I know the password of non-root user 'foo', and
assuming that 'foo' can sudo yum):
[hacker@tooeasy]$ rpm -q --scripts hacker_pkg.rpm
postinstall scriptlet (using /bin/sh):
rm -rf /
exit 0
[hacker@tooeasy]$ scp -p hackers_pkg.rpm foo@host:
[hacker@tooeasy]$ ssh -t foo@host sudo yum localinstall --nogpgcheck
./hackers_pkg.rpm
Am I wrong in assuming that yum is not necessarily a safe command to
be used with sudo? Or more exactly, that there is no point in blocking
root ssh logins if you're going to let a user that can login remotely
use sudo on yum?
Thanks.
Scary. At first glance it looks like a successful attack. But that wouldn't
really be unusual.
If your authentication model is based upon passwords, and passwords escape,
security is largely out the window. Using a wheel group, etc., can make
things tougher, but once you have a bad guy on the system, escalation of
privilege attacks are a probability, not a possibility. And they're usually
an order of magnitude (at least) easier. Authorization seldom gets the
attention that authentication does.
That's one reason (but not the major one) that I was asking about whether
anyone was thinking about mounting /home noexec. It at least adds an extra
authorization layer (though you still have to pay attention to authorization,
to prevent attacks in the same vein as the one you've described), in making
it harder to do things such as launching a dead-simple (`$0 & $0 &`) forkbomb
attack at a critical moment (which can be devastating, depending upon how you
have /etc/security/limits.conf set up).
The up side is that everyone should be on shadowed passwords, and random bad
guys with a user account can't run cracking software against /etc/passwd. The
downside is that if you have an undetected bad guy on the system, you will
probably lose, in the end. If your attack fails, another will be found. If
it's an order of magnitude easier for the bad guy, it's an order of magnitude
worse for the admin. If you were 100% confident (hubris) of protecting the
sytem before, you should now be 10% confident.
Assuming you're going to allow multiple users:
If you're going to base everything around passwords, at least read man(1)
chage, beware of shoulder-surfing, etc. If you're doing keys, protect your
~/.ssh. If you're doing two-factor, check out your vendor--some fingerprint
scanners have been trivially defeated in the past, etc.
If thou should lose the Mighty Authentication Battle, thou whilst surely find
thyself Groveling Amongst Backups.
--
Fedora-security-list mailing list
Fedora-security-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-security-list