
Vulnerability in Microsoft TLS library could allow remote code execution - molf
https://technet.microsoft.com/library/security/ms14-066
======
mike_hearn
After Heartbleed, I decided to run a Java servlet container as my direct web
server so I can use JSSE rather than OpenSSL or some other SSL stack written
in C. It seems to me that if you can, an SSL stack written in a safe language
is not a bad idea. JSSE is pretty modern though doesn't support every possible
feature (it's missing OCSP stapling at the moment). But it can do forward
secrecy and AES-GCM. I get an A- from the Qualys test: for some reason PFS
doesn't work with IE and it doesn't like that my cert has a SHA1 based
signature (I'll go get my cert reissued at some point). Oh and the SCSV
fallback hack is missing. Otherwise it's doing OK. And ... no buffer
overflows.

~~~
diminoten
How performant is that setup, out of curiosity? I've always assumed the
tradeoff here is a safe language is slower, and slow crypto is no bueno.

~~~
Someone1234
At runtime modern Java is around 10x slower than modern C++ (assuming both are
fully optimised and the benchmark is relatively unbiased).

That isn't significant on modern hardware relative to other bottlenecks
(network, IO, etc). Plus people keep adding additional security layers between
C/C++ and the CPU which eat away at some of its advantages (e.g. Docker
containers, virtual machines, exploit detection libraries, etc).

Java speed matters in certain situations and for certain tasks. For example I
wouldn't rewrite an SQL database into Java since performance could definitely
be impactful there. But realistically CPU times are such a tiny minority of
latency that it stopped being relevant a very long time ago.

~~~
mike_hearn
_At runtime modern Java is around 10x slower than modern C++ (assuming both
are fully optimised and the benchmark is relatively unbiased)._

I don't think you can pick a single number like that, it depends very much on
what the code is doing.

You probably got this 10x figure from a Google paper published a few years ago
([https://days2011.scala-
lang.org/sites/days2011/files/ws3-1-H...](https://days2011.scala-
lang.org/sites/days2011/files/ws3-1-Hundt.pdf)). Redux: the default out of the
box 32 bit JVM (in 2011) was 12x slower than the same algorithm implemented in
Java. But with a few simple GC flag changes, it became 3.7x slower. And then
the Java version had a few further simple optimisations applied to the code
and it became as fast as the original C++ version.

Meanwhile the C++ version was optimised again and became around 3x to 5x
faster, but that version relied heavily on Google proprietary data structure
code and could not be open sourced (!). So for most programmers on most
projects, it seems likely to be a wash.

Meanwhile an alternative benchmark that reimplemented a non-trivial C++
program in Java found it became 1.09 to 1.5 times slower, but that was with
Java 6 which is now two generations out of date:

[http://www.best-of-
robotics.org/pages/publications/gherardi1...](http://www.best-of-
robotics.org/pages/publications/gherardi12java.pdf)

It would be interesting to get more recent benchmarks with the latest JVMs and
C++ compilers.

~~~
TheLoneWolfling
As you say, it depends very much on what the code is doing.

In particular, anything requiring manipulating unsigned values all over the
place will be a lot slower.

Also, see this[1] for talk about JGit. An actual project with direct
comparisons.

[1]
[http://marc.info/?l=git&m=124111702609723](http://marc.info/?l=git&m=124111702609723)

~~~
pjmlp
Those comparisons will be again out of date when Java 9+ comes out with value
types, official unsafe package and lots of other goodies for performance being
worked on.

~~~
mike_hearn
I'm not aware of any intent on adding unsigned types in Java 9 though. The
lack of them is a real PITA, for sure. Not only for performance but it's
incredibly easy to forget a & 0xFF here or there and introduce bugs.

The MMAP thing is also a good point. I believe HotSpot will compile the get
methods on the MappedByteBuffer down to raw access so it shouldn't matter much
for performance, in theory, but the code is still damned ugly. I never
understood why they can't expose it as a byte[].

~~~
pjmlp
> I'm not aware of any intent on adding unsigned types in Java 9 though.

You kind of have them in Java 8, but not as primitive type.

[https://blogs.oracle.com/darcy/entry/unsigned_api](https://blogs.oracle.com/darcy/entry/unsigned_api)

I also think a very least having ubyte would be quite nice.

Apparently the reason behind the decision has to do with overflows and
underflows in unsigned arithmetic.

Hotspot is just one of many Java native compilers out there , so it is better
not to rely on what Hotspot does.

On the other hand, you can make use of JIT Watch or Solaris Studio debugging
to see what Assembly is being generated.

> I never understood why they can't expose it as a byte[].

Maybe the official unsafe class will make this better.

------
mpyne
No acknowledgement of the source, either in the Technet article or the
security bulletin's acknowledgements. I wonder who the private source must be
that would ask for anonymity?

~~~
stusmall
Here[1] I saw that it was from an internal audit.

[1]
[http://blogs.technet.com/b/srd/archive/2014/11/11/assessing-...](http://blogs.technet.com/b/srd/archive/2014/11/11/assessing-
risk-for-the-november-2014-security-updates.aspx)

EDIT: Added a better source.

------
codys
I'm interested in knowing if this affects Windows XP. From the page:

> Other versions or editions are either past their support life cycle or are
> not affected

And XP is unlisted. Seems to imply that it could be either one.

~~~
ams6110
XP is not supported. Why would they make a statement one way or the other?

~~~
hueving
To face the reality that there are a ton of XP deployments. It would be in
Microsoft's interest to at least notify them of the problem and even
incentivize them to upgrade.

~~~
tracker1
Well, XP likely has the same issues in their implementation, given similar
origins, especially for older protocols. XP requires SP3 for TLS1 iirc, and
doesn't support > TLS 1.0, let alone 1.1 or 1.2 (current).

There are other issues with browsers (namely that a lot of XP users are still
using IE8, which has a host of other issues).

The project I am now on isn't supporting IE8, we're going to load some
HTML5/ES6 shims, and a notice to users that it may not work, but given how
poorly MS's VMs for testing IE8 on XP are, it's really a non-starter. IE8 is
about 3-4% of our current traffic, which will likely be displaced by mobile
traffic once our site/app is no longer mobile hostile.

I wouldn't consider XP a viable OS at this point, and many users would be
better off with a more recent ubuntu, and wine.

------
yuhong
Wonder why didn't they add GCM with ECDHE even though it is already in Win10
preview. I considered it strange that they added GCM with DHE in the first
place when all the rest of the suites are ECDHE.

~~~
mike_hearn
From the article:

 _Does this update contain any additional security-related changes to
functionality?

Yes. In addition to the changes that are listed in the Vulnerability
Information section of this bulletin, this update includes changes to
available TLS cipher suites. This update includes new TLS cipher suites that
offer more robust encryption to protect customer information. These new cipher
suites all operate in Galois/counter mode (GCM), and two of them offer perfect
forward secrecy (PFS) by using DHE key exchange together with RSA
authentication._

~~~
Perseids
I don't see the relevance of the quote. It only states the changes and not why
other changes were not made.

------
servowire
The attack vector is a bit vague, and I'm not sure how to bring this news to
some of my clients.

Is the exploit only for when running services on/to the internet (IIS,
Exchange webmail, etc - ) , or is visiting an https (TLS) website on and end-
user enough to make the exploit happen (even in Firefox/Chrome and behind a
tradional proxy server).

Sadly Microsoft does not explain the exact parameters that make this exploit
tick - this makes risk assessment hard.

~~~
el_duderino
Indeed it does make it tricky, but I think they purposely left out some
details for the time being.

See more: [http://adi.is/winshock.txt](http://adi.is/winshock.txt)

------
dmix
_Triggers the tptacek bat signal_ (or other kind infosec people)

How worried should people reasonably be?

~~~
jeffmcjunkin
I'm not tptacek, but right now I think the answer is: "We don't know."

There isn't an acknowledged proof-of-concept, so we're not sure that it's
exploitable. It hasn't been made clear whether it's wormable, either.

My bet is it will affect XP if it's exploitable, but only for those who added
IIS (not default, and not terribly common). It will likely remain unpatched
forever, as Microsoft is unlikely to send a patch to an "unsupported" OS
again, like they did with the Internet Explorer 0-day [0]

[0]: [http://blogs.technet.com/b/msrc/archive/2014/05/01/out-of-
ba...](http://blogs.technet.com/b/msrc/archive/2014/05/01/out-of-band-release-
to-address-microsoft-security-advisory-2963983.aspx)

~~~
userbinator
_It will likely remain unpatched forever_

By Microsoft, but I'd bet someone else is definitely going to fix it and
distribute a patch. If the amount of effort put forth by the Windows _98SE_
community in making unofficial patches that let much newer applications work
is any indication (look up KernelEx and "98SE unofficial service pack"), XP is
going to enjoy an even larger community of unofficial support.

------
Robin_Message
We upgraded to this, only to find it activates some new encryption modes (4
new GCM suites) that seem to cause RST packets when used. Anyone else seen
that issue?

(Technical details: If the client offer one of the suites, the server is
accepting it in the ServerHello, but then RSTing the connection after the
client sends their encrypted handshake, and the event log says "none of the
cipher suites supported by the client application are supported by the
server". Browser and curl don't use that suite, but Amazon ELB does.)

------
0x0
Is this the beginning of another sasser/codered worm?

------
executive
could allow? or allows?

~~~
13
Go with the assumption that it does.

------
aluhut
4 hours for 5MB? Wow...

