This UAF vulnerability is caused by an unconstrained race condition,
The issue arises with the following associated functions: CClipBase::OnFileContentsRequest & CClipClient::OnMonitorReady
Reverse engineering yields the following pseudocode representation.
CClipBase::OnFileContentsRequest(...) {
[...]
hr = CFileContentsReaderManager::ProcessFileContentsRequest(this: this->m_pCFileContentsReader, ...) { // reference here
[...]
CFileContentsStreamReader::ValidateData(*(this + 6), a4, __PAIR64__(a3, a2)); {
OleGetClipboard(this + 5); // <-- CRASH
[...]
}
[...]
}
}
the another window is CClipClient::OnMonitorReady:
CClipClient::OnMonitorReady(...) {
[...]
CClipBase::GetFormatListFromOleClipboard(pbFormatList, pcbFormatList) {
[...]
ppCFileContentsReader = &this->m_pCFileContentsReader;
if ( this->m_pCFileContentsReader )
{
TCntPtr<CAutoReconnectDlg>::SafeRelease(&this->m_pCFileContentsReader); // Free
*ppCFileContentsReader = 0i64;
}
hr = CFileContentsReaderManager::CreateInstance(this->field_328, &this->m_pCFileContentsReader); // New
if ( hr >= 0 )
{
v15 = this->field_FC && IsClipboardFormatAvailable(0xFu);
hr = CFileContentsReaderManager::CreateReader(*ppCFileContentsReader, v15, &this->m_pCFgdCache, v14);
[...]
}
[...]
}
}
What needs to be noted is that the cliprdr channel protocol processes some messages asynchronously, corresponding to the function name rule: (CClipClient|CClipBase)::On.*AsyncCallback::Invoke.
Two functions handle messages: Server Monitor Ready PDU & File Contents Request PDU.
The former is normally sent during the Clipboard Redirection Initialization Sequence, while the latter is during Data Transfer Sequences. When we simultaneously send these two PDUs to trigger the functions,
there will be a competition for the variable referred to here as m_pCFileContentsReader. Specifically, the following scenarios may occur:
CClipBase::OnMonitorReady creates a CFileContentsReader instance.
CClipBase::OnFileContentsRequest calls CFileContentsReaderManager::ProcessFileContentsRequest to process clipboard contents.
CClipBase::OnMonitorReady is called again to destroy and create another CFileContentsReader instance.
This is the reason for the UAF formation.
PoC (pseudocode)
#include <Windows.h>
#include <Wtsapi32.h>
#include <iostream>
#include <cstdlib>
#include <cstdio>
#pragma comment(lib, "WtsApi32.lib")
// ......
CClipBaseController clip_ctl;
int main()
{
clip_ctl.send_server_clipboard_capabilities_req();
while (1) {
clip_ctl.send_monitor_ready_req();
clip_ctl.send_copy_seq_file_contents_req();
}
}