1791598 - (CVE-2022-40674) Evaluate expat CVE-2022-40674 fix

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

The new expat 2.4.9 release shipped today included a CVE fix:

#629 #640 CVE-2022-40674 -- Heap use-after-free vulnerability in function doContent. Expected impact is denial of service or potentially arbitrary code execution.

https://github.com/libexpat/libexpat/pull/629/commits/4a32da87e931ba54393d465bb77c40b5c33d343b

While our RLBox sandboxing likely mitigates the severity of this issue, we still might want to consider cherry-picking the fix to our import for safety's sake.

Comment 2

[Frederik Braun [:freddy]]

[Tracking Requested - why for this release]: From a background conversation with Tom -- RLBoxing makes this less severe, but we should get this fixed and uplifted

Comment 4

[Daniel Veditz [:dveditz]]

The 2.4.9-based patch linked in comment 0 doesn't apply cleanly because of some object restructuring, though it totally applies functionally. Debian is maintaining a 2.2.10-based fork so their version of the patch might be easier to use.

Comment 6

[Peter Van der Beken [:peterv]]

Attachment: Bug 1791598 - Ensure raw tagnames are safe exiting internalEntityParser. r?mccr8!

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8ff03ef1553f
Ensure raw tagnames are safe exiting internalEntityParser. r=mccr8

Comment 8

[Pascal Chevrel:pascalc]

Peter, are you going to request an uplift to release and esr branches?

Comment 9

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/8ff03ef1553f

Comment 10

[Peter Van der Beken [:peterv]]

I spent some time writing a testcase for this (which was a bit tricky, have to block the parser at the right time and pause sending data to force a boundary in the buffer in the right spot). It turns out that we ran into this issue while fixing some crashes and intermittent failures after landing RLBox, and bholley landed a similar fix (bug 1746996). I had vaguely assumed that the failure was specific to our copy of Expat, but apparently not :-/. So we don't need to port this to branches that already have the fix for bug 1746996 (which landed in 96).

Comment 11

[jayjayjazz]

Hi Ryan,

I might have a silly question: Why not backporting this to ESR102? Does it mean that the CVE-2022-40674 was already fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1746996 as mentioned by :peterv? So, in this case, I would expect no change needed also in FF107 or that the fix lands in both FF107 and ESR102.5, right?

Sorry for the confusion, but I would like to understand the severity of this fix and if it is okay to still use ESR102 or wait until ESR115 to use it again.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

That was my understanding of comment 10, yes. We effectively fixed this bug already in 96.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

That said, Peter, can you confirm that comment 10 applies in the non-RLBox scenario (as I understand it, some distros don't have it enabled in their builds)?

Comment 14

[Peter Van der Beken [:peterv]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #13)

That said, Peter, can you confirm that comment 10 applies in the non-RLBox scenario (as I understand it, some distros don't have it enabled in their builds)?

Yes.

Comment 15

[Tom Ritter [:tjr] (OOTO until April)]

Attachment: advisory.txt

Comment 16

[Tom Ritter [:tjr] (OOTO until April)]

bad script