Tag Archives: Hotfix

Security Updates for Exchange 2013 & 2016

Posted on by
9

Despite the quarterly wave of Cumulative Updates being imminent, CVE-2017-11932 and ADV170023 warranted a quick release of Security Update KB4045655 for current versions of Exchange 2013 and Exchange 2016.

This security update fixes a vulnerability in OWA, which could allow elevation of privilege or spoofing if an attacker sends an email that has a specially crafted attachment to a vulnerable Exchange server.

You can download the security updates here:

Be advised the update may leave your Exchange services in a disabled state, despite installing correctly. In those cases, reconfigure those services to Automatic and start them manually.

Also note that this security update overrides an earlier update, KB4036108, which might cause Calendar Sharing issues when split DNS is used.

Security updates are Cumulative Update level specific. Be advised that updates may carry the same name, e.g. the update for CU7 and the one for CU6 are both Exchange2016-KB4045655-x64-en.msp. I suggest adding some form of Cumulative Update identification to the file name when archiving it, e.g. Exchange2016-KB4045655-x64-en-CU7.msp.

As with any patch or update, I’d recommend to thoroughly test this in a test and acceptance environment first, prior to implementing it in production.

 

Exchange 2010-2016 Security Fixes

Posted on by
4

Ex2013 LogoMicrosoft released security updates to fix a remote code execution vulnerability in Exchange Server. The related knowledge base article is KB4018588.

More information is contained in the following Common Vulnerabilities and Exposures articles:

  • CVE-2017-8521 – Scripting Engine Memory Corruption Vulnerability
  • CVE-2017-8559 – Microsoft Exchange Cross-Site Scripting Vulnerability
  • CVE-2017-8560 – Microsoft Exchange Cross-Site Scripting Vulnerability

Depending on the lifecycle status of the product, fixes are made available either through a Rollup or as a security fix for the following product levels:

As you might notice, the security fix is made available for the N-1 builds of Exchange 2013 and Exchange 2016. This could imply the issue was addressed in the latest builds of those products. I hope to receive official confirmation on this soon.

The issue is deemed Important, which means organizations are advised to apply these updates at the earliest opportunity. However, as with any update, it is recommended to thoroughly test updates and fixes prior to deploying them in a production environment.

MS17-015: Security Fix for Exchange 2013 SP1+CU14 & 2016 CU3

Posted on by
3

Ex2013 LogoMicrosoft published security fixes for the issue described in bulletin MS17-105. Fixes have been released for the following product levels:

You are reading it correctly: the later Cumulative Updates are not affected. Earlier builds will not receive a security fix, as support is provided up to N-2 generation builds. Reason for Exchange 2013 SP1 being in there is that Service Packs are on a different support scheme.

Note that this Rollup or security fix replaces MS16-108 (kb3184736) – you can install MS13-105 over installations containing this security fix (no need to uninstall it first).

Advisory: Hold off deploying Exchange 2016 CU3 on WS2016 for now

Posted on by
4

Ex2013 LogoLast Update: December 13th, 2016: The Windows team published an update for Windows Server 2016, which should fix the issue with DAG members crashing when restarted. The related article is KB3206632, and you can download it here. Be advised, the Windows Server 2016 update – which also fixes other issues – is nearly 1 GB!

About one month ago, Exchange Server 2016 Cumulative Update 3 was released which supported deployment on Windows Server 2016. However, recently issues are being reported on various communities as well in related blog comments, where Exchange 2016 became unstable, symptoms being randomly crashing IIS application pools (which says nothing about the root cause).

Microsoft acknowledged there is an issue with Exchange Server 2016 CU3 on Windows Server 2016:

If you attempt to run Microsoft Exchange 2016 CU3 on Windows Server 2016, you will experience errors in the IIS host process W3WP.exe. There is no workaround at this time. You should postpone deployment of Exchange 2016 CU3 on Windows Server 2016 until a supported fix is available.

So, be advised to hold off to deploying Exchange 2016 on Windows Server 2016 until further notice.

Update: The Exchange Team has also posted a notice that an update is in the works, and to delay further Exchange 2016 deployments on Windows Server 2016 until this delay has been made available. No ETA on the update yet.

Mitigating MS15-034 exploit

Posted on by
2

WarningUpdate: Made changes to reflect that IIS Request Filtering will not work.

This week, Microsoft released a security fix MS15-034 (KB3042553) for IIS which potentially allows for remote code execution on IIS, denial of service attacks (DOS) or bugchecking of servers. Since Exchange leverages IIS, Exchange servers are affected.

The vulnerability is easy to exploit, using an HTTP or HTTPS request and specifying a Range header with a value of 18446744073709551615 (maximum 64-bit unsigned integer). The Range header, introduced in the HTTP/1.1 specification, can be used by the requester to receive only a portion of data, for example the first few bytes of a JPG to determine its dimensions.The issue occurs when you specify out of bounds value. for example, when using cURL you can specify:

curl -v https://exchangeserver.contoso.com/iisstart.htm -H "Host: contoso.com" -H "Range: bytes = 0-8192" -k
Exchange-fellow Dave Stork did a nice write-up on the issue and how to prevent it from happening, i.e.
  • The most recommended solution is of course to install the KB3042553 security fix on servers running IIS, starting with servers that are internet-facing.
  • Filter requests on your reverse proxy, load balancer or IPS solution:
    • KEMP has provided instructions how to accomplish this on their Loadmasters here.
    • F5 has provided instructions here.
    • ISC SANS institute provided instructions for SNORT here.
  • Disable IIS kernel caching, but this is not recommended due to negative impact on performance.

Unfortunately, Request Filtering is not an option so you can not prevent the exploit using IIS’ built-in Request Filtering feature. The Request Filtering will occur after parsing of the Range header, and it is in this parsing causing the issue.