You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Security patch part 1
Never use $SHELL or sh.shpath when executing shebang-less scripts
- sh_ntfork(): Removed a misguided optimization that causes ksh to
run scripts without a shebang using the binary pointed to by
either $SHELL or sh.shpath. This has a few problems:
- The shell in sh.shpath or more disastrously in $SHELL has
no guarantee of being identical to the currently running
copy of ksh93 or even existing at all, so using either is
not only bogus, but potentially dangerous.
- The optimization has no ability to pass down the current
POSIX mode status to the script.
- It's only activated for virtual subshells, resulting in
arbitrarily different behavior depending on whether or
not we're in a virtual subshell.
- It does some weird stuff with /dev/fd that seems superfluous,
and also lacks any SHOPT_DEVFD if directive. (Additionally,
if it did have one, that stat(2) would likely become mere
dead code and a waste of context switches.)
The optimization was probably intended to be used for running a
shebang-less script via posix_spawn, which is ostensibly faster
than fork. But this simply isn't possible without risking running
the shebang-less script in a shell environment different from
the current one. (If ksh were updated by the package manager
while ksh is still running, this optimization would cause the
script to run via the new version, rather than the currently
running older version.) The optimization is unfixable by design,
and as such must be removed to ensure correct behavior.
* Security patch part 2 (re: bae02c3)
rm setuid script code leading to arbitrary command execution
Changes:
- Delete code for setuid scripts on "Solaris 2.5+" because it
allows for arbitrary command execution. One millisecond you think
you're launching ksh, the next you're at the mercy of a hijacker.
Example:
SHELL=/bin/ppmflash /bin/ksh -l /dev/fd/0 < <(true)
MANPATH: usage: MANPATH flashfactor [ppmfile]
flashfactor: 0.0 = original picture, 1.0 = total whiteout
The pathshell() code doesn't *seem* to be vulnerable to privilege
escalation, but who knows (cf. CVE-2019-14868; this might need its
own CVE 2025. Maybe pathshell() should be scrapped entirely???)
- Add fickle but functional regression test (you may need to pass
KSH=/bin/ksh or some such to get it to fail against vulnerable
versions of ksh). The test uses a login shell via the -l option,
but the bug *does not* need a login shell. See:
#874 (comment)
Modify the execveat reproducer to pass along environ (which
could include a hijacked SHELL), and you're in for a BAD time.
Maybe the deleted code (introduced sometime within the period of 1995
and 1999) was relevant to some Solaris-specific use case or something.
Maybe the erasure even causes an incompatibility. But that code must
go; it's far too dangerous to execv whatever the hell pathshell gives
us during **init**. (Need I bring CVE-2019-14868 back to remembrance
again? This bug has similarities to that one.)
FWIW, all of the regression tests in the ksh and modernish suites pass
with this patch applied.
* Security patch part 3
Delete pathshell() and replace uses of it with safer equivalents
This function is a dangerous attack vector that ought not remain
in the code base. The value returned by astconf() is doubtless
safer than what is returned by pathshell().
* Other changes
The libast pathprog function and prog feature test are now unused,
and are removed.
0 commit comments