CVE-2024-0519 notes

//Preconditons
//----------------------
// (1) The receiver must be a regular object and the key a unique name.
//        this excludes special objects such as globalThis, wasm object, etc
// (2) The property to be deleted must be the last property.
// (3) The property to be deleted must be deletable.
//        this excludes non-configurable properties. So no frozen or sealed objects.
// (4) The map must have a back pointer.
//        this excludes prototype maps
// (5) The last transition must have been caused by adding a property
//        
//are these checks sufficient / correct ?
//
//
//receiver
//----------------------
// - Heap::NotifyObjectLayoutChange
//     seems like a no-op as invalidate_recorded_slots == InvalidateRecordedSlots::kNo 
//     and invalidate_external_pointer_slots == InvalidateExternalPointerSlots::kNo
//     only performs diagnostic  HeapVerifier::SetPendingLayoutChangeObject when v8_flags.verify_heap == true
// - JSReceiver::SetProperties
//     only performed when last out of object property deleted - replacing the object's properties with 
//     an empty fixed array.
// - ClearField (similiar to JSObject::FastPropertyAtPut)
//     - TaggedField<MapWord>::Release_Store - if in-object
//     - object->property_array()->set - if out-object
// - Heap::ClearRecordedSlot
//     only performed on in-object property
// - HeapObjectLayout::set_map
// - JSObject::MigrateInstance (if parent map is deprecated)
//
//
//receiver_map
//----------------------
// - Map::NotifyLeafMapLayoutChange (also called in slow deletion path)
//
//transition descriptor(s) from parent_map with key of last deleted property name
//----------------------
// - MapUpdater::GeneralizeField (must be PropertyKind::kData and PropertyConstness::kConst descriptor)
//      only changes the PropertyConstness to kMutable 
//
//
//Only known issue (so far):
//"Property deletions can undo map transitions
//while keeping the backing store around, meaning that even though the
//map might believe that objects have no unused property fields, there
//might actually be some."
//
//This does not seem useful for exploitation AFAIK


//In this POC both the constness of p4 will be marked as mutable for MapA and MapB. This seems like a bug as o2's p4 field 
is non-writable and non-configurable. Unfortunately this does not seem useful for exploitation AT ALL.... 

var o = {}; //MapA
o.p1 = 1;
o.p2 = 1;
o.p3 = 1;
o.p4 = 1;
 
const o2 = {}; //MapB
o2.p1 = 1;
o2.p2 = 1;
o2.p3 = 1;
Object.defineProperty(o2, "p4", {
    value: 1,
    writable: false,
    enumerable: true,
    configurable: false,
});

delete o.p4;

%DebugPrint(o);
%DebugPrint(o2);


///////////////////////

DeleteObjectPropertyFast used to be vulnerable to hash clearing vuln.

https://github.com/v8/v8/commit/eab2f2e654da8c0edfdd8a47a73432b07127321c


///////////////////////
https://issues.chromium.org/issues/40055882
https://issues.chromium.org/issues/42212420
https://chromium.googlesource.com/v8/v8/+/d489e88cdfd04afe24c6d6c5c8cc61a9010a7c29
https://github.com/v8/v8/commit/a2db71667affeed7e6fb3d202e73f1ba03c11add
https://chromium.googlesource.com/v8/v8.git/+/571cc43c39516e529a93914a313ed124f2d448d4%5E%21/#F0
https://github.com/v8/v8/commit/f0e054c2c6b5422b4cc3bca264220fb584054916
https://github.com/v8/v8/commit/98acfb36e1acf2ab52ab6b6439eb6356c83dcda6
https://github.com/v8/v8/commit/0f88153075bbc97d4701533454cf11a690ad7210
https://issues.chromium.org/issues/41470618
https://issues.chromium.org/issues/40095556#comment16
https://chromium-review.googlesource.com/c/v8/v8/+/1751346