I don't see why a possibility for chaining this with an old, already patched RCE would suffice for qualifying as RCE itself. I mean, @xaitax video shows coupling with Follina (CVE-2022-30190), and couples it with CVE-2023-21716. I think there must be more than that there.github.com/labesterOct/CV…
@HaifeiLi @xaitax Besides, parsing of this "!" format must be insane: Exclamation mark is a valid character in a file name. How would you go about parsing that? My money is on this parsing being broken and exploitable.
Well, well, well. You try to see if function ole32!MkParseDisplayName was patched by February updates - but ole32.dll hasn't changed at all! So the function wasn't patched, right?
Then you put a breakpoint on this function in Outlook process and - HELLO, Microsoft! The function is hotpatched and, with a jmp instruction written over the first bytes, replaced with its alternative in mso.dll.
This is what we at @0patch have been doing (albeit more "surgically" modifying just a part of a function) for 9 years now, and it's nice to see Microsoft finally joining the party on on-prem Windows.
However, this is bad news for patch analysis. Simply diffing two consecutive EXE/DLL versions no longer gives one a reliable list of changes in said EXE/DLL. With the CVE-2024-21413 patch Outlook self-patches ole32.dll loaded in its process and replaces original function ole32!MkParseDisplayName with its own function. Diffing ole32.dll does not reveal that.
@HaifeiLi @xaitax Interestingly, this "!" trick has been used before in a CVE-2021-40444 exploit as noticed by @wdormann back in 2021
Having a @tetrane REVEN one-on-one training today - absolutely LOVING every moment as well as the potential of this product. My jaw dropped even further when I saw the integration with WinDbg. I didn't know I needed it until I saw it :)
@tetrane For those who don't know @tetrane REVEN yet: it allows you to do a recording of an entire virtual machine, and then walk forward and back through execution of any process, search who changed some memory location and when, trace the flow of data using tainting (forward and back).
So you have a crash and want to see why it happened. Oh, process tried to write to [rdx] which points to 0x41414141. Where did this value come from? Ok, it was read from address 0x2235543F2. Who wrote it there? Check the ENTIRE history of this address and find the last write.
Today's Microsoft cloud services outage is a perfect plot twist to the "Everyone stop using on-prem Exchange and migrate to Office 365" fairy tale.
I sense a strong presence of actual Exchange admins in retweets and likes above, the presence I sensed severely lacking in a popular Twitter thread condescendingly promoting said fairy tale :)