Heap hardening

Description

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

• BlackAlps 2022: Generic Remote Exploit Techniques For The PHP Allocator, And 0days by Charles Fol
• SSD Advisory – PHP SplDoublyLinkedList UAF Sandbox Escape
• Gollum: Modular and Greybox Exploit Generation for Heap Overflows in Interpreters
  
• In the land of PHP you will always be (use-after-)free and Solution to Adepts of 0xCC Challenge 01
• mm0r1's exploits

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

El issue es un plan amplio de hardening del heap de PHP, no un cambio en un único archivo o test. Empieza revisando las técnicas aún no marcadas y los issues y diseños de allocator referenciados; después, acuerda un alcance concreto con los maintainers. Para darlo por terminado, habría que implementar una técnica de hardening acordada y validarla en los tests relevantes del allocator de PHP.