The unserialize() function supported a type code, S, which was meant to be supported only for APC serialization. This type code allowed arbitrary memory addresses to be accessed as if they were static StringData objects. This issue affected HHVM prior to v4.32.3, between versions 4.33.0 and 4.56.0, 4.57.0, 4.58.0, 4.58.1, 4.59.0, 4.60.0, 4.61.0, 4.62.0.
The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Hhvm | * | 4.32.3 (excluding) | |
| Hhvm | 4.33.0 (including) | 4.56.1 (excluding) | |
| Hhvm | 4.57.0 (including) | 4.57.0 (including) | |
| Hhvm | 4.58.0 (including) | 4.58.0 (including) | |
| Hhvm | 4.58.1 (including) | 4.58.1 (including) | |
| Hhvm | 4.59.0 (including) | 4.59.0 (including) | |
| Hhvm | 4.60.0 (including) | 4.60.0 (including) | |
| Hhvm | 4.61.0 (including) | 4.61.0 (including) | |
| Hhvm | 4.62.0 (including) | 4.62.0 (including) | |
| Hhvm | Ubuntu | bionic | * |
| Hhvm | Ubuntu | trusty | * |
| Hhvm | Ubuntu | xenial | * |
An attacker can supply a pointer for memory locations that the product is not expecting. If the pointer is dereferenced for a write operation, the attack might allow modification of critical state variables, cause a crash, or execute code. If the dereferencing operation is for a read, then the attack might allow reading of sensitive data, cause a crash, or set a variable to an unexpected value (since the value will be read from an unexpected memory location). There are several variants of this weakness, including but not necessarily limited to: