8000 OOM vulnerability in the imaplib module · Issue #119511 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

OOM vulnerability in the imaplib module #119511

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
serhiy-storchaka opened this issue May 24, 2024 · 0 comments
Closed

OOM vulnerability in the imaplib module #119511

serhiy-storchaka opened this issue May 24, 2024 · 0 comments
Labels
3.8 (EOL) end of life 3.9 only security fixes 3.10 only security fixes 3.11 only security fixes 3.12 only security fixes 3.13 bugs and security fixes 3.14 bugs and security fixes stdlib Python modules in the Lib dir topic-email topic-IO type-security A security issue

Comments

@serhiy-storchaka
Copy link
Member
serhiy-storchaka commented May 24, 2024 •
edited by bedevere-app bot
Loading

The IMAP4 protocol supports "literal" syntax, when one side specifies the size of the data and then sends the specified amount of bytes. The imaplib client reads such data with a single read(size) call, and therefore is affected by the general vulnerability in the read() method -- it allocates the amount of memory that came from untrusted source. Just an attempt to connect to the malicious IMAP4 server can send your Python program in swap.

Linked PRs
@serhiy-storchaka serhiy-storchaka added type-security A security issue stdlib Python modules in the Lib dir 3.11 only security fixes 3.10 only security fixes 3.9 only security fixes 3.8 (EOL) end of life 3.12 only security fixes 3.13 bugs and security fixes 3.14 bugs and security fixes labels May 24, 2024
serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this issue May 24, 2024
@serhiy-storchaka
pythongh-119511: Fix OOM vulnerability in imaplib
a60f186 
The IMAP4 client could consume an arbitrary amount of memory when trying
to connent to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this issue May 24, 2024
@serhiy-storchaka
pythongh-119511: Fix OOM vulnerability in imaplib
6322049 
The IMAP4 client could consume an arbitrary amount of memory when trying
to connent to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
@bedevere-app bedevere-app bot mentioned this issue May 24, 2024
Merged
encukou pushed a commit that referenced this issue Jan 27, 2025
@serhiy-storchaka @gpshead
gh-119511: Fix a potential denial of service in imaplib (#119514)
735f25c 
The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.

Co-authored-by: Gregory P. Smith <greg@krypto.org>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jan 27, 2025
@serhiy-storchaka @gpshead @miss-islington
pythongh-119511: Fix a potential denial of service in imaplib (python…
5801b50 
…GH-119514)

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit 735f25c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jan 27, 2025
@serhiy-storchaka @gpshead @miss-islington
pythongh-119511: Fix a potential denial of service in imaplib (python…
4586386 
…GH-119514)

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit 735f25c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
@bedevere-app bedevere-app bot mentioned this issue Jan 27, 2025
Merged
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jan 27, 2025
@serhiy-storchaka @gpshead @miss-islington
pythongh-119511: Fix a potential denial of service in imaplib (python…
871bdd6 
…GH-119514)

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit 735f25c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
@bedevere-app bedevere-app bot mentioned this issue Jan 27, 2025
Merged
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jan 27, 2025
@serhiy-storchaka @gpshead @miss-islington
pythongh-119511: Fix a potential denial of service in imaplib (python…
777ef08 
…GH-119514)

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit 735f25c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
This was referenced Jan 27, 2025
Merged
Merged
gpshead added a commit that referenced this issue Jan 27, 2025
@miss-islington @serhiy-storchaka @gpshead
[3.13] gh-119511: Fix a potential denial of service in imaplib (GH-11…
5829f7b 
…9514) (GH-129355)

gh-119511: Fix a potential denial of service in imaplib (GH-119514)

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit 735f25c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
gpshead added a commit that referenced this issue Jan 27, 2025
@miss-islington @serhiy-storchaka @gpshead
[3.12] gh-119511: Fix a potential denial of service in imaplib (GH-11…
2df8b39 
…9514) (GH-129356)

gh-119511: Fix a potential denial of service in imaplib (GH-119514)

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit 735f25c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
@bedevere-app bedevere-app bot mentioned this issue Feb 18, 2025
Merged
ambv pushed a commit that referenced this issue Feb 19, 2025
@miss-islington @serhiy-storchaka @gpshead
[3.11] gh-119511: Fix a potential denial of service in imaplib (GH-11…
3abcace 
…9514) (#129357)

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit 735f25c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
ambv added a commit that referenced this issue Feb 19, 2025
@miss-islington @serhiy-storchaka
@gpshead @ambv
[3.10] gh-119511: Fix a potential denial of service in imaplib (GH-11…
8175648 
…9514) (#129358)

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit 735f25c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
ambv pushed a commit that referenced this issue Feb 19, 2025
@hugovk @serhiy-storchaka @gpshead
[3.9] gh-119511: Fix a potential denial of service in imaplib (GH-119514
f116a9c 
) (#130248)

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit 735f25c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
@ambv ambv closed this as completed Feb 19, 2025
gentoo-bot pushed a commit to gentoo/cpython that referenced this issue Apr 9, 2025
@hugovk @serhiy-storchaka
@gpshead @mgorny
[3.9] pythongh-119511: Fix a potential denial of service in imaplib (p…
3a6c6e0 

662E
ythonGH-119514) (python#130248)

The IMAP4 client could consume an arbitrary amount of memory when trying
to connect to a malicious server, because it read a "literal" data with a
single read(size) call, and BufferedReader.read() allocates the bytes
object of the specified size before reading. Now the IMAP4 client reads data
by chunks, therefore the amount of used memory is limited by the
amount of the data actually been sent by the server.
(cherry picked from commit 735f25c)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
3.8 (EOL) end of life 3.9 only security fixes 3.10 only security fixes 3.11 only security fixes 3.12 only security fixes 3.13 bugs and security fixes 3.14 bugs and security fixes stdlib Python modules in the Lib dir topic-email topic-IO type-security A security issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ambv @serhiy-storchaka
0