Closed Bug 415191 Opened 17 years ago Closed 16 years ago

Check in rdf/chrome version of bug 413250

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dveditz, Assigned: dveditz)

References

Details

(Keywords: verified1.8.1.12, verified1.8.1.13) 

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
Closed: 17 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.
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
Closed: 17 years ago → 16 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
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.
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.
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.