python / python/cpython

Doc/library/tarfile.rst: document that the 'tar' extraction filter does not bound link targets

未關閉
#156,026 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

docs
主要語言
Python
星號
77.2k
分支
36k
平均合併
1 天 9 小時
30 天內合併 PR
558

描述

Documentation

Documentation

Doc/library/tarfile.rst, the "Extraction filters" section — specifically tar_filter and the 'tar' entry in the filter list.

Summary

The 'tar' extraction filter does not check TarInfo.linkname. A symbolic link member whose target is an absolute path, or a relative path that climbs outside the destination, is extracted as given. Only 'data' refuses such members.

This is deliberate and consistent with PEP 706 — I am not proposing a behaviour change. The problem is that the documentation never states it, and one sentence in the tar_filter description reads as though it does the opposite.

Where the docs mislead

tar_filter's third bullet currently reads:

Refuse to extract files whose absolute path (after following symlinks) would end up outside the destination. This raises OutsideDestinationError.

The parenthetical "(after following symlinks)" describes os.path.realpath() applied to the member's own destination path — i.e. symlinks that already exist in the destination tree. It reads naturally as "symlink-related escapes are handled here".

That link targets are unchecked is currently derivable only by absence: the reader has to notice that data_filter is introduced with "In addition to what tar_filter does", and that link-target containment appears only in that second list. The non-guarantee is never stated positively, so nobody reading the tar_filter section can learn it from that section.

Why it matters in practice

I found this because five independent projects selected the 'tar' filter (or tarfile.tar_filter directly) in code whose stated purpose is safe extraction, leaving link targets unbounded as a result: unstructured-ingest, container-inspector, portage, poetry, and Samba's python/samba/safe_tarfile.py. Each has been reported to its maintainers separately; I am raising this here because five independent readings landing the same way looks like a docs problem rather than five coincidences.

Samba's case shows the mechanism most clearly, because the comment quotes the docs almost verbatim:

# The 'data' filter preserves no permissions so we select the
# intermediate 'tar' filter here which prevents escape but
# preserves permissions.
extraction_filter = staticmethod(tarfile.tar_filter)

"which prevents escape" is a restatement of the bullet above. That same class's pre-3.12 fallback implements _is_unsafe_symlink() and _is_unsafe_link() by hand — so the module became less strict when it moved to the stdlib filter, which is presumably the opposite of what was intended.

Measurement

Python 3.10.12 on Linux. The harness diffs the destination tree against a pre-extraction snapshot, so a member that was never created cannot be miscounted as written, and it runs with errorlevel=2 so nothing is silently skipped.

CONTROLS -- if these do not pass, nothing below means anything
  CONTROL-BENIGN plain file     filter=tar   -> extracted                          [ok]
  CONTROL-BENIGN plain file     filter=data  -> extracted                          [ok]
  CONTROL-DOTDOT member path    filter=tar   -> REFUSED (OutsideDestinationError)  [ok]
  CONTROL-DOTDOT member path    filter=data  -> REFUSED (OutsideDestinationError)  [ok]

PAYLOADS -- symlink TARGETS
  sym -> /etc                   filter=tar   -> LINK CREATED, POINTS OUTSIDE
  sym -> /etc                   filter=data  -> REFUSED (AbsoluteLinkError)
  sym -> /etc/passwd            filter=tar   -> LINK CREATED, POINTS OUTSIDE
  sym -> /etc/passwd            filter=data  -> REFUSED (AbsoluteLinkError)
  sym -> ../../OUTSIDE          filter=tar   -> LINK CREATED, POINTS OUTSIDE
  sym -> ../../OUTSIDE          filter=data  -> REFUSED (LinkOutsideDestinationError)

The CONTROL-DOTDOT row is the one that makes the rest meaningful: tar_filter genuinely does close the original CVE-2007-4559 path-traversal case, so "refused" is observable in this harness and the symlink rows are a real difference rather than a broken probe.

Reading through the resulting link works:

read through .../sandbox/lvl1/lvl2/dest/secrets
  -> /etc/passwd line 1: 'root:x:0:0:root:/root:/bin/bash'

Stated precisely so the proposed wording is not overclaimed: writing through such a link with a later member in the same archive is refused (OutsideDestinationError), because each member path is re-resolved at extraction time. Under 'tar' this is link placement and file read, not arbitrary write. Hard links to absolute outside paths failed here for an unrelated reason (ExtractError during link-target resolution), so I make no claim about them — the wording below covers symbolic links, which is what I measured.

Proposed change

Two edits, no behaviour change:

  1. In the filter list, the 'tar' entry gains one clause, since that list is where the choice between 'tar' and 'data' is actually made:
* the string ``'tar'``: Honor most *tar*-specific features (i.e. features of
  UNIX-like filesystems), but block features that are very likely to be
  surprising or malicious. This does not include limiting the targets of
  symbolic links. See :func:`tar_filter` for details.
  1. tar_filter gains a warning stating the non-guarantee positively:
  .. warning::

     This filter does not limit where a link member *points*.
     :attr:`TarInfo.linkname` is not checked, so a symbolic link whose target
     is an absolute path, or a relative path that climbs outside the
     destination, is extracted as given.
     The rule above constrains where each member is *written*; it does not
     constrain where a link resolves to.

     Only :func:`data_filter` refuses such members, raising
     :class:`~tarfile.AbsoluteLinkError` or
     :class:`~tarfile.LinkOutsideDestinationError`.

I have this as a patch and am happy to open the PR. I care that the fact appears somewhere in the tar_filter section — the phrasing is entirely yours to change.

Linked PRs
  • gh-156056

貢獻指南

開啟貢獻指南

從這裡開始

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

研究方向

閱讀 Doc/library/tarfile.rst,重點關注 Extraction filters 區段、tar_filter 以及 'tar' 篩選器項目。根據 PEP 706 和文件中說明的 data_filter 行為,檢視提議的措辭。完成的標準是文件明確說明符號連結的目標不受 tar_filter 限制,同時不改變行為。

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

評估

技術堆疊
python
領域
documentation
Issue 類型
文件
難度
1/5
預估耗時
1-3 小時
活躍度
停滯
描述清晰度
描述清楚
新手友好度
35/100

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

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