Re: hi all..

On Sat, 2007-02-03 at 01:09 -0800, Evan Klitzke wrote:


I strongly disagree with you on this. In real life, if you are an admin
and someone gets access your shell account, you're screwed. I am _not_
talking about exploits here. For example, if I somehow got hold of your
password and could get a shell on your system, I could just put my own
"su" on your computer and change your path.

The su command is a suid binary. Only root can install an su binary.
While you could create something with a similar name and modify
my .bashrc file to put it in my path, that would be fairly easily
detectable.

Until you get root on my box, you can't poke holes in my firewall to
open up ports to listen on. You can't alter my binaries and modify my
rpm database. When I log into my system, I will get a notice stating
where my last login was from - and as far as I know, you can't hide that
without being root. For example:

[admin@atlantis ~]$ ssh -l texlive jerusalem
texlive@jerusalem's password:
Last login: Thu Feb 1 23:01:29 2007 from 192.168.15.100
[texlive@jerusalem ~]$

Or change your shell to log
your keystrokes. Or use the keys in your ssh-agent. Or do any number of
nasty things. None of them are guaranteed to work, but if you don't know
your account has been compromised the odds are very good for the
attacker.

How are you going to use the keys in my ssh-agent?
I'm not stupid enough to not require a gpg pashphrase authentication, so
you would need to get my gpg pass phrase. btw, I'm not sure you can
install an effective key logger without root. Of course, if I have sudo
set up such that "sudo sh" only requires my user password, then you
could easily install a keystroke logger.


Furthermore, it is definitely not reasonable to assume that because
someone can get a shell with your account they have your password.

Of course it is not. It is also not reasonable to assume thay your
password isn't installed in a world readable text file
*cough*ubuntu*cough* or that users are smart enough to never use ftp to
upload files to their home computer from the Starbucks with free wifi.

For
example, say you attach to an ssh-agent on some other machine. The root
user of that machine can attach to the ssh-socket and authenticate with
your keys, and get a shell on your machine. Does this mean they have
your password? Of course not.

It does mean they have my pass phrase.

What if some vulnerability comes out that
lets them trick PAM? They still don't have your password. Here's an even
better case: what if you download some malicious software? That software
can spawn a shell and execute shellcode, but it doesn't have your
password. If someone can get into your account _and_ has your password,
you've been seriously compromised and if you are really concerned about
the security of your system you should just reinstall.

Sure - there are lots of ways for them to get on a system w/o having the
users password. But there also is something called a brute force attack.
Maybe you've seen it in your logs. Someone with a cable modem has their
box compromised. The system cracker then uses that box to try brute
force attacks on various systems - picking common users and password
(btw - this is why I think it is wrong for Fedora to allow root ssh
login by default, it is a known user account name).

If they succeed and your box has insecure sudo, now they can have their
shell root your box, poke holes in your firewall, install a root kit,
and start attacking other peoples box from yours - all without the
cracker needing to install a fake su and modify my path and wait for me
to fall victim.

Do you see how the default sudo in OS X and Ubuntu and other distros is
a worm just waiting to happen?


The default user on Ubuntu can sudo. Other newly created users can't.

Most people installing Ubuntu are installing it to be a single user
machine. They use the default user. Same with OS X.

Same with Fedora. The first user enters the root password. Other users
don't know it. The only difference is that to let another user access
root you would either need to set up sudo, or give them the root
password anyway. There isn't a huge difference.

Sure there is. If the shell script mentioned manages to get the default
users password, the shell script has now rooted the box.

While a failed use of sudo would alert the sysadmin that someone tried
to use it, it isn't very hard to use the "groups" command first and only
root the box with sudo if the user is in the wheel group.

While Fedora does provide a wheel group, no users are put there by
default - and even if you add users to the wheel group, they only have
extra permission if the system administrator specifically allows it.

There are three types of accounts -

root
system (daemons etc)
users (UID 500 and above)

There are not users that are more or privileged than others unless you
set it up that way, which is vastly different than the insecure
ubuntu/OS X model.



No, most people will not change how sudo operates. But that's ok,
because it isn't a security issue.

Yes it is - I just explained how. A shell script running brute force
attacks against open ports will be able to root the box if it is
succesful. With Fedora, it will only be able to root the box if it
specifically was able to brute force the root account or there is a
known local exploit that has not been patched. Any other rooting
requires social engineering (such as waiting for me to stupidly use an
su command that is not /bin/su). btw - given that you can not install a
suid root application w/o already being root, that makes it a little
harder to trick me into using a fake su w/o alerting me that something
is amiss. I suppose you could do it with tcl via expect and *maybe* give
me no visual indication that you I am not running the real su. I believe
though there are protections against that.

If I looked in /var/log/auth and
realized that someone was logging onto my regular user account remotely,
I wouldn't say "Good thing I have a root password!" I'd realize that an
administrator account had been compromised, and I'd treat it the same
way I would if I was using Ubuntu or OS X and reinstall.

But if they have access to sudo, your /var/log/auth file will lie to
you.

The point of
installing sudo by default isn't to make the system more secure, it's to
make it more convenient.

Makes it more convenient at the cost of security.
sudo should NEVER be used to run a program that can spawn a shell.
Period.

If you really feel that the minimal amount of
extra protection you get from having a root password in addition to your
regular user password makes a big difference, your computer wasn't
secure enough to start out with.

I'm sorry, but I think you are clueless.
For what its worth - my dad just retired a few years ago, but UNIX
security was his job. I'm not my dad, nor am I as nearly knowkedgeable
on the topic of security as he is, but I do talk with him about this
sort of thing and I certainly know about the dangers of sudo.


-- Evan Klitzke


--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Relevant Pages

  • Re: hi all..
    ... And with sudo, I certainly wouldn't because they already have root. ... If you somehow had access to my account right now, ... install an effective key logger without root. ...
    (Fedora)
  • Re: Easy way/script to add another user like me?
    ... do to give a user sudo privileges is to add them to the admin group. ... I used my root account to add joker to the "admin group" via ...
    (Ubuntu)
  • Re: Choosing a distribution
    ... potentially be cracked and hence give the intruder root access. ... However, with sudo you can ... and with a root account you use a different password that now needs ... You're claiming "increased" security by use of a root ...
    (Ubuntu)
  • Re: hi all..
    ... compromise security to achieve it - such as very insecure sudo defaults ... that essentially make any admin group user password a root password. ... IE someone gets your user account password, they can do more than just ...
    (Fedora)
  • Re: Sudo question
    ... even with Rsh ... Subject: Sudo question ... allow sudo to call a restricted shell. ... this command full root access. ...
    (AIX-L)
Loading