Through attachments and links, an evil person could use bugzilla to lure a Mozilla Developer or Community member to execute an attack using an unpatched vulnerability in the browser. The masking of the attack as a bug report would be an effective lure. I don't know of how this might be fixed, but considering the current environment in the world and on the web it seems to me that it is only a matter of time before it happens. Possible approaches to reducing the threat are some "best" practices like dveditz uses: view-source, java|javascript|flash disabled etc, but it would be good to be more proactive although we should publish a list of things to do for safe bugzilla triaging. One possibility is to use instances of Mozilla|Firefox on each architecture to act as a canary by loading the links and attachments in a bug. If we could determine (somehow) that the Mozilla|Firefox instance was attacked we could quarantine the link|attachment|bug|whatever.

If we could determine that the browser was under attack we would solve our security problems once and for all...

(In reply to comment #1) true, but you missed the point of a canary. It would not detect that an attack was attempted, but that an attack succeeded by looking for unauthorised file changes or network connections or some other indicator that the machine had been compromised.

I think the correct fix for this problem is to fix the unpatched vulnerability in the browser! :-) Given that we now have a large market share, I don't see Bugzilla as a place attackers would particularly target with their 0day exploit. There are better ways to get your exploit run on lots of Geckos. How many people view a particular new bug report? 10 or 20 at most, I'd say. Gerv

(In reply to comment #3) > I think the correct fix for this problem is to fix the unpatched vulnerability > in the browser! :-) > Of course the vulnerability should be fixed, I never said otherwise. > Given that we now have a large market share, I don't see Bugzilla as a place > attackers would particularly target with their 0day exploit. There are better > ways to get your exploit run on lots of Geckos. How many people view a > particular new bug report? 10 or 20 at most, I'd say. > Sure, just 10 or 20 of the core Mozilla developers thats all. If you want to attack 10,000,000 people then bugzilla is not the vector you want. If you _want to attack Mozilla developers specifically_, then bugzilla is the perfect vector. If an evil person wishes to disrupt Mozilla development and if they had a 0day code execution exploit, it would be relatively easy for them to file an exploit in a bug which wiped the entire disk of the developer viewing the bug and its links.

(In reply to comment #4) > If an evil person wishes to disrupt Mozilla development and if they had a 0day > code execution exploit, it would be relatively easy for them to file an exploit > in a bug which wiped the entire disk of the developer viewing the bug and its > links. Or more subtle, installs a trojan that steals the private SSH key used for CVS and then later checks in some innocent-looking exploitable code. Or approves a rogue extension for UMO.

I think another possible solution in many cases is to run attachments through ClamAV.

We've been talking for ages about trying to get some sort of plug-in system for attachment filters (both during upload and for display/interpreting purposes, such as pretty diffs and htmlizing word docs, or other nifty tricks like that), but nobody's done it yet.

Georgi has a nice idea in bug 319154 comment 3

> another possible solution in many cases is to run attachments through ClamAV. That won't help in the proposed scenario, no virus checker will have signatures for 0-day exploits pretty much by definition. > Georgi has a nice idea in bug 319154 comment 3 That's bug 38862

(In reply to comment #9) > That's bug 38862 > Yeah, this bug is talking about exactly the same issue as in bug 38862. There is no reason to keep both bugs open. And there is much more discussion there.