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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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