Re: [Qemu-devel] [PATCH for-1.4 01/12] qmp: Fix design bug and read beyond buffer in memchar-write

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> On 6 February 2013 09:06, Markus Armbruster <address@hidden> wrote:
>> As far as I can tell, it never fails, but silently ignores characters
>> outside the alphabet [A-Za-z0-9+/]
>
> This bit at least is required behaviour: see RFC2045 section 6.8:
>
>    Any characters outside of the base64 alphabet are to be ignored in
>    base64-encoded data.
>
> (thanks to Tony Finch for pointing that one out to me.)

RFC 2045 is "Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies".  As such, it is about a *transfer
encoding* of Base64.

RFC 3548 "The Base16, Base32, and Base64 Data Encodings":

2.3.  Interpretation of non-alphabet characters in encoded data

   Base encodings use a specific, reduced, alphabet to encode binary
   data.  Non alphabet characters could exist within base encoded data,
   caused by data corruption or by design.  Non alphabet characters may
   be exploited as a "covert channel", where non-protocol data can be
   sent for nefarious purposes.  Non alphabet characters might also be
   sent in order to exploit implementation errors leading to, e.g.,
   buffer overflow attacks.

   Implementations MUST reject the encoding if it contains characters
   outside the base alphabet when interpreting base encoded data, unless
   the specification referring to this document explicitly states
   otherwise.  Such specifications may, as MIME does, instead state that
   characters outside the base encoding alphabet should simply be
   ignored when interpreting data ("be liberal in what you accept").
   Note that this means that any CRLF constitute "non alphabet
   characters" and are ignored.  Furthermore, such specifications may
   consider the pad character, "=", as not part of the base alphabet
   until the end of the string.  If more than the allowed number of pad
   characters are found at the end of the string, e.g., a base 64 string
   terminated with "===", the excess pad characters could be ignored.

8.  Security Considerations
[...]
   If non-alphabet characters are ignored, instead of causing rejection
   of the entire encoding (as recommended), a covert channel that can be
   used to "leak" information is made possible.  The implications of
   this should be understood in applications that do not follow the
   recommended practice.
[...]