Moderate
CVE-2023-29336
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Add References:
CVE-2023-29336
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Topic Tags
Description
Win32k Elevation of Privilege Vulnerability
Add Assessment
Ratings
-
Attacker ValueMedium
Technical Analysis
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 with BinDiff 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.
After some time getting proper structures defined in Binary Ninja, I was able to come up with the following HLIL graph showing the code for xxxEnableMenuItem
before the patch was issued:
And here is the code after the patch was issued:
Of note is the fact that the new edition of the code is checking that pRealMenu
exists and then if it does, its incrementing that object’s cObjLock
count by one. This extra lock appears to then be undone in a call to pRealMenu = ThreadUnlock1()
, which was also added in.
Further analysis is available at https://www.numencyber.com/cve-2023-29336-win32k-analysis/ which explains how this bug is a UAF, which makes sense given that a check was added into update the lock count appropriately. As explained in that writeup, prior to the patch, the code purely locked the window object pointed to by pMenu->spwndNotify
and failed to also lock the menu object nested within the window object, aka the pRealMenu
object returned by the call to MenuItemState
.
Tracing the call flow backwards we can see that xxxEnableMenuItem()
is called by NtUserEnableMenuItem()
. According to the writeup, the menu item passed in via the first argument to xxxEnableMenuItem()
, aka pMenu
, would typically be locked inside of inside of a higher level function such as NtUserEnableMenuItem()
. However they raise the question of “okay so you have a menu object you need to lock, but which menu item would need locking?”
So why this question in particular? Surely we are just dealing with one menu object which means one menu itself right? Well as the writeup explains, the object returned by a function such as MenuItemState()
may encompass not only the main menu within a window object but also its submenus, and even subsubmenus in some cases.
This is becuase MenuItemState()
will call MNLookupItem()
which will in turn recursively call itself until it finds the object its looking for, meaning that pMenu
may actually point to a nested set of menu objects. This looks like a potential case where assumptions could lead to some incorrect results.
In the exploit they create 4 menus, namely MenuA, MenuB, MenuC and MenuD, with MenuB being a child of MenuA, MenuC being a child of MenuB, and so on. They set the ID of MenuD to be 0xF060, aka SC_CLOSE. As noted at https://stackoverflow.com/questions/10101742/difference-between-wm-close-and-sc-close, this is sent when the user presses the close button or otherwise uses some menu control to close the window. They remove the class ID of SC_CLOSE from MenuA. They then release MenuC by deleting all references to it within MenuB, in order to ensure proper memory deallocation.
When xxxRedrawTitle()
is called from within xxxEnableMenuItem()
, a transfer will be made to a user mode callback via a call to xxxSendMessage()
, at which point the exploit removes the reference between MenuC and MenuB, effectively releasing MenuC. At this point the reference to MenuC within xxxEnableMenuItem()
will become invalid. Keep in mind in the code MenuC is effectively var_pMenu_spwndNotify
so thats where the relationship comes into play.
Hope that helps!
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportCVSS V3 Severity and Metrics
General Information
Vendors
- microsoft
Products
- windows 10 1507,
- windows 10 1607,
- windows server 2008 -,
- windows server 2008 r2,
- windows server 2012 -,
- windows server 2012 r2,
- windows server 2016 -
Exploited in the Wild
- Vendor Advisory (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-29336)
- 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/09/cisa-adds-one-known-exploited-vulnerability-catalog)
Would you like to delete this Exploited in the Wild Report?
Yes, delete this reportReferences
Additional Info
Technical Analysis
Report as Exploited in the Wild
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
does the same cpp code work for the windows 1507 ver?