Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 18:02:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 08 14:02:34 2019 Received: from localhost ([127.0.0.1]:51466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iHtoe-0000WI-Gd for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 14:02:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1iHtod-0000TI-7V for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 14:02:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>) id 1iHtoX-0002H1-D3; Tue, 08 Oct 2019 14:02:25 -0400 Received: from [176.228.60.248] (port=4917 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 1iHtoW-0004Zl-Kx; Tue, 08 Oct 2019 14:02:25 -0400 Date: Tue, 08 Oct 2019 21:02:22 +0300 Message-Id: <83r23nw1xt.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Kangas <stefan@HIDDEN> In-reply-to: <CADwFkmmsqNEKCPxTOgZuASHJEAtrZW8GXGW1naJ97HGuhRQDzQ@HIDDEN> (message from Stefan Kangas on Tue, 8 Oct 2019 19:38:40 +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> <83tv8jw3t1.fsf@HIDDEN> <CADwFkmmsqNEKCPxTOgZuASHJEAtrZW8GXGW1naJ97HGuhRQDzQ@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 19:38:40 +0200 > Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 19565 <at> debbugs.gnu.org > > > > Maybe this is a stupid question, but what if I'm on a slow connection? > > > > Please define "slow" in terms of bytes/sec. > > - 56 kbps dialup is 7000 bytes/sec. > - 2G cellular network is 40 kbps, or 384 kbps, which is 5000 bytes/sec > and 48000 bytes/sec respectively. I see no problem with these numbers. If a process buffer receives more than some threshold at speed like these or faster, we can prompt the user.
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.Received: (at 19565) by debbugs.gnu.org; 8 Oct 2019 17:38:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 08 13:38:59 2019 Received: from localhost ([127.0.0.1]:51457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1iHtRr-0006MG-63 for submit <at> debbugs.gnu.org; Tue, 08 Oct 2019 13:38:59 -0400 Received: from mail-pg1-f176.google.com ([209.85.215.176]:43046) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1iHtRp-0006M3-Dk for 19565 <at> debbugs.gnu.org; Tue, 08 Oct 2019 13:38:57 -0400 Received: by mail-pg1-f176.google.com with SMTP id i32so3330156pgl.10 for <19565 <at> debbugs.gnu.org>; Tue, 08 Oct 2019 10:38:57 -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=H8oT1MJomHUr/jGE1OCFSn2kcg5EIYYEdQxXsDCgRe4=; b=NH8Xg5qZcIuRmDEoe4e7Nx0BRTO8ZX9jzLaQjVY/8JYHqRO40Gm2jUJOyeyXuUplfI ZtrdaF+VRoMei3/CagvVkeKharrw99xS6dbGWB94yeeK5wI2mbQi1mSaHMHxr/crc/8g 5bsumWgzbLQtfKL3bO0zUvM/l0ZstUdfHkk/D1q2SPBhRmt/iqxuoBxHYTNFb0lDsGt8 TkKdBDBqAN/AaH0LuGXffj8XVwu436F8sRSa2ssRRrHJbzKfo/lAGpwVqlT1bRXnqlRb fJX5uHouE72tyXrOv5lSTiWzzJDtqlebmTX4/bCtno+f/Golv91JKMppDusW/V7SiFAj 8QRQ== X-Gm-Message-State: APjAAAVLfm1GAA3jDFz+I/CZOKaBNbGT3Gm6hVeevYVR2yQK9sgM/cy9 76seOc+JEr+9Whj00eAD7RAu5BeILTfsHyWe+H0= X-Google-Smtp-Source: APXvYqwFrIzZSKEfaV+Oa58Xe6k8WCIbgiwYwL+JYtYX6SvYdYWxQZJev1rUydUpvri+p6uOTZC5dMosJsgXo7mfjSQ= X-Received: by 2002:aa7:8009:: with SMTP id j9mr39737793pfi.107.1570556331540; Tue, 08 Oct 2019 10:38:51 -0700 (PDT) MIME-Version: 1.0 References: <A95hYv6eiwhN4ZlplHCcmBnPjnFHgrKiNiO1xKjhUqg@local> <CADwFkmnhZzczftBeTPhDYt3Nctw7eonUyfHD1EsRYSjX2h2yXw@HIDDEN> <83a7ad3hlf.fsf@HIDDEN> <874l0le314.fsf@HIDDEN> <831rvo1qlk.fsf@HIDDEN> <87zhibyzh8.fsf@HIDDEN> <CADwFkmnP4+c=o5B5eQ9hVtOciURv_tsKBTTC3=JJzrVMv8K=8A@HIDDEN> <83tv8jw3t1.fsf@HIDDEN> In-Reply-To: <83tv8jw3t1.fsf@HIDDEN> From: Stefan Kangas <stefan@HIDDEN> Date: Tue, 8 Oct 2019 19:38:40 +0200 Message-ID: <CADwFkmmsqNEKCPxTOgZuASHJEAtrZW8GXGW1naJ97HGuhRQDzQ@HIDDEN> Subject: Re: bug#19565: Emacs vulnerable to endless-data attack (minor) To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 19565 Cc: Lars Ingebrigtsen <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: -0.7 (/) Eli Zaretskii <eliz@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. - 56 kbps dialup is 7000 bytes/sec. - 2G cellular network is 40 kbps, or 384 kbps, which is 5000 bytes/sec and 48000 bytes/sec respectively. These are theoretical maximums. Best regards, Stefan Kangas
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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?
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.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.
Kelly Dean <kelly@HIDDEN>
:bug-gnu-emacs@HIDDEN
.
Full text available.bug-gnu-emacs@HIDDEN
:bug#19565
; Package emacs
.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.