bug#19479: Package manager vulnerable

[Kelly Dean]

Stefan Monnier wrote:
> AFAICT, this vulnerability also applies to the way GNU packages are
> distributed in ftp.gnu.org (i.e. as a tarball plus a .sig file).
>
> Is that right?

Yes, because there are no hashes in, or signatures on, 
http://ftp.gnu.org/find.txt.gz or http://ftp.gnu.org/ls-lrRt.txt.gz

They used to do it right; see
http://ftp.gnu.org/before-2003-08-01.md5sums.asc

But it looks like they stopped.

Having to redo a huge monolithic metadata file whenever any data file changes 
is inefficient; it's more efficient for the metadata for each directory to just 
have the hash of each file in the directory and the hash of the metadata of 
each subdirectory, like Git does. But either way will prevent package replay 
attacks.

>> Executive summary to fix the vulnerabilities:
>
> Another way to attack the problem is to include the file name along with
> its content in "the thing that gets signed".
> I.e. the signature shouldn't apply to the output of "cat <foo>" but to
> the output of "echo <foo>; cat <foo>".
>
> This way an attacker can't take <vulnerable>.tar along with
> <vulnerable>.tar.sig and send them off as <safe>.tar along with
> <safe>.tar.sig.

If filenames include version numbers and the version numbers are never reused, 
then your solution does prevent package replay attacks. Since Emacs packages 
already include a Version header (and the package name), you could actually do 
your proposed verification using that header, without changing the way 
signatures are currently made, which is a solution I addressed in my original 
emacs-devel message.

But having a list of hashes of all the packages (and even better, chaining 
together all the versions of that list) makes changes to any package more 
conspicuous, which makes the attacker's job harder, as I explained. And if you 
do that, then the elpa key no longer needs to sign individual packages at all. 
Git, Fossil, and Debian's apt-get use hash lists, and Git and Fossil also chain 
together the lists, so there's good precedence. Both are simple to do for 
Emacs: in the archive-contents file, include the hash of each package and the 
hash of the previous version of archive-contents.

But remember, none of the above prevents metadata replay attacks. If the user 
himself is specifying the metadata (e.g. you manually request Emacs 24.4 
because you know that's the latest version), then verification to prevent 
metadata replay attacks isn't the computer's job. But when the user just says 
to update some package(s) to the latest version, without specifying the 
version, then it is the computer's job. For this, put a timestamp of the 
archive-contents file into the file itself.