Emacs package manager vulnerable to replay attacks

Emacs package manager vulnerable to replay attacks

[Kelly Dean]

Remove your ~/.emacs.d/elpa/ directory, and start 24.4.
Use the default of '(("gnu" . "http://elpa.gnu.org/packages/")) for package-archives.
Do M-x list-packages, which will download the archive metadata (http://elpa.gnu.org/packages/archive-contents and its sig file), verify the sig, and generate archive-contents.signed which indicates successful verification.
Then:
mkdir /tmp/localarch; cd /tmp/localarch
cp ~/.emacs.d/elpa/archives/gnu/* . # archive-contents and archive-contents.signed
wget http://elpa.gnu.org/packages/undo-tree-0.6.5.el # Currently latest in elpa
wget http://elpa.gnu.org/packages/undo-tree-0.6.5.el.sig

Now in Emacs, do (setq package-archives '(("gnu" . "/tmp/localarch/")))

Undo-tree 0.6.7 doesn't exist yet, but let's pretend that it does, and it fixes a hypothetical security vulnerability in 0.6.5, and the update has been uploaded to elpa. (Skipping 0.6.6 for this example since it does exist, just not in elpa.)

To simulate this, edit /tmp/localarch/archive-contents, find the entry for undo-tree, and change the (0 6 5) to (0 6 7). Your modified file will no longer verify with http://elpa.gnu.org/packages/archive-contents.sig, but that's ok since you already have /tmp/localarch/archive-contents.signed.

Now, to simulate a package replay attack, rename undo-tree-0.6.5.el to undo-tree-0.6.7.el, and undo-tree-0.6.5.el.sig to undo-tree-0.6.7.el.sig. Then do M-x list-packages again, then install undo-tree 0.6.7. It installs successfully, meaning you've tricked Emacs into installing the vulnerable version of the package even though archive-contents lists the fixed version.

For a live attack, first retrieve all packages and their sig files from elpa, then wait for a vulnerability to be discovered and fixed in one of them, e.g. undo-tree 0.6.5.
Allow your victim to run list-packages to download the new archive-contents (which lists the fixed undo-tree 0.6.7) and to verify it using the new archive-contents.sig.
Then when he tries to download undo-tree-0.6.7.el and undo-tree-0.6.7.el.sig, intercept his connection and give him the content of undo-tree-0.6.5.el and undo-tree-0.6.5.el.sig, so that his Emacs saves the old content using the new names.

His Emacs will successfully verify the signature because it is authentic; you retrieved authentic (but now stale) packages and signatures in your first step. His Emacs will then install the stale package because the version number embedded in the filename matches the version number specified in the new archive-contents file.

The attack also works for already-installed packages when new versions are published; you can deliver stale data when the victim tries to upgrade.

To solve the problem above, simply include a hash of the package content in the package's record in archive-contents, rather than only including the package name and version number in that file as Emacs currently does. This solution also happens to make per-package signatures from the elpa key superfluous, so you can remove that feature from Emacs and remove those signature files from elpa for the sake of simplicity, and use the elpa key only to sign the archive-contents file.
(Of course, per-commit (not just per-package) signatures from authors would still be useful, so that users don't have to trust the elpa keyholder alone, but that's a separate issue. Emacs should barf if a package hash doesn't verify, regardless of whether any signatures verify.)

Package replay attacks could be prevented without putting hashes in archive-contents, by instead verifying that the version number listed in archive-contents matches the version number listed in the package itself, if version numbers were never reused for different versions of packages. But there is at least one package (undo-tree) that does re-use version numbers, so hashes are still necessary. Hashes also prevent elpa itself from reusing version numbers; forcing elpa to issue a new archive-contents whenever it lists a new version of any package makes it more conspicuous that something changed, and making the historical record clear closes off one particular method of attack if the elpa key is compromised.

After the problem of package replay attacks is solved, you can still attack by replaying not only packages, but also the metadata (i.e. the archive-contents and archive-contents.sig files). To solve this problem, include a timestamp of archive-contents in that file itself (so that the signature depends on the timestamp), and have Emacs ignore any new archive-contents that's older than the latest valid one that Emacs has already seen or is older than some specified limit (IIRC Debian's apt-get uses a 10-day limit).

For details on replay attacks, see the 2008 publication
https://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html

Another attack is the endless-data attack; I haven't checked whether Emacs is vulnerable. See
https://www.cs.arizona.edu/stork/packagemanagersecurity/otherattacks.html
But since Emacs signs its repository metadata, it appears it is not vulnerable to any of the other attacks described on that page.

In addition to recording hashes, also record the length of the content; it's convenient for early detection of endless-data attacks and of misconfigurations.

One final feature that isn't necessary for preventing any of the vulnerabilities above, but still is helpful to make the historical record even more clear, is to include in each version of archive-contents a hash (and length) of the previous version of that file. This further constrains an attacker who has compromised the elpa key; he can still launch attacks, but it's harder to keep the attacks secret for very long, since he's forced to cause a fork in what's supposed to be a linear hash chain.

Fortunately, all four of these features (package hashes, content length, archive timestamps, and archive hash chaining) are straightforward to implement.

Re: Emacs package manager vulnerable to replay attacks

[Ivan Shmakov]

>>>>> Kelly Dean <kelly@prtime.org> writes:

[…]

 > To solve this problem, include a timestamp of archive-contents in
 > that file itself (so that the signature depends on the timestamp),
 > and have Emacs ignore any new archive-contents that's older than the
 > latest valid one that Emacs has already seen or is older than some
 > specified limit (IIRC Debian's apt-get uses a 10-day limit).

	Debian uses an explicit expiration date, as set in the InRelease
	(or Release) file.  Consider, e. g., [1]:

Date: Tue, 30 Dec 2014 08:52:15 UTC
Valid-Until: Tue, 06 Jan 2015 08:52:15 UTC

	For stable releases, Valid-Until: isn’t used (AIUI) [2]; perhaps
	then a fall back value of some kind is used.

[1] http://http.debian.net/debian/dists/jessie/InRelease
[2] http://http.debian.net/debian/dists/wheezy/InRelease

[…]

 > Fortunately, all four of these features (package hashes, content
 > length, archive timestamps, and archive hash chaining) are
 > straightforward to implement.

	Well, thanks for the heads-up, but could you please file these
	as actual Emacs bug reports, perhaps even separate ones?  I’d
	then try to suggest patches within the next few days.  (Not that
	I’m the only person who could do that, anyway.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19479: Copyright issue (was: Re: bug#19479: Package manager vulnerable)

[Kelly Dean]

[-- Attachment #1: Type: text/plain, Size: 4230 bytes --]

Stefan Monnier wrote:
>>> You're one of the very rare oddballs who can't
>>> be bothered to sign a trivial document to get this out of the way
>> That's not true. I offered to sign a document saying my work is PD.
>
> I didn't mean "a trivial document" in the sense "any trivial document",
> but rather "the particular trivial document that everybody else signed".

The FSF doesn't have just one document for contributors; it has multiples, three of which I linked to in my previous message, and at least two more that are for assignment instead of disclaimer (one for only past contributions, and one for past and future contributions).

More than two years ago, I asked the copyright clerk to send me a disclaimer form to sign. He refused. This is the _only_ reason that the FSF doesn't already have a disclaimer on file for me.

If I sign an assignment document (i.e. saying that I own intellectual property for my work and that I'm assigning that ownership to the FSF), then I would just be committing perjury, because I don't own PD works. Nothing I sign can remove anything from the public domain.

Again, please don't conflate two separate issues:
0. The FSF is refusing new PD code in Emacs. (I would be happy to learn that I'm mistaken about this.)
1. My code is PD. (In case the FSF disputes this fact, I'm attaching a signed document to establish it.)

Because the clerk refused to send me anything to sign that would establish #1 to the FSF's satisfaction, today I printed, signed, and scanned the attached document based on the disclaimer forms the FSF has published, to make it abundantly clear that my work is PD and that the FSF is free to use my work with no legal restrictions whatsoever.

I'm also CCing it to assign@gnu.org, even though at this point I assume the clerk will come up with some excuse to reject it.

If the clerk feels this doesn't make #1 clear enough, then please tell me what needs to change. Even better, send me the exact disclaimer form you want me to sign, which I asked for in the first place.

I repeat: nothing I sign can remove anything from the public domain. So nothing I sign can assign to the FSF ownership of my work; if assignment is what the FSF insists on, then it's asking for the impossible.

The attached document is to establish #1 to the FSF's satisfaction. The FSF alone has the ability to solve #0; it has nothing to do with me.

Here's the text of the attached document:

This document is derived from the following sources:
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/disclaim.manual
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/disclaim.program

I, Kelly Dean, American citizen and resident, hereby disclaim all patent, copyright, and all other forms of intellectual property ownership of and interest in all of my patches, software manuals, software programs, source code, documentation, revisions thereof, and all other works, past, present, and future, that I sent or will send to the emacs-devel@gnu.org or bug-gnu-emacs@gnu.org mailing lists, to 19479@debbugs.gnu.org, to any other mailing list or email address at gnu.org or any subdomain thereof, or to any developer or maintainer of GNU Emacs or any other GNU software, from my previous (no longer active) email address of kellydeanch@yahoo.com, my current email address of kelly@prtime.org, or any other email address.

I affirm that I have no other proprietary interest that would undermine this release, and will do nothing to undermine it in the future. I represent that all of the aforementioned works are my own and not a copy of someone else's work, except where sources are cited. Patches include citations and partial copies of the works to which the patches apply.

I created all of the works exclusively on my own time. They are not works made for hire, and there's no educational institution, employer, or any other organization or person who owns them. I do not have any agreement with any person or organization saying he or it owns programs I write, and I did not have any such agreement when I created any of the aforementioned works.

All of the works are permanently and irrevocably in the public domain.

Kelly Dean
kelly@prtime.org
January 8, 2015


[-- Attachment #2: gnu-disclaimer.pdf --]
[-- Type: application/pdf, Size: 29848 bytes --]

bug#19479: Copyright issue

[Stefan Monnier]

> 1. My code is PD. (In case the FSF disputes this fact, I'm attaching
>    a signed document to establish it.)

It can't be PD.  You're simply confused about it.  It will only be PD 75
years after your death (or something like that).  Until then, all you
can do is sign paperworks, and currently for Emacs contributions we
require this paperwork to be a copyright assignment rather than
a disclaimer.


        Stefan

Re: bug#19479: Copyright issue

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> 1. My code is PD. (In case the FSF disputes this fact, I'm attaching
>>    a signed document to establish it.)
>
> It can't be PD.  You're simply confused about it.  It will only be PD
> 75 years after your death (or something like that).

If I remember correctly, if he is living in the U.S.A. and registers a
specific work with the U.S. copyright office as being released by him
into the public domain, then the work will indeed be in the public
domain within the U.S.A.  We need to bother with more than the U.S.A.,
however, and one can only register specific works which means it is not
possible to register them before they are even created.

-- 
David Kastrup

Re: Copyright issue

[Kelly Dean]

Stefan Monnier wrote:
>> 1. My code is PD. (In case the FSF disputes this fact, I'm attaching
>>    a signed document to establish it.)
>
> It can't be PD.  You're simply confused about it.  It will only be PD 75
> years after your death (or something like that).  Until then, all you
> can do is sign paperworks, and currently for Emacs contributions we
> require this paperwork to be a copyright assignment rather than
> a disclaimer.

GNU's own website says it can be PD. The documents at the three links I sent you start with:
⌜I'd like to ask you to sign a disclaimer for the manual, thus putting it in the public domain.⌝
⌜I'd like to ask you to sign a disclaimer for the program, thus putting it in the public domain.⌝
⌜I'd like to ask you to sign a disclaimer for your changes, thus putting them in the public domain.⌝

Notice the ⌜thus putting them in the public domain⌝.

Also, do you claim that SQLite is not PD? The author, Richard Hipp, says it's PD, and the many millions of users of SQLite, including many major companies with lots of copyright lawyers, accept the legal fact that it's PD. And Richard Hipp is not dead.

Also, do you claim that feedmail.el is not PD? The first lines of it are:
;;; feedmail.el --- assist other email packages to massage outgoing messages
;;; This file is in the public domain.

;; This file is part of GNU Emacs.

Re: bug#19479: Copyright issue

[Glenn Morris]

I must say, that it was not my impression that disclaimers were not
accaptable for Emacs. Only that the FSF does not offer a "past and
future" option for disclaimers like it does for assignments, so a new
disclaimer would have to be completed for every new change. I thought
this was not worth bothering with, so I advised you not to send more patches.

But I certainly don't know, I just go with whatever assign@gnu says.

I don't see much point discussing this on emacs-devel. None of us are
lawyers so our opinions are pretty irrelevant. We need to wait and see
what assign@gnu says.

Re: bug#19479: Copyright issue

[Glenn Morris]

Glenn Morris wrote:

> I must say, that it was not my impression that disclaimers were not
> accaptable for Emacs. Only that the FSF does not offer a "past and
> future" option for disclaimers like it does for assignments, so a new
> disclaimer would have to be completed for every new change. I thought
> this was not worth bothering with, so I advised you not to send more patches.

PS but yes, for a non-trivial security issue like 19479 it did seem
worth it to me, so I was on the verge of saying, would you be willing to
complete a disclaimer for this change. But then Stefan said disclaimers
were not viable, so I didn't bother to say it.

Re: Emacs package manager vulnerable to replay attacks

[Kelly Dean]

Note, I'm not implementing the metadata-replay fix, because it's unlikely my patch would be accepted, so somebody else will need to do it. See my January 11th message to bug #19479 for a description of how to do it.

Re: bug#19479: Disclaimer is now on file at FSF

[Glenn Morris]

So, I don't want to get into this discussion, but I've always assumed
that disclaimers do not/cannot apply to future changes. I asked
assign@gnu.org, and they confirmed "Disclaimers are not valid for future
contributions".

I mention this because AFAICS you are sending new patches.

Your disclaimer is dated 2015-1-8. AFAICS we cannot apply anything after
that. Someone should also check the several patches from you that have
been applied recently to make sure they originated before this date.

Sorry, I don't have time/inclination to discuss special cases.
Maybe you want to take it up with rms and/or assign@gnu.

Re: bug#19479: Disclaimer is now on file at FSF

[Kelly Dean]

> So, I don't want to get into this discussion,

And yet you chose to dig it back up, even after everybody else was satisfied that it was resolved more than a month ago. The copyright clerk's exact words on January 20th were, ‟We've accepted the public domain disclaimer and added you to our records”, not ‟we've accepted part of the disclaimer, but rejected another part”.

The disclaimer covers future changes, and everybody's comments about that part had already been CCed to the clerk, and his answer was, ‟We've accepted the public domain disclaimer”.

> but I've always assumed
> that disclaimers do not/cannot apply to future changes. I asked
> assign@gnu.org, and they confirmed "Disclaimers are not valid for future
> contributions".

Good luck finding a copyright judge anywhere in America who would agree with your absurd claim that my work since January 8th is not in the public domain, despite my signed statement that it is.

Or if you admit it is PD, I'm sure you can dream up some rationalization of why PD code isn't allowed in Emacs, and then try to remove it all, which is a lot more than just my code.

Either way, I'm done trying to work on Emacs. This B.S. isn't worth my time.

Re: bug#19479: Disclaimer is now on file at FSF

[Vibhav Pant]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On 24 Feb 2015 23:41, "Glenn Morris" <rgm@gnu.org> wrote:
>
>
> So, I don't want to get into this discussion, but I've always assumed
> that disclaimers do not/cannot apply to future changes. I asked
> assign@gnu.org, and they confirmed "Disclaimers are not valid for future
> contributions".
Well, what about
http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future?
This is the form to request documents for assigning past and future works,
which according to you     isn't possible.

[-- Attachment #2: Type: text/html, Size: 800 bytes --]

Re: bug#19479: Disclaimer is now on file at FSF

[Stephen J. Turnbull]

Vibhav Pant writes:

 > This is the form to request documents for assigning past and future
 > works, which according to you isn't possible.

The point is that copyright assignment is a *contract* involving "good
and valuable consideration" from the recipient of the assignment.  On
the other hand, a *disclaimer* is a one-sided act by the copyright
holder, and legally has a different character.

I am not familiar with the legislation and case law, so I can't say
whether the law actually treats assignment and disclaimer differently
in this respect.  But I assure you that theoretically it could, since
assignment is governed by contract law, while disclaimer is purely a
matter of copyright.

Re: bug#19479: Disclaimer is now on file at FSF

[Glenn Morris]

Kelly Dean wrote:

>> So, I don't want to get into this discussion,
>
> And yet you chose to dig it back up, even after everybody else was
> satisfied that it was resolved more than a month ago.

I've been largely on a break from Emacs. I always thought there was
something strange here, and I just happened to get motivated enough now
to ask assign@gnu for clarification when I saw patches were still arriving.

> The copyright clerk's exact words on January 20th were, ‟We've
> accepted the public domain disclaimer and added you to our records",
> not ‟we've accepted part of the disclaimer, but rejected another
> part".

I specifically mentioned you by name in the question I asked assign@gnu,
and the reply I got (one day ago) was, in totality:

   Disclaimers are not valid for future contributions. Thanks for checking in.

Like I said, you can take it up with them if you disagree.
I'be glad to be corrected, but it all seems pretty clear to me.

I am not trying to be the bad guy and I am not out to get you.
I applied several patches from you and would have been happy to apply more.
I am just trying to ensure Emacs follows the FSF's procedures,
which seem pretty clear to me.


Vibhav Pant wrote:

> Well, what about
> http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future?
> This is the form to request documents for assigning past and future
> works, which according to you isn't possible.

That's not what I said.
I said: I am told *disclaimers* cannot apply to future changes.

You will note that there are separate documents for *assigning* past
changes (request-assign.changes), and past-and-future changes
(request-assign.future). But for *disclaimers* there is only
request-disclaim.changes. There is no request-disclaim.future.
If you read

http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-disclaim.changes

it quite clearly states that it only applies to past, finished changes.

I am not a lawyer (AFAIK, neither is anyone else on this list) and
have no interest in discussing why these things are different.
They just are.

I said the first time we went through this that it was my
understanding that disclaimers worked this way. I said it again here:
https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00198.html

I have now had this confirmed by assign@gnu.


If you (the generic you) want to contribute to Emacs, there is a
well-defined, simple procedure that hundreds of people have followed
with no problem.

If you don't want to follow the procedure, then fine, that's your
prerogative. Then you can't contribute.

But please don't start arguing with us about what the procedure is, or
should be, or what you think a judge might say, or why you need to be an
exception. We don't set the rules here at Emacs, and it just isn't a
productive use of anyone's time.

bug#19479: Disclaimer is now on file at FSF

[Eli Zaretskii]

unblock 24655 by 19479
thanks

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 25 Feb 2015 16:09:57 -0500
> Cc: 19479@debbugs.gnu.org, emacs-devel@gnu.org
> 
> I am not a lawyer (AFAIK, neither is anyone else on this list) and
> have no interest in discussing why these things are different.
> They just are.
> 
> I said the first time we went through this that it was my
> understanding that disclaimers worked this way. I said it again here:
> https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00198.html
> 
> I have now had this confirmed by assign@gnu.
> 
> 
> If you (the generic you) want to contribute to Emacs, there is a
> well-defined, simple procedure that hundreds of people have followed
> with no problem.
> 
> If you don't want to follow the procedure, then fine, that's your
> prerogative. Then you can't contribute.
> 
> But please don't start arguing with us about what the procedure is, or
> should be, or what you think a judge might say, or why you need to be an
> exception. We don't set the rules here at Emacs, and it just isn't a
> productive use of anyone's time.

Two and a half years later, with no one complaining about this, it
doesn't sound right for this issue to block the release of Emacs 26.1.