[opensuse] Risky ssh + sudo behaviour?
I wonder if this behaviour is a kind of security bug or something like that. In the LOCAL MACHINE (openSUSE 11.4) 1. ~> ssh remote_user@remote_host (password) 2. remote_user@remote_host:/> sudo ls / (root password) 3. remote_user@remote_host:/> exit Then, in the REMOTE MACHINE (also openSUSE 11.4): 4. open a new (gnome) terminal 5. ~> sudo ls / _(The sudo command in the remote machine doesn't ask for root password)_ bin boot dev etc home lib ... I think this is a security issue. An unprivileged user that knows that the system is maintained remotely using ssh and, perhaps, sudo, could keep attempting to use sudo until they gets it. PS. I use GNOME. Thanks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 01 June 2011 00:24:22 Edwin Helbert Aponte Angarita wrote:
I think this is a security issue. An unprivileged user that knows that the system is maintained remotely using ssh and, perhaps, sudo, could keep attempting to use sudo until they gets it.
They would first need to log in as the same user the admin was using. sudo won't do that for all users. It just remembers that you have already authenticated once, and won't force you to do it again until some time later. It is a convenience thing in sudo, so the same user won't have to type the admin password every single time. You can disable it if you like in /etc/sudoers by adding timestamp_timeout 0 By default sudo will not ask the same user for the password until 5 minutes later Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Thanks a lot for your answer. On Wed, 2011-06-01 at 00:40 +0200, Anders Johansson wrote:
On Wednesday 01 June 2011 00:24:22 Edwin Helbert Aponte Angarita wrote:
I think this is a security issue. An unprivileged user that knows that the system is maintained remotely using ssh and, perhaps, sudo, could keep attempting to use sudo until they gets it.
They would first need to log in as the same user the admin was using. sudo won't do that for all users. It just remembers that you have already authenticated once, and won't force you to do it again until some time later.
It is a convenience thing in sudo, so the same user won't have to type the admin password every single time. You can disable it if you like in /etc/sudoers by adding
timestamp_timeout 0
By default sudo will not ask the same user for the password until 5 minutes later
Anders
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 5/31/2011 3:40 PM, Anders Johansson wrote:
On Wednesday 01 June 2011 00:24:22 Edwin Helbert Aponte Angarita wrote:
I think this is a security issue. An unprivileged user that knows that the system is maintained remotely using ssh and, perhaps, sudo, could keep attempting to use sudo until they gets it.
They would first need to log in as the same user the admin was using. sudo won't do that for all users. It just remembers that you have already authenticated once, and won't force you to do it again until some time later.
I think the point Edwin was trying to make was assume you ssh into a remote machine _that is being used_ by an authorized users, and you use that person's login and then issue a sudo command. The regular user sitting at that remote machine can then issue another sudo without knowing root's login (allegedly). (If I'm interpreting Edwin's posting correctly.) I'm don't think this really works, because cashing of sudo credentials is specific to a login session, not specific to a user id. I tested this by ssh into my (11.4+kde) laptop from my other machine. I logged in as me in the ssh session, and I was already logged in on the laptop itself. I issued a sudo command, gave root's password, and immediately tried it on the other machine. Regardless of where I first did the sudo command, I was forced to enter root's password again when doing it in the other place. Didn't matter if the first sudo was over ssh or at the console. Each session was individually authenticated. So I have to ask Edwin if he is speculating, or if he actually tried this.
It is a convenience thing in sudo, so the same user won't have to type the admin password every single time. You can disable it if you like in /etc/sudoers by adding
timestamp_timeout 0
By default sudo will not ask the same user for the password until 5 minutes later
Anders
I'm running normal settings here. sudo authentication persists for 5 minutes but it is specific to the login session. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, May 31, 2011 at 05:42:40PM -0700, John Andersen wrote:
On 5/31/2011 3:40 PM, Anders Johansson wrote:
On Wednesday 01 June 2011 00:24:22 Edwin Helbert Aponte Angarita wrote:
I think this is a security issue. An unprivileged user that knows that the system is maintained remotely using ssh and, perhaps, sudo, could keep attempting to use sudo until they gets it.
They would first need to log in as the same user the admin was using. sudo won't do that for all users. It just remembers that you have already authenticated once, and won't force you to do it again until some time later.
I think the point Edwin was trying to make was assume you ssh into a remote machine _that is being used_ by an authorized users, and you use that person's login and then issue a sudo command.
The regular user sitting at that remote machine can then issue another sudo without knowing root's login (allegedly).
(If I'm interpreting Edwin's posting correctly.)
I'm don't think this really works, because cashing of sudo credentials is specific to a login session, not specific to a user id.
This is the default, but it can be overriden by setting "tty_tickets" to off in /etc/sudoers. Edwin, you may want to check this. Petr -- Petr Uzel IRC: ptr_uzl @ freenode
On Wed, 2011-06-01 at 09:11 +0200, Petr Uzel wrote:
On Tue, May 31, 2011 at 05:42:40PM -0700, John Andersen wrote:
On 5/31/2011 3:40 PM, Anders Johansson wrote:
On Wednesday 01 June 2011 00:24:22 Edwin Helbert Aponte Angarita wrote:
I think this is a security issue. An unprivileged user that knows that the system is maintained remotely using ssh and, perhaps, sudo, could keep attempting to use sudo until they gets it.
They would first need to log in as the same user the admin was using. sudo won't do that for all users. It just remembers that you have already authenticated once, and won't force you to do it again until some time later.
I think the point Edwin was trying to make was assume you ssh into a remote machine _that is being used_ by an authorized users, and you use that person's login and then issue a sudo command.
The regular user sitting at that remote machine can then issue another sudo without knowing root's login (allegedly).
(If I'm interpreting Edwin's posting correctly.)
I'm don't think this really works, because cashing of sudo credentials is specific to a login session, not specific to a user id.
This is the default, but it can be overriden by setting "tty_tickets" to off in /etc/sudoers. Edwin, you may want to check this.
I'm very sorry for not answering before. I thought this tread was ended. Also thanks for your interest in this treat. Let me rewrite the steps to reproduce this and pay attention to the step 4. In the LOCAL MACHINE (openSUSE 11.4) 1. ~> ssh remote_user@remote_host (password) 2. remote_user@remote_host:/> sudo ls / (root password) 3. remote_user@remote_host:/> exit Then, in the REMOTE MACHINE (also openSUSE 11.4): 4. open a _NEW_ (gnome) terminal <-- _new terminal_ 5. ~> sudo ls / _(The sudo command in the remote machine doesn't ask for root password)_ bin boot dev etc home lib ... As John said, this doesn't work if I try to issue a sudo in a terminal opened (in the remote machine) before I ssh the remote machine from the local one and issue the sudo command through the ssh link. I had to _open a new_ (gnome) terminal to make this happen. Again, thanks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 06/06/11 18:03, Edwin Helbert Aponte Angarita wrote:
On Wed, 2011-06-01 at 09:11 +0200, Petr Uzel wrote:
On Tue, May 31, 2011 at 05:42:40PM -0700, John Andersen wrote:
On 5/31/2011 3:40 PM, Anders Johansson wrote:
On Wednesday 01 June 2011 00:24:22 Edwin Helbert Aponte Angarita wrote:
I think this is a security issue. An unprivileged user that knows that the system is maintained remotely using ssh and, perhaps, sudo, could keep attempting to use sudo until they gets it. They would first need to log in as the same user the admin was using. sudo won't do that for all users. It just remembers that you have already authenticated once, and won't force you to do it again until some time later. I think the point Edwin was trying to make was assume you ssh into a remote machine _that is being used_ by an authorized users, and you use that person's login and then issue a sudo command.
The regular user sitting at that remote machine can then issue another sudo without knowing root's login (allegedly).
(If I'm interpreting Edwin's posting correctly.)
I'm don't think this really works, because cashing of sudo credentials is specific to a login session, not specific to a user id. This is the default, but it can be overriden by setting "tty_tickets" to off in /etc/sudoers. Edwin, you may want to check this. I'm very sorry for not answering before. I thought this tread was ended. Also thanks for your interest in this treat.
Let me rewrite the steps to reproduce this and pay attention to the step 4.
In the LOCAL MACHINE (openSUSE 11.4) 1. ~> ssh remote_user@remote_host (password) 2. remote_user@remote_host:/> sudo ls / (root password) 3. remote_user@remote_host:/> exit Then, in the REMOTE MACHINE (also openSUSE 11.4): 4. open a _NEW_ (gnome) terminal<-- _new terminal_ 5. ~> sudo ls / _(The sudo command in the remote machine doesn't ask for root password)_ bin boot dev etc home lib ...
As John said, this doesn't work if I try to issue a sudo in a terminal opened (in the remote machine) before I ssh the remote machine from the local one and issue the sudo command through the ssh link. I had to _open a new_ (gnome) terminal to make this happen.
Again, thanks.
This is a known for many years feature/issue. Basically sudo doesn't delete tty tickets when the tty disappears, so the if you close your authorised terminal, and open another one and it happens to get the same tty number - it is still authorised. (see files under /var/run/sudo, this is with tty_tickets already enabled (the default) - without it's even worse) But noone important seems to believe this is a genuine security vulnerability ... for example here is an ubuntu bug discussing it without resolution for the last four years: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/87023 It does make me uneasy ... although if an attacker has access to a sudo-enabled account you're probably hosed anyway ... Regards, Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
El 06/06/11 15:23, Tejas Guruswamy escribió:
But noone important seems to believe this is a genuine security vulnerability ...
Because, it isnt, it is actually a feature. ;) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 6/6/2011 10:03 AM, Edwin Helbert Aponte Angarita wrote: bin boot dev etc home lib ...
As John said, this doesn't work if I try to issue a sudo in a terminal opened (in the remote machine) before I ssh the remote machine from the local one and issue the sudo command through the ssh link. I had to _open a new_ (gnome) terminal to make this happen.
Again, thanks.
And you must CLOSE/exit the first ssh session in order for the subsequent session to still have sudo rights. As Tejas points out (in another message) you need to snag the tty number. It need not be a gnome terminal, any subsequent ssh connection, or KDE konsole terminal within the timeout will have sudo rights. Ubuntu may not "think" this is a problem because of the way they handle sudo. In ubuntu, you don't give ROOT's password for sudo privileges, you only give your own password, and presumable your actions are limited by the sudo setup. With OpenSUSE, you give Root's password, which seems to make it less useful to use sudo, because of the need to share that password around. If you know that, then you can simply log in as root and game-over! In either case, unless your administrator restricts what can be done with sudo, anyone obtaining login to an sudo enabled account need only do something like sudo -s to obtain a root shell where they can do anything. But with opensuse, at least they need two passwords to do so, unless, that is, they sneak thru using this exploit. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-06-06 at 14:25 -0700, John Andersen wrote:
And you must CLOSE/exit the first ssh session in order for the subsequent session to still have sudo rights. As Tejas points out (in another message) you need to snag the tty number.
That's right. I had to close the first ssh session. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 06/06/2011 05:09 PM, Edwin Helbert Aponte Angarita wrote:
On Mon, 2011-06-06 at 14:25 -0700, John Andersen wrote:
And you must CLOSE/exit the first ssh session in order for the subsequent session to still have sudo rights. As Tejas points out (in another message) you need to snag the tty number. That's right. I had to close the first ssh session.
sudo itself provides a very simple way to deal with this "security hole". From the man page: -K The -K (sure kill) option is like -k except that it removes the user's timestamp entirely and may not be used in conjunction with a command or other option. This option does not require a password. -k When used by itself, the -k (kill) option to sudo invalidates the user's timestamp by setting the time on it to the Epoch. The next time sudo is run a password will be required. This option does not require a password and was added to allow a user to revoke sudo permissions from a .logout file. So, "sudo -k" in the user's .lougout file ought to remove any lingering sudo rights. Jim -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 07/06/11 02:16, Jim Cunning wrote:
On 06/06/2011 05:09 PM, Edwin Helbert Aponte Angarita wrote:
On Mon, 2011-06-06 at 14:25 -0700, John Andersen wrote
And you must CLOSE/exit the first ssh session in order for the subsequent session to still have sudo rights. As Tejas points out (in another message) you need to snag the tty number. That's right. I had to close the first ssh session. sudo itself provides a very simple way to deal with this "security hole". From the man page:
-K The -K (sure kill) option is like -k except that it removes the user's timestamp entirely and may not be used in conjunction with a command or other option. This option does not require a password.
-k When used by itself, the -k (kill) option to sudo invalidates the user's timestamp by setting the time on it to the Epoch. The next time sudo is run a password will be required. This option does not require a password and was added to allow a user to revoke sudo permissions from a .logout file.
So, "sudo -k" in the user's .lougout file ought to remove any lingering sudo rights.
Jim
Though that removes sudo authorization from ALL running tty's, not only the one you just exited. YMMV Tejas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 06/07/2011 02:01 AM, Tejas Guruswamy wrote:
On 07/06/11 02:16, Jim Cunning wrote:
On 06/06/2011 05:09 PM, Edwin Helbert Aponte Angarita wrote:
On Mon, 2011-06-06 at 14:25 -0700, John Andersen wrote
And you must CLOSE/exit the first ssh session in order for the subsequent session to still have sudo rights. As Tejas points out (in another message) you need to snag the tty number. That's right. I had to close the first ssh session. sudo itself provides a very simple way to deal with this "security hole". From the man page:
-K The -K (sure kill) option is like -k except that it removes the user's timestamp entirely and may not be used in conjunction with a command or other option. This option does not require a password.
-k When used by itself, the -k (kill) option to sudo invalidates the user's timestamp by setting the time on it to the Epoch. The next time sudo is run a password will be required. This option does not require a password and was added to allow a user to revoke sudo permissions from a .logout file.
So, "sudo -k" in the user's .lougout file ought to remove any lingering sudo rights.
Jim
Though that removes sudo authorization from ALL running tty's, not only the one you just exited. YMMV
Tejas Not true..........
'sudo -k' only sets the timestamp for the invoking tty to epoch. 'sudo -K' (note upper case) only REMOVES the timestamp for the invoking tty. Others remain. Jim -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
John Andersen wrote:
On 5/31/2011 3:40 PM, Anders Johansson wrote:
On Wednesday 01 June 2011 00:24:22 Edwin Helbert Aponte Angarita wrote:
I think this is a security issue. An unprivileged user that knows that the system is maintained remotely using ssh and, perhaps, sudo, could keep attempting to use sudo until they gets it. They would first need to log in as the same user the admin was using. sudo won't do that for all users. It just remembers that you have already authenticated once, and won't force you to do it again until some time later.
I think the point Edwin was trying to make was assume you ssh into a remote machine _that is being used_ by an authorized users, and you use that person's login and then issue a sudo command.
The regular user sitting at that remote machine can then issue another sudo without knowing root's login (allegedly).
The whole point of sudo is to delegate authority to particular users. So the only person who should know that user's password and be able to login as them is that person themselves. If you're able to login as that person you *are* that person, in sudo's security model. Indeed the default is as ubuntu has it, that there is no root password; it's your own password that you use to gain rootly power. That setup increases auditability and accountability. It's always possible to trace exactly who made some change and to know that it was them that did it knowingly. At least, that's the theory. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 6/1/2011 2:29 AM, Dave Howorth wrote:
John Andersen wrote:
On 5/31/2011 3:40 PM, Anders Johansson wrote:
On Wednesday 01 June 2011 00:24:22 Edwin Helbert Aponte Angarita wrote:
I think this is a security issue. An unprivileged user that knows that the system is maintained remotely using ssh and, perhaps, sudo, could keep attempting to use sudo until they gets it. They would first need to log in as the same user the admin was using. sudo won't do that for all users. It just remembers that you have already authenticated once, and won't force you to do it again until some time later.
I think the point Edwin was trying to make was assume you ssh into a remote machine _that is being used_ by an authorized users, and you use that person's login and then issue a sudo command.
The regular user sitting at that remote machine can then issue another sudo without knowing root's login (allegedly).
The whole point of sudo is to delegate authority to particular users. So the only person who should know that user's password and be able to login as them is that person themselves. If you're able to login as that person you *are* that person, in sudo's security model. Indeed the default is as ubuntu has it, that there is no root password; it's your own password that you use to gain rootly power.
That setup increases auditability and accountability. It's always possible to trace exactly who made some change and to know that it was them that did it knowingly. At least, that's the theory.
Cheers, Dave
This is all interesting (if not redundant) background information, but how is it germane to the problem at hand, where according to one report, (Edwin's) transient state information leaked from one login session to another, but according to my tests NO SUCH LEAK OCCURRED? -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (8)
-
Anders Johansson -
Cristian Rodríguez -
Dave Howorth -
Edwin Helbert Aponte Angarita -
Jim Cunning -
John Andersen -
Petr Uzel -
Tejas Guruswamy