The security landscape is dynamic, changing often and as a result, attack surfaces evolve. MSRC receives a wide variety of cases spanning different products, bug types and exploit primitives. One particularly interesting primitive we see is an arbitrary kernel pointer read. These often happen when kernel mode code does not validate that pointers read from attacker-controlled input actually point to the user-mode portion of the Virtual Address Space (VAS). An attacker can utilize such a primitive to supply a kernel mode-pointer which will then be de-referenced by kernel-mode code. Sometimes, there is a further restriction that even though the attacker can cause a read of an arbitrary kernel address / pointer they cannot retrieve the contents of the memory read. If the virtual memory at a given address X contains data Y, then we assume the attacker can cause the kernel to read X but does not have a direct way of obtaining the read data, Y. If the attacker could read Y then they can read memory contents from the VAS and we would generally assess this as an information disclosure vulnerability. However, it isn’t always clear how to assess cases where the primitive an attacker has is to cause an arbitrary kernel pointer read but cannot leak the data. Traditionally, these would have an impact of Denial of Service (DoS) or in some cases a second-order Kernel Memory Information Disclosure (where side channels or indirect probing are possible) but we wonder if such a limited primitive could actually be exploited for code execution / privilege escalation?
This post was created with our nice and easy submission form. Create your post!
GIPHY App Key not set. Please check settings