[Pkg-mozext-maintainers] Bug#559267: Bug#559267: Sage Firefox extensions vulnerabilities

[awoodland at debian.org]

2009/12/10 Roberto Suggi Liverani <roberto.suggi at security-assessment.com>:
> Hi Alan,
>
> Sorry for the delay, very busy days here...
>
> The vulnerability was originally reported in the Sage bugzilla
> mailing-list and here you can find the link:
>
> https://www.mozdev.org/bugs/show_bug.cgi?id=20610
>
> and here is the security report detailing the bug:
>
> https://www.mozdev.org/bugs/attachment.cgi?id=5749
>
> I have tried to follow up with the author but still today I haven't got
> any response as you can see from the thread.
>
> Recently, we have been contacted by another guy, Dave Schaefer, who
> joined the thread above and who is willing to fix the bug. My suggestion
> would be to touch base with Dave and then work together to fix the
> issue. I am not sure about the author and its current involvement with
> the extension code.
>
> Regarding your questions:
>
> Q: Is this a regression of the 2006 vulnerability [4]?
>
> I am not sure about the vulnerability in 2006. What I know is that
> according to the Sage author, Peter Andrews, the '2006' bug was fixed
> and resolved. That is also reported in this thread:
> https://www.mozdev.org/bugs/show_bug.cgi?id=15101
> So the current bug is a new bug as far as I can tell you. Also, I can't
> access the PoC of the vulnerability in 2006, which should be available here:
> https://www.gnucitizen.org/static/blog/2006/09/sage-feed-poc.xml so I am
> not sure where the "injection" point was.

The current version of sage fails two of the test cases that were associated with the 2006 vulnerability. The fix I prepared for that regression doesn't correct these two new test cases however.

> Q: Are there more problems I should be aware of besides that?
>
> Potentially, there might be other input-validation issues.
>
> Q: How would you suggest dealing with this?
>
> My suggestion would be to render untrusted content in about:blank
> instead of a window with chrome privileges. Second recommendation would
> be to filter input based on whitelist and escape output as well. Some
> extension developers suggest the use of the
> nsIScriptableUnescapeHTML.parseFragment() function to perform input
> validation. However, some other developers do not agree with that. I am
> not an extension developer, so I am not able to tell you if u can just
> rely on that function. Other recommendation would be to have a look to
> other RSS readers and see how the handle the feeds, in which location,
> and what type of filtering they perform.

Ok, that makes sense. I think for the two stable releases at least that's too major a change to be making in a security fix, and a cruder patch might be the solution.

I'll have a look now at dropping all HTML from the descriptions/links for the released versions and try to incorporate a proper fix for the forth coming release.

Alan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 272 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mozext-maintainers/attachments/20091210/4184eac5/attachment.pgp>