Monthly Archives: November 2014

US-CERT

TA14-323A: Microsoft Windows Kerberos KDC Remote Privilege Escalation Vulnerability

Original release date: November 19, 2014

Systems Affected

  • Microsoft Windows Vista, 7, 8, and 8.1
  • Microsoft Server 2003, Server 2008, Server 2008 R2, Server 2012, and Server 2012 R2

Overview

A remote escalation of privilege vulnerability exists in implementations of Kerberos Key Distribution Center (KDC) in Microsoft Windows which could allow a remote attacker to take control of a vulnerable system. [1]

Description

The Microsoft Windows Kerberos KDC fails to properly check service tickets for valid signatures, which can allow aspects of the service ticket to be forged. The improper check allows an attacker to escalate valid domain user account privileges to those of a domain administrator account, which renders the entire domain vulnerable to compromise.

At the time this release was issued, Microsoft was aware of limited, targeted attacks attempting to exploit this vulnerability.

Impact

A valid domain user can pass invalid domain administrator credentials, gain access and compromise any system on the domain, including the domain controller. [2]

Solution

An update is available from Microsoft. Please see Microsoft Security Bulletin MS14-068 and Microsoft Research Security and Defense Blog for more details, and apply the necessary updates.[1, 3] 

References

Revision History

  • November 19, 2014: Initial Draft

This product is provided subject to this Notification and this Privacy & Use policy.

Fedora

Fedora EPEL 6 Security Update: nodejs-0.10.33-1.el6,libuv-0.10.29-1.el6

Resolved Bugs
1161900 – nodejs: CVE-2014-3566 fixed upstream in new stable release v0.10.33
1152789 – CVE-2014-3566 SSL/TLS: Padding Oracle On Downgraded Legacy Encryption attack<br
This release handles the recent POODLE vulnerability by disabling SSLv2/SSLv3
by default for the most predominate uses of TLS in Node.js.
It took longer than expected to get this release accomplished in a way that
would provide appropriate default security settings, while minimizing the
surface area for the behavior change we were introducing. It was also important
that we validated that our changes were being applied in the variety of
configurations we support in our APIs.
With this release, we are confident that the only behavior change is that of
the default allowed protocols do not include SSLv2 or SSLv3. Though you are
still able to programatically consume those protocols if necessary.
Included is the documentation that you can find at
https://nodejs.org/api/tls.html#tls_protocol_support that describes how this
works going forward for client and server implementations.
—
Node.js is compiled with SSLv2 and SSLv3 protocol support by default, but these
protocols are **disabled**. They are considered insecure and could be easily
compromised as was shown by CVE-2014-3566. However, in some situations, it
may cause problems with legacy clients/servers (such as Internet Explorer 6).
If you wish to enable SSLv2 or SSLv3, run node with the `–enable-ssl2` or
`–enable-ssl3` flag respectively. In future versions of Node.js SSLv2 and
SSLv3 will not be compiled in by default.
There is a way to force node into using SSLv3 or SSLv2 only mode by explicitly
specifying `secureProtocol` to `’SSLv3_method’` or `’SSLv2_method’`.
The default protocol method Node.js uses is `SSLv23_method` which would be more
accurately named `AutoNegotiate_method`. This method will try and negotiate
from the highest level down to whatever the client supports. To provide a
secure default, Node.js (since v0.10.33) explicitly disables the use of SSLv3
and SSLv2 by setting the `secureOptions` to be
`SSL_OP_NO_SSLv3|SSL_OP_NO_SSLv2` (again, unless you have passed
`–enable-ssl3`, or `–enable-ssl2`, or `SSLv3_method` as `secureProtocol`).
If you have set `securityOptions` to anything, we will not override your
options.
The ramifications of this behavior change:
* If your application is behaving as a secure server, clients who are `SSLv3`
only will now not be able to appropriately negotiate a connection and will be
refused. In this case your server will emit a `clientError` event. The error
message will include `’wrong version number’`.
* If your application is behaving as a secure client and communicating with a
server that doesn’t support methods more secure than SSLv3 then your connection
won’t be able to negotiate and will fail. In this case your client will emit a
an `error` event. The error message will include `’wrong version number’`.
—
2014.10.20, node.js Version 0.10.33 (Stable)
* child_process: properly support optional args (cjihrig)
* crypto: Disable autonegotiation for SSLv2/3 by default (Fedor Indutny, Timothy J Fontaine, Alexis Campailla)
This is a behavior change, by default we will not allow the negotiation to
SSLv2 or SSLv3. If you want this behavior, run Node.js with either
`–enable-ssl2` or `–enable-ssl3` respectively.
This does not change the behavior for users specifically requesting
`SSLv2_method` or `SSLv3_method`. While this behavior is not advised, it is
assumed you know what you’re doing since you’re specifically asking to use
these methods.
—
2014.10.21, libuv Version 0.10.29 (Stable)
Relevant changes since version 0.10.28:
* linux: try epoll_pwait if epoll_wait is missing (Michael Hudson-Doyle)

Fedora

Fedora EPEL 7 Security Update: nodejs-0.10.33-1.el7,libuv-0.10.29-1.el7

Resolved Bugs
1161900 – nodejs: CVE-2014-3566 fixed upstream in new stable release v0.10.33
1152789 – CVE-2014-3566 SSL/TLS: Padding Oracle On Downgraded Legacy Encryption attack<br
This release handles the recent POODLE vulnerability by disabling SSLv2/SSLv3
by default for the most predominate uses of TLS in Node.js.
It took longer than expected to get this release accomplished in a way that
would provide appropriate default security settings, while minimizing the
surface area for the behavior change we were introducing. It was also important
that we validated that our changes were being applied in the variety of
configurations we support in our APIs.
With this release, we are confident that the only behavior change is that of
the default allowed protocols do not include SSLv2 or SSLv3. Though you are
still able to programatically consume those protocols if necessary.
Included is the documentation that you can find at
https://nodejs.org/api/tls.html#tls_protocol_support that describes how this
works going forward for client and server implementations.
—
Node.js is compiled with SSLv2 and SSLv3 protocol support by default, but these
protocols are **disabled**. They are considered insecure and could be easily
compromised as was shown by CVE-2014-3566. However, in some situations, it
may cause problems with legacy clients/servers (such as Internet Explorer 6).
If you wish to enable SSLv2 or SSLv3, run node with the `–enable-ssl2` or
`–enable-ssl3` flag respectively. In future versions of Node.js SSLv2 and
SSLv3 will not be compiled in by default.
There is a way to force node into using SSLv3 or SSLv2 only mode by explicitly
specifying `secureProtocol` to `’SSLv3_method’` or `’SSLv2_method’`.
The default protocol method Node.js uses is `SSLv23_method` which would be more
accurately named `AutoNegotiate_method`. This method will try and negotiate
from the highest level down to whatever the client supports. To provide a
secure default, Node.js (since v0.10.33) explicitly disables the use of SSLv3
and SSLv2 by setting the `secureOptions` to be
`SSL_OP_NO_SSLv3|SSL_OP_NO_SSLv2` (again, unless you have passed
`–enable-ssl3`, or `–enable-ssl2`, or `SSLv3_method` as `secureProtocol`).
If you have set `securityOptions` to anything, we will not override your
options.
The ramifications of this behavior change:
* If your application is behaving as a secure server, clients who are `SSLv3`
only will now not be able to appropriately negotiate a connection and will be
refused. In this case your server will emit a `clientError` event. The error
message will include `’wrong version number’`.
* If your application is behaving as a secure client and communicating with a
server that doesn’t support methods more secure than SSLv3 then your connection
won’t be able to negotiate and will fail. In this case your client will emit a
an `error` event. The error message will include `’wrong version number’`.
—
2014.10.20, node.js Version 0.10.33 (Stable)
* child_process: properly support optional args (cjihrig)
* crypto: Disable autonegotiation for SSLv2/3 by default (Fedor Indutny, Timothy J Fontaine, Alexis Campailla)
This is a behavior change, by default we will not allow the negotiation to
SSLv2 or SSLv3. If you want this behavior, run Node.js with either
`–enable-ssl2` or `–enable-ssl3` respectively.
This does not change the behavior for users specifically requesting
`SSLv2_method` or `SSLv3_method`. While this behavior is not advised, it is
assumed you know what you’re doing since you’re specifically asking to use
these methods.
—
2014.10.21, libuv Version 0.10.29 (Stable)
Relevant changes since version 0.10.28:
* linux: try epoll_pwait if epoll_wait is missing (Michael Hudson-Doyle)

NVD

CVE-2014-6324 (windows_7, windows_8, windows_8.1, windows_server_2003, windows_server_2008, windows_server_2012, windows_vista)

The Kerberos Key Distribution Center (KDC) in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, and Windows Server 2012 Gold and R2 allows remote authenticated domain users to obtain domain administrator privileges via a forged signature in a ticket, as exploited in the wild in November 2014, aka “Kerberos Checksum Vulnerability.”