Security issues in Emacs packages

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2020-11-25 10:01]:
> 
> Jean Louis <bugs@gnu.support> writes:
> 
> > * Tim Cross <theophilusx@gmail.com> [2020-11-24 23:40]:
> >> If people are really concerned about security, they should look first at
> >> their use of repositories like MELPA. There is no formal review or
> >> analysis of packages in these repositories, yet people will happily
> >> select some package and install it.
> >
> > Interesting that you are one who mentions that. There are just few
> > people ever mentioned it.
> >
> > I am still in process of the review of MELPA packages and its
> > system. There are many security issues.
> >
> > Package signing is one example. It does not offer much of security
> > when packages are signed automatically, but it raises level of
> > security.
> >
> > MELPA packages and archive-contents are not PGP signed, while GNU ELPA
> > packages are signed.
> >
> 
> IMO signing of packages is irrelevant when there is no formal review
> process or even any formal process to verify the credentials of
> signatures. In fact, just adding signing would likely be
> coutner-productive as it would give the impression of some sort of
> security where there is none.

When user receives a signed package from GNU ELPA, that means it comes
from GNU ELPA. If signed package is then distributed by mirrors or
other websites users who enable package signature verifications will
know that package still comes from GNU ELPA, and not from Chinese
distributor. If the package is tampered the signature verification
will not allow installation of the package.

Variable package-check-signature is not enabled by default and it is
due to similar issue just as local variables.

Users who seek to verify the credential of the signatures can do so in
human non-automated way as that is also how GnuPG instructions advise
users to do so. The GPG/PGP keys are in ~/.emacs.d/elpa/gnupg/ and
users can contact GNU ELPA maintainers and verify the signature. M-x
package-install will automatically verify signatures if the option
package-check-signature has been enabled.

That it does add to security shows the fact that GNU/Linux
distributions do sign packages. There is difference if the package
comes from trusted source or not trusted source. 

> Basically, anyone can upload anything to MELPA.

Maintainers verifies the package initially for certain conventions,
after that, how I have understood it, packages are automatically
pulled from Git. The more authors give packages to MELPA the more
insecurity probability is raised.

GNU ELPA how I understand it, I may be wrong, works like this:

1) packages are uploaded to GNU ELPA
2) then automatically signed by GNU ELPA PGP keys
3) offered for distribution

The point number (1) is human, not automated. Author decides when is
the package ripe for distribution and what is "release".

Git repository is never release and not meant to be "release". Git is
for collaborative development and users are made blind that it is some
kind of release while it is not. One shall always assume that Git
repository contains development versions not ready for public.

MELPA pulls those packages, correct me if I am wrong, automatically
from Git repositories without regard if the package is actually
release. That does not align or respect the established Emacs
conventions how packages should be released, if they are multi files
they should be in .tar file otherwise .el and there are version
numbers that MELPA fiddles with and makes possible conflicts and
introduces confusions.

In GNU ELPA authors decide when package is release ready and when
it should be released.

In MELPA authors only apply for their packages to be pulled out
automatically and offered for distribution.

Both repositories could be compromised but probability is becoming
larger and larger that by automatic pulling of packages something
worse happens.

MELPA cannot know possibly who is behind authors who offer those
packages for distribution and who has access or who may do something
malicious.

Some new similar package like angry-police-captain could serve for
potential attacks.

#+TITLE: <2020-10-23 Fri 18:28>  WTF angry-police-captain
#+AUTHOR: Jean Louis
- This should scrap information from a third party unknown website and
  show it in minibuffer. Function does not work, and yes, it is just
  one function inside. Good example of nonsensical
  "packages". *Deleted*

While similar packages can be made for entertainment they can be also
used to track users and save data that should not be saved. Update to
this package would not be checked by MELPA, and users who have enabled
it would continue using it. And package could suddenly start doing
something else. Author of the package could know how many users are
using it as package is actually fetching from their website. By
fetching the information from website the website can know many things
about those users such as their locations, operating system and
versions, etc. and could invoke specific malicious stuff for those
specific users including send different information to users by their
different location or other attributes.

For that reason MELPA's automatic pulling of packages and race to
offer "large package repository" is rather by its design detrimental
for future. I hope it will change, but currently that is unlikely.

> The only way anyone would find out that an uploaded package has
> malicious code is if someone does a code review and spots the
> malicious payload. Even once they find that, there is little chance
> of being able to attribute the actions to any individual because no
> real identity vetting is conducted. MELPA is the wild west.

Thank you for saying your observation.

> The new non-GNU repository has bene setup precisely due to both the
> licensing issue and the fact many MELPA packages recommend/encourage the
> use of non-free software/services. While non-GNU will improve this
> situation, I don't believe there are any plans to actively review the
> code in the packages.

For my personal uses I am reviewing packages and constructing list of
required packages that I may use and subset of my group would use.

There also exist possibility of annotation of packages or one could
make a feedback by users so that more things can be discovered about
packages. 

> So, like MELPA, all you really have to go on is package
> reputation. You cannot have any high level of confidence a package
> does not contain malicious code other than an expectation that if it
> is used by a sufficiently large enough number of users, it is
> unlikely.

Interpreting statistics is not for everyone. It would be nice that
users give a human feedback which can be used for package reputation.

If one counts "download statistics" that is incorrect to be used for
reputation.

If let us say imaginary, a package about angry-police-captain would
contain some malicious code, then if user cannot differentiate what is
reputation and download, then number of 1000+ downloads would be quite
convincing to load the package.

Download number is now used for reputation as it is currently the only
attribute that may be obtained.

> this is not an issue unique to Emacs. You only have to look at the
> issues both Google's play store and Apples app store have had in the
> past to see what the risks are.

Of course, I know that. That is why there is no Google on any of my
mobile phones as they run LineageOS operating system. I would switch
to Replicant would I have access to supported hardware. All our
clients and staff members are warned not to use the Google.

Do you think MELPA authors would act on these comments to change
something?