From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kelly Dean Newsgroups: gmane.emacs.bugs Subject: bug#19565: Emacs vulnerable to endless-data attack (minor) Date: Sun, 11 Jan 2015 11:12:00 +0000 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1420974861 13703 80.91.229.3 (11 Jan 2015 11:14:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Jan 2015 11:14:21 +0000 (UTC) To: 19565@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 11 12:14:14 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YAGTE-0005dx-0q for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Jan 2015 12:14:12 +0100 Original-Received: from localhost ([::1]:57963 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAGTD-0008AZ-6g for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Jan 2015 06:14:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAGT9-00087L-VP for bug-gnu-emacs@gnu.org; Sun, 11 Jan 2015 06:14:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAGT4-0007zp-TX for bug-gnu-emacs@gnu.org; Sun, 11 Jan 2015 06:14:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAGT4-0007zl-Qc for bug-gnu-emacs@gnu.org; Sun, 11 Jan 2015 06:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YAGT4-0006a7-I2 for bug-gnu-emacs@gnu.org; Sun, 11 Jan 2015 06:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Kelly Dean Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Jan 2015 11:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 19565 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.142097478325204 (code B ref -1); Sun, 11 Jan 2015 11:14:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 11 Jan 2015 11:13:03 +0000 Original-Received: from localhost ([127.0.0.1]:42393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YAGS7-0006YR-1J for submit@debbugs.gnu.org; Sun, 11 Jan 2015 06:13:03 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:53848) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YAGS4-0006Y2-OI for submit@debbugs.gnu.org; Sun, 11 Jan 2015 06:13:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAGS3-0007WY-49 for submit@debbugs.gnu.org; Sun, 11 Jan 2015 06:13:00 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:47428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAGS3-0007WU-11 for submit@debbugs.gnu.org; Sun, 11 Jan 2015 06:12:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAGS1-0007dA-RJ for bug-gnu-emacs@gnu.org; Sun, 11 Jan 2015 06:12:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAGRw-0007Pk-LT for bug-gnu-emacs@gnu.org; Sun, 11 Jan 2015 06:12:57 -0500 Original-Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:43285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAGRw-0007Pa-FO for bug-gnu-emacs@gnu.org; Sun, 11 Jan 2015 06:12:52 -0500 Original-Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id AB817172070 for ; Sun, 11 Jan 2015 12:12:51 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Original-Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Ta6gEpVNEc4m for ; Sun, 11 Jan 2015 12:12:50 +0100 (CET) X-Originating-IP: 66.220.3.179 Original-Received: from localhost (gm179.geneticmail.com [66.220.3.179]) (Authenticated sender: kelly@prtime.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 254F617207C for ; Sun, 11 Jan 2015 12:12:48 +0100 (CET) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:98222 Archived-At: 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.