Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Check in rdf/chrome version of bug 413250

VERIFIED FIXED

Status

()

Core
General
VERIFIED FIXED
10 years ago
10 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

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+
Depends on: 413250
fixed (patch in 413250)
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Keywords: fixed1.8.1.12, fixed1.8.1.13
Resolution: --- → FIXED
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. :-)
You could ask the SeaMonkey 1.1.8 folks to verify this one.
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

10 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?
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.
fixed on trunk
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 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

10 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

10 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

10 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.