Bug 1343453 (CVE-2017-5437)

3 public security flaws in libevent, which may affect mozilla products

RESOLVED FIXED in Firefox -esr45

Status

()

defect
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: huzaifas, Assigned: RyanVM)

Tracking

({csectype-bounds, sec-high})

50 Branch
mozilla55
Points:
---
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox-esr4553+ fixed, firefox51 wontfix, firefox52 wontfix, firefox-esr5253+ fixed, firefox53+ fixed, firefox54+ fixed, firefox55 fixed)

Details

(Whiteboard: [adv-main53+][adv-esr52.1+][adv-esr45.9+])

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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
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
Group: firefox-core-security → dom-core-security
Component: Untriaged → IPC
Flags: needinfo?(ryanvm)
Product: Firefox → Core
(Assignee)

Comment 2

2 years ago
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.
Assignee: nobody → ryanvm
Flags: needinfo?(ryanvm)
(Assignee)

Comment 3

2 years ago
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
Attachment #8842493 - Flags: review?(wmccloskey)
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 :-).
Attachment #8842493 - Flags: review?(wmccloskey) → review+
(Assignee)

Comment 5

2 years ago
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.
Attachment #8842493 - Flags: sec-approval?
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.
Attachment #8842493 - Flags: sec-approval? → sec-approval+
(Assignee)

Comment 8

2 years ago
https://hg.mozilla.org/mozilla-central/rev/2e025eb770e8
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
(Assignee)

Comment 9

2 years ago
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
Attachment #8842493 - Flags: approval-mozilla-esr52?
Attachment #8842493 - Flags: approval-mozilla-esr45?
Attachment #8842493 - Flags: approval-mozilla-beta?
Attachment #8842493 - Flags: approval-mozilla-aurora?
Comment on attachment 8842493 [details] [diff] [review]
backport some upstream libevent fixes

Fix a sec-high. Aurora54+.
Attachment #8842493 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8842493 [details] [diff] [review]
backport some upstream libevent fixes

This should land for beta 2 next week.
Attachment #8842493 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 8842493 [details] [diff] [review]
backport some upstream libevent fixes

We'd also want these on ESR branches.
Attachment #8842493 - Flags: approval-mozilla-esr52?
Attachment #8842493 - Flags: approval-mozilla-esr52+
Attachment #8842493 - Flags: approval-mozilla-esr45?
Attachment #8842493 - Flags: approval-mozilla-esr45+
Group: dom-core-security → core-security-release
Setting qe-verify- based on Ryan's assessment on manual testing needs (see Comment 9) and the fact that this fix has automated coverage.
Flags: qe-verify-
Whiteboard: [adv-main53+][adv-esr52.1+][adv-esr45.9+]
Alias: CVE-2017-5437
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.