[issue43086] Excess data in not handled properly in binascii.a2b_base64()

[Idan Moral]

Change by Idan Moral :


--
pull_requests: +25796
pull_request: https://github.com/python/cpython/pull/27249

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43086] Excess data in not handled properly in binascii.a2b_base64()

[Gregory P. Smith]

Gregory P. Smith  added the comment:

I've merged Idan's PR adding a strict_mode parameter to a2b_base64.  It 
defaults to False for backwards compatibility.

>From a security perspective, it'd be _ideal_ if this were True.  But I expect 
>doing that would break a bunch of existing code and tests that has been 
>relying on some of the former leniency behaviors so I recommended the 
>conservative approach of the old-behavior default.  It'd be a good thing to 
>change it to True, but disruptive.  We need motivating reason to do that.

As it is a new feature due to the new parameter, this is for 3.11.

Workaround for Pythons without this: do a validity check before calling 
a2b_base64.  I suspect a regex could be constructed for that if you're careful. 
 If you come up with one, please share it here.

--
components: +Extension Modules
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed
versions: +Python 3.11 -Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43086] Excess data in not handled properly in binascii.a2b_base64()

[Gregory P. Smith]

Gregory P. Smith  added the comment:


New changeset 35b98e38b6edd63153fc8e092f94cb20725dacc1 by Idan Moral in branch 
'main':
bpo-43086: Add handling for out-of-spec data in a2b_base64 (GH-24402)
https://github.com/python/cpython/commit/35b98e38b6edd63153fc8e092f94cb20725dacc1


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43086] Excess data in not handled properly in binascii.a2b_base64()

[Gregory P. Smith]

Change by Gregory P. Smith :


--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43086] Excess data in not handled properly in binascii.a2b_base64()

[Eric V. Smith]

Change by Eric V. Smith :


--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43086] Excess data in not handled properly in binascii.a2b_base64()

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +23216
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24402

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43086] Excess data in not handled properly in binascii.a2b_base64()

[Idan Moral]

New submission from Idan Moral :

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 (twitter: https://twitter.com/0xrepnz) for bringing this 
behavior up,
and thanks to Ryan Mast (twitter: https://twitter.com/rmast), and many of the 
other great guys for discussing the problem in the comments.

Link to the tweet: https://twitter.com/0xrepnz/status/1355295649915404291

--

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

--
components: Library (Lib)
messages: 386032
nosy: idan22moral
priority: normal
severity: normal
status: open
title: Excess data in not handled properly in binascii.a2b_base64()
type: security
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com