summaryrefslogtreecommitdiff
path: root/src/tests/disable_function/config/config_disabled_functions_namespace.ini
diff options
context:
space:
mode:
authorjvoisin2026-04-24 11:09:54 +0200
committerjvoisin2026-04-24 11:09:54 +0200
commitc0ea33d05dfb503f60a842372c336d12b23259ba (patch)
tree5c112de6c98aa99b393c12e2594ed9f7620e222f /src/tests/disable_function/config/config_disabled_functions_namespace.ini
parent75446f7bf62d3390fc8e9c6b578431a8991fc60b (diff)
Fix a type confusion on cookie encryption
Cookies can be arrays (session_id[]=x), and we called `Z_STRLEN_P(pDest)` without checking if `Z_TYPE_P(pDest) == IS_STRING`, leading to a type confusion, leaking at least `HashTable->arData`, and the rest of the code is going to corrupt some stuff, leading to a crash. While exploitation can't be ruled out, it looks stupidly harder. The array will be decoded as base64 into another variable, decrypted, and have this value written back to the array. To obtain a controlled read, an attacker would have to bruteforce decryption to find an encrypted value that could be properly decrypted, as we're using authenticated encryption. The next steps are depending on the heap's layout, which should be pretty deterministic/simple as cookie decryption happens at RINIT. But since the heap overflow is happening in the cookies, odds are that they're stored somewhere with other data like POST/GET/… and thus nothing super-duper juicy. While remote heap exploitation in PHP have been done in the past, this primitive looks a tad too limited to yield something powerful enough to pop a shell. Reported-by: Vozec
Diffstat (limited to 'src/tests/disable_function/config/config_disabled_functions_namespace.ini')
0 files changed, 0 insertions, 0 deletions