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

L’issue est un plan général de renforcement du heap de PHP plutôt qu’une modification d’un seul fichier ou test. Commencez par examiner les techniques non cochées ainsi que les issues et les conceptions d’allocator référencées, puis définissez un périmètre précis avec les maintainers. La tâche serait considérée comme terminée lorsqu’une technique de renforcement convenue aura été implémentée et validée dans les tests d’allocator PHP concernés.