[R-sig-Debian] cran-r debian readme used to include security flaw

[Michael Rutter]

Kurt,

Thank you for the email.  Quick summary/responses:

- The thread title is misleading.  The issue is/was with Ubuntu, not Debian.

- I recently addressed this on my blog 
(http://rubuntu.netlify.com/post/changes-to-cran-ubuntu-webpage-regarding-apt-secure-key/).

- This will be a difficult issue to alert people to.  The blog post, 
twitter, this post, and an update on the readme will be the best we can 
do, I think.

- Thank you the suggestion of using the longer id.  I am updating the 
readme accordingly.

Thanks,
Michael

On 09/06/2018 05:00 PM, Kurt Wheeler wrote:
> I had to bust the cache on one of my Docker images and when I rebuilt it I
> noticed something rather concerning from the `apt-get install` step:
> 
> gpg: requesting key E084DAB9 from hkp server ha.pool.sks-keyservers.net
> gpg: key E084DAB9: public key "Totally Legit Signing Key <
> mallory using example.org>" imported
> gpg: key E084DAB9: public key "Michael Rutter <marutter using gmail.com>" imported
> gpg: Total number processed: 2
> gpg:               imported: 2  (RSA: 2)
> 
> The "Totally Legit Signing Key" didn't look so totally legit to me. It
> turns out it's because I followed the installation instructions from cran-r
> from way back (
> https://web.archive.org/web/20170702124141/https://cran.r-project.org/bin/linux/ubuntu/README.html
> ) and had this in my Dockerfile:
> 
> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E084DAB9
> 
> Which was only a 32 bit GPG key. Someone recently got around to exploiting
> this:
> https://seclists.org/oss-sec/2018/q3/174
> 
> You can see in his description that  `Totally Legit Signing Key <mallory ()
> example org>` is listed as proof of the exploit.
> 
> Now if you go to:
> https://cran.r-project.org/bin/linux/ubuntu/README.html
> 
> now the line has since been changed to use a 64 bit GPG key:
> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys
> 0x51716619e084dab9
> 
> which actually makes this exploit much harder. This is great, except that
> if I hadn't been watching the output as closely I never would have known
> that the code I copied from the official R installation instructions were
> insecure.
> 
> The author of the exploit report actually commented on our pull request to
> change this:
> https://github.com/AlexsLemonade/refinebio/pull/590#issuecomment-419234831
> 
> and had this to say:
> 
>> Duplicating 64-bit key IDs is not trivial, but it could be still within
> budget of a large criminal organization.
>> Please consider using full fingerprint instead, i.e.:
> E298A3A825C0D65DFD57CBB651716619E084DAB9
> 
> 
> 
> In conclusion, this email is intended to be a warning to anyone who has
> that line sitting in a script, dockerfile, or worse a blog post. I would
> also like to raise the question about whether or not anything more can be
> done to alert others. Finally I would recommend updating Cran's readme to
> suggest using the full fingerprint instead of the 64-bit key like so:
> 
> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys
> E298A3A825C0D65DFD57CBB651716619E084DAB9
> 
> Thank you,
> - Kurt
> 
> 	[[alternative HTML version deleted]]
> 
> _______________________________________________
> R-SIG-Debian mailing list
> R-SIG-Debian using r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian
>