When an MS15-034 vulnerability notice lands on an ops team, two questions matter most: is my server within the affected range, and what if the patch can’t be applied right away? This post walks the full response path for CVE-2015-1635 in order: confirm the blast radius → respond (patching first, mitigation second) → verify the fix.

Symptoms and Affected Range

CVE-2015-1635 corresponds to Microsoft security bulletin MS15-034: HTTP.sys, the Windows HTTP protocol stack component, mishandles specially crafted HTTP requests during parsing. An attacker who sends a malicious request to an affected system can execute arbitrary code with System privileges — this is a kernel-level HTTP stack vulnerability, and the IIS web service sits right on top of it, so every server running IIS is directly exposed to the risk surface.

The affected environments are a fixed set of Windows generations (per the bulletin’s own list):

  • Windows 7 SP1 (32-bit / x64)
  • Windows Server 2008 R2 SP1 (x64 / Itanium, including Server Core)
  • Windows 8, Windows 8.1 (32-bit / x64)
  • Windows Server 2012, Windows Server 2012 R2 (including Server Core)

All of the above are rated Critical. Windows 10 / Server 2016 and later releases, which came after, are not affected. Checking your own server versions is step one: as long as the system version falls inside the list above and it serves HTTP to the outside, follow the response below.

The Vulnerability in One Sentence

When parsing the Range header of an HTTP request (the byte-range declaration used by resumable downloads), HTTP.sys mishandles integer overflow on very large values. An attacker sends an upper range bound approaching the 64-bit limit, corrupting kernel memory and ultimately executing code with kernel privileges. Once you understand this, the mitigation of “turning off the kernel cache” falls into place naturally — the kernel cache is the precondition switch that walks a Range request into the vulnerable code path.

Detection: Probe First Without Touching the System

Between the notice and the response there is often an approval process; in that window you can use one harmless request to probe whether a target is affected. The public detection method is sending a request with an oversized Range header to any static resource on the target site:

1
curl -i -H "Range: bytes=0-18446744073709551615" http://target-server/any-static-page

Based on public vulnerability analyses (no Windows in this environment; not live-tested): a 416 Requested Range Not Satisfiable response means the Range header was processed through the vulnerable path and the system is affected; a patched system rejects the malformed header (400 Bad Request, flagging an illegal header name). This is a read-only probe that sends no attack payload, but going through change management before running it in production is still advisable.

Response Measures

1. Apply the patch (the real fix)

Microsoft has released the fix (KB3042553), available through Windows Update or as a manual download from the security bulletin page:

https://docs.microsoft.com/zh-cn/security-updates/Securitybulletins/2015/ms15-034

The bulletin page contains the patch download entry and the affected-system version table — verify your system version before installing. After installation, reboot as prompted: HTTP.sys is a kernel component, and the new version only takes effect after the restart.

2. Temporarily disable the IIS kernel cache (mitigation)

For servers that cannot patch immediately, the official workaround is disabling the IIS kernel cache: in IIS Manager select the server node, open the Output Caching settings, turn off kernel caching, then restart IIS for it to take effect.

Note: not live-tested (a Windows/IIS environment cannot be verified in a container); the procedure follows the workaround description in Microsoft security bulletin MS15-034. The bulletin explicitly warns: this measure applies to IIS only and causes performance degradation — use it only as a temporary bridge until patching, and restore the kernel cache configuration once the patch is in.

Keep the priority straight: patching is the fix; disabling the kernel cache is only a mitigation — it closes the path that triggers the vulnerability, but the vulnerable code is still in the system. Once the patch is done, be sure to turn the cache back on, otherwise you carry the performance loss indefinitely.

Verifying the Fix

To confirm the patch is installed, query the list of installed updates on the server:

1
wmic qfe get HotFixID | findstr 3042553

KB3042553 appearing in the output means the patch is installed.

Note: command not live-tested (no Windows environment); wmic qfe listing installed updates is standard Windows practice; some newer systems have deprecated wmic — use “Settings → Update & Security → View update history” instead.

Prevention Going Forward

  • The first reaction to a vulnerability notice is confirming the blast radius, not rushing online for mitigation scripts — the blast radius sets the response priority.
  • Kernel-level component vulnerabilities (HTTP.sys, Winsock, etc.) usually come with a reboot requirement; reserve a maintenance window for patching.
  • Every temporary mitigation must have a rollback plan on record: the kernel cache disabled this time must be restored once the patch lands — miss that step and the performance problem lingers long before anyone notices.
  • Converge the external attack surface by service: expose IIS only when needed. The blast radius of a kernel-level vulnerability scales with exposure — when a notice arrives, machines with a smaller surface naturally rank lower in response priority.

This post was rewritten from the author’s CSDN blog articles originally published between 2020 and 2024 on CSDN.