Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.20.0245 +0100]: If the use of switch user has remote security implications I want to be able to understand them. The same as I want to be able to understand if leaving a root console open has remote security implications. Don't worry about local physical access. I want everyone to assume this is impossible. You have to assume this is impossible to not get sidetracked. the point is that you can't assume that. i hold network security seminars on a regular basis, and i research the facts every single time as well as possible, just to deliver the most accurate info to my students. excuse me if i can't provide you with a source (it was CERT), but my notes from the seminar that i was to hold today (it was canceled) state that 76% of all attacks are internal, and that around 40% of those are physical attacks, the remaining 60% are network attacks. okay, we are getting sidetracked, but local physical access is never impossible. and it's all too often a factor that is ignored. nevertheless, leave a root console open on a production machine really just calls for trouble. imagine you are about to head for lunch with a friend, but you decide to check something in the server room quickly. while you stare at your Annex ports or your Cisco switch, your friend idles around and notices the root console. had there not been a root console, he would have never thought of doing what he now does, but since the prompt # is so inviting, he takes all of 20 seconds to install a backdoor in the system, binding a shell to a high port, installing his RSA identity.pub in /root/.ssh, scp'ing/email'ing /etc/shadow to himself etc. no. he'd have to steal your actual tty session, and if all you are doing is surfing the web, then he can't really do that. however, which browser are you using? are you running X? why not use tty2-tty6 for a separate user login? Please don't worry about what else I could do. That's all sensible (unnecessary) advice. I want to understand this from a theoretical viewpoint. It gives me a very weird feeling in my intestines as well using su - to switch to a user account and I want to understand why. if you use the console only, and lynx or w3m to browse the web, you might be fine. if you start X as root, and run the browser as root, or if you somehow start X in general, security issues pop up everywhere. there's a reason why a server's a server and a workstation's a workstation. no, i can't give you a precise recipe or a definite this-is-how-it-is answer, simply because this is what security is all about: there is no right or wrong, there are simply gut feelings, and the good security administrators have sensible guts. it's really what makes security interesting and what keeps you young :) Can anyone provide a plausible scenario for how someone might be able to gain root level access because su - has been used to switch to a user account. Martin has already answered that your tty session would have to be stolen. How can you steal a tty session using only remote means? you'd have to be more specific as to what you are doing locally. X or not X? well, i guess that you're expecting a potential attacker not to know this. the only thing i can think of are escape sequences through /dev/tty, which cause the local shell to be trashed and possibly made to execute commands. whether you can harvest a privilege escalation from that, well, i am sure you can. i don't have a recipe off-hand. i just read ahead in the thread to see that someone else posted this already. woops. i think that you have a conceptual problem with what a server and a workstation are, and their differences, and what a superuser account is to be used for. in all but the rarest cases do production servers even have local accounts, and if, then usually without shell access. yes, i know that there are companies and institutions that provide shell access, but they usually have dedicated servers for that. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck when I was a boy I was told that anybody could become president. now i'm
Re: su - user question
On Mon, 2002-01-21 at 23:40, martin f krafft wrote: snip nevertheless, leave a root console open on a production machine really just calls for trouble. imagine you are about to head for lunch with a friend, but you decide to check something in the server room quickly. while you stare at your Annex ports or your Cisco switch, your friend idles around and notices the root console. had there not been a root console, he would have never thought of doing what he now does, but since the prompt # is so inviting, he takes all of 20 seconds to install a backdoor in the system, binding a shell to a high port, installing his RSA identity.pub in /root/.ssh, scp'ing/email'ing /etc/shadow to himself etc. Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. snipped useful discussion of an exploit i think that you have a conceptual problem with what a server and a workstation are, and their differences, and what a superuser account is to be used for. in all but the rarest cases do production servers even have local accounts, and if, then usually without shell access. yes, i know that there are companies and institutions that provide shell access, but they usually have dedicated servers for that. Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: Here's a scenario where using su - could be less risky than always logging in as a user: First assume there is a local root vulnerability in the operating systems of two computers that can be accessed once a user level account has been obtained. Second, assume that the root passwords of both systems are very strong. Third, assume that the systems are logged into locally by a user/administrator. However they are connected to the Internet and are providing Internet services (it's not the best security practice to allow remote logins when they are not necessary but it's still a plausible scenario). In the first system the administrator sets up a user account with an easy to remember password. Over time a cracker is able to guess this password and obtain local user and then root access to the computer. In the second system the administrator sets up a user account with a randomly generated dual case alphanumeric password. The administrator has to write this password down to remember it. Consulting the document is a hassle so he/she decides to use su - to log in as the user instead. The remote cracker is never able to guess the user password and obtain user (then root) access to the system. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. Or to put it another way in some circumstances it may be superior for an administrator/user to only have to remember one long password than trying to remember two potentially less effective passwords. The user password can be even _unknown_ to the user. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. okay. but your server has a permanent internet connection, and though you might not have mission-critical and confidential data, it is a prime target for hackers because of distributed denial of service attacks. so it needs to be secured, and you are on track. what's your server serving? i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. good. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck it is the mark of an educated mind to be able to entertain a thought without accepting it. -- aristoteles msg05441/pgp0.pgp Description: PGP signature
Re: su - user question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Jan 20, 2002 at 11:04:13AM +1300, Adam Warner wrote: Hi everyone, ... The question I have is if I su - username and then browse the web, etc. is it impossible for a remote user who managed to gain access to that user session to become root by exiting out of the user account? Is there a reason to leave the parent shell around? How about, instead of su - - username exec su - username. If you are simply running a console as root that should remove any way of getting back to root from username. If you are running X as root, then you have bigger problems. donfede -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8TGDjSeRbV/op2s4RAooKAJ9WWW9snELp6NL+YgbfEbgk/100RgCdHzUd EPpCfFMyeB9L1ePRZk7mlq8= =J/aS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
On Tue, 2002-01-22 at 03:11, martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. An amazing story. Did you ever find out why the intruder did that? What data he/she was after? Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. okay. but your server has a permanent internet connection, and though you might not have mission-critical and confidential data, it is a prime target for hackers because of distributed denial of service attacks. so it needs to be secured, and you are on track. what's your server serving? It is secured in a respectible manner. Ports 53 (bind9 DNS), 80 (Apache/Zope), 113 (no server just a connection refused) and 119 (local news server) are accessible to the world. Non-LAN logins are blocked. I also enable ICMP echo-requests because I believe it is a responsible service to provide. I attempt to keep up to date with security releases. Yes I am on track. You could suggest that I chroot (jail) bind 9 and have a better log analysis policy. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. In other words it's not relevant to my situation. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. good. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? Because you will have to weigh up the costs and benefits in the scenario like any good security expert. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. So this is an admission that in my contrived scenario the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember.? You just rewrote the scenario because you didn't like the idea of someone using an easy to use password--even though this is a relatively common scenario. What you provided is a solution to overcoming the problem. Not a comment on which scenario was more secure. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
On Tue, 2002-01-22 at 07:41, Federico Grau wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Jan 20, 2002 at 11:04:13AM +1300, Adam Warner wrote: Hi everyone, ... The question I have is if I su - username and then browse the web, etc. is it impossible for a remote user who managed to gain access to that user session to become root by exiting out of the user account? Is there a reason to leave the parent shell around? How about, instead of su - - username exec su - username. If you are simply running a console as root that should remove any way of getting back to root from username. If you are running X as root, then you have bigger problems. Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. Woah, that does sound a little far-fetched. I am assuming there is a little more to this story? I would think most *physical* intruders would try to nab DVD players, valuables, and money, not wander into a spare room and whip out some UNIX skills to break into machines. Well, if I were a robber, I would certainly just take machines and not concern myself with having remote access to them. Hmm, likely most people that know about init=/bin/sh have enough money to not have to break into places. Hmm, maybe the recession has made life so bad that script kiddies can't afford ISPs any longer, and thus need to have physical access to machines to do their IRC takeovers... There has to be more there, like you offended someone you know and he wandered to your house or your some sort of spy that knows people that do that stuff ;) Just a little healthy skepticism... -A. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2304 +0100]: as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. An amazing story. Did you ever find out why the intruder did that? What data he/she was after? no. he claims that all he wanted was root access to the box for a dDoS (it was on a 2mbps line). i think he was after money, but then turned into an opportunist as he couldn't find any. when will people finally realize that i am poor :) It is secured in a respectible manner. Ports 53 (bind9 DNS), 80 (Apache/Zope), 113 (no server just a connection refused) and 119 (local news server) are accessible to the world. Non-LAN logins are blocked. if your news server is non-root and chrooted as well as bind, and your apache does not use suexec and runs as www-data (and is reasonably new), then you should have little to fear. then we could settle this discussion as i think we can endlessly toss the turns. there is no right and wrong in security, only gut feelings (gosh, i am repeating myself, and it isn't even that good of a quote...) I also enable ICMP echo-requests because I believe it is a responsible service to provide. why? I attempt to keep up to date with security releases. you also run Debian. that's a good start ;) Yes I am on track. You could suggest that I chroot (jail) bind 9 and have a better log analysis policy. you *should*, especially because with a 2.4 kernel, you can do so in 10 commands. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. In other words it's not relevant to my situation. okay, fine. you win. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? Because you will have to weigh up the costs and benefits in the scenario like any good security expert. i never said i am good. nevertheless, read on below. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. So this is an admission that in my contrived scenario the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember.? there is nothing to be said against keeping a hint to the password written down somewhere. for instance, i once had to remember the weekly changing security code of a lab, which was four digits. i am *really* good with numbers, but not if they change every week, and so i simply carried a piece of paper around with me with a matrix. say the number was 4723, my paper would look like this: 2830 6121 2979 0045 and all i had to remember was: third column, upside down. granted, even that could be considered insecure, but you always have to trade off security vs. necessity, as you stated. you can apply the same to root passwords. as long as you don't write on the paper: root's password to mymachine.mydomain.net [124.45.26.117] (hidden telnet at port 31776), and possibly encrypt the passsword in a very custom and non-algorithmic way as i did above, you'd be safe. oh, and as long as you don't pull it out in front of the machine and type it off. go to the bathroom or something, and remember it for the 60 seconds it takes you to get back and onto a shell prompt. see, my thing with security is that i am actually well aware of security flaws and considerations, but i don't employ 100% secure means for everything. simply because it's overkill. i don't keep my passwords on a post-it on the screen, i do use SecurID or S/Key whenever possible, but i have had other security people or paranoid admins scream at me. usability and security are mutually exclusive, but you can find a way to combine both with respect to what the environment needs, and i am really good at that actually. and the last time i entered a root password anywhere was like 3 months ago, thanks to properly configured sudo installations. You just rewrote the scenario because you didn't like the idea
Re: su - user question
also sprach Dave Kline [EMAIL PROTECTED] [2002.01.21.2340 +0100]: Woah, that does sound a little far-fetched. I am assuming there is a little more to this story? I would think most *physical* intruders would try to nab DVD players, valuables, and money, not wander into a spare room and whip out some UNIX skills to break into machines. Well, if I were a robber, I would certainly just take machines and not concern myself with having remote access to them. Hmm, likely most people that know about init=/bin/sh have enough money to not have to break into places. i don't have a DVD player, i have no valuables, and definitely no money. all my machines are physically locked down though. and no, there wasn't more to the story. There has to be more there, like you offended someone you know and he wandered to your house or your some sort of spy that knows people that do that stuff ;) Just a little healthy skepticism... maybe it's just me, but i have the weirdest shit happening to me. skepticism accepted, i don't have anything more to say though. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck 1-800-psych hello, welcome to the psychiatric hotline. if you are obsessive-compulsive, please press 1 repeatedly. msg05465/pgp0.pgp Description: PGP signature
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2307 +0100]: Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. no, he actually says that with exec, you should theoretically be more secure as in a root-su-user scenario, because after you exec, the root shell is gone. it's an interesting proposal and when i have time, i would like to look at the user status after su vs. a normal login to see if there's *any* difference. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck i'd rather be riding a high speed tractor with a beer on my lap, and a six pack of girls next to me. msg05467/pgp0.pgp Description: PGP signature
Re: su - user question
On Tue, 2002-01-22 at 12:21, martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2307 +0100]: Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. no, he actually says that with exec, you should theoretically be more secure as in a root-su-user scenario, because after you exec, the root shell is gone. it's an interesting proposal and when i have time, i would like to look at the user status after su vs. a normal login to see if there's *any* difference. That would be an interesting analysis. I enjoyed your long email discussion and understood it, thanks. I set out to find out if su - username was a large security risk in the circumstances I outlined and it appears it is not. And with Federico's proposal of using exec (which you helped me understand) it may even be identically secure. Please CC me your analysis if you find time so there's no chance I miss it. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.20.0245 +0100]: If the use of switch user has remote security implications I want to be able to understand them. The same as I want to be able to understand if leaving a root console open has remote security implications. Don't worry about local physical access. I want everyone to assume this is impossible. You have to assume this is impossible to not get sidetracked. the point is that you can't assume that. i hold network security seminars on a regular basis, and i research the facts every single time as well as possible, just to deliver the most accurate info to my students. excuse me if i can't provide you with a source (it was CERT), but my notes from the seminar that i was to hold today (it was canceled) state that 76% of all attacks are internal, and that around 40% of those are physical attacks, the remaining 60% are network attacks. okay, we are getting sidetracked, but local physical access is never impossible. and it's all too often a factor that is ignored. nevertheless, leave a root console open on a production machine really just calls for trouble. imagine you are about to head for lunch with a friend, but you decide to check something in the server room quickly. while you stare at your Annex ports or your Cisco switch, your friend idles around and notices the root console. had there not been a root console, he would have never thought of doing what he now does, but since the prompt # is so inviting, he takes all of 20 seconds to install a backdoor in the system, binding a shell to a high port, installing his RSA identity.pub in /root/.ssh, scp'ing/email'ing /etc/shadow to himself etc. no. he'd have to steal your actual tty session, and if all you are doing is surfing the web, then he can't really do that. however, which browser are you using? are you running X? why not use tty2-tty6 for a separate user login? Please don't worry about what else I could do. That's all sensible (unnecessary) advice. I want to understand this from a theoretical viewpoint. It gives me a very weird feeling in my intestines as well using su - to switch to a user account and I want to understand why. if you use the console only, and lynx or w3m to browse the web, you might be fine. if you start X as root, and run the browser as root, or if you somehow start X in general, security issues pop up everywhere. there's a reason why a server's a server and a workstation's a workstation. no, i can't give you a precise recipe or a definite this-is-how-it-is answer, simply because this is what security is all about: there is no right or wrong, there are simply gut feelings, and the good security administrators have sensible guts. it's really what makes security interesting and what keeps you young :) Can anyone provide a plausible scenario for how someone might be able to gain root level access because su - has been used to switch to a user account. Martin has already answered that your tty session would have to be stolen. How can you steal a tty session using only remote means? you'd have to be more specific as to what you are doing locally. X or not X? well, i guess that you're expecting a potential attacker not to know this. the only thing i can think of are escape sequences through /dev/tty, which cause the local shell to be trashed and possibly made to execute commands. whether you can harvest a privilege escalation from that, well, i am sure you can. i don't have a recipe off-hand. i just read ahead in the thread to see that someone else posted this already. woops. i think that you have a conceptual problem with what a server and a workstation are, and their differences, and what a superuser account is to be used for. in all but the rarest cases do production servers even have local accounts, and if, then usually without shell access. yes, i know that there are companies and institutions that provide shell access, but they usually have dedicated servers for that. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] when I was a boy I was told that anybody could become president. now i'm
Re: su - user question
On Mon, 2002-01-21 at 23:40, martin f krafft wrote: snip nevertheless, leave a root console open on a production machine really just calls for trouble. imagine you are about to head for lunch with a friend, but you decide to check something in the server room quickly. while you stare at your Annex ports or your Cisco switch, your friend idles around and notices the root console. had there not been a root console, he would have never thought of doing what he now does, but since the prompt # is so inviting, he takes all of 20 seconds to install a backdoor in the system, binding a shell to a high port, installing his RSA identity.pub in /root/.ssh, scp'ing/email'ing /etc/shadow to himself etc. Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. snipped useful discussion of an exploit i think that you have a conceptual problem with what a server and a workstation are, and their differences, and what a superuser account is to be used for. in all but the rarest cases do production servers even have local accounts, and if, then usually without shell access. yes, i know that there are companies and institutions that provide shell access, but they usually have dedicated servers for that. Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: Here's a scenario where using su - could be less risky than always logging in as a user: First assume there is a local root vulnerability in the operating systems of two computers that can be accessed once a user level account has been obtained. Second, assume that the root passwords of both systems are very strong. Third, assume that the systems are logged into locally by a user/administrator. However they are connected to the Internet and are providing Internet services (it's not the best security practice to allow remote logins when they are not necessary but it's still a plausible scenario). In the first system the administrator sets up a user account with an easy to remember password. Over time a cracker is able to guess this password and obtain local user and then root access to the computer. In the second system the administrator sets up a user account with a randomly generated dual case alphanumeric password. The administrator has to write this password down to remember it. Consulting the document is a hassle so he/she decides to use su - to log in as the user instead. The remote cracker is never able to guess the user password and obtain user (then root) access to the system. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. Or to put it another way in some circumstances it may be superior for an administrator/user to only have to remember one long password than trying to remember two potentially less effective passwords. The user password can be even _unknown_ to the user. Regards, Adam
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. okay. but your server has a permanent internet connection, and though you might not have mission-critical and confidential data, it is a prime target for hackers because of distributed denial of service attacks. so it needs to be secured, and you are on track. what's your server serving? i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. good. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] it is the mark of an educated mind to be able to entertain a thought without accepting it. -- aristoteles pgpyy1zWj35BE.pgp Description: PGP signature
Re: su - user question
On Tue, 2002-01-22 at 03:11, martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. An amazing story. Did you ever find out why the intruder did that? What data he/she was after? Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. okay. but your server has a permanent internet connection, and though you might not have mission-critical and confidential data, it is a prime target for hackers because of distributed denial of service attacks. so it needs to be secured, and you are on track. what's your server serving? It is secured in a respectible manner. Ports 53 (bind9 DNS), 80 (Apache/Zope), 113 (no server just a connection refused) and 119 (local news server) are accessible to the world. Non-LAN logins are blocked. I also enable ICMP echo-requests because I believe it is a responsible service to provide. I attempt to keep up to date with security releases. Yes I am on track. You could suggest that I chroot (jail) bind 9 and have a better log analysis policy. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. In other words it's not relevant to my situation. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. good. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? Because you will have to weigh up the costs and benefits in the scenario like any good security expert. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. So this is an admission that in my contrived scenario the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember.? You just rewrote the scenario because you didn't like the idea of someone using an easy to use password--even though this is a relatively common scenario. What you provided is a solution to overcoming the problem. Not a comment on which scenario was more secure. Regards, Adam
Re: su - user question
On Tue, 2002-01-22 at 07:41, Federico Grau wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Jan 20, 2002 at 11:04:13AM +1300, Adam Warner wrote: Hi everyone, ... The question I have is if I su - username and then browse the web, etc. is it impossible for a remote user who managed to gain access to that user session to become root by exiting out of the user account? Is there a reason to leave the parent shell around? How about, instead of su - - username exec su - username. If you are simply running a console as root that should remove any way of getting back to root from username. If you are running X as root, then you have bigger problems. Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. Regards, Adam
Re: su - user question
martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. Woah, that does sound a little far-fetched. I am assuming there is a little more to this story? I would think most *physical* intruders would try to nab DVD players, valuables, and money, not wander into a spare room and whip out some UNIX skills to break into machines. Well, if I were a robber, I would certainly just take machines and not concern myself with having remote access to them. Hmm, likely most people that know about init=/bin/sh have enough money to not have to break into places. Hmm, maybe the recession has made life so bad that script kiddies can't afford ISPs any longer, and thus need to have physical access to machines to do their IRC takeovers... There has to be more there, like you offended someone you know and he wandered to your house or your some sort of spy that knows people that do that stuff ;) Just a little healthy skepticism... -A. Dave
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2304 +0100]: as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. An amazing story. Did you ever find out why the intruder did that? What data he/she was after? no. he claims that all he wanted was root access to the box for a dDoS (it was on a 2mbps line). i think he was after money, but then turned into an opportunist as he couldn't find any. when will people finally realize that i am poor :) It is secured in a respectible manner. Ports 53 (bind9 DNS), 80 (Apache/Zope), 113 (no server just a connection refused) and 119 (local news server) are accessible to the world. Non-LAN logins are blocked. if your news server is non-root and chrooted as well as bind, and your apache does not use suexec and runs as www-data (and is reasonably new), then you should have little to fear. then we could settle this discussion as i think we can endlessly toss the turns. there is no right and wrong in security, only gut feelings (gosh, i am repeating myself, and it isn't even that good of a quote...) I also enable ICMP echo-requests because I believe it is a responsible service to provide. why? I attempt to keep up to date with security releases. you also run Debian. that's a good start ;) Yes I am on track. You could suggest that I chroot (jail) bind 9 and have a better log analysis policy. you *should*, especially because with a 2.4 kernel, you can do so in 10 commands. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. In other words it's not relevant to my situation. okay, fine. you win. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? Because you will have to weigh up the costs and benefits in the scenario like any good security expert. i never said i am good. nevertheless, read on below. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. So this is an admission that in my contrived scenario the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember.? there is nothing to be said against keeping a hint to the password written down somewhere. for instance, i once had to remember the weekly changing security code of a lab, which was four digits. i am *really* good with numbers, but not if they change every week, and so i simply carried a piece of paper around with me with a matrix. say the number was 4723, my paper would look like this: 2830 6121 2979 0045 and all i had to remember was: third column, upside down. granted, even that could be considered insecure, but you always have to trade off security vs. necessity, as you stated. you can apply the same to root passwords. as long as you don't write on the paper: root's password to mymachine.mydomain.net [124.45.26.117] (hidden telnet at port 31776), and possibly encrypt the passsword in a very custom and non-algorithmic way as i did above, you'd be safe. oh, and as long as you don't pull it out in front of the machine and type it off. go to the bathroom or something, and remember it for the 60 seconds it takes you to get back and onto a shell prompt. see, my thing with security is that i am actually well aware of security flaws and considerations, but i don't employ 100% secure means for everything. simply because it's overkill. i don't keep my passwords on a post-it on the screen, i do use SecurID or S/Key whenever possible, but i have had other security people or paranoid admins scream at me. usability and security are mutually exclusive, but you can find a way to combine both with respect to what the environment needs, and i am really good at that actually. and the last time i entered a root password anywhere was like 3 months ago, thanks to properly configured sudo installations. You just rewrote the scenario because you didn't like the idea
Re: su - user question
also sprach Dave Kline [EMAIL PROTECTED] [2002.01.21.2340 +0100]: Woah, that does sound a little far-fetched. I am assuming there is a little more to this story? I would think most *physical* intruders would try to nab DVD players, valuables, and money, not wander into a spare room and whip out some UNIX skills to break into machines. Well, if I were a robber, I would certainly just take machines and not concern myself with having remote access to them. Hmm, likely most people that know about init=/bin/sh have enough money to not have to break into places. i don't have a DVD player, i have no valuables, and definitely no money. all my machines are physically locked down though. and no, there wasn't more to the story. There has to be more there, like you offended someone you know and he wandered to your house or your some sort of spy that knows people that do that stuff ;) Just a little healthy skepticism... maybe it's just me, but i have the weirdest shit happening to me. skepticism accepted, i don't have anything more to say though. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] 1-800-psych hello, welcome to the psychiatric hotline. if you are obsessive-compulsive, please press 1 repeatedly. pgprvg8PsIhaE.pgp Description: PGP signature
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2307 +0100]: Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. no, he actually says that with exec, you should theoretically be more secure as in a root-su-user scenario, because after you exec, the root shell is gone. it's an interesting proposal and when i have time, i would like to look at the user status after su vs. a normal login to see if there's *any* difference. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] i'd rather be riding a high speed tractor with a beer on my lap, and a six pack of girls next to me. pgp495ydNQEbM.pgp Description: PGP signature
Re: su - user question
On Tue, 2002-01-22 at 12:21, martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2307 +0100]: Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. no, he actually says that with exec, you should theoretically be more secure as in a root-su-user scenario, because after you exec, the root shell is gone. it's an interesting proposal and when i have time, i would like to look at the user status after su vs. a normal login to see if there's *any* difference. That would be an interesting analysis. I enjoyed your long email discussion and understood it, thanks. I set out to find out if su - username was a large security risk in the circumstances I outlined and it appears it is not. And with Federico's proposal of using exec (which you helped me understand) it may even be identically secure. Please CC me your analysis if you find time so there's no chance I miss it. Regards, Adam
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.19.2304 +0100]: Firstly the servers are physically secure and there is no relevant issue about having a local root console open for administration purposes. mh. no comment. sure, if physical access would be available, no box is secure. but having a root login right there only means that an intruder wouldn't have to reboot the box (which is noticeable), he could just leave a backdoor in as little as 30 seconds. don't do it. The question I have is if I su - username and then browse the web, etc. is it impossible for a remote user who managed to gain access to that user session to become root by exiting out of the user account? I'm almost certain the answer should be no. But I'd just like confirmation. no. he'd have to steal your actual tty session, and if all you are doing is surfing the web, then he can't really do that. however, which browser are you using? are you running X? why not use tty2-tty6 for a separate user login? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck in the stage of grand illusion you walked into my life out of my dreams. -- david bowie msg05402/pgp0.pgp Description: PGP signature
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.19.2304 +0100]: The question I have is if I su - username and then browse the web, etc. is it impossible for a remote user who managed to gain access to that user session to become root by exiting out of the user account? an addition: your setup and question sounds really flakey to me, and even though i can't really think of ways to break in, that *does not* say that there aren't any. fact is, when i imagine your situation, i get a very weird feeling in my intestines, and as a security person, the only sensible advise i can actually give you is to say: no, don't do it. first, it's a server, server's are *not* workstations, and you only surf the web on a workstation. second, having a persistent root console open sounds horrible. third, to say that physical security is ensured it foolish. fourth, it really just sounds bad. fifth, did i say it sounds bad? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck core error - bus dumped msg05403/pgp0.pgp Description: PGP signature
Re: su - user question
On Sun, 20 Jan 2002 00:41:48 +0100 martin f krafft [EMAIL PROTECTED] wrote: ensured it foolish. fourth, it really just sounds bad. fifth, did i say it sounds bad? I'd just like to take a quite moment to second this. Security is an attitude, not any single set of procedures. It can't be solved, it can't be adequate. Given the situation set forth, my impression is that the attitude is not one of security. Okay, it sounds high-handed :) So sue me, it's the truth :) -- .--=-=-=-=--=---=-=-=. /David Barclay HarrisAut agere, aut mori. \ \Clan Barclay Either action, or death./ `---==-=-=-=-===-=---=--=' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
On Sun, 2002-01-20 at 15:16, Kevin Littlejohn wrote: On Sun, Jan 20, 2002 at 02:45:53PM +1300, Adam Warner wrote: Can anyone provide a plausible scenario for how someone might be able to gain root level access because su - has been used to switch to a user account. Martin has already answered that your tty session would have to be stolen. How can you steal a tty session using only remote means? The only thing I can think of off-hand is the old tty bomb approach - because you're running as the user at that point, your /dev/tty will likely have appropriate perms for the user to write to it, and they could conceivably send you escape sequences that may trigger strange behaviour at your client end. There used to be a sequence that'd trigger the execution of arbitrary commands in ansi terminals - that's been closed, but it flags one possible spot, I guess. Alternately, the user may be able to write spurious info to your terminal. That in itself could cause you to behave differently, although whether it could be leveraged to root-level access or not is something else altogether. Finally, su - will execute the user's own profile - which means you're executing user-controlled scripts, which may do interesting things like setup something to intercept and log keypresses etc. At the very least, su without the - is probably called for if you mistrust the user. Thanks for those possibilities Kevin. Perhaps you or someone else could expand on the first 2 as to how the switch user part could assist in gaining root access. In your last paragraph I don't see how using su - would make any difference in regard to the execution of user-controlled scripts compared to just logging in as the user. Here's a scenario where using su - could be less risky than always logging in as a user: First assume there is a local root vulnerability in the operating systems of two computers that can be accessed once a user level account has been obtained. Second, assume that the root passwords of both systems are very strong. Third, assume that the systems are logged into locally by a user/administrator. However they are connected to the Internet and are providing Internet services (it's not the best security practice to allow remote logins when they are not necessary but it's still a plausible scenario). In the first system the administrator sets up a user account with an easy to remember password. Over time a cracker is able to guess this password and obtain local user and then root access to the computer. In the second system the administrator sets up a user account with a randomly generated dual case alphanumeric password. The administrator has to write this password down to remember it. Consulting the document is a hassle so he/she decides to use su - to log in as the user instead. The remote cracker is never able to guess the user password and obtain user (then root) access to the system. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. Or to put it another way in some circumstances it may be superior for an administrator/user to only have to remember one long password than trying to remember two potentially less effective passwords. The user password can be even _unknown_ to the user. Yes this sounds heretical. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
su - user question
Hi everyone, I'm just wondering about the safety of this security practice. Firstly the servers are physically secure and there is no relevant issue about having a local root console open for administration purposes. The question I have is if I su - username and then browse the web, etc. is it impossible for a remote user who managed to gain access to that user session to become root by exiting out of the user account? I'm almost certain the answer should be no. But I'd just like confirmation. Thanks, Adam
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.19.2304 +0100]: Firstly the servers are physically secure and there is no relevant issue about having a local root console open for administration purposes. mh. no comment. sure, if physical access would be available, no box is secure. but having a root login right there only means that an intruder wouldn't have to reboot the box (which is noticeable), he could just leave a backdoor in as little as 30 seconds. don't do it. The question I have is if I su - username and then browse the web, etc. is it impossible for a remote user who managed to gain access to that user session to become root by exiting out of the user account? I'm almost certain the answer should be no. But I'd just like confirmation. no. he'd have to steal your actual tty session, and if all you are doing is surfing the web, then he can't really do that. however, which browser are you using? are you running X? why not use tty2-tty6 for a separate user login? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] in the stage of grand illusion you walked into my life out of my dreams. -- david bowie pgpstnAXAa1Yw.pgp Description: PGP signature
Re: su - user question
On Sun, Jan 20, 2002 at 02:45:53PM +1300, Adam Warner wrote: Can anyone provide a plausible scenario for how someone might be able to gain root level access because su - has been used to switch to a user account. Martin has already answered that your tty session would have to be stolen. How can you steal a tty session using only remote means? The only thing I can think of off-hand is the old tty bomb approach - because you're running as the user at that point, your /dev/tty will likely have appropriate perms for the user to write to it, and they could conceivably send you escape sequences that may trigger strange behaviour at your client end. There used to be a sequence that'd trigger the execution of arbitrary commands in ansi terminals - that's been closed, but it flags one possible spot, I guess. Alternately, the user may be able to write spurious info to your terminal. That in itself could cause you to behave differently, although whether it could be leveraged to root-level access or not is something else altogether. Finally, su - will execute the user's own profile - which means you're executing user-controlled scripts, which may do interesting things like setup something to intercept and log keypresses etc. At the very least, su without the - is probably called for if you mistrust the user. KJL
Re: su - user question
On Sun, 2002-01-20 at 15:16, Kevin Littlejohn wrote: On Sun, Jan 20, 2002 at 02:45:53PM +1300, Adam Warner wrote: Can anyone provide a plausible scenario for how someone might be able to gain root level access because su - has been used to switch to a user account. Martin has already answered that your tty session would have to be stolen. How can you steal a tty session using only remote means? The only thing I can think of off-hand is the old tty bomb approach - because you're running as the user at that point, your /dev/tty will likely have appropriate perms for the user to write to it, and they could conceivably send you escape sequences that may trigger strange behaviour at your client end. There used to be a sequence that'd trigger the execution of arbitrary commands in ansi terminals - that's been closed, but it flags one possible spot, I guess. Alternately, the user may be able to write spurious info to your terminal. That in itself could cause you to behave differently, although whether it could be leveraged to root-level access or not is something else altogether. Finally, su - will execute the user's own profile - which means you're executing user-controlled scripts, which may do interesting things like setup something to intercept and log keypresses etc. At the very least, su without the - is probably called for if you mistrust the user. Thanks for those possibilities Kevin. Perhaps you or someone else could expand on the first 2 as to how the switch user part could assist in gaining root access. In your last paragraph I don't see how using su - would make any difference in regard to the execution of user-controlled scripts compared to just logging in as the user. Here's a scenario where using su - could be less risky than always logging in as a user: First assume there is a local root vulnerability in the operating systems of two computers that can be accessed once a user level account has been obtained. Second, assume that the root passwords of both systems are very strong. Third, assume that the systems are logged into locally by a user/administrator. However they are connected to the Internet and are providing Internet services (it's not the best security practice to allow remote logins when they are not necessary but it's still a plausible scenario). In the first system the administrator sets up a user account with an easy to remember password. Over time a cracker is able to guess this password and obtain local user and then root access to the computer. In the second system the administrator sets up a user account with a randomly generated dual case alphanumeric password. The administrator has to write this password down to remember it. Consulting the document is a hassle so he/she decides to use su - to log in as the user instead. The remote cracker is never able to guess the user password and obtain user (then root) access to the system. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. Or to put it another way in some circumstances it may be superior for an administrator/user to only have to remember one long password than trying to remember two potentially less effective passwords. The user password can be even _unknown_ to the user. Yes this sounds heretical. Regards, Adam
