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

Previous Next

Package: emacs;

Reported by: Kelly Dean <kelly <at> prtime.org>

Date: Sun, 11 Jan 2015 11:14:02 UTC

Severity: normal

Tags: security

Full log


View this message in rfc822 format

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 19565 <at> debbugs.gnu.org
Subject: bug#19565: Emacs vulnerable to endless-data attack (minor)
Date: Mon, 7 Oct 2019 14:50:41 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> 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




This bug report was last modified 5 years and 252 days ago.

Previous Next


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