1343453 - (CVE-2017-5437) 3 public security flaws in libevent, which may affect mozilla products

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Huzaifa Sidhpurwala]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161130084355

Steps to reproduce:

Vulnerable code here is present in libevent embedded in firefox, thunderbird, xulrunner - part of the Chromium IPC code, which seems to be used for internal IPC between mozilla processes.

Previously https://www.mozilla.org/en-US/security/advisories/mfsa2015-57/ concerned Chromium IPC, and it looks like in fixing that you ensured IPC peers are authenticated.  Thus any compromise could only be through causing an IPC peer to send a dangerous message, which would force a hostname, IPv6 address or DNS packet to be parsed by libevent code from attacker-controlled input.

In decreasing order of impact:

CVE-2016-10196 is a full stack smash parsing an IPv6-like address from a >2GiB string.

CVE-2016-10195 can leak ~50 bytes past the end of a malformed DNS query or response packet.

CVE-2016-10197 can read a single byte from before an empty string.

http://seclists.org/oss-sec/2017/q1/250

Comment 1

[Daniel Veditz [:dveditz]]

These bugs are fixed in 2.1.6 and we just landed 2.0.22-stable according to bug 1331297. We'll need to see if these bugs affect the 2.0.x versions, or since they were fixed 11 months ago, perhaps made their way into stable also.

https://github.com/libevent/libevent/issues/317
https://github.com/libevent/libevent/issues/318
https://github.com/libevent/libevent/issues/332

Comment 2

[Ryan VanderMeulen [:RyanVM]]

v2.0.22 was released on Jan 5, 2015. v2.1.5 was released at the same time. v2.1.6 was released Aug 26, 2016. So going off that alone, it sounds pretty unlikely these are fixed anywhere on 2.0.x.

I actually have a working patch for updating us to 2.1.8 but have held off on getting a bug filed and landing it due to poor upstream distro support for it and since it's the first "stable" release in the 2.1 series.

That said, these 3 patches all look pretty small. We could probably create a branch-friendly uplift patch pretty easily here.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Attachment: backport some upstream libevent fixes

This patch backports upstream fixes for the issues cited in this bug plus a couple other small fixes sitting on the upstream 2.0.x branch that look useful.

Green on Try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=9e601cf431eb5ba95932b65ba40fb4a02878a879

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Comment on attachment 8842493 [details] [diff] [review]
backport some upstream libevent fixes

Review of attachment 8842493 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks. It looks like we don't use the code in evutil.c or evdns.c. The buffer.c stuff probably gets used though.

I filed bug 1343699 to get rid of libevent so that I don't have to review any more of these patches :-).

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8842493 [details] [diff] [review]
backport some upstream libevent fixes

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

Not easily AFAIK. Also, these issues are already publicly disclosed upstream.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

I left the commit message pretty generic, though I do reference the (public) upstream issues being fixed.

Which older supported branches are affected by this flaw?

All.

If not all supported branches, which bug introduced the flaw?

Bug 842887.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

Trivial to backport. This code basically never changes.

How likely is this patch to cause regressions; how much testing does it need?

It's green on Try across all test suites, and that certainly exercises our IPC code heavily. I'm reasonably confident that we won't see any issues in the wild.

Comment 6

[Al Billings [:abillings - ex-MoCo]]

Sec-approval+ for checkin. Please find a way to checkin without mentioning a security bug (this bug) in the checkin and we're golden! "Updating versions" etc.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2e025eb770e85de558fb72825539903b3e049172

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/2e025eb770e8

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8842493 [details] [diff] [review]
backport some upstream libevent fixes

Approval Request Comment
[Feature/Bug causing the regression]: bug 842887
[User impact if declined]: possible Linux/OSX security issues
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: this is a straight backport of upstream code, so there's really nothing to verify here
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: these fixes have baked upstream for nearly 2 years now without known regressions
[String changes made/needed]: none

Comment 10

[Gerry Chang [:gchang]]

Comment on attachment 8842493 [details] [diff] [review]
backport some upstream libevent fixes

Fix a sec-high. Aurora54+.

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/742d73198be8

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8842493 [details] [diff] [review]
backport some upstream libevent fixes

This should land for beta 2 next week.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/ed77e7b7d76e
https://hg.mozilla.org/releases/mozilla-beta/rev/b2299dd1dc57

Comment 14

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8842493 [details] [diff] [review]
backport some upstream libevent fixes

We'd also want these on ESR branches.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/c5c236ff438c
https://hg.mozilla.org/releases/mozilla-esr45/rev/ff67ec15166b

Comment 16

[Andrei Vaida [:avaida]]

Setting qe-verify- based on Ryan's assessment on manual testing needs (see Comment 9) and the fact that this fix has automated coverage.