On Sat, 2007-02-03 at 17:20 -0800, Evan Klitzke wrote: > 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. And with sudo, I certainly wouldn't because they already have root. Anything that would work on a system without sudo loosely configured would work on a system with sudo loosely configured. The loose configuration of sudo simply adds a very easy way to get root w/o doing anything that triggers suspicion. That's the whole point. su --command="foo" works very nicely if you just want to run one thing. su - works very nicely if you want to run several things. The ubuntu configuration of sudo is not necessary, it only serves to add a very easy path to root for those who don't belong there. > > > 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? > > evan@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@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 have never used ssh-agent for anything. > > > 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. Got a demo of one that catches password fed to su? > > > > 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. But it shows how dangerous sudo is. The password wasn't even a root password, but because of sudo, it might as well have been. > > > 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. I don't use ssh agent. I enter my pass phrase every time I connect. That was on the advice of my father - guess that's why. Another piece of software used for convenience that sacrifices real world security. > > > > 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. They do work in practice because a lot of people have really bad passwords. They don't work against me, but they do work. Interesting story that happened to a coworker - he thought he had a secure password. jtr couldn't crack it, at least not in a reasonable amount of time. His account was brute force attacked. How? It turns out his password was a variation of a russian word, completely unknown to him, and the cracker was using a russian dictionary running permutations with numbers mixed in (might have been a russian toolkit that got onto a US machine - the attack came from the US). > 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. Actually - by default the ssh daemon does start on Fedora and the default firewall allows it. The reason is the same reason why they permit root ssh login - headless installs via kickstart. The admin has to have a way to get in post install before a user account has been created. I think there could be a better way though, such as a kickstart setting that specifically enables it for those rare cases. > > > 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. Sure it will. I just tried l1i2n3u4x5 Look at the non number digits and the easy order of the numbers. People do stuff like that all the freaking time. > > > 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. It's completely un-necessary though. Here's another scenario that DOES happen a lot. The big student servers at Universities frequently get cracked. The reason is because of hardware keystroke loggers at computer labs, insecure boxes at the labs that have sniffers installed on them, and the fact that they have to allow telnet for that grad student doing research in Iran because he would be arrested for using encryption. So the shadow file gets grabbed from time to time. Cracker runs that shadow file through a passwd cracker (like jtr) and gets some of the matches with user names and passwords. Now he has something to use in a brute force attack against other machines on the uni network - as many students will not have separate passwords for each machine, but often use the same password for the ubuntu box in their dorm room that they used for on Slowaris box they are doing their big assignment on. So the cracker does a brute force attack on various machines using the username/passwd pairs he has managed to crack from the stolen shadow file, thus increasing the odds that he gets a hit on other systems on the network. > > 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. Sure. BSD su only allows su to root from the wheel group, and I like that better than GNU su. But a user needs to be able to su to other user accounts that are not root. You don't want to have to add a user to the wheel group for them to su to another user - su should be world executable. But I do like the bsd su that only allows su to root from a member of the wheel group. I think Solaris su is the same but I'm not sure. > > > 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? It is world executable as it should be (IE so that I can run su - joe to become joe. > > 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. I believe the su command does not work from a fake tty like what expect opens with the spawn command. I'm not positive that is the case with gnu su. > > 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. There are many ways to get a password - especially since it is common for uni users to have the same password on multiple machines. > > 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. I don't dispute that I'm insane :) As far as not understanding the "actual security vectors" that a sysadmin should be worried about, not using sudo w/ insecure defaults does not prevent me from worrying about them. I can worry about several things at once. I just think the small convenience of sudo isn't worth it. Not unless it is properly configured such that only specified commands (that can't spawn a shell) can be used.
