Package: flashplugin-nonfree Version: 1:3.4 Severity: critical Tags: security Justification: root security hole
Hi. This is basically a follow up from the lengthy discussion at debian-devel: https://lists.debian.org/debian-devel/2014/06/msg00171.html (somewhere deeper in the thread). I've head a short glance over the code and assume the following: - You use OpenPGP to verify whether the flash plugin downloaded from Debian servers is "valid" (whatever that means, since it's closed source). - The key used for signing is solely under YOUR (i.e. the package maintainer's) control. It is especially NOT a key that is under the control of upstream. - AFAICS, you never use https, TLS/SSL or X.509 in that security framework (which would make things usually just more insecure). While all this sounds nice and secure at first, it is acutally not in several places: - I rather don't like the idea that a key is used to sign the binary at all. If your key would be compromised, an attacker could _selectively_ attack single users by giving them forged code. Of course you may say "if my key is compromised, than an attacker can as well use it to upload new packages to Debian". Yes, but such a package would then be delivered to _all_ users, thereby increasing the chance that any forgery is noticed. The whole schema has one big problem as it basically circumvents the package management system and the security support, as it is it's "own" package installation system. This leads to several problems: - User won't notice when new versions of the binary (and with flash this most definitely means critical security updates) are available. Only when they run the installer, they will get a new version). Thus, any of the standard mechanisms (apt, aptitude, notifiers) that tell people of new versions are kicked out of the game. - As you implemented your OpenPGP signature based verification system, you allow for both, downgrade and blocking attacks: As far as I can see, you never check for any cryptographically secured "valid-from/through" period. This means, an attacker can simply download packages and signatures from the server and when such version of the binary is long known to have security holes, he could MitM someone that runs the installer, present him some binary and your still valid (but old) signature. Even signature revocations or that like won't help (since he could just block such). - Also, even if you'd run the installer automatically via e.g. cron, he could do blocking attacks (when you don't check for some "valid-from/through" period), i.e. he could just block any "messages" from the server, that there are new versions/signatures available... making the downloader believe that everything is still fine. Please have a look at the aforementioned mailing list thread (the stuff about downloader packages is rather deep in it) and familiarise yourself with potential problems. Another resource might be bug #752275, which is vaguley the same for torbrowser-launcher (actually with some issues more, since they use the upstream GPG keys)- The best advise I can give for such downloader packages is the following: - Hard code the hashsum of the binary/bundle/archive to be downloaded in your package. - Use a "good" state of the art hash algo (i.e. not MD5)... or even use more (I'd suggest SHA512 and SHA3 - since those two even base on different cryto) and fail with bells and whistles when _any_ of them doesn't verify. - If anything didn't verify,... make sure you remove everything that was downloaded (users might think it's safe and use it themselves) - When you extract archives (tar/zip/etc.) take care that leading / in the archive would be forcibly ignored. - Everytime, you see that upstream has a new package,... make a new debian package and replace the hashes - that way you also get all the notifications and stuff in package management for free. Further. - Never use TLS/SSL/X.509 for security... it can be made secure - but it's tricky - Don't use OpenPGP as well... while it's much (and I really mean veeerrrryyy much better than X.509) you still may run into tricky isses as the downgrading attacks described above. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
