Check in rdf/chrome version of bug 413250

VERIFIED FIXED

Status

()

Core
General
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: dveditz, Assigned: dveditz)

Tracking

({verified1.8.1.12, verified1.8.1.13})

unspecified
verified1.8.1.12, verified1.8.1.13
Points:
---
Bug Flags:
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

10 years ago
Don't want to hold up FF3b3 respin waiting for seamonkey reviews on the mozilla/rdf/chrome version of bug 413250. This bug is to track checking in that one
Flags: wanted1.8.1.x+
(Assignee)

Updated

10 years ago
Depends on: 413250
(Assignee)

Comment 1

9 years ago
fixed (patch in 413250)
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: fixed1.8.1.12, fixed1.8.1.13
Resolution: --- → FIXED
(Assignee)

Comment 2

9 years ago
oops, this is for the trunk landing. Not done yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I'm not sure what to do with this, Dan. :-)
(Assignee)

Comment 4

9 years ago
You could ask the SeaMonkey 1.1.8 folks to verify this one.
(Assignee)

Comment 5

9 years ago
Any seamonkey-compatible flat extension will do. Greasemonkey ought to work.

You can't use quite the exploit in bug 413250 because rdf/chrome actually caught %2e%2e just fine (see bug 413250 comment 17). But a variation like

chrome://greasemonkey/content/.%2e/%2e./

shouldn't show you part of your profile directory.

Comment 6

9 years ago
As far as I can tell, old versions of seamonkey were not vulnerable to the firefox exploits.  Seamonkey chrome URI handling used the rule of "if you try to go above [extension]/, just stay at [extension]/"

So
chrome://stylish/content/../content/common.js redirects to chrome://stylish/content/common.js

and
chrome://stylish/content/../../../content/common.js also redirects to chrome://stylish/content/common.js

In SM 1.1.7, loading chrome://stylish/content/%252e./ says "The file /content/%2e./ cannot be found."
In SM 1.1.8, trying to load that does nothing.

Beyond that, I don't see any difference between 1.1.7 and 1.1.8

...so I think everything is fixed on the seamonkey side.
Fixed or masked?
(Assignee)

Comment 8

9 years ago
fixed -- the exploit case in 1.1.8 "does nothing". The 1.1.7 behavior of trying to load the file "/content/%2e./" is wrong, though maybe means the bug was constrained enough in SeaMonkey to not be exploitable. Maybe it was, but in any case the patch stops it.
(Assignee)

Comment 9

9 years ago
fixed on trunk
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
Do we need to do anything special to verify that this also landed on branch for 1.8.1.13 and not just the 1.8.1.12 relbranch?
Keywords: fixed1.8.1.12 → verified1.8.1.12

Comment 11

9 years ago
I'd guess looking at bonsai should be enough to verify it actually landed. For verifying it actually works, I'd use branch SeaMonkey nightlies.
I looked at this with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.14pre) Gecko/20080324 SeaMonkey/1.1.10pre, just to see if I could repro the fix. When I try to install the Seamonkey greasemonkey extension, I receive an error code of -214 with a note that the installation cannot write to Profile/chrome. I don't know if this is expected or not but the extension, or a similar one, is necessary to test the fix.

Can someone in the Seamonkey community verify this fix for 1.8.1.13? I'm admitting failure here.

Comment 13

9 years ago
You must have read/write access to the SeaMonkey application directory. Because the SeaMonkey GM mod was packed on a windows machine the attributes of the installed files are wrong. You'll need to recursively chmod the installed files.

Comment 14

9 years ago
marking as VERIFIED
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.13 → verified1.8.1.13
You need to log in before you can comment on or make changes to this bug.