php / php/php-src

Heap hardening

Aperta
#14,083 7 commenti 9 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Feature Status: Needs Triage
Lingua principale
C
Stelle
40.4k
Fork
8.1k
Merge medio
2g 13h
PR unite (30g)
96

Descrizione

Description

Currently, PHP's heap implementation is ~trivial to exploit:

There are several hardening techniques that could/should be implemented, listed here in order of difficulty:

  • prevent unlink abuses:
    • #13943
    • #14339
  • prevent freelist-corruption via shadow-pointer à la XNU/linux/partitionAlloc/suhosin/…: #14054
  • Disable ZEND_MM_CUSTOM by default: #14570
  • Make some parts of _zend_mm_heap read-only at runtime: #14570
  • surround large allocations with guard-pages, as done in partitionAlloc, scudo, …
  • Freelist randomisation, see Linux' SLAB_FREELIST_RANDOM
  • isolate types in different heaps to make type confusion/use after free more difficult, as in kalloc_type. An additional benefit of type isolation + freelist bitmap is that we wouldn't need the object_store anymore to enumerate objects. A less invasive approach would be to simply isolate by size as done in partitionAlloc and Webkit's libpas
    • once this is done, heaps need to be pinned by size/type, to prevent an attacker from re-using the memory space of a destructed heap with one of different type/size.
    • a low-hanging fruit would be to allocate GET/POST/COOKIES into a separated heap, to reduce the reach of heap feng-shui: #14304
  • allocate strings and array buckets in GigaCages so that a corrupt length doesn't allow to access anything else than other strings/array buckets. This will significantly increase the virtual-memory usage though. this isn't doable since those structures have a maximum size of SIZE_MAX

cc @arnaud-lb @cfreal @therealcoiffeur

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

La issue è un piano ampio di hardening dell’heap di PHP, non una modifica a un singolo file o test. Inizia esaminando le tecniche non ancora selezionate e le issue e i design degli allocator a cui si fa riferimento, quindi concorda un ambito specifico con i maintainer. Per considerare il lavoro completato, sarebbe necessario implementare una tecnica di hardening concordata e convalidarla nei test dell’allocator PHP pertinenti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
c, php
Ambito
security
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Ferma
Chiarezza
Da chiarire
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.