Re: ksh / CVE-2019-14868
Hi
Interesting. I wonder how I concluded that it was just arithmetic
expressions. Do you want me to re-check it?
Segmentation faults can be problematic too, but it looks like we have
some protection against this CVE already. The question is whether the
subshell is actually executed before the sigsegv.
Cheers
// Ola
On Tue, 14 Jul 2020 at 00:02, Brian May <bam@debian.org> wrote:
>
> Ola Lundqvist <ola@inguza.com> writes:
>
> > Ah one more thing. In the jessie version (I was the one marking it as
> > ignored) I concluded that any arithmetic expression could be executed
> > but not any expression. This means that you could run for example
> > 10+4+5 (evaluated to 19) but not $(/bin/bash). I suggest checking if
> > the stretch version has the same conclusion. Because if that is the
> > case, there is no point in fixing it.
>
> Running through the supplied tests cases
> https://github.com/att/ast/commit/c7de8b641266bac7c77942239ac659edfee9ecd2,
> on both Jessie and Stretch, I get identical results:
>
> (jessie-amd64-default)root@silverfish:/home/brian# SHLVL='7' ksh -c 'echo $SHLVL'
> 8
> (jessie-amd64-default)root@silverfish:/home/brian# SHLVL='013' ksh -c 'echo $SHLVL'
> 14
> (jessie-amd64-default)root@silverfish:/home/brian# SHLVL='2#11' ksh -c 'echo $SHLVL'
> 4
> (jessie-amd64-default)root@silverfish:/home/brian# SHLVL='16#B' ksh -c 'echo $SHLVL'
> 12
> (jessie-amd64-default)root@silverfish:/home/brian# SHLVL='2#11+x[$(echo DANGER WILL ROBINSON >&2)0]' ksh -c 'echo $SHLVL'
> Segmentation fault
> (jessie-amd64-default)root@silverfish:/home/brian# SHLVL='2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]' ksh -c 'echo $SHLVL'
> Segmentation fault
> DANGER WILL ROBINSON
>
>
> (stretch-amd64-default)root@silverfish:/home/brian# SHLVL='7' ksh -c 'echo $SHLVL'
> 8
> (stretch-amd64-default)root@silverfish:/home/brian# SHLVL='013' ksh -c 'echo $SHLVL'
> 14
> (stretch-amd64-default)root@silverfish:/home/brian# SHLVL='2#11' ksh -c 'echo $SHLVL'
> 4
> (stretch-amd64-default)root@silverfish:/home/brian# SHLVL='16#B' ksh -c 'echo $SHLVL'
> 12
> (stretch-amd64-default)root@silverfish:/home/brian# SHLVL='2#11+x[$(echo DANGER WILL ROBINSON >&2)0]' ksh -c 'echo $SHLVL'
> Segmentation fault
> (stretch-amd64-default)root@silverfish:/home/brian# SHLVL='2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]' ksh -c 'echo $SHLVL'
> Segmentation fault
> DANGER WILL ROBINSON
>
> So it looks like not only is the echo process running, but I am also
> getting a segmentation fault too :-(
>
> Although sometimes the shell prompt will appear first before the echo
> message:
>
> (stretch-amd64-default)root@silverfish:/home/brian# SHLVL='2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]' ksh -c 'echo $SHLVL'
> Segmentation fault
> (stretch-amd64-default)root@silverfish:/home/brian# DANGER WILL ROBINSON
>
> Which is odd, because there AFAIK all processes should be running in the
> foreground. But that might be something to do with the segfault in the
> parent process.
>
> Did I do this test correctly? It actually looks fine to me. Including if
> I strace it:
>
> (stretch-amd64-default)root@silverfish:/home/brian# SHLVL='2#11+x[$(/bin/echo DANGER WILL ROBINSON >&2)0]' strace -ff ksh -c 'echo $SHLVL'
> [...]
> [pid 29071] execve("/bin/echo", ["/bin/echo", "DANGER", "WILL", "ROBINSON"], [/* 4 vars */] <unfinished ...>
> [pid 29070] <... clone resumed> child_stack=0x7f923b956ff0, flags=CLONE_VM|CLONE_VFORK|SIGCHLD) = 29071
> [pid 29070] close(5) = 0
> [pid 29070] read(4, <unfinished ...>
> [pid 29071] <... execve resumed> ) = 0
> [pid 29070] <... read resumed> "", 4) = 0
> [pid 29070] munmap(0x7f923b94e000, 36864 <unfinished ...>
> [pid 29071] brk(NULL <unfinished ...>
> [pid 29070] <... munmap resumed> ) = 0
> [pid 29071] <... brk resumed> ) = 0x5633d6b5c000
> [pid 29070] close(4) = 0
> [pid 29071] access("/etc/ld.so.nohwcap", F_OK <unfinished ...>
> [pid 29070] rt_sigprocmask(SIG_SETMASK, [], <unfinished ...>
> [pid 29071] <... access resumed> ) = -1 ENOENT (No such file or directory)
> [pid 29070] <... rt_sigprocmask resumed> NULL, 8) = 0
> [pid 29071] access("/etc/ld.so.preload", R_OK <unfinished ...>
> [pid 29070] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
> [pid 29071] <... access resumed> ) = -1 ENOENT (No such file or directory)
> [pid 29071] open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> [pid 29071] fstat(3, {st_mode=S_IFREG|0644, st_size=15058, ...}) = 0
> [pid 29071] mmap(NULL, 15058, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2ccefe6000
> [pid 29071] close(3) = 0
> [pid 29071] access("/etc/ld.so.nohwcap", F_OK <unfinished ...>
> [pid 29070] +++ killed by SIGSEGV +++
> <... access resumed> ) = -1 ENOENT (No such file or directory)
> open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\4\2\0\0\0\0\0"..., 832) = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=1689360, ...}) = 0
> mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2ccefe4000
> mmap(NULL, 3795296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2ccea28000
> mprotect(0x7f2ccebbd000, 2097152, PROT_NONE) = 0
> mmap(0x7f2ccedbd000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x195000) = 0x7f2ccedbd000
> mmap(0x7f2ccedc3000, 14688, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2ccedc3000
> close(3) = 0
> arch_prctl(ARCH_SET_FS, 0x7f2ccefe5480) = 0
> mprotect(0x7f2ccedbd000, 16384, PROT_READ) = 0
> mprotect(0x5633d68d1000, 4096, PROT_READ) = 0
> mprotect(0x7f2ccefea000, 4096, PROT_READ) = 0
> munmap(0x7f2ccefe6000, 15058) = 0
> brk(NULL) = 0x5633d6b5c000
> brk(0x5633d6b7d000) = 0x5633d6b7d000
> fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
> write(1, "DANGER WILL ROBINSON\n", 21DANGER WILL ROBINSON
> ) = 21
> close(1) = 0
> close(2) = 0
> exit_group(0) = ?
> +++ exited with 0 +++
> Segmentation fault
>
> --
> Brian May <bam@debian.org>
>
--
--- Inguza Technology AB --- MSc in Information Technology ----
| ola@inguza.com opal@debian.org |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
---------------------------------------------------------------
Reply to: