Re: [BUG] Two vulnerabilities in zsh

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

tl;dr: Despite Mr Esau's subject line, I don't see any "vulnerabilities"
here.  Rather, all I see is two bugs that manifest as segfaults.  More
below.

Aaron Esau wrote on Tue, 19 May 2020 06:48 +0000:
> ------ #1 :: null dereference in check_colon_subscript in subst.c ------
> 
> 
> ## Reproduction Steps
> 
> I was able to reproduce this bug on every zsh version I tested. I am running zsh 5.8 (x86_64-pc-linux-gnu) on Arch Linux.
> 
> 1. Start zsh and execute the following (including quotes):
> 
>   "${: :${{{\"{{i use arch btw}}"
> 
> 2. Observe that the command causes a segmentation fault.

Confirmed in 5.7.1 and master.

> The stack trace is:
> 
>   $rip 0x5555555eb22e => movzx eax, BYTE PTR [rax]
>   [#1] 0x5555555ed61e => prefork()
>   [#2] 0x555555583815 => mov rsi, r12
>   [#3] 0x555555588e01 => mov rbx, QWORD PTR [rbx]
>   [#4] 0x55555558c32f => pop rcx
>   [#5] 0x55555558c6d1 => mov eax, DWORD PTR [rip+0x9e8c1] # [rip+0x9e8c1] => 0x55555562af98
>   [#6] 0x55555558e051 => execlist()
>   [#7] 0x55555558e564 => execode()
>   [#8] 0x5555555a43d4 => loop()
>   [#9] 0x5555555a7d36 => zsh_main()

> A denial of service vulnerability exists in zsh <5.8 due to a null dereference in check_colon_subscript in subst.c.

s/</≤/

More importantly, this is not a denial of service vulnerability.  For it
to qualify as a vulnerability, a situation would have to be identified
in which someone who _doesn't_ control the source code being executed
can trigger the segfault.  Until such a case is identified, this is
merely a bug that manifests as a segfault.

We thank you for the reproduction recipe and the patch.  We'll add
a regression test based on the recipe and review the patch.  Right now,
however, I consider it a higher priority to finish assessing your other
bug report and post my conclusions of both reports.

> ------ #2 :: memory corruption in ?? ------
> 
> 
> ## Reproduction Steps
> 
> I am running zsh 5.8 (x86_64-pc-linux-gnu) on Arch Linux, kernel version 5.6.11-arch1-1.
> 
> 1. Execute the following PoC command:
> 
>   echo $'******** **********************$\\\n(>$' | zsh

This instruction is underspecified because it does not identify «echo»
implementation being used and the shell being used (which affects how
the «$'…'» would be parsed).  That aside, I can reproduce this:

$ printf '******** **********************$\\\n(>$' | zsh -f 
 BUG: parse error in command substitution
Segmentation fault
$ 

That's zsh from master.  The BUG message is likely generated in debug
builds only.

> A memory corruption vulnerability exists in zsh <5.8 which may enable arbitrary code execution or memory disclosure via unspecified methods.

Everything I wrote about #1 applies here, too.  In particular, this
isn't a vulnerability either.

> There are two vulnerabilities in zsh <5.8. I'll request a couple CVE IDs if that's okay.
> 

Assignment of a CVE ID does not constitute recognition of a report as
a vulnerability.  The purpose of CVE ID's is not to catalogue _valid_
issues but to catalogue _potential_ issues; to give them names so they
may be referred to unambiguously.  On that basis, assigning CVE ID's to
_suspected_ issues while they're under discussion is perfectly normal.

However, to avoid any possibility of misunderstanding the previous
paragraph, let me state my view unambiguously:

    I am a zsh developer and I do not consider these to be vulnerabilities,
    since triggering the segfaults seems to require the attacker to be
    able to control the script's source code.

You can also refer to these issues using the X-Seq number of your
message.  In this case, this would be "45853#1" and "45853#2", since
"workers/45853" is the X-Seq identifier of your report:
http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=45843

> I contacted Peter <p.w.stephenson@xxxxxxxxxxxx> about these a few days ago. Neither have common, practical attack scenarios ("oh no! someone with a shell could pop a shell!"), so I'm disclosing them here.
> 

You didn't disclose vulnerabilities; you reported bugs.  If they had
been vulnerabilities, they would not have been made public before
a patch had been prepared and vetted.

The bug reports are valid and appreciated, and will be fixed.  However,
your subject line was inappropriate: it portrayed you as a boy crying
"Wolf!" and required me to rearrange my morning at short notice.

To the list, let's please not discuss #1 and #2 under the same subject
line as each other.

> I did a little analysis on each vulnerability. The more severe one appears to be some form of memory corruption, but it's decently complex, and I couldn't find the root cause. I think it'll take someone more experienced than me to find it. But, I was able to track down the null dereference bug. :)
> 
> Frankly, I'm not a C developer, but I think I at least know how to fix the null dereference vuln, so I added a section with a patch there.
> 
> Thanks for the awesome shell!
> 
> Sincerely,
> Aaron Esau

For future reference, acrostics aren't customarily embedded in
vulnerability reports.