Re: Zsh - Multiple DoS Vulnerabilities

[Stephane Chazelas <stephane.chazelas@xxxxxxxxx>]

2019-05-13 09:29:36 -0700, David Wells:
> Thanks for taking a look at these bugs. As Stephanie mentioned, security
> related risk may depend more on Zsh usage, and being that these crashes are
> Invalid Memory Access issues, they might allow an attacker to disclose
> parts of memory to help with a pre-exploitation process.
[...]

Thanks David,

I think it's fair to say you've flagged those as DoS
vulnerabilities solely on the ground they were "invalid memory
access issues" irrespective of how exploitable they are.

I'd say those reports are useful as bug reports as they point to
areas where zsh isn't doing the right thing, and I'm sure zsh
developers are grateful for it.

However I think it does a disservice (to the sysadmin and
security community (your customers as I understand your company
creates vulnerability scanning software), not so much to zsh
developers) to call them DoS vulnerabilities as they are not.

It's a shell's (or any interpreter's for that matters) expected
behaviour to fail when provided with unexpected input, so, that
the shell crashes upon invalid input is not really a problem.

A shell will exit when given "exit" or "<()>" as input, that
doesn't mean it's a DoS.

Also, it's a shells job to execute arbitrary command. A
:(){ :|:&};: input (the infamous fork bomb) will cripple a
system, but that's as intended by whoever wrote that code.

From what I can see, those reported issues would only be
vulnerabilities if they were a way to escape the "restricted
mode" of zsh, a "security" feature inherited from the Bourne
shell which hopefully nobody uses these days, but not as DoS
vulnerabilities.

I think you should change the vectors.

IMO, from a security standpoint, it's not very useful to fuzz
"code" input provided to zsh, as anyway any "code" allows zsh to
run any arbitrary command (except for the restricted mode). In
other words, the "code" is generally not the attacker supplied
data. You could fuzz environment variables (the ones zsh cares
about) or other attacker-controlled data fed to zsh scripts like
"limits" instead.

-- 
Stephane