1611482 - Double free inside nsZipHandle upon FindDataStart failure

Status: RESOLVED FIXED

(Core :: Networking: JAR, defect, P1)

Description

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/releases/mozilla-release/annotate/8260da04c9b13f7c0e9cc6984a75e689b5fcb8c8/modules/libjar/nsZipArchive.cpp#l217 de-allocated the map, however at that point it has already been set on the handle object, handle->mMap and handle->mFileStart are not dangling pointers.

In ~nsZipHandle it will proceed to attempt to de-allocate the memory and trigger a double free.

Comment 1

[Bas Schouten (:bas.schouten)]

Attachment: Bug 1611482: Prevent the existance of dangling pointers upon failure of FindDataStart. r=spohl

Comment 2

[Valentin Gosu [:valentin] (he/him) <<Parental leave March 1 - August 1>>]

Double free sounds like a security issue

Comment 3

[Daniel Veditz [:dveditz]]

It can be a problem, but I think in this case there's a very small window between failure and the deconstructor so it'd be a hard race to win reliably. Calling it sec-moderate for now.

Comment 4

[Bas Schouten (:bas.schouten)]

Comment on attachment 9122942 [details]
Bug 1611482: Prevent the existance of dangling pointers upon failure of FindDataStart. r=spohl

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Window is pretty small as Daniel mentioned. And it's not even clear to me what triggers this situation. It's based on code analysis and crash stats.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
• Which older supported branches are affected by this flaw?: All I believe
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: Low risk, this patch should apply.
• How likely is this patch to cause regressions; how much testing does it need?: Not really.

Comment 5

[Daniel Veditz [:dveditz]]

Comment on attachment 9122942 [details]
Bug 1611482: Prevent the existance of dangling pointers upon failure of FindDataStart. r=spohl

It's too late to get into next week's releases, but looking at the crash volume we'll want this fix on ESR for next time too.

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/0c0f77ca0a7eccbbb91a45df7ee63d687fac88ee
https://hg.mozilla.org/mozilla-central/rev/0c0f77ca0a7e

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR68 approval when you get a chance.

Comment 8

[Bas Schouten (:bas.schouten)]

Comment on attachment 9122942 [details]
Bug 1611482: Prevent the existance of dangling pointers upon failure of FindDataStart. r=spohl

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Sec moderate, but low risk and an easy fix to take.
• User impact if declined: Potential UAF
• Fix Landed on Version: 77
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simply removes a dangling pointer.
• String or UUID changes made by this patch: None.

Comment 9

[Julien Cristau [:jcristau]]

Comment on attachment 9122942 [details]
Bug 1611482: Prevent the existance of dangling pointers upon failure of FindDataStart. r=spohl

approved for 68.8esr

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/3394cb213d2d