MS14-066 / CVE-2014-6321

[Update 2014/11/18]
Details of the vulnerability have been released. If you still haven’t patched internet-facing Windows systems, do it ASAP.
[Update]

After all the (well, partly justified) rage and criticism openssl or free/open source software in general received recently with fuckups like the heartbleed, changecipherspec or shellshock vulnerabilities, it’s been about time for a major vulnerability of a similar scale in our most beloved Windows systems.

This security update resolves a privately reported vulnerability in the Microsoft Secure Channel (Schannel) security package in Windows. The vulnerability could allow remote code execution if an attacker sends specially crafted packets to a Windows server.
The security update addresses the vulnerability by correcting how Schannel sanitizes specially crafted packets.Mitigating Factors
Microsoft has not identified any mitigating factors for this vulnerability.
Workarounds
Microsoft has not identified any workarounds for this vulnerability.
FAQWhat might an attacker use the vulnerability to do?
An attacker who successfully exploited this vulnerability could run arbitrary code on a target server.

How could an attacker exploit the vulnerability?
An attacker could attempt to exploit this vulnerability by sending specially crafted packets to a Windows server.

What systems are primarily at risk from the vulnerability?
Server and workstation systems that are running an affected version of Schannel are primarily at risk.

Oh? What do we have here? Is this an unauthenticated remote code execution vulnerability in the schannel Windows SSL/TLS library, affecting every Windows version since 2003 (probably XP and maybe 2000 as well)?. Let the SSL/TLS fuzzing begin; it’s probably only a matter of time until a PoC exploit is published (if it isn’t already in some secret channels, this was “privately reported”). Patch that stuff now.
Incidentally, this update also adds two new TLS 1.2 cipher suites to the schannel repository.

openssl heartbleed attack – The cryptocalypitc judgement day has arrived

The internet is now (no really, this time it is, pinky-promise) officially broken™. Or at least a large part of it that is responsible for securely handing your shopping cart and credit card information, e-mails, passwords, router configuration or whatever flows through your tubes over encrypted SSL/TLS connections.

That escalated quickly.Since yesterday there’s a big fuss on the internet over the so-called openssl heartbleed bug that was disclosed yesterday. It exploits the TLS heartbeat extensions and allows an attacker to read up to 64KiB of memory managed by openssl from the target system. This memory could contain sensitive data such as passwords, session-cookies, credit card information, or in one of the worst cases even the server’s x509 certificate private key. Since the attack is basically untraceable (no webserver logs or anything), it’s entirely possible that certificate private keys have been compromised en masse already without anyone noticing and never being able to find out.
You can find some interesting background information about the discovery and disclosure in this article.

To be on the really safe side, you have to replace your certificates, revoking the old ones, changing passwords and generally being PITA’d. Note that this has nothing to do with the openssl version a certificate was generated with, but is about the runtime application using openssl for it’s SSL/TLS traffic. Your private key can be just as compromised if you generated the certificate with Windows CA tools or gnutls and use it with an openssl-based application. Continue reading

July 2012 ESXi and vCenter updates

Yesterday and today VMware released an unusual Update for vCenter (and VCSA) titled “5.0 Update 1a” as well as couple regular bug fixes and security patches for ESXi 5 hosts.
Update Aug 20 2012: VMware recently released vCenter 5.0 Update 1b, which replaces 1a due to some issues with Oracle databases. Apart from that, there seem no other new fixes that weren’t present in 1a already. So if you’re on 1a already with a non-oracle database, there is no real need to upgrade to 1b.

VMware vCenter Server 5.0 Update 1a – a as in accident? Update 1b – b as in bummer

Grab the official release notes here:
https://www.vmware.com/support/vsphere5/doc/vsp_vc50_u1a_rel_notes.html
https://www.vmware.com/support/vsphere5/doc/vsp_vc50_u1b_rel_notes.html

It’s the first time VMware officially released such an official out-of-band update for vCenter with a small set of fixes and enhancements, I was quite surprised too. As expected of such a minor update, it doesn’t provide any significant new features. Adding support for using vCenter with some very specific Oracle version, or switching from DB2 to PostgreSQL for the VCSA? Ok, next please.
Much more interesting and probably the reason why they made this move in the first place, are a couple of bugs this update fixes. One of them is the infamous Storage vMotion dvSwitch issue for which until now the workaround meant some manual labor or running scripts after each Storage vMotion (including SDRS).
The other fixes don’t seem particulary interesting, but I’m glad VMware finally fixed the Storage vMotion issue.

Oh joy, installing another complete vSphere Client of a whooping 350MB for just a few vCenter-side fixes! Not speaking of the actual vCenter “update” process which is essentially a whole reinstall of the new version every time.
Will VMware ever offer a proper patching method for this? Praying seems to be the only hope left.

New set of ESXi 5 patches – (a as in) adhering to a patchday policy?

Note: You do not need the above mentioned 5.0 U1a vCenter for these ESXi patches.
Less unusual appears to be the release of a series of new ESXi 5 patches for both, security and bug fixing reasons. It’s been almost exactly a month (hello patchday) since the last security patch, which was a really important one, but luckily these two new security patches for a libxml 3rd party component and a stability issue in the VMware Tools don’t seem that critical to require your immediate attention (rated important by VMware).
I will highlight a few fixes and points from the patch notes I personally deem important:

Security patches:
VMware ESXi 5.0, Patch ESXi500-201207101-SG: Updates esx-base
>This patch updates the esx-base VIB to incorporate an important libxml2 security update.
VMware ESXi 5.0, Patch ESXi500-201207102-SG: Updates tools-light
   >This patch updates the tools-light VIB to resolve a stability issue in VMware Tools.
The full advisory that came with the first patch is available here: http://www.vmware.com/security/advisories/VMSA-2012-0012.html

Other bug fixing patches:
VMware ESXi 5.0, Patch ESXi500-201207401-BG: Updates esx-base
   >PR 831801: The default value of FIN_WAIT_2 timer was erroneosly set to TCPTV_KEEPINTVL * TCP_KEEPCNT = 75* 0x400. This discrepancy results in the socket at FIN_WAIT_2 state to exist for a much longer time and if multiple such sockets are accumulated, they might impact new socket creation.
    >PR 835040: An ESXi host might not respond or get disconnected due to the esx.conf file being locked. This might happen because when updating the ESX configuration (esx.conf configuration file) a lock file /etc/vmware/esx.conf.LOCK is created and it is linked to the process attempting to lock the file. If the link (known as a symlink) is not valid then it prevents the esx.conf from being unlocked.
    >PR 838922: An ESXi host might not restart UDP logging after a temporary interruption that might be caused by target server reboot or network UDP package being lost.
    >PR 838946: During the installation of Windows Server 2012 or Windows 8 64-bits virtual machine, the virtual machine displays a black screen with a loading icon and stops responding during the start-up process.
    >PR 848382: An ESXi host might become unresponsive with a purple diagnostic screen (PSOD) that displays messages similar to the following if any changes are made to BufferCache.HardMaxDirty.
    >PR 866810: On Dvportgroup, a promiscuous port might not work in promiscuous mode if the DVMirror sessions are reconfigured.
    >PR 855177: If you configure the loghost of syslogd incorrectly via esxcli or edit the /etc/vmsyslog.conf file directly followed by syslog reload, syslogd might terminate abruptly. You might notice the following symptoms with this issue:
VMware ESXi 5.0, Patch ESXi500-201207402-BG: Updates tools-light
 >PR 751508: Windows Vista and later versions of Windows do not recommend allowing services to be interactive; however, VMware Tools Service is installed as an interactive service.
VMware ESXi 5.0, Patch ESXi500-201207403-BG: Updates scsi-mptsas
VMware ESXi 5.0, Patch ESXi500-201207405-BG: Updates misc-drivers
VMware ESXi 5.0, Patch ESXi500-201207406-BG: Updates net-e1000
Just your usual driver updates with no detailed info of the last 3 here.

You can install VMware Tools updates without maintenance mode or reboots btw. since it effectively only overwrites the Tools ISO images in /vmimages/tools-isoimages. Note that ESX(i)4 patches are also pending to be released. As per VMware support for a case we have open, I also expect a real vCenter and ESXi  5.0U2 to be released soon-ish. Maybe around VMworld 2012 and with the potential release of vSphere 5.1?