From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12108 invoked from network); 19 May 2020 17:05:19 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 19 May 2020 17:05:19 -0000 Received: (qmail 20203 invoked by alias); 19 May 2020 17:05:08 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45846 Received: (qmail 28416 invoked by uid 1010); 19 May 2020 17:05:08 -0000 X-Qmail-Scanner-Diagnostics: from wout3-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25814. spamassassin: 3.4.4. Clear:RC:0(64.147.123.19):SA:0(-2.6/5.0):. Processed in 4.768142 secs); 19 May 2020 17:05:08 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtjedguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkjghfofggtgfgsehtqhdttdertdejnecuhfhrohhmpeffrghn ihgvlhcuufhhrghhrghfuceougdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvqe enucggtffrrghtthgvrhhnpedtgeegfffghffhgeefgefglefguefgvedvgfeuledthfet udefheejueffveehveenucffohhmrghinhepiihshhdrohhrghenucfkphepjeelrdduje ejrddufeegrdefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepugdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Date: Tue, 19 May 2020 17:04:18 +0000 From: Daniel Shahaf To: Aaron Esau Cc: "zsh-workers@zsh.org" , Peter Stephenson Subject: Re: [BUG] Two vulnerabilities in zsh Message-ID: <20200519170418.5bc00b2f@tarpaulin.shahaf.local2> In-Reply-To: References: X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 ------ >=20 >=20 > ## Reproduction Steps >=20 > I was able to reproduce this bug on every zsh version I tested. I am runn= ing zsh 5.8 (x86_64-pc-linux-gnu) on Arch Linux. >=20 > 1. Start zsh and execute the following (including quotes): >=20 > "${: :${{{\"{{i use arch btw}}" >=20 > 2. Observe that the command causes a segmentation fault. Confirmed in 5.7.1 and master. > The stack trace is: >=20 > $rip 0x5555555eb22e =3D> movzx eax, BYTE PTR [rax] > [#1] 0x5555555ed61e =3D> prefork() > [#2] 0x555555583815 =3D> mov rsi, r12 > [#3] 0x555555588e01 =3D> mov rbx, QWORD PTR [rbx] > [#4] 0x55555558c32f =3D> pop rcx > [#5] 0x55555558c6d1 =3D> mov eax, DWORD PTR [rip+0x9e8c1] # [rip+0x9e8c= 1] =3D> 0x55555562af98 > [#6] 0x55555558e051 =3D> execlist() > [#7] 0x55555558e564 =3D> execode() > [#8] 0x5555555a43d4 =3D> loop() > [#9] 0x5555555a7d36 =3D> zsh_main() > A denial of service vulnerability exists in zsh <5.8 due to a null derefe= rence in check_colon_subscript in subst.c. s/ ------ #2 :: memory corruption in ?? ------ >=20 >=20 > ## Reproduction Steps >=20 > I am running zsh 5.8 (x86_64-pc-linux-gnu) on Arch Linux, kernel version = 5.6.11-arch1-1. >=20 > 1. Execute the following PoC command: >=20 > echo $'******** **********************$\\\n(>$' | zsh This instruction is underspecified because it does not identify =C2=ABecho= =C2=BB implementation being used and the shell being used (which affects how the =C2=AB$'=E2=80=A6'=C2=BB would be parsed). That aside, I can reproduce= this: $ printf '******** **********************$\\\n(>$' | zsh -f=20 BUG: parse error in command substitution Segmentation fault $=20 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 arb= itrary 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. >=20 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=3D45843 > I contacted Peter about these a few days ag= o. Neither have common, practical attack scenarios ("oh no! someone with a = shell could pop a shell!"), so I'm disclosing them here. >=20 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 appear= s to be some form of memory corruption, but it's decently complex, and I co= uldn't find the root cause. I think it'll take someone more experienced tha= n me to find it. But, I was able to track down the null dereference bug. :) >=20 > Frankly, I'm not a C developer, but I think I at least know how to fix th= e null dereference vuln, so I added a section with a patch there. >=20 > Thanks for the awesome shell! >=20 > Sincerely, > Aaron Esau For future reference, acrostics aren't customarily embedded in vulnerability reports.