[Security] Memory Exhaustion (OOM) and Resource Leak via crafted PAX Headers in tarfile

未關閉
  • 哪裡不對？
#161,955 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
3/5
預估耗時
1-2 天
新手友好度
30/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
python
領域
security

研究方向

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.

由索引模型根據 Issue 內容生成。

描述

type-bug
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.

sever.py

PoC.py

CPython versions tested on:

3.15

Operating systems tested on:

Windows

主要語言
Python
星號
78.2k
分支
36.6k
平均合併
19 小時 57 分鐘
30 天內合併 PR
630

環境準備

在 Codespaces 中開啟

在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

python/cpython 的其他 Issue

查看 python/cpython 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。