InformAction Forums

So Firefox 39.0.3 was released to deal with exploit involving something to do with both Gecko & pdf.js... but I'm not running Firefox, I've got a self build of SeaMonkey - with PDF viewer as an add-on that is *not* integrated into the browser.

My question is this: to those who know details of these vulnerabilities, if I want to fix it on my end by updating things, is it enough just to update SeaMonkey to be based on Gecko 39.0.3 (which I've just done on my primary machine and will do elsewhere within the next few days), or do I need to update the PDF Viewer addon (currently version 1.0.978) as well?

with PDF viewer

Is that the pdf.js extension?
(URL?)

is it enough just to update SeaMonkey to be based on Gecko 39.0.3

A current build (last day or so, & actually from SeaMonkey 2.35 & up), should have the FF patched included.

or do I need to update the PDF Viewer addon (currently version 1.0.978) as well

Now that's a good question? Guess you could see what the fix on the FF end actually fixed (but then you can't because the Bug is still locked) & see if it did anything to pdf.js or if only code to FF itself? So... don't know?

Also don't know if disabling pdf.js would be a mitigating factor (on the FF end)? (At least I didn't catch anything - definitively, to that effect.)

Oh, & most likely, depending on settings, NoScript probably provides a mitigating effect.


http://forums.mozillazine.org/viewtopic ... #p14271395

Yes the pdf.js extension.
https://github.com/mozilla/pdf.js

therube wrote:Also don't know if disabling pdf.js would be a mitigating factor (on the FF end)? (At least I didn't catch anything - definitively, to that effect.)

From what I read it sounds like it *is* a mitigating factor, at least for the exploit(s) found in the wild. For *all* exploits of that nature against Fx 39, I don't know because I don't have access to that bug either.

therube wrote:Oh, & most likely, depending on settings, NoScript probably provides a mitigating effect.

Not so sure about that (that's why I'm going for this upgrade so soon). Noscript doesn't block pdf.js at all so I wouldn't expect it to have an effect against this, unless the PDF has to be loaded through JS and/or Flash (and given what I read, I can't depend on that necessarily being the case).

Well DV did state that Adblock Plus users may have been protected - depending on filters used.

So if ABP had a mitigating affect, you might think that NoScript also may have had a mitigating affect - but you never know, unless & until the bug is opened or the process by which the exploit occurs is better understood.

Unfortunately I feel that using ABP to protect against any malware or any kind of security exploit is somewhat of a lottery given that it's a blacklist approach - see viewtopic.php?f=19&t=21124 for example. Just because I use a custom variant of RU AdList and what they saw was on a Russian ad site, doesn't make me feel any safer against this. For all I know, tomorrow it might be on a site I don't block, and with the chances of NS saving me being uncertain...


Oh, and the reason I don't just update PDF.js anyway is A) I heed the advice in my signature, and B) it's working for me. I normally update when it's broken (probably by a Gecko update) *and* there have not been changes to the Github repository for a longer period of time (indicating to me that that dev build is more likely to be stable); neither condition is currently satisfied. I'd rather ask than do an unnecessary update in non-ideal conditions.

If ABP could sometimes mitigate this threat, then perhaps the exploit relies on external code to complete its work? In which case NoScript might be helpful.

Thrawn wrote:If ABP could sometimes mitigate this threat, then perhaps the exploit relies on external code to complete its work? In which case NoScript might be helpful.

Normally yes, but pdf.js works in a privileged context which NoScript doesn't block, and without knowing details of the exploit, I have to be sceptical...

IIUC the only reason ABP mitigates the threat is that as I mentioned above these exploit(s) found in the wild was delivered by malvertising.

barbaz wrote: IIUC the only reason ABP mitigates the threat is that as I mentioned above these exploit(s) found in the wild was delivered by malvertising.

Well, NS certainly helps there too.

Just by chance happened to run into a discussion on this involving a couple people who have access to the bug... can't find the discussion again, but I think the upshot of it was something like A) the extension isn't as prone to this exploit as the integrated-in-the-browser PDF.js (which doesn't exist in SM) (although IIUC the extension isn't immune), and B) PDF.js isn't itself vulnerable, it's a vulnerability purely in the browser which could be exploited through PDF.js due to the way PDF.js interacts privileged & non-privileged code.

So I conclude that I do not need to update PDF.js to take care of this issue, all I needed was the 39.0.3 Gecko update.