CVE-2019-14868

[posguy99]

Apple just released macOS 10.15.5, and a secuity vuln they claim they fixed is this one. If you look at the CVE, it refers to a krader patch against what I think is ksh2020?

Apple's open source site ends at 10.15.3, so I can't see what they patched.

At 10.15.3, they were using 93u+.

Someone tell me, please, they haven't jumped tracks. I haven't installed the update yet, and don't really want to, but do want to, because it fixes a whale of a lot of security holes besides this one.

https://nvd.nist.gov/vuln/detail/CVE-2019-14868
https://support.apple.com/en-us/HT211170

att/ast@c7de8b6

[marcastel]

@posguy99 Thanks for your feedback.

We should obviously follow up on this. From my understanding this has been pushed by a Red Hat representative. Commitment by Apple, I hope, is just procedural.

In all cases NIST should be informed and so should Apple Open Source that ksh2020 IS NOT an AT&T supported and amended version of their original works.

As for the vulnerability itself, I would first want more evidence to qualify it as a vulnerability. The definition as initially filed at Red Hat by zsh developer Oliver Kiddle states:

During ksh startup, environment variables that are expected to contain a number are evaluated as an arithmetic expression. If an attacker is able to set specially crafted values in one of these environment variables before a ksh shell is executed (either directly or through a script), he could execute arbitrary commands before shell restrictions are in place.

In case of services and applications that use ksh scripts and allow remote users to provide one of the arithmetic environment variables, it could allow an attacker to exploit this issue.

The affirmation if an attacker is able to set specially crafted values needs to be demonstrated for the vulnerability to exist. IMO we are mixing two topics: a) local execution, and b) remote access.

Interesting to see that the patched KSH2020 uses the test case below. if strval is the culprit, I would assume it should be strval that should be patched, not arith.c.

actual=$(env SHLVL="2#11+x[\$($echo DANGER WILL ROBINSON >&2)0]" $SHELL -c 'echo $SHLVL')

[posguy99]

Someone who's already installed the update checked for me and ksh is still calling itself 93u+. I don't have immediate access to a 10.15.5 installation.

[marcastel]

Well that's good news... you have the stable suff then :-)
Apple updates can safely be applied too.

As for the possible vulnerability, further investigation needs to be done.
However I would not flag this as high priority for now (unless, obviously, if the vulnerability in ksh93u+ is demonstrated).

[posguy99]

Yeah, but given the reference, wtf patch did Apple apply? THAT patch won't apply to 93u+. That's what was my immediate concern because I didn't want to end up with a broken shell if I updated.

[kdudka]

I cannot speak for other vendors but the patches backported by Red Hat for older releases of ksh are publicly available. See for example:
https://git.centos.org/rpms/ksh/blob/c8/f/SOURCES/ksh-20120801-cve-2019-14868.patch

[marcastel]

Thanks for the heads up @kdudka.

Against which source code are the aforementioned patches applied?

The specs file points to stale http://www.research.att.com URLs (but does reference the patch you mentioned).

[marcastel]

So this patch was added 7 days ago.

And (at least by the filenames) seems to be applied to original AT&T tarballs and not against clones of GitHub's att/ast repository. To be confirmed.

[posguy99]

I assume that's the right result...

[kdudka]

On Wednesday, May 27, 2020 5:17:39 PM CEST JM Marcastel wrote: So this patch was added [7 days ago](https://git.centos.org/rpms/ksh/c/859d0e11b5c270181c2f49e885b6c1924ab4 0915?branch=859d0e11b5c270181c2f49e885b6c1924ab40915).

It was just an example. You can find backported patches in other branches where they were applied months ago: https://git.centos.org/rpms/ksh/c/fe135eb6

And (at least by the filenames) seems to be applied to _original_ AT&T tarballs and not against clones of GitHub's att/ast repository. To be confirmed.

The source URL in the SPEC file was valid when we picked the tarball from upstream. The server is obviously not under our control, so we cannot make the URL valid forever. But you can still download the tarball from lookaside cache if needed: https://fedoraproject.org/wiki/Package_Source_Control#Lookaside_Cache Kamil

[PATinfo]

@kdudka Thanks for the heads up. The lookaside cache is a neat feature. And the whole approach is pretty reassuring, especially for cases such as that of the AT&T KornShell :-)

[saper]

Here is what I think the problem might be (using ksh93 93u+):

$ typeset -ix Y__; env Y__='2+log10(1000)' csh -c 'echo $Y__'                                            
2+log10(1000)

$ typeset -ix Y__; env Y__='2+log10(1000)' /usr/local/bin/ksh93u -c 'env |grep '\''^[AY]__'\''; print "${Y__}"; print "$((Y__+2))"'
Y__=5
A__z=F*COMP_KEY=F*COMP_POINT=F*COMP_TYPE="*SHLVL="*Y="*Y__
5
7

The question is whether Y__ has been evaluated prior to staring the inner shell or afterwards. C-shell example indicates the expression is passed intact in the environment. So I have tried this is the debugger:

> env -i /usr/local/bin/ksh93u -c 'typeset -ix Y__; env Y__='\''2+log10(1000)'\'' gdb --args /usr/local/bin/ksh93u'                
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) break main
Breakpoint 1 at 0x4070ba: file /usr/home/saper/sw/freebsd-ksh-port/r495520/ast-ksh/work/ksh93-20120801_2/src/cmd/ksh93/sh/pmain.c, line 45.
(gdb) run
Starting program: /usr/local/bin/ksh93u 

Breakpoint 1, main (argc=1, argv=0x7fffffffece8)
    at /usr/home/saper/sw/freebsd-ksh-port/r495520/ast-ksh/work/ksh93-20120801_2/src/cmd/ksh93/sh/pmain.c:45
45	/usr/home/saper/sw/freebsd-ksh-port/r495520/ast-ksh/work/ksh93-20120801_2/src/cmd/ksh93/sh/pmain.c: No such file or directory.
	in /usr/home/saper/sw/freebsd-ksh-port/r495520/ast-ksh/work/ksh93-20120801_2/src/cmd/ksh93/sh/pmain.c
Current language:  auto; currently minimal
(gdb) print argv[0]
$1 = 0x7fffffffeee8 "/usr/local/bin/ksh93u"
(gdb) print argv[1]
$2 = 0x0
(gdb) print argv[2]
$3 = 0x7fffffffeefe "A__z=\"*SHLVL=\"*Y__"
(gdb) print argv[3]
$4 = 0x7fffffffef11 "PWD=/usr/home/saper"
(gdb) print argv[4]
$5 = 0x7fffffffef25 "COLUMNS=146"
(gdb) print argv[5]
$6 = 0x7fffffffef31 "_=*13854*/usr/bin/env"
(gdb) print argv[6]
$7 = 0x7fffffffef47 "Y__=2+log10(1000)"
(gdb) print argv[7]
$8 = 0x7fffffffef59 "LINES=62"
(gdb) print argv[8]
$9 = 0x7fffffffef62 "SHLVL=1"
(gdb) print argv[9]
$10 = 0x0

Therefore Y__ must have been evaluated during the ksh93 initialization.

ksh93v- does the same