hi all..

[Evan Klitzke]

On Sat, 2007-02-03 at 01:51 -0800, Michael A. Peters wrote:
> 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.

Of course it's easy to detect. The question is whether or not you would
actually detect it in time.

> 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 at atlantis ~]$ ssh -l texlive jerusalem
> texlive at jerusalem's password: 
> Last login: Thu Feb  1 23:01:29 2007 from 192.168.15.100
> [texlive at 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?

evan at green ~ $ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-xZvwEx3082/agent.3082; export SSH_AUTH_SOCK;
SSH_AGENT_PID=3083; export SSH_AGENT_PID;
echo Agent pid 3083;
evan at green ~ $ ls -l /tmp/ssh-xZvwEx3082/agent.3082
srw------- 1 evan evan 0 Feb  3 16:47 /tmp/ssh-xZvwEx3082/agent.3082

If you somehow had access to my account right now, you could connect to
this socket, and use any keys that ssh-agent was storing, even if they
were password protected (this is why using ssh-agent on a computer you
don't 100% trust is a Bad Thing).

> 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.

You are mostly correct. You can't set up a very good key logger without
getting into the kernel, which of course requires that you are root. But
in practice if you just put an exec statement at the end of someone's
~/.bashrc that ran a program to log keystrokes, it would probably work.

> > 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*

You know as well as I do that this was a bug and has been addressed.

> 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.

No, it doesn't. Ssh-agent only asks for your passwords once. After that,
any processes with the same UID as your account (or the root account)
can connect to the socket and use the keys that you've added to the
agent, password protected or not.

> >  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).

Brute force attacks against ssh don't really work in practice. You'd
have to have a really awful password (e.g. the same as your username)
for this to actually work. I've never seen a log entry from someone
trying the same username with more than two or three password attempts.
But since SSH doesn't run on Fedora by default (and the firewall closes
access to that port), it's kind of a moot point.

> 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.

This is correct, but passwd won't let you choose a password weak enough
to be easily brute forced without chastising you, so I wouldn't worry
about it.

> 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.

I see what you're saying here, it's just that I'm not convinced that it
is a big enough issue to worry about, especially in comparison to all of
the other security incidents waiting to happen. If someone some how gets
your password and they have physical access to your account or you have
sshd running with password authentication, sure, you are 100% screwed.
Your box will be rooted and there is nothing you can do about it. And
maybe in that scenario having a root password would help. But I just
don't see it happening in real life, and I don't think it's something to
lose sleep over.

> > 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.

Isn't this the same with su? Would you let someone su if they weren't in
the wheel group? Now _that_ is a security incident waiting to happen.

> 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.

Ok, I did not realize this. On my account I am in the wheel group, but I
could see myself stupidly adding myself to that group when something
wasn't working. I think that this is a bad security model. How does
Fedora determine who can run su?

> 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.

You can do it in pretty much any scripting language (including bash,
although I don't know how you would make keyboard input not echo to the
shell), or in C of course. If there was a protection against this I
would be very interested to hear what it is.

> >  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.

Yes, I think that I just disagree with you wrt the idea that someone
would actually be able to get your password and exploit this.
> 
> >  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.

Well I guess we just disagree. I think that if you are worried about the
security implications of sudo you are insane and don't understand the
actual security vectors that a sysadmin should be worrying about.

> 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
> > 
>