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.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10536 in the body.
You can then email your comments to 10536 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#10536; Package emacs. (Tue, 17 Jan 2012 17:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 17 Jan 2012 17:09:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.3; Make base64-decode more fault tolerant
Date: Tue, 17 Jan 2012 15:39:20 +0100
Hello,

Not a bug in Emacs, but I have received base64-encoded mails from a
not-so-small company which could not be decoded.  It turns out that
there was a missing padding character, i.e. the last quartet was
"xy=" rather than the proper "xy==".

I would suggest that base64-decode should tolerate this, like with
the appended patch.

Regards,
Wolfram.

--- 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);
 
 	  if (c != '=')
 	    return -1;




Severity set to 'minor' from 'normal' Request was from Chong Yidong <cyd <at> gnu.org> to control <at> debbugs.gnu.org. (Thu, 26 Jan 2012 15:36:02 GMT) Full text and rfc822 format available.

Added tag(s) patch. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 17 Apr 2018 22:21:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10536; Package emacs. (Tue, 17 Apr 2018 22:23:02 GMT) Full text and rfc822 format available.

Message #12 received at 10536 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de>
Cc: 10536 <at> debbugs.gnu.org
Subject: Re: bug#10536: 23.3; Make base64-decode more fault tolerant
Date: Wed, 18 Apr 2018 00:22:42 +0200
Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de> writes:

> Not a bug in Emacs, but I have received base64-encoded mails from a
> not-so-small company which could not be decoded.  It turns out that
> there was a missing padding character, i.e. the last quartet was
> "xy=" rather than the proper "xy==".
>
> I would suggest that base64-decode should tolerate this, like with
> the appended patch.
>
> Regards,
> Wolfram.
>
> --- 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.)

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10536; Package emacs. (Wed, 18 Apr 2018 02:26:02 GMT) Full text and rfc822 format available.

Message #15 received at 10536 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 10536 <at> debbugs.gnu.org, Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de>
Subject: Re: bug#10536: 23.3; Make base64-decode more fault tolerant
Date: Tue, 17 Apr 2018 22:25:06 -0400
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

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

>> there was a missing padding character, i.e. the last quartet was
>> "xy=" rather than the proper "xy==".
>>
>> I would suggest that base64-decode should tolerate this, like with
>> the appended patch.

>>        if (c == '=')
>>  	{
>> -	  READ_QUADRUPLET_BYTE (-1);
>> +	  /* Be tolerant against missing final padding '='.  */
>> +	  READ_QUADRUPLET_BYTE (e-to);

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

Makes sense to me.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10536; Package emacs. (Wed, 18 Apr 2018 06:21:01 GMT) Full text and rfc822 format available.

Message #18 received at 10536 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 10536 <at> debbugs.gnu.org, wmglo <at> dent.med.uni-muenchen.de
Subject: Re: bug#10536: 23.3; Make base64-decode more fault tolerant
Date: Wed, 18 Apr 2018 09:20:43 +0300
> 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.)

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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10536; Package emacs. (Wed, 18 Apr 2018 09:44:03 GMT) Full text and rfc822 format available.

Message #21 received at 10536 <at> debbugs.gnu.org (full text, mbox):

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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10536; Package emacs. (Wed, 18 Apr 2018 09:49:01 GMT) Full text and rfc822 format available.

Message #24 received at 10536 <at> debbugs.gnu.org (full text, mbox):

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

No, I mean that this omission is either due to a bug at the malicious
end or is somehow related to the malicious part itself (i.e. it is
part of the scam).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10536; Package emacs. (Wed, 18 Apr 2018 11:42:02 GMT) Full text and rfc822 format available.

Message #27 received at 10536 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10536 <at> debbugs.gnu.org, wmglo <at> dent.med.uni-muenchen.de
Subject: Re: bug#10536: 23.3; Make base64-decode more fault tolerant
Date: Wed, 18 Apr 2018 13:40:47 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> > --- 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);

[...]

> Could this "omission" be a sign of malicious stuff in there?

Hm...  I don't think so.  This is about the very last characters of a
base64-encoded text.  The standard says that if there are too few bytes
in the original text, then the base64-encoded thing should be padded
with = signs.

Here's an example:

(base64-encode-string "hel")
=> "aGVs"
(base64-encode-string "hell")
=> "aGVsbA=="
(base64-encode-string "hello")
=> "aGVsbG8="
(base64-encode-string "helloh")
=> "aGVsbG9o"

The proposed patch is that base64-decode should handle the end-padding
and missing end-padding equivalently: That is, both "aGVsbA==" and
"aGVsbA" should decode to "hell".

Unless I'm missing something, I don't think there's much room for
maliciousness here...

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10536; Package emacs. (Thu, 27 Jun 2019 15:43:02 GMT) Full text and rfc822 format available.

Message #30 received at 10536 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de>
Cc: 10536 <at> debbugs.gnu.org
Subject: Re: bug#10536: 23.3; Make base64-decode more fault tolerant
Date: Thu, 27 Jun 2019 17:42:37 +0200
Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de> writes:

> -	  READ_QUADRUPLET_BYTE (-1);
> +	  /* Be tolerant against missing final padding '='.  */
> +	  READ_QUADRUPLET_BYTE (e-to);

We discussed this a bit last year, but didn't come to any conclusion,
but I think on the whole, having base64-decode be strict or non-strict
here doesn't make much practical difference (because it's very uncommon
to strip the trailing = padding characters), but theoretical paranoia
about this somehow leading to subsequent errors...  somehow...  may be
warranted.

So I'm closing this bug report.

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




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 27 Jun 2019 15:43:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 10536 <at> debbugs.gnu.org and Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 27 Jun 2019 15:43:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10536; Package emacs. (Thu, 27 Jun 2019 17:17:01 GMT) Full text and rfc822 format available.

Message #37 received at 10536 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 10536 <at> debbugs.gnu.org, Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de>
Subject: Re: bug#10536: 23.3; Make base64-decode more fault tolerant
Date: Thu, 27 Jun 2019 13:16:27 -0400
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de> writes:
>
>> -	  READ_QUADRUPLET_BYTE (-1);
>> +	  /* Be tolerant against missing final padding '='.  */
>> +	  READ_QUADRUPLET_BYTE (e-to);
>
> We discussed this a bit last year, but didn't come to any conclusion,
> but I think on the whole, having base64-decode be strict or non-strict
> here doesn't make much practical difference (because it's very uncommon
> to strip the trailing = padding characters), but theoretical paranoia
> about this somehow leading to subsequent errors...  somehow...  may be
> warranted.

We did meanwhile get a base64url-* which has an optional NOPAD argument,
and base64-decode-* functions got an optional BASE64URL argument which
allows decoding unpadded base64, by the way.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10536; Package emacs. (Thu, 27 Jun 2019 17:23:01 GMT) Full text and rfc822 format available.

Message #40 received at 10536 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 10536 <at> debbugs.gnu.org, Wolfram Gloger <wmglo <at> dent.med.uni-muenchen.de>
Subject: Re: bug#10536: 23.3; Make base64-decode more fault tolerant
Date: Thu, 27 Jun 2019 19:22:23 +0200
Noam Postavsky <npostavs <at> gmail.com> writes:

> We did meanwhile get a base64url-* which has an optional NOPAD argument,
> and base64-decode-* functions got an optional BASE64URL argument which
> allows decoding unpadded base64, by the way.

Ah, yeah, I'd forgotten about that.

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




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 26 Jul 2019 11:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 247 days ago.

Previous Next


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