GNU bug report logs - #19565
Emacs vulnerable to endless-data attack (minor)

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kelly Dean <kelly <at> prtime.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs vulnerable to endless-data attack (minor)
Date: Sun, 11 Jan 2015 11:12:00 +0000

A few days ago I speculated, but now I confirmed. It's technically considered a vulnerability, but in Emacs's case it's a minor problem; exploiting it would be more a prank than a real attack.

To demo locally for archive metadata:
echo -en 'HTTP/1.1 200 OK\r\n\r\n' > header
cat header /dev/urandom | nc -l -p 80

Then in Emacs:
(setq package-archives '(("foo" . "http://127.0.0.1/")))
M-x list-packages

Watch Emacs's memory usage grow and grow...

If you set some arbitrary limit on the size of archive-contents, then theoretically you break some legitimate ginormous elpa. And if you're getting garbage, you wouldn't know it until you've downloaded more garbage than the limit. The right way to fix it is to include the size of archive-contents in another file that can legitimately be constrained to a specified small maximum size, sign that file, and in the client, abort the archive-contents download if you get more data than you're supposed to.

The timestamp file that I proposed for fixing the metadata replay vuln (bug #19479) would be a suitable place to record the size; then no additional file (and signature) is needed just to solve endless-metadata. For the corresponding endless-data vuln for packages instead of metadata, I already put sizes in the package records in my patch for the package replay vuln.

Don't forget you need to set a maximum size not only on the timestamp file, but also on the signature file, or they would be vulnerable too. E.g. just hardcode 1kB.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.