Hacker News Reader

Comment by nominated1 | Hacker News Reader

Can someone explain why Mozilla is not signing gmpopenh264.dll and now eme-adobe.dll? These are executed from AppData (a folder with read/write permissions). Executing dll's from AppData is generally a bad idea but if I'm going to allow it I at least want a Publisher rule attached. Google signs their CDM (WideVine) dll delivered with Chrome that executes from AppData, why isn't Mozilla?

View on HN

Firefox checks SHA-512 hashes at download time. If you have local malware that changes the GMP DLLs thereafter, the malware might as well change Firefox itself.

> If you have local malware that changes the GMP DLLs thereafter, the malware might as well change Firefox itself.

Well hopefully firefox itself is signed. This is exactly what signing is designed to prevent.

For software that runs as non-admin, authenticode is very much about checking delivery-time integrity. If you have admin-level malware, it can replace signed software (that gets run without admin privs and doesn't have UAC at launch) with unsigned lookalikes.

> If you have admin-level malware

...you should reinstall your OS. Really, that shouldn't even be an "if" these days. Of course security doesn't matter if people can just execute random code on your machine.

Anyway, code signing is not about delivery time integrity. It's easy to check whether a given binary is code signed at any given time—without it you wouldn't be able to revoke bad certificates. The only reason you shouldn't sign is if signing has some cost (like in the Mac OS X ecosystem) or you can't trust a single root certificate anyway (at which point you might as well move to OpenBSD anyway).

Not if the computer is configured to only run signed code, which is an option on Windows.

It can't change Firefox itself if it has no administrative privileges but it can change anything in the user's directories.

Your scenario already has the malware running with the user's privileges. This means that the malware already has more privileges than sandboxed GMPs in your scenario.

While that is a valid point, it doesn't changes the fact that the more attack surface the more likely to break through.

Sometimes you have few limited vulnerabilities that can add up to complete systems compromise.

I'm approaching it like this - I need to execute unsigned binaries from a location that does not have execute permissions. How can I manage this? The lack of a signature is at best an administrative burden and at worst an attack vector depending on how the Admin handles it ("let's just add a wildcard exeception"). Mozilla should recognize this and sign the dll's. I still haven't seen a reason for NOT signing them. We don't use WebRTC so ignoring gmpopenh264.dll was not a problem. However, now we're talking about "necessary" Adobe code. Need I say more? Chrome performs the same functions and adheres to common sense. This is one of those things that gets a package removed from offering. I like and use Firefox myself but I don't like the position Mozilla has put me in. Should I open a bug report or do you speak for Mozilla in an official capacity?

Please open a bug report and CC :hsivonen

I filed Firefox bug 1164948 for this issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=1164948

Firefox is now a malware installer?

Awesome!

Your post may seem snarky, but I upvoted you for truth. Many of us consider Adobe's DRM software to be nothing but malware.

It's easy to remove (see https://support.mozilla.org/en-US/kb/enable-drm); or, if you don't want it at all, you retain that option: http://download.cdn.mozilla.net/pub/firefox/releases/38.0/wi...

Reply on news.ycombinator.com