Using Flash and the -moz-opacity filter you can get access to about:config and make the user silently change values [secunia http://secunia.com/advisories/14160/ moderately critcial ]

VERIFIED FIXED

Status

()

Core
Plug-ins
VERIFIED FIXED
13 years ago
10 years ago

People

(Reporter: Michael Krax, Assigned: jst)

Tracking

({fixed-aviary1.0.1, fixed1.4.5, fixed1.7.6})

Trunk
x86
Windows XP
fixed-aviary1.0.1, fixed1.4.5, fixed1.7.6
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7.6 +
blocking-aviary1.0.1 +
blocking1.8b +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Using Flash and the -moz-opacity filter it is possible to display the
about:config site in a hidden frame.

By making the user double-click at a specific screen position (e.g. using a
DHTML game) you can toggle the status of boolean config parameters.

As long as the number of about:config parameters is unchanged (unlikly a casual
user will change them) you can move the parameter you want to change to the
specified screen position by using CSS (change the .hideframe class). 

Reproducible: Always

Steps to Reproduce:
1. Open http://www.mikx.de/fireflashing/
2. Open example link (make sure Flash 7 is installed)
3. Double click inside the red box

Actual Results:  
You can silently toggle any boolean config parameter

Expected Results:  
Security manager should prevent that a plugin can open about:config or file:///
links

This bug also affects Mozilla 1.7.5 and Netscape 7.1, but Mozilla raises a
dialog instead of toggeling a boolean value and Netscape does not support the
-moz-opacity filter.
(Reporter)

Comment 1

13 years ago
Oh, and please don't blame flash only. You can also load about:config using the
real player plugin and merged url events. See
http://service.real.com/help/library/guides/producerpro/htmfiles/command.htm for
details and merge a command like:

u 0:0:0:0.0 0:0:0:30.0 &&targetframe&&about:config 

This is core code somewhere, guessing plugins (non-plugin attempts to get
about:config loaded fail as they should). Is it as simple as a missing CheckLoadURI?
Assignee: firefox → nobody
Blocks: 256195, 278184, 278186
Status: UNCONFIRMED → NEW
Component: General → Plug-ins
Ever confirmed: true
Flags: blocking-aviary1.0.1?
Product: Firefox → Core
QA Contact: general → plugins
Whiteboard: [sg:fix]
Version: unspecified → Trunk
We *have* the security checks, but only do them for OJI (java) plugins? The
checks were added with bug 59767, the rationale for skipping other plugins
appears to be https://bugzilla.mozilla.org/show_bug.cgi?id=59767#c21 (only
file:// urls were considered).

Johnny, do you see any ill effects from doing the checks for all plugins?
Flags: blocking1.7.6?

Updated

13 years ago
Flags: blocking1.8b+
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1+
(Assignee)

Comment 4

13 years ago
Sounds to me like the checks were left out for non-java plugins not because
they'd harm anything, but because we thought they weren't needed. That doesn't
mean this won't break sites, but I can't think of any sites that it really would
break. I'd be fine with doing the checks for all plugins, and in fact, this bug
is already at least partly fixed on the trunk since there we do security checks
when trying to load content into frames, and those checks block this testcases
from working.

I'll write a patch that takes out the java check.
Assignee: nobody → jst
(Assignee)

Comment 5

13 years ago
Created attachment 173211 [details] [diff] [review]
Do security checks when loading URIs from any plugin
Attachment #173211 - Flags: superreview?(brendan)
Attachment #173211 - Flags: review?(dveditz)
Comment on attachment 173211 [details] [diff] [review]
Do security checks when loading URIs from any plugin

r=dveditz, but don't we need to do the same thing down in
nsPluginHostImpl::PostURL ?
Attachment #173211 - Flags: review?(dveditz) → review+

Comment 7

13 years ago
Published on public website, leaked to press, they want to report and asked me
for a statement. Can I open the bug? Same for bug 280056 and bug 279945.

Comment 8

13 years ago
Actually, it's pretty pointless to hide a bug when it's on a public website.
opening.
Group: security

Updated

13 years ago
Group: security
Comment on attachment 173211 [details] [diff] [review]
Do security checks when loading URIs from any plugin

taking back my r= pending an answer to my question about PostURL in comment 6
Attachment #173211 - Flags: review+ → review?(dveditz)
(Assignee)

Comment 10

13 years ago
Comment on attachment 173211 [details] [diff] [review]
Do security checks when loading URIs from any plugin

Duh, yeah, same change needed there too. New patch coming...
Attachment #173211 - Flags: superreview?(brendan)
Attachment #173211 - Flags: review?(dveditz)
(Assignee)

Comment 11

13 years ago
Created attachment 173316 [details] [diff] [review]
Do security checks when loading URIs from any plugin
Attachment #173211 - Attachment is obsolete: true
Attachment #173316 - Flags: superreview?(brendan)
Attachment #173316 - Flags: review?(dveditz)
Comment on attachment 173316 [details] [diff] [review]
Do security checks when loading URIs from any plugin

Great, thanks! r=dveditz
Attachment #173316 - Flags: review?(dveditz) → review+
Comment on attachment 173316 [details] [diff] [review]
Do security checks when loading URIs from any plugin

sr=me.

/be
Attachment #173316 - Flags: superreview?(brendan) → superreview+
Attachment #173316 - Flags: approval1.7.6?
Attachment #173316 - Flags: approval-aviary1.0.1?
(Assignee)

Comment 14

13 years ago
Fix landed on the trunk.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Reporter)

Comment 15

13 years ago
Since the bug is fixed i will make it public tonight. Just to let you now
beforehand.
Attachment #173316 - Flags: approval1.7.6?
Attachment #173316 - Flags: approval1.7.6+
Attachment #173316 - Flags: approval-aviary1.0.1?
Attachment #173316 - Flags: approval-aviary1.0.1+

Comment 16

13 years ago
Unhiding <http://www.heise.de/newsticker/meldung/56140>
Group: security
the patch is approved for 1.7.6 and 1.0.1. 
Anyone going to check it in please? (in case is has been checked in already
please update the keywords)
Checked into 1.7 and aviary1.0.1 branches
Keywords: fixed-aviary1.0.1, fixed1.7.6

Comment 19

12 years ago
This was (is) assigned as Secunia ID 14160;

http://secunia.com/advisories/14160/
(Mozilla / Firefox Three Vulnerabilities)

marked as "The vulnerabilities have been fixed in the CVS repository" on 8th
February, 2005.

Comment 20

12 years ago
Verified Fixed everywhere with 2/21 builds (Aviary 1.0.1, Mozilla 1.7.6, and
both Trunks).  Testcase no longer opens the about:config with Flash.
Status: RESOLVED → VERIFIED

Updated

12 years ago
Summary: Using Flash and the -moz-opacity filter you can get access to about:config and make the user silently change values → Using Flash and the -moz-opacity filter you can get access to about:config and make the user silently change values [secunia http://secunia.com/advisories/14160/ moderately critcial ]
Keywords: fixed1.4.5
awarded a bug bounty
Blocks: 256197
No longer blocks: 256195

Updated

12 years ago
Flags: testcase+
Depends on: 284963

Updated

10 years ago
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.