[Secure-testing-team] Bug#752277: flashplugin-nonfree: several security issues

[Christoph Anton Mitterer]

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.