From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#19565: Emacs vulnerable to endless-data attack (minor) Date: Sun, 6 Oct 2019 05:13:27 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="171197"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 19565@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 06 05:14:12 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iGwzr-000iPb-8Y for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Oct 2019 05:14:11 +0200 Original-Received: from localhost ([::1]:59928 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGwzp-0000dp-HL for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Oct 2019 23:14:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46948) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iGwzj-0000dj-89 for bug-gnu-emacs@gnu.org; Sat, 05 Oct 2019 23:14:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iGwzi-0006gd-4G for bug-gnu-emacs@gnu.org; Sat, 05 Oct 2019 23:14:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36600) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iGwzi-0006gZ-0f for bug-gnu-emacs@gnu.org; Sat, 05 Oct 2019 23:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iGwzh-0007l3-PA for bug-gnu-emacs@gnu.org; Sat, 05 Oct 2019 23:14:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Oct 2019 03:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19565 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 19565-submit@debbugs.gnu.org id=B19565.157033163329796 (code B ref 19565); Sun, 06 Oct 2019 03:14:01 +0000 Original-Received: (at 19565) by debbugs.gnu.org; 6 Oct 2019 03:13:53 +0000 Original-Received: from localhost ([127.0.0.1]:45421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iGwzZ-0007kW-AD for submit@debbugs.gnu.org; Sat, 05 Oct 2019 23:13:53 -0400 Original-Received: from mail-pf1-f178.google.com ([209.85.210.178]:40827) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iGwzQ-0007k8-Dr for 19565@debbugs.gnu.org; Sat, 05 Oct 2019 23:13:51 -0400 Original-Received: by mail-pf1-f178.google.com with SMTP id x127so6298389pfb.7 for <19565@debbugs.gnu.org>; Sat, 05 Oct 2019 20:13:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=cVCKHJgKUNMjwLgeJp+kj7cbEFBtRI2B77Ezb+x9zKk=; b=t2gOIsqquIae4Zz9Eq0e2t2lIJi31sSIEIs32KQ5cRLnfX2I8Kz+4f3zZGsSI6iiuK TEp7DYBzIH/eXEPVvy5iWeoO87mM4oNm6vUTMhp6AcGuw8GfO7kKqv5A+lnWV6ipGBI9 2tZhenHcxnYpNCExxo97EOI+yxsESxSEc6AaSCM/Ssfj8RK4qTejiP0DNqI5yj/srUFI y8AqeMpAej6olM76oKMFGJIe7EyM9pgpEjh84exQXJDGjpXTjrwlFVQJPlSwGMAGpD0+ K9BQAeapdSlSx3t5VyhGLc2dEbW6qW5c3iFt9P1Xg4NqcRrXnw8NhgSyTwyzeSJvGF+d 7/Rg== X-Gm-Message-State: APjAAAXu8HADzbzjivbUr9zFH30EZ3yMo83UUVzybf05D+IU8lcP4QR3 iUYh12ZsvxlAPzZHqep3/Mjmyyybnk/kG/4fPeM= X-Google-Smtp-Source: APXvYqxBowy186hNLQJYnY1SBm5EMiLjenmd6prYhd3ZCPd4BezUn9QArgAi/uUnpHuvhEzKSsWJVZQCiULY5R6MshY= X-Received: by 2002:a62:e917:: with SMTP id j23mr25745085pfh.50.1570331618693; Sat, 05 Oct 2019 20:13:38 -0700 (PDT) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:168411 Archived-At: Kelly Dean writes: > 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. I think this affects more than just package.el. AFAICT, anywhere we use the url library, an endless data attack can get Emacs to fill up all available memory (wasting also bandwidth resources, of course). Lars, perhaps we could add code to handle this in with-fetched-url? For example, a new keyword argument :max-size, which would make it stop after having reached that many bytes. IMO, it would be even better if this was set to some arbitrarily chosen high value by default, like 256 MiB or something, so that this protection is on unless explicitly turned off with nil. Best regards, Stefan Kangas