python / python/cpython

Use-after-free in _Unpickler_ReadIntoFromFile: temporary memoryview passed to readinto() can outlive its buffer

Ouverte
#151,046 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

extension-modules type-crash
Langage dominant
Python
Étoiles
77.2k
Forks
35.9k
Métriques de merge des PR
Métriques de PR en attente

Description

Bug report

Bug description

The C implementation of pickle.Unpickler, when reading from a file-like
object that provides readinto(), hands that method a temporary memoryview
created over an internal buffer:

PyObject *buf_obj = PyMemoryView_FromMemory(buf, n, PyBUF_WRITE);
...
PyObject *read_size_obj = _Pickle_FastCall(self->readinto, buf_obj);

(Modules/_pickle.c, _Unpickler_ReadIntoFromFile.)

buf points into a short-lived buffer (e.g. the bytes object allocated in
load_counted_binbytes, which may also be reallocated by _PyBytes_Resize or
freed when unpickling ends). The memoryview is never released or invalidated
after readinto() returns. A readinto() implementation that keeps a
reference to the view can therefore use it to read or write the buffer after
it has been freed, which is a use-after-free at the C level.

This only requires a pure-Python file-like object -- no ctypes. A pure-Python
program should not be able to make the interpreter read or write freed memory.

Reproducer

import pickle, struct, gc

stashed = []

class EvilFile:
    def __init__(self):
        self._h = b"\x80\x05" + b"\x8e" + struct.pack("<Q", 200_000)
        self._p = 0
    def read(self, n=-1):
        d = self._h[self._p:] if (n is None or n < 0) else self._h[self._p:self._p+n]
        self._p += len(d); return d
    def readline(self):
        return self.read(-1)
    def readinto(self, view):
        stashed.append(view)             # keep the view past readinto()
        view[:] = b"A" * len(view); return len(view)

up = pickle.Unpickler(EvilFile())
try:
    up.load()                            # stream ends after the payload
except EOFError:
    pass
del up; gc.collect()                     # free the backing buffer
_ = [bytes(200_000) for _ in range(8)]   # churn the allocator
stashed[0][0]                            # <-- use-after-free read

On a --with-address-sanitizer --with-pydebug build this reports a clean
heap-use-after-free (READ in unpack_single, the buffer freed via
Pdata_dealloc and originally allocated in load_counted_binbytes).

Root cause and fix direction

The view is a non-owning window over a raw pointer that the unpickler does not
keep alive. Other CPython sites that drive a user readinto() (e.g.
_io.RawIOBase.read()) hand out an owning object (a bytearray) whose buffer
protocol prevents it from being freed while still exported. The pickle path
should release the temporary memoryview as soon as readinto() returns, so a
surviving reference raises ValueError: operation forbidden on released memoryview object instead of dereferencing freed memory.

I have a patch with a regression test and will open a PR.

(For context: this was originally raised privately with the Python Security
Response Team, who advised opening a public issue.)

CPython versions tested on

3.16.0a0 (main, commit 5755d0f).

Operating systems tested on

macOS (arm64), --with-address-sanitizer --with-pydebug build.

Linked PRs
  • gh-151048

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez dans Modules/_pickle.c, au niveau de _Unpickler_ReadIntoFromFile, et examinez la façon dont le memoryview temporaire est géré après le retour de readinto(). Utilisez le reproducer EvilFile fourni avec une build ASAN et pydebug, puis ajoutez ou inspectez le test de régression mentionné. C’est terminé lorsque la vue conservée ne peut pas accéder au tampon libéré et lève l’erreur attendue de memoryview libéré.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
c, python
Domaine
backend, security
Type d'issue
Bug
Difficulté
4/5
Temps estimé
3-5 jours
Activité
À l'abandon
Clarté
Clairement spécifiée
Accessibilité débutants
20/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.