In October 2023, Microsoft patched a critical Denial of Service (DoS) vulnerability (CVE-2023-36585) affecting the Active Template Library (ATL), a commonly used set of C++ templates for COM objects, especially in Windows applications. This long read will help you understand what the vulnerability is, how it can be exploited, and what you can do to stay protected. We'll include an explanation, code examples, and key references. Let's break it down in plain English.

What Is the Active Template Library (ATL)?

ATL is a set of C++ template classes developed by Microsoft to simplify developing COM (Component Object Model) objects. A lot of Windows software uses COM via ATL, especially those that need high performance.

ATL is shipped with Microsoft Visual Studio and is widely deployed—if you’re running Windows or build native Windows apps, you very likely have code using ATL under the hood.

What Is CVE-2023-36585?

CVE-2023-36585 is a Denial of Service (DoS) vulnerability found and disclosed in Windows versions shipped before October 2023. Exploiting it lets a remote attacker cause an affected service or application to stop responding—often requiring a manual restart.

According to Microsoft Security Guidance:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36585

Attack Vector: Network (over the wire!)

### Impact: Denial of Service *(No code execution, no privilege escalation, but service/app crash is possible.)*

Vulnerability Details

The vulnerability lies in the way Microsoft’s ATL handles specially crafted method calls or object marshaling/unmarshaling. An unauthenticated attacker could send a malformed request that triggers a crash in the target application or service using ATL.

Microsoft’s Summary:
> "A denial of service vulnerability exists when the Active Template Library improperly handles objects in memory. An attacker who successfully exploited this vulnerability could cause a target application to stop responding."
— Microsoft

The vulnerability triggers a null-pointer dereference or similar memory access issue when certain COM objects are initialized or queried in a non-standard way, leading to a process crash.


## Proof-Of-Concept/Exploit Details

This bug is particularly dangerous for applications that expose COM objects remotely or across network boundaries (like DCOM or OLE Automation).

Simple Exploit Idea

A remote attacker can register a COM client, then send a malformed request for a specific ATL object method, causing the server (or application) to crash.

Here’s a simplified example in Python using pywin32 (THIS IS FOR EDUCATIONAL PURPOSES ONLY)

import pythoncom
import win32com.client

# Replace with actual ProgID of the vulnerable ATL COM object
PROG_ID = "Vulnerable.ATLObject"

try:
    obj = win32com.client.Dispatch(PROG_ID)
    # Send a malformed parameter (e.g., None or oversized buffer)
    obj.SomeMethod(None)
    print("Method call succeeded (not vulnerable or fixed).")
except Exception as e:
    print("Crash or error: Might be vulnerable:", e)

*Replace Vulnerable.ATLObject and SomeMethod with actual object and method names, as appropriate.*

Another typical attack uses marshaled COM objects with unexpected/unverified arguments that ATL does not adequately check, leading to unexpected terminations.

Let’s say you have this COM class

#include <atlbase.h>
#include <atlcom.h>

class ATL_NO_VTABLE CVulnerableObj : 
    public CComObjectRootEx<CComSingleThreadModel>,
    public CComCoClass<CVulnerableObj, &CLSID_VulnerableObj>,
    public IDispatchImpl<IVulnerableObj, &IID_IVulnerableObj, &LIBID_TestLib, /*wMajor =*/ 1>
{
public:
    // Other ATL declarations

    STDMETHOD(SomeMethod)(VARIANT* param)
    {
        // Vulnerable: improper parameter validation
        // A malformed VARIANT (e.g., invalid type or pointing to unmapped memory)
        // can crash the process here.
        if (param->vt == VT_BSTR)
        {
            // Use param->bstrVal without full verification
        }
        // ...
        return S_OK;
    }
};

An attacker sending a malformed (or purposely invalid) parameter can crash the ATL object.

Run old (pre-Oct 2023) builds of ATL-enabled software

- Use fuzzing tools to test interface robustness, such as Peach Fuzzer or BooFuzz

Mitigation & Patch

Microsoft released a patch:
KB5031356

Apply all Windows Updates released in October 2023 or later

- Rebuild and redeploy ATL components using patched Visual Studio versions (check for ATL library updates)

References & Further Reading

- Official CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36585
- Microsoft Advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36585
- Microsoft Patch: https://support.microsoft.com/en-us/topic/october-10-2023-kb5031356-os-build-22621-2428-and-22631-2428-d6b464a5-c9d9-4ae3-b720-071d3f30d74b
- ATL COM Overview: https://learn.microsoft.com/en-us/cpp/atl/atl-com-overview?view=msvc-170
- ACROS Security blog post (early analysis)

Recap

CVE-2023-36585 is a reminder: COM and ATL can still expose serious risks! Even if there’s no obvious “hack” or remote compromise, a simple input can crash critical business services—sometimes causing big downtime.

Patch your systems.

- Never trust raw/unvalidated input.


Stay safe! And if you’re a developer, make sure your code checks every parameter—because attackers sure will.


*This post was written exclusively for educational and awareness purposes. Do not attempt to exploit this vulnerability on any system without permission.*

Timeline

Published on: 10/10/2023 18:15:14 UTC
Last modified on: 10/13/2023 19:09:26 UTC