Closed
Bug 867056
(CVE-2013-1700)
Opened 12 years ago
Closed 12 years ago
Arbitrary code execution using a temporarily inaccessible file
Categories
(Toolkit :: Application Update, defect)
Tracking
()
RESOLVED
FIXED
mozilla24
Tracking | Status | |
---|---|---|
firefox20 | --- | unaffected |
firefox21 | --- | affected |
firefox22 | + | fixed |
firefox23 | + | fixed |
firefox24 | + | fixed |
firefox-esr17 | --- | unaffected |
b2g18 | --- | unaffected |
People
(Reporter: sebbity, Assigned: bbondy)
References
Details
(Keywords: csectype-priv-escalation, reporter-external, sec-high, Whiteboard: [adv-main22+])
Attachments
(1 file)
6.63 KB,
patch
|
robert.strong.bugs
:
review+
akeybl
:
approval-mozilla-aurora+
akeybl
:
approval-mozilla-beta+
abillings
:
sec-approval+
|
Details | Diff | Splinter Review |
In fixing Bug 850492, the updater.exe that the Maintenance Service tries to verify is now copied to a known safe location to stop the user pointing it to a malicious path and replacing the executable after verification.
Unfortunately, if the system cannot copy the file it doesn't error and exit, just logs a warning, uses the malicious path and continues on like normal.
This introduces a second race condition in that if you have an updater.exe which doesn't exist when execution hits workmonitor.cpp:589 the file copy will fail and the system will use the malicious path. The attacker can then create malicious_path\updater.exe before the program sets the write lock at workmonitor.cpp:332 and then use the same process described in Bug 850492 to execute arbitrary code as SYSTEM.
For convenience, source revision the line numbers are for is latest at the current time and located at:
https://hg.mozilla.org/mozilla-central/file/1eb382609c2d/toolkit/components/maintenanceservice/workmonitor.cpp
Updated•12 years ago
|
Flags: sec-bounty?
Comment 1•12 years ago
|
||
That seems like a tough timing condition to pull off, but I guess if you're trying to get elevated permissions on your own locked-down machine there's nothing to prevent you from trying over and over until you get it.
Assignee: nobody → netzen
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•12 years ago
|
Depends on: CVE-2013-1672
Updated•12 years ago
|
Keywords: csec-priv-escalation
Updated•12 years ago
|
status-firefox20:
--- → unaffected
status-firefox21:
--- → affected
status-firefox22:
--- → affected
status-firefox23:
--- → affected
status-firefox24:
--- → affected
tracking-firefox22:
--- → +
tracking-firefox23:
--- → +
tracking-firefox24:
--- → +
Flags: sec-bounty? → sec-bounty+
Keywords: sec-high
Assignee | ||
Comment 3•12 years ago
|
||
Attachment #752767 -
Flags: review?(robert.bugzilla)
Assignee | ||
Comment 4•12 years ago
|
||
Comment on attachment 752767 [details] [diff] [review]
Patch v1.
Request is for landing on try, oak (for testing nightly updates), and m-i.
[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Hard to hit the timing condition but can be done repeatedly until exploited.
Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Somewhat but it is not completely obvious why the changes are being made.
Which older supported branches are affected by this flaw?
Firefox 21 - 23.
If not all supported branches, which bug introduced the flaw?
bug 850492 tried to fix it where it was reported originally but didn't catch all cases.
Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
Code for other branches should be the same.
How likely is this patch to cause regressions; how much testing does it need?
should land on m-c first since it's an updater task. It is not likely it will cause regressions.
Attachment #752767 -
Flags: sec-approval?
![]() |
||
Updated•12 years ago
|
Attachment #752767 -
Flags: review?(robert.bugzilla) → review+
Comment 5•12 years ago
|
||
Comment on attachment 752767 [details] [diff] [review]
Patch v1.
sec-approval+ for m-c. Please prepare and nominate branch patches for general approval after this is in.
We might want QA to do some testing on trunk before taking it on branches.
Attachment #752767 -
Flags: sec-approval? → sec-approval+
Assignee | ||
Comment 6•12 years ago
|
||
Tested default settings update in:
- win 8
- win vista admin account
- win vista limited user account installed into app data
- win xp admin account
- win vista limited user account installed into app data
Also tested manually failing the CopyFile to be sure it falls back.
Assignee | ||
Comment 7•12 years ago
|
||
Target Milestone: --- → mozilla24
Comment 8•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 9•12 years ago
|
||
Please nominate for uplift no later than Monday so that this can make it into our fourth FF22 beta.
Assignee | ||
Comment 10•12 years ago
|
||
Comment on attachment 752767 [details] [diff] [review]
Patch v1.
[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 850492
User impact if declined: The fix found in bug 850492 didn't fully address the concern about arbitrary code being executed by the service under elevated privs.
Testing completed (on m-c, etc.): This has been on m-c for a while and updating nightly.
Risk to taking this patch (and alternatives if risky): Low
String or IDL/UUID changes made by this patch: none
Attachment #752767 -
Flags: approval-mozilla-beta?
Attachment #752767 -
Flags: approval-mozilla-aurora?
Updated•12 years ago
|
Attachment #752767 -
Flags: approval-mozilla-beta?
Attachment #752767 -
Flags: approval-mozilla-beta+
Attachment #752767 -
Flags: approval-mozilla-aurora?
Attachment #752767 -
Flags: approval-mozilla-aurora+
Assignee | ||
Comment 11•12 years ago
|
||
Updated•12 years ago
|
status-b2g18:
--- → unaffected
status-firefox-esr17:
--- → unaffected
Updated•12 years ago
|
Whiteboard: [adv-main22+]
Updated•12 years ago
|
Alias: CVE-2013-1700
Updated•11 years ago
|
Group: core-security
Updated•9 months ago
|
Keywords: reporter-external
You need to log in
before you can comment on or make changes to this bug.
Description
•