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
Product: Firefox → Core
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
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+
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+
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 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.
Setting qe-verify- based on Ryan's assessment on manual testing needs (see Comment 9) and the fact that this fix has automated coverage.
You need to log in before you can comment on or make changes to this bug.