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

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Kelly Dean <kelly@HIDDEN>; Keywords: security; dated Sun, 11 Jan 2015 11:14:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 17:22:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 08 13:22:14 2019
Received: from localhost ([127.0.0.1]:51427 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHtBd-0003rm-LT
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 13:22:13 -0400
Received: from eggs.gnu.org ([209.51.188.92]:40699)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1iHtBc-0003rZ-Pg
 for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 13:22:13 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:47247)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1iHtBV-0004SY-Q9; Tue, 08 Oct 2019 13:22:07 -0400
Received: from [176.228.60.248] (port=2473 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1iHtBU-0000tA-Uk; Tue, 08 Oct 2019 13:22:05 -0400
Date: Tue, 08 Oct 2019 20:22:02 +0300
Message-Id: <83tv8jw3t1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Kangas <stefan@HIDDEN>
In-reply-to: <CADwFkmnP4+c=o5B5eQ9hVtOciURv_tsKBTTC3=JJzrVMv8K=8A@HIDDEN>
 (message from Stefan Kangas on Tue, 8 Oct 2019 18:50:22 +0200)
Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN> <831rvo1qlk.fsf@HIDDEN>
 <87zhibyzh8.fsf@HIDDEN>
 <CADwFkmnP4+c=o5B5eQ9hVtOciURv_tsKBTTC3=JJzrVMv8K=8A@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 19565
Cc: larsi@HIDDEN, 19565 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Kangas <stefan@HIDDEN>
> Date: Tue, 8 Oct 2019 18:50:22 +0200
> Cc: Eli Zaretskii <eliz@HIDDEN>, 19565 <at> debbugs.gnu.org
> 
> Lars Ingebrigtsen <larsi@HIDDEN> writes:
> 
> > So bytes/sec, as you suggest, may be the best heuristic.  But it should
> > only kick in after having received a large number of bytes, probably.
> 
> Maybe this is a stupid question, but what if I'm on a slow connection?

Please define "slow" in terms of bytes/sec.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 16:50:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 08 12:50:42 2019
Received: from localhost ([127.0.0.1]:51391 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHsh7-0000zI-RF
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:50:42 -0400
Received: from mail-pg1-f179.google.com ([209.85.215.179]:38394)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1iHsh5-0000z4-LC
 for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:50:39 -0400
Received: by mail-pg1-f179.google.com with SMTP id x10so10561992pgi.5
 for <19565 <at> debbugs.gnu.org>; Tue, 08 Oct 2019 09:50:39 -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:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=Tgr6jf8dpCM9V5gjAaAqYly3gWMIgw0+qhReVOepk2A=;
 b=X1ptRFUDvdUOD4ZpGX603XCLuqntz8sUWGmThjzYHIjY0VRzs1jWmVWWsO4KFAWx/4
 Ki6spizXB8svnJboI29pvVhIKO3WtKuL54UtcKGE92BcsQTUqu1awC+v5m/Cj/7dlkL5
 /Hhv66bqi+bb1J00XXlDcQIYWuyf0e5xjDPBYWiB4rYsJv7LjgXjD+72NR/gXfBcr+CU
 ZrQjzpS+hTqfTiwcB3UXosq4nON1Kn3EkdQwdaZ3JFxkoJhvIwuIvzqe/wnQU1pY84zZ
 V/wGllc3i6+GNCpTbvED/CgPL50jePBaL2b23EuoPr5OzrStmr0K5H/h+d655obDavcJ
 YgkQ==
X-Gm-Message-State: APjAAAU0crqlf7xRcgzaARWTQH7UAMUDD6xfI6dUel4TQrMAJ76SX0X+
 oODHgH2cDzDqDRDjjHHQ7CpezFuGhTQ4BHLZCGs=
X-Google-Smtp-Source: APXvYqyN/i9d8+6p/wKutkj2BlE5Als7kXaKLh+JhPLayQTyWO0UF4o0CoenGZd9qJ428DNOhnEakSm0v1Cz15kViUU=
X-Received: by 2002:a63:1310:: with SMTP id i16mr34861166pgl.200.1570553433663; 
 Tue, 08 Oct 2019 09:50:33 -0700 (PDT)
MIME-Version: 1.0
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN> <831rvo1qlk.fsf@HIDDEN>
 <87zhibyzh8.fsf@HIDDEN>
In-Reply-To: <87zhibyzh8.fsf@HIDDEN>
From: Stefan Kangas <stefan@HIDDEN>
Date: Tue, 8 Oct 2019 18:50:22 +0200
Message-ID: <CADwFkmnP4+c=o5B5eQ9hVtOciURv_tsKBTTC3=JJzrVMv8K=8A@HIDDEN>
Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor)
To: Lars Ingebrigtsen <larsi@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 19565
Cc: Eli Zaretskii <eliz@HIDDEN>, 19565 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Lars Ingebrigtsen <larsi@HIDDEN> writes:

> So bytes/sec, as you suggest, may be the best heuristic.  But it should
> only kick in after having received a large number of bytes, probably.

Maybe this is a stupid question, but what if I'm on a slow connection?
 Then I would never hit the max?  Emacs does have users also in areas
of the world where the connections are generally slow, but where AFAIK
in addition to that they may have to pay for data.  Also consider the
use case of a user from the developed world currently on data roaming,
with a maximum of 100 MiB of free data...

I'm not against the bytes/sec idea, and maybe I don't understand it
well enough, but I also think there is a case for being able to
specify a maximum number of bytes for a particular connection.  For
example, the "archive-contents" file is never that big unless
something is seriously wrong.  The MELPA "archive-contents" file is
probably one of the biggest examples in use today and currently weighs
in at 1,433,186 bytes.  This means that a maximum of, say, 128 MiB
should be extremely generous in this case, also allowing for it to
grow quite a lot in the next decade or so.

Best regards,
Stefan Kangas




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 16:48:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 08 12:48:12 2019
Received: from localhost ([127.0.0.1]:51387 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHsei-0000vO-Aa
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:48:12 -0400
Received: from eggs.gnu.org ([209.51.188.92]:35937)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1iHseg-0000v9-Fx
 for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:48:10 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:46735)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1iHseY-0004EC-42; Tue, 08 Oct 2019 12:48:03 -0400
Received: from [176.228.60.248] (port=4378 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1iHseR-0006C5-VQ; Tue, 08 Oct 2019 12:47:59 -0400
Date: Tue, 08 Oct 2019 19:47:54 +0300
Message-Id: <83wodfw5dx.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
In-reply-to: <87zhibyzh8.fsf@HIDDEN> (message from Lars Ingebrigtsen on Tue, 
 08 Oct 2019 18:27:15 +0200)
Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN>
 <831rvo1qlk.fsf@HIDDEN> <87zhibyzh8.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 19565
Cc: stefan@HIDDEN, 19565 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Lars Ingebrigtsen <larsi@HIDDEN>
> Cc: stefan@HIDDEN,  19565 <at> debbugs.gnu.org
> Date: Tue, 08 Oct 2019 18:27:15 +0200
> 
> So bytes/sec, as you suggest, may be the best heuristic.  But it should
> only kick in after having received a large number of bytes, probably.

Yes, I agree.  So maybe make it kick in once the process buffer is
large enough?  And even here we will need to consider, say, shell and
term.el buffers, which could grow quite large.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 16:27:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 08 12:27:22 2019
Received: from localhost ([127.0.0.1]:51323 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHsKY-0006iG-F3
	for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:27:22 -0400
Received: from quimby.gnus.org ([80.91.231.51]:39376)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1iHsKW-0006i8-A4
 for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 12:27:21 -0400
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie)
 by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <larsi@HIDDEN>)
 id 1iHsKS-0007M0-7U; Tue, 08 Oct 2019 18:27:18 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN>
 <831rvo1qlk.fsf@HIDDEN>
Date: Tue, 08 Oct 2019 18:27:15 +0200
In-Reply-To: <831rvo1qlk.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 07 Oct
 2019 19:13:11 +0300")
Message-ID: <87zhibyzh8.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Eli Zaretskii <eliz@HIDDEN> writes: > I think this must be
 in terms of bytes/sec, not just bytes. E.g., I > have a spell-checker active
 during my entire Emacs session (which > could go on for weeks and months
 on end), and I don't want t [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 19565
Cc: stefan@HIDDEN, 19565 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

> I think this must be in terms of bytes/sec, not just bytes.  E.g., I
> have a spell-checker active during my entire Emacs session (which
> could go on for weeks and months on end), and I don't want to get a
> prompt just because the number of bytes that went in that pipe becomes
> above the threshold.  We may also need to measure the growth of the
> Emacs memory footprint during that time, because if Emacs reads bytes
> and discards them, it isn't going to be a problem, right?

Yeah, that's true -- a counter wouldn't help at all here.

Would checking the size of the `process-buffer' of the process be more
helpful?  It might be a somewhat unnatural thing to do -- Emacs doesn't
give you a warning if you say

(dotimes (i 100000000) (insert (make-string 80 ?a)))

so perhaps that's not a good heuristic, either.

So bytes/sec, as you suggest, may be the best heuristic.  But it should
only kick in after having received a large number of bytes, probably.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 7 Oct 2019 16:13:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 07 12:13:31 2019
Received: from localhost ([127.0.0.1]:48965 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHVdb-0004ea-7o
	for submit <at> debbugs.gnu.org; Mon, 07 Oct 2019 12:13:31 -0400
Received: from eggs.gnu.org ([209.51.188.92]:47569)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1iHVdY-0004eM-JX
 for 19565 <at> debbugs.gnu.org; Mon, 07 Oct 2019 12:13:29 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:53100)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1iHVdT-0001q4-4x; Mon, 07 Oct 2019 12:13:23 -0400
Received: from [176.228.60.248] (port=4915 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1iHVdO-0008M7-6u; Mon, 07 Oct 2019 12:13:20 -0400
Date: Mon, 07 Oct 2019 19:13:11 +0300
Message-Id: <831rvo1qlk.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Lars Ingebrigtsen <larsi@HIDDEN>
In-reply-to: <874l0le314.fsf@HIDDEN> (message from Lars Ingebrigtsen on Mon, 
 07 Oct 2019 03:51:35 +0200)
Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 19565
Cc: stefan@HIDDEN, 19565 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Lars Ingebrigtsen <larsi@HIDDEN>
> Cc: Stefan Kangas <stefan@HIDDEN>,  19565 <at> debbugs.gnu.org
> Date: Mon, 07 Oct 2019 03:51:35 +0200
> 
> I think it would perhaps make some sense to warn (or query) the user if
> you get more data than `large-file-warning-threshold'.  I think it would
> be pretty trivial to implement -- at least in the new with-fetched-url
> interface, which I think is where this pretty theoretical problem is
> least theoretical, perhaps?
> 
> On the other hand, I could see that in some ways it would be easier to
> implement in wait_reading_process_output: We could just maintain a byte
> counter in the process objects (if we don't do that already) and have a
> callback we call if that counter grows larger than
> `large-file-warning-threshold'.

I think this must be in terms of bytes/sec, not just bytes.  E.g., I
have a spell-checker active during my entire Emacs session (which
could go on for weeks and months on end), and I don't want to get a
prompt just because the number of bytes that went in that pipe becomes
above the threshold.  We may also need to measure the growth of the
Emacs memory footprint during that time, because if Emacs reads bytes
and discards them, it isn't going to be a problem, right?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 7 Oct 2019 12:51:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 07 08:51:01 2019
Received: from localhost ([127.0.0.1]:47455 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHSTd-0007yY-Du
	for submit <at> debbugs.gnu.org; Mon, 07 Oct 2019 08:51:01 -0400
Received: from mail-pl1-f172.google.com ([209.85.214.172]:44944)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1iHSTa-0007yF-QN
 for 19565 <at> debbugs.gnu.org; Mon, 07 Oct 2019 08:50:59 -0400
Received: by mail-pl1-f172.google.com with SMTP id q15so6807443pll.11
 for <19565 <at> debbugs.gnu.org>; Mon, 07 Oct 2019 05:50:58 -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:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=B/99XR5MTyBZGSZPFZ2DXiEoRXS2qCqMMGm/XtgyHFQ=;
 b=IxDjsyGoUz+JKfphVpooZ0tmLPd4Wfg2VW4BPhHmFPDvDG7azq5WyGZ4yHAN0ySeaL
 W8qSbfEj5HULS0ZSMs4rrKtD5/dCP7DK4XrZjfuGipcYRIRRHATh6PMTGny1W67JgFOn
 Q1yK3EuaBuxgGbk8+eQYcQa0Xu2qlKGTxjGLEmINAvsy2PPSWof6ZD81o9JHmbW3+cOF
 0/LdtKegyH6ikggCXa4KnNZRjMVazTefun6uJlB9v9rMpNVCS081R/+jnhxv6wSOYLp3
 T7n1y6OO6kJzRCuHI3jimH+eoY0Xc5OBINgpOsFj9ZS8UiZuNpXVC+RMB30t9YubZB21
 ZtOg==
X-Gm-Message-State: APjAAAUVjIYHyXwqeuczHDPh6nUZNQRJShUr6z2ift8VmrZSFOu+gCNx
 GC1jH6Epzv+9d3KpOaHsYtx+ivbJBm/do8yBJs8=
X-Google-Smtp-Source: APXvYqz7ZDi+h8MjZNW1387veNdrhwA1LjENbGkM7O8jrwCMxX58UGk+72Tlv23+LmjCfbBecOI40MpXLh+h4WjCqTM=
X-Received: by 2002:a17:902:326:: with SMTP id
 35mr30189600pld.128.1570452652980; 
 Mon, 07 Oct 2019 05:50:52 -0700 (PDT)
MIME-Version: 1.0
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN>
In-Reply-To: <874l0le314.fsf@HIDDEN>
From: Stefan Kangas <stefan@HIDDEN>
Date: Mon, 7 Oct 2019 14:50:41 +0200
Message-ID: <CADwFkmn4-ZfxyacpZua7fjE4P0dM_MKbTGPJjmK0rfrVgejRGw@HIDDEN>
Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor)
To: Lars Ingebrigtsen <larsi@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 19565
Cc: Eli Zaretskii <eliz@HIDDEN>, 19565 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Lars Ingebrigtsen <larsi@HIDDEN> writes:

> It's not something we have to do, but it would be nice to have some
> protection against this.

This is my view, too.  And don't we usually treat a potential crash as
a bug to be fixed?

> I think it would perhaps make some sense to warn (or query) the user if
> you get more data than `large-file-warning-threshold'.  I think it would
> be pretty trivial to implement -- at least in the new with-fetched-url
> interface, which I think is where this pretty theoretical problem is
> least theoretical, perhaps?

Not sure if it's practical, but perhaps we could initialize the
threshold depending on the available memory.

> On the other hand, I could see that in some ways it would be easier to
> implement in wait_reading_process_output: We could just maintain a byte
> counter in the process objects (if we don't do that already) and have a
> callback we call if that counter grows larger than
> `large-file-warning-threshold'.
>
> That way Emacs wouldn't be open to flooding from, say, rogue SMTP
> servers, either.

If we can have a more general protection, that would be even better,
in my view.  Are there any drawbacks to such a solution?

Best regards,
Stefan Kangas




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 7 Oct 2019 01:51:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 06 21:51:42 2019
Received: from localhost ([127.0.0.1]:47041 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHIBa-0002kb-JB
	for submit <at> debbugs.gnu.org; Sun, 06 Oct 2019 21:51:42 -0400
Received: from quimby.gnus.org ([80.91.231.51]:53178)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1iHIBY-0002kS-M7
 for 19565 <at> debbugs.gnu.org; Sun, 06 Oct 2019 21:51:41 -0400
Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie)
 by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <larsi@HIDDEN>)
 id 1iHIBT-0003uP-M7; Mon, 07 Oct 2019 03:51:38 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 <83a7ad3hlf.fsf@HIDDEN>
Date: Mon, 07 Oct 2019 03:51:35 +0200
In-Reply-To: <83a7ad3hlf.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 06 Oct
 2019 20:32:28 +0300")
Message-ID: <874l0le314.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Eli Zaretskii <eliz@HIDDEN> writes: >> 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 [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 19565
Cc: Stefan Kangas <stefan@HIDDEN>, 19565 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> 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).
>
> At which point the system will kill the Emacs process.  Why is that a
> problem we need to work, given that we already have at least some
> protection against stack overflows and running out of memory?

It's not something we have to do, but it would be nice to have some
protection against this.

>> For example, a new keyword argument :max-size, which would make it
>> stop after having reached that many bytes.
>
> The Gnu Coding Standards frown on having arbitrary limits in a
> program.  So this could only work if we had some reasonable way of
> computing a limit that is not arbitrary.

I think it would perhaps make some sense to warn (or query) the user if
you get more data than `large-file-warning-threshold'.  I think it would
be pretty trivial to implement -- at least in the new with-fetched-url
interface, which I think is where this pretty theoretical problem is
least theoretical, perhaps?

On the other hand, I could see that in some ways it would be easier to
implement in wait_reading_process_output: We could just maintain a byte
counter in the process objects (if we don't do that already) and have a
callback we call if that counter grows larger than
`large-file-warning-threshold'.

That way Emacs wouldn't be open to flooding from, say, rogue SMTP
servers, either.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 6 Oct 2019 17:32:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 06 13:32:48 2019
Received: from localhost ([127.0.0.1]:46789 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iHAOm-00087d-72
	for submit <at> debbugs.gnu.org; Sun, 06 Oct 2019 13:32:48 -0400
Received: from eggs.gnu.org ([209.51.188.92]:57677)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1iHAOk-00087M-6I
 for 19565 <at> debbugs.gnu.org; Sun, 06 Oct 2019 13:32:46 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60541)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1iHAOe-0007ob-Vz; Sun, 06 Oct 2019 13:32:41 -0400
Received: from [176.228.60.248] (port=1761 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1iHAOd-00052N-Ti; Sun, 06 Oct 2019 13:32:40 -0400
Date: Sun, 06 Oct 2019 20:32:28 +0300
Message-Id: <83a7ad3hlf.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Kangas <stefan@HIDDEN>
In-reply-to: <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
 (message from Stefan Kangas on Sun, 6 Oct 2019 05:13:27 +0200)
Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
 <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 19565
Cc: larsi@HIDDEN, 19565 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Kangas <stefan@HIDDEN>
> Date: Sun, 6 Oct 2019 05:13:27 +0200
> Cc: 19565 <at> debbugs.gnu.org
> 
> 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).

At which point the system will kill the Emacs process.  Why is that a
problem we need to work, given that we already have at least some
protection against stack overflows and running out of memory?

> For example, a new keyword argument :max-size, which would make it
> stop after having reached that many bytes.

The Gnu Coding Standards frown on having arbitrary limits in a
program.  So this could only work if we had some reasonable way of
computing a limit that is not arbitrary.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 6 Oct 2019 03:13:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 05 23:13:53 2019
Received: from localhost ([127.0.0.1]:45421 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iGwzZ-0007kW-AD
	for submit <at> debbugs.gnu.org; Sat, 05 Oct 2019 23:13:53 -0400
Received: from mail-pf1-f178.google.com ([209.85.210.178]:40827)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1iGwzQ-0007k8-Dr
 for 19565 <at> debbugs.gnu.org; Sat, 05 Oct 2019 23:13:51 -0400
Received: by mail-pf1-f178.google.com with SMTP id x127so6298389pfb.7
 for <19565 <at> 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)
MIME-Version: 1.0
From: Stefan Kangas <stefan@HIDDEN>
Date: Sun, 6 Oct 2019 05:13:27 +0200
Message-ID: <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN>
Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor)
To: Lars Ingebrigtsen <larsi@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 19565
Cc: 19565 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Kelly Dean <kelly@HIDDEN> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 11 Jan 2015 21:19:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 11 16:19:24 2015
Received: from localhost ([127.0.0.1]:42921 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YAPuu-0007PV-1X
	for submit <at> debbugs.gnu.org; Sun, 11 Jan 2015 16:19:24 -0500
Received: from relay5-d.mail.gandi.net ([217.70.183.197]:51865)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <kelly@HIDDEN>) id 1YAPur-0007PJ-1N
 for 19565 <at> debbugs.gnu.org; Sun, 11 Jan 2015 16:19:21 -0500
Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148])
 by relay5-d.mail.gandi.net (Postfix) with ESMTP id 4AAF941C064
 for <19565 <at> debbugs.gnu.org>; Sun, 11 Jan 2015 22:19:20 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net
Received: from relay5-d.mail.gandi.net ([217.70.183.197])
 by mfilter20-d.gandi.net (mfilter20-d.gandi.net [10.0.15.180]) (amavisd-new,
 port 10024) with ESMTP id TTLrsY1Bq0kF for <19565 <at> debbugs.gnu.org>;
 Sun, 11 Jan 2015 22:19:19 +0100 (CET)
X-Originating-IP: 66.220.3.179
Received: from localhost (gm179.geneticmail.com [66.220.3.179])
 (Authenticated sender: kelly@HIDDEN)
 by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0035041C061
 for <19565 <at> debbugs.gnu.org>; Sun, 11 Jan 2015 22:19:17 +0100 (CET)
From: Kelly Dean <kelly@HIDDEN>
To: 19565 <at> debbugs.gnu.org
Subject: Re: Emacs vulnerable to endless-data attack (minor)
In-Reply-To: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
Date: Sun, 11 Jan 2015 21:18:29 +0000
Message-ID: <dXJcMhaCvuo4JeWptrVIHP2ruS6z4KudXFZv9NCYUHO@local>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 19565
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

If Emacs gets an auto-updater, or even an auto-checker for updates, like some common operating systems and web browsers have, then this bug would become an actual problem, enabling denial-of-service attacks. Since Emacs is an OS, and now a web browser too, it might get an auto-updater or auto-checker.

Even so, it would only enable DOS attacks, nothing more.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at 19565 <at> debbugs.gnu.org:


Received: (at 19565) by debbugs.gnu.org; 11 Jan 2015 18:33:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 11 13:33:37 2015
Received: from localhost ([127.0.0.1]:42868 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YANKT-0003MK-0A
	for submit <at> debbugs.gnu.org; Sun, 11 Jan 2015 13:33:37 -0500
Received: from fencepost.gnu.org ([208.118.235.10]:48598)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rms@HIDDEN>) id 1YANKQ-0003MC-Tc
 for 19565 <at> debbugs.gnu.org; Sun, 11 Jan 2015 13:33:35 -0500
Received: from rms by fencepost.gnu.org with local (Exim 4.71)
 (envelope-from <rms@HIDDEN>)
 id 1YANKQ-0006v8-6Y; Sun, 11 Jan 2015 13:33:34 -0500
Date: Sun, 11 Jan 2015 13:33:34 -0500
Message-Id: <E1YANKQ-0006v8-6Y@HIDDEN>
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
To: Kelly Dean <kelly@HIDDEN>
In-reply-to: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local> (message from
 Kelly Dean on Sun, 11 Jan 2015 11:12:00 +0000)
Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor)
References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 19565
Cc: 19565 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: rms@HIDDEN
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

That is a relief.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 11 Jan 2015 11:13:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 11 06:13:03 2015
Received: from localhost ([127.0.0.1]:42393 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1YAGS7-0006YR-1J
	for submit <at> debbugs.gnu.org; Sun, 11 Jan 2015 06:13:03 -0500
Received: from eggs.gnu.org ([208.118.235.92]:53848)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <kelly@HIDDEN>) id 1YAGS4-0006Y2-OI
 for submit <at> debbugs.gnu.org; Sun, 11 Jan 2015 06:13:01 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <kelly@HIDDEN>) id 1YAGS3-0007WY-49
 for submit <at> debbugs.gnu.org; Sun, 11 Jan 2015 06:13:00 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:47428)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <kelly@HIDDEN>) id 1YAGS3-0007WU-11
 for submit <at> debbugs.gnu.org; Sun, 11 Jan 2015 06:12:59 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55562)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <kelly@HIDDEN>) id 1YAGS1-0007dA-RJ
 for bug-gnu-emacs@HIDDEN; Sun, 11 Jan 2015 06:12:58 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <kelly@HIDDEN>) id 1YAGRw-0007Pk-LT
 for bug-gnu-emacs@HIDDEN; Sun, 11 Jan 2015 06:12:57 -0500
Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:43285)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <kelly@HIDDEN>) id 1YAGRw-0007Pa-FO
 for bug-gnu-emacs@HIDDEN; Sun, 11 Jan 2015 06:12:52 -0500
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 <bug-gnu-emacs@HIDDEN>; Sun, 11 Jan 2015 12:12:51 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net
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 <bug-gnu-emacs@HIDDEN>;
 Sun, 11 Jan 2015 12:12:50 +0100 (CET)
X-Originating-IP: 66.220.3.179
Received: from localhost (gm179.geneticmail.com [66.220.3.179])
 (Authenticated sender: kelly@HIDDEN)
 by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 254F617207C
 for <bug-gnu-emacs@HIDDEN>; Sun, 11 Jan 2015 12:12:48 +0100 (CET)
From: Kelly Dean <kelly@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: Emacs vulnerable to endless-data attack (minor)
Date: Sun, 11 Jan 2015 11:12:00 +0000
Message-ID: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local>
MIME-Version: 1.0
Content-Type: text/plain
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-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

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.




Acknowledgement sent to Kelly Dean <kelly@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#19565; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Tue, 8 Oct 2019 17:30:02 UTC

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