Closed Bug 1225023 Opened 8 years ago Closed 8 years ago

NPAPI sandbox is blocking flash from creating the "Flash Player" parent directories.

Categories

(Core :: Security: Process Sandboxing, defect)

x86_64
Windows
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla45
Tracking Status
firefox42 --- affected
firefox43 --- fixed
firefox44 --- fixed
firefox45 --- fixed
b2g-v2.5 --- fixed

People

(Reporter: bobowen, Assigned: bobowen)

References

Details

Attachments

(1 file)

We give r/w access to everything under %APPDATA%\Adobe\Flash Player\ and %APPDATA%\Macromedia\Flash Player\.

However if these don't exist for some reason, then the Flash Player gets blocked from creating them.
Comment on attachment 8687858 [details] [diff] [review]
Allow Flash Player to create Adobe\Flash Player and Macromedia\Flash Player directories.

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

Does this apply for content processes and plugins? 
Just wondering if this makes a larger attack surface since if a junction exists in that directory it could be exploited by anything and not just flash?
Can it apply to only the flash instead?
(In reply to Brian R. Bondy [:bbondy] from comment #3)
> Comment on attachment 8687858 [details] [diff] [review]
> Allow Flash Player to create Adobe\Flash Player and Macromedia\Flash Player
> directories.
> 
> Review of attachment 8687858 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Does this apply for content processes and plugins? 
> Just wondering if this makes a larger attack surface since if a junction
> exists in that directory it could be exploited by anything and not just
> flash?
> Can it apply to only the flash instead?

This only applies to NPAPI processes and therefore just flash 64-bit, as it is the only one for which we have the sandbox turned on.

The content process (in Nightly) can only write to low integrity directories.
Comment on attachment 8687858 [details] [diff] [review]
Allow Flash Player to create Adobe\Flash Player and Macromedia\Flash Player directories.

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

Sounds good, thanks.
Attachment #8687858 - Flags: review?(netzen) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/fd53b630ea8b68248d8a2b74c10d4c507826364d
Bug 1225023: Allow Flash Player to create Adobe\Flash Player and Macromedia\Flash Player directories. r=bbondy
https://hg.mozilla.org/mozilla-central/rev/fd53b630ea8b
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Comment on attachment 8687858 [details] [diff] [review]
Allow Flash Player to create Adobe\Flash Player and Macromedia\Flash Player directories.

Approval Request Comment
[Feature/regressing bug #]:
Bug 1185532, which turned on the NPAPI sandbox for flash on 64-bit, caused this regression.

[User impact if declined]:
Users who delete their Flash Player or Adobe/Macromedia directories will lose certain Flash functionality that relies on these directories. This includes caching and licences for viewing video.

[Describe test coverage new/current, TreeHerder]:
Fix confirmed by original reporter at Adobe.

[Risks and why]:
Low - fairly small code change along the lines of existing code. New sandbox rules only give control over specific directories.

[String/UUID change made/needed]:
None
Attachment #8687858 - Flags: approval-mozilla-beta?
Attachment #8687858 - Flags: approval-mozilla-aurora?
Comment on attachment 8687858 [details] [diff] [review]
Allow Flash Player to create Adobe\Flash Player and Macromedia\Flash Player directories.

Fix for recent regression, preventing data loss sounds good.
Approved for uplift to aurora and beta.
Attachment #8687858 - Flags: approval-mozilla-beta?
Attachment #8687858 - Flags: approval-mozilla-beta+
Attachment #8687858 - Flags: approval-mozilla-aurora?
Attachment #8687858 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.