Currently, when providing binascii.a2b_base64() base-64 input with excess data after the padding (=/==), the excess data is ignored.

Example:

import binascii
binascii.a2b_base64(b'aGVsbG8=')       # b'hello' (valid)
binascii.a2b_base64(b'aGVsbG8==')      # b'hello' (ignoring data)
binascii.a2b_base64(b'aGVsbG8=python') # b'hello' (ignoring data)

Note: MANY libraries (such as the all-time favorite base64) use this function as their decoder.

Why is it problematic:

• User input can contain additional data after base64 data, which can lead to unintended behavior in products.
• Well-crafted user input can be used to bypass conditions in code (example in the referenced tweet).
• Can be used to target vulnerable libraries and bypass authentication mechanism such as JWT (potentially).

The logic behind my fix PR on GitHub:

• Before deciding to finish the function (after knowing the fact that we passed the data padding),
  we should check if there's no more data after the padding.
• If excess data exists, we should raise an error, free the allocated writer, and return null.
• Else, everything's fine, and we can proceed to the function's end as previously.

Though not publicly disclosed, this behavior can lead to security issues in heavily-used projects.
Preventing this behavior sounds more beneficial than harmful, since there's no known good usage for this behavior.

From what I read, the python implementation in not so close (when speaking about this case of course) to the base64 RFC.
(link: https://tools.ietf.org/html/rfc4648#section-3.3)

Thanks to Ori Damari for bringing this behavior up,
and thanks to Ryan Mast, and many of the other great guys for discussing the problem in the comments.

Link to the tweet

Idan Moral
Twitter: https://twitter.com/idan_moral
GitHub: https://github.com/idan22moral

https://bugs.python.org/issue43086