Activity Feed

Still evaluating this some more but from what I can tell this doesn’t affect Windows 11, but only older versions of Windows such as Windows 10 1607 and earlier. It has however been exploited in the wild.

Doing a patch diff between a Windows 10 1607 x86 version of win32kfull.sys prior to the patch and after the patch shows that only one function changed: xxxEnableMenuItem.

Looking at the code diff for this shows that two new blocks were added. These appear to be doing some validation of data and then optionally also incrementing a different data element. The decompiled code that was added looks like this in the decompiled code:

    local_14 = *(undefined4 *)(*(int *)pcVar1 + 0xd0);
    *(undefined4 **)(*(int *)pcVar1 + 0xd0) = &local_14;
    local_10 = pRealMenu;
    if (pRealMenu != (tagMENU *)0x0) {
      *(int *)&pRealMenu->field_0x4 = *(int *)&pRealMenu->field_0x4 + 1;
    }

And here is the raw ASM that was added:

                             *************************************************************
                             * This entire section is new                                 
                             *************************************************************
                             LAB_0002518a                                    XREF[1]:     00025185 (j)   
        0002518a 8b  4c  24  10    MOV        param_1 ,dword ptr [ESP  + local_28 ]
        0002518e 8b  54  24  0c    MOV        param_2 ,dword ptr [ESP  + pRealMenu ]
        00025192 8b  09           MOV        param_1 ,dword ptr [param_1->field0_0x0 ]
        00025194 8b  81  d0       MOV        EAX ,dword ptr [param_1->field0_0x0  + 0xd0 ]
                 00  00  00
        0002519a 89  44  24  24    MOV        dword ptr [ESP  + local_14 ],EAX
        0002519e 8d  44  24  24    LEA        EAX =>local_14 ,[ESP  + 0x24 ]
        000251a2 89  81  d0       MOV        dword ptr [param_1->field0_0x0  + 0xd0 ],EAX
                 00  00  00
        000251a8 89  54  24  28    MOV        dword ptr [ESP  + local_10 ],param_2
        000251ac 85  d2           TEST       param_2 ,param_2
        000251ae 74  03           JZ         LAB_000251b3
        000251b0 ff  42  04       INC        dword ptr [param_2  + 0x4 ]

My guess without looking into this further is that we are checking if local_2c is 0, by doing TEST EDX, EDX and then JZ LAB_000251b3 to continue to the original code if local_2c is zero. If it is not zero, then we are now executing a new code branch in which we treat EDX as a pointer to some sort of structure, take offset 0x4 into that structure, and increment it by 1.

This may be a reference counter if we are incrementing it by one and perhaps the previous edition of the code didn’t account for this field being some element and then used it without appropriately adjusting its reference count?

There also appears to be an additional call to ThreadUnlock1 where it takes the output from the previous ThreadUnlock1 call and passes it back into a call to ThreadUnlock1 again? Specifically this code:

        000251fc ff  d6           CALL       ESI =>WIN32KBASE.SYS::ThreadUnlock1
        000251fe 89  44  24  0c    MOV        dword ptr [ESP  + 0xc ],EAX
        00025202 ff  d6           CALL       ESI =>WIN32KBASE.SYS::ThreadUnlock1

Is different in the last two lines.

Looking inside ThreadUnlock1 can be done by using the code at https://systemroot.gitee.io/pages/apiexplorer/ and then searching for ThreadUnlock1.

This is as far as I have gotten so far. I thought there might be a NULL pointer dereference issue however Windows 8 should have this mitigation enabled as per https://media.blackhat.com/bh-us-12/Briefings/M_Miller/BH_US_12_Miller_Exploit_Mitigation_Slides.pdf yet its listed as affected. Same for Windows 10 as per https://www.blackhat.com/docs/us-16/materials/us-16-Weston-Windows-10-Mitigation-Improvements.pdf and as noted at https://www.abatchy.com/2018/01/kernel-exploitation-6.

Will have to do more digging into things to figure out what has changed percisely but hopefully this gives a good initial idea.

I saw this vulnerability and dug a bit because it is an improper fix to CVE-2016-5118, which was a big deal and I wanted to know what was missed. To be clear, this vulnerability is not a big deal. Where CVE-2016-5118 was vulnerable in a default configuration, this vulnerability requires a non-default, purposefully-vulnerable configuration. The maintainers for the project went so far as to revert the community-provided fix for this vulnerability claiming the behavior was a poorly-documented feature. From the issue on ImageMagick (https://github.com/ImageMagick/ImageMagick/issues/6339):

When --enable-pipes is used the user opens themselves up to a potential security risk when they don't filter the input. And you don't even need to use back ticks. It is also possible to do this magick '|cat test.txt > /tmp/leak|< logo.jpg' info: when the user of our library enables this option. And as we said before this option is not enabled by default but we should make it more clear what could happen when the user of our library enables this option.

This is not particularly surprising; enabling pipes in an application like this increases the complexity and makes proper sanitization much more difficult. Users should ensure that the application does not have this vulnerable option turned on.