GNU bug report logs - #10536
23.3; Make base64-decode more fault tolerant

Previous Next

Package: emacs;

Reported by: Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de>

Date: Tue, 17 Jan 2012 17:09:02 UTC

Severity: minor

Tags: patch, wontfix

Found in version 23.3

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10536 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>, wmglo <at> dent.med.uni-muenchen.de
Subject: bug#10536: 23.3; Make base64-decode more fault tolerant
Date: Wed, 18 Apr 2018 11:42:52 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Wed, 18 Apr 2018 00:22:42 +0200
>> Cc: 10536 <at> debbugs.gnu.org
>> 
>> > --- src/fns.c~	2011-04-05 05:46:44.000000000 +0200
>> > +++ src/fns.c	2012-01-17 13:59:26.000000000 +0100
>> > @@ -3590,7 +3590,8 @@
>> >
>> >        if (c == '=')
>> >  	{
>> > -	  READ_QUADRUPLET_BYTE (-1);
>> > +	  /* Be tolerant against missing final padding '='.  */
>> > +	  READ_QUADRUPLET_BYTE (e-to);
>> 
>> It probably won't harm anything to add this patch...  On the other hand,
>> it's not very common to have base64 encoded data that fails in this
>> manner.
>> 
>> What do the rest of you people think?  (I think I'm slightly for
>> applying the patch.  "Be liberal in what you receive" and all that.)
>

That principle is starting to change: "Be intolerant in what you
receive, else malicious actors will exploit your tolerance" is
starting to become more common.

> Could this "omission" be a sign of malicious stuff in there?  If so,
> maybe it's better to introduce a variable that would allow this to be
> tolerated, and by default fail with a message telling the user that if
> they trust the source of the data, set the variable and retry?

You mean that someone would deliberately send incorrect base64 in the
hope that interim attachment scanners would ignore it, but that the
final recipient's software would be tolerant and decode it? That seems
a little farfetched [1], but if it really is uncommon, then a variable
would not do much harm.

Robert

Footnotes:
[1]  Then again, someone just hacked a casino via an aquarium
     thermometer, so who am I to judge whatʼs farfetched.





This bug report was last modified 6 years and 22 days ago.

Previous Next


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