Activity Feed
- Government or Industry Alert (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- Other: CISA Gov Alert (https://www.cisa.gov/news-events/alerts/2023/06/02/cisa-adds-one-known-exploited-vulnerability-catalog)
Technical Analysis
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.
- Government or Industry Alert (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- Other: CISA Gov Alert (https://www.cisa.gov/news-events/alerts/2023/05/31/cisa-adds-one-known-exploited-vulnerability-catalog)
Technical Analysis
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.
- Government or Industry Alert (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- Other: CISA Gov Alert (https://www.cisa.gov/news-events/alerts/2023/05/26/cisa-adds-one-known-exploited-vulnerability-catalog)
- News Article or Blog (https://cn-sec.com/archives/1417413.html)
Thanks for sharing;
Why the setting below will not work?
RewriteRule “^/(.*)” “http://localhost:8081/$1” [P]