2019-06-21 08:00:34 +0100, Stephane Chazelas:
[...]
> If you want some examples, the autoconf "configure" script as
> used for instance to build bash is affected by the change where
> it now has one of those "time-bomb" bugs you were referring to.
[...]
and remember most security vulnerabilities come from those
time-bomb bugs.
Also, with that bash5 change, \.\. now becomes a new spelling
for .. giving way to a potential new class of directory
traversal vulnerabilities.
That autoconf example above is actually pretty damning.
That autoconf configure is meant to be insanely portable even
to systems where /bin/sh is the V7 shell (provided they also
have a "decent" shell).
They try to find a usable echo/print/printf command that can
output its arguments verbatim. With POSIX sh on POSIX systems,
they settle on
as_echo='printf %s\n'
(at that point they can't use functions).
But, now for the first time in 40 years, with the release of
bash5, they can no longer do that because a \ in an unquoted
word expansion has become a wildcard operator.
And it's not fixable with a variable alone.
as_echo='printf %s\\n' will obviously not work (even in bash5).
They'll need to special-case bash here. Something like:
if test -n "$BASH_VERSION"; then
eval 'as_f_echo() { printf "%s\n" "$@"; }'
as_echo=as_f_echo
fi
Now in bash5, like for *, ?, and [ it's no longer possible to
use \ in an unquoted word expansion unless you disable globbing.
--
Stephane
