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

Issue này là một kế hoạch hardening heap PHP trên phạm vi rộng, thay vì chỉ là thay đổi một file hoặc một test. Hãy bắt đầu bằng việc xem xét các kỹ thuật chưa được đánh dấu cùng các issue và thiết kế allocator được tham chiếu, sau đó thống nhất một phạm vi cụ thể với các maintainer. Để được coi là hoàn tất, cần triển khai một kỹ thuật hardening đã thống nhất và xác thực kỹ thuật đó trong các test allocator PHP liên quan.