Annus HORRIBILIS for TLS! ALL the bigguns now officially pwned in 2014 The appearance of a critical flaw in Microsoft SChannel - patched as part of this year's phenomenal November Patch Tuesday - means that every major TLS stack has now fallen victim to a critical flaw at some time during this year. The security flaw (MS14-066) in Microsoft's TLS cryptography library open the door to remote code …
So you're suggesting that this bug in Windows code arose because Microsoft were copying an open source TLS implmentation in 1995? Yes, the bug is that old. Why isn't the open source TLS stack that they copied also vulnerable?
If, as you allege, Microsoft have been just copying their code from free open source projects since the mid nineties, then why are you paying for Windows?
This page http://blogs.technet.com/b/srd/archive/2014/11/11/assessing-risk-for-the-november-2014-security-updates.aspx reckons that it was "Internally found during a proactive security assessment."
I'm guessing it was found when someone went checking the code after the heartbleed stuff.
It looks like the BBC have confused 2 bugs into one. From what I have read so far, there is an issue which has existed in the client OS since Windows 95 that was discovered by IBM. This is different to the SChannel server issue which appears to have been discovered interally. BBC are reporting them as one and the same.
In fairness to the BBC, it seems a lot of sites are confusing the issues. Many are referring to the TLS bug as 'Winshock' however it seems that name was first applied to the more critical buffer overflow issue in Internet Explorer CVE-2014-6332 (severity rating of 9.3 out of 10). Some articles even acknowledge that they are different issues but still imply a link between them.
It never ceases to amaze me, I take a few days away from monitoring the security news and all hell breaks loose.
I was wondering about those odd attacks coming from our vulnerability scanners. Now, I have to update the IPS and assorted other sensors with these vulnerabilities.
Oh well, it sure beats reading pcaps all day.
But as ever implementation is hard.
Ir ecall being told that I should avoid writing code as cleverly as I could, because bugs are always subtler than the code around them.
With really smart people working on this stuff I imagine some of the bugs are *really* subtle, and massively bad.
No, SSL (and TLS) are a disaster. They're simultaneously over-engineered and under-specified (at least up until TLS). They use the god-awful X.509 PKI (for suites with authentication). While TLS 1.1 has finally fixed most of the known inherent design flaws, it's terribly stovepiped.
And yes, implementation is hard. In fact, it seems to be impossible, since - as this article points out, and I pointed out a couple of days ago in response to another article - all the major current implementations have been shown to have severe, security-compromising flaws in less than a year.
Like any security measure, SSL is supposed to increase the attacker's work factor more than the defender's. It's proving to be rather poorer at the former than advertised, and not so great at the latter either.
Unfortunately, for many applications there's no good alternative currently available or on the horizon. SSH's DIY PKI is an unmitigated disaster, and PGP/GPG's isn't much better, even if it were suited to SSL-style applications. Various VPNs have their own security flaws and aren't suited to the ad hoc connections SSL is primarily used for. IPSec is dead in the water.
No, the difference is that MS users don't believe they use "superior code" just because they were told so. Unlike many open source users who have a religious faith in their model and believe it is perfect and leads to the best code ever written. Instead, both models will contains bugs, and some nasty one as well. Because after all everything comes down to the very programmer writing the code, and those officially in charge to review and test it. Beyond that, bugs can escape and lurk into code for years, before someone spots them - and that's regardless if the code is open or closed, because there's too much code to review nowadays, and too few eyes and brains willingly to dedicate their time to do it, even if the code is available.
It's not strange that all discoveries come from professional researches who have an economic incentive in hunting them - not from "freelance" coders who happily review someone else code...
You're right in that it comes down to the programmers in the first place. Round the programmers there's an environment with attitudes ranging from "It compiles, ship it" to "Only release when we're sure it's right". And those attitudes can be found in organisations writing closed or open source.
You're also right in saying there are few eyes and brains willing (and, I'd add, able) to review code.
OTOH you say "It's not strange that all discoveries come from professional researches who have an economic incentive in hunting them". Are those professional researchers going to have an easier job with source they can read or with black boxes?
This post has been deleted by its author
With no details on the vulnerability addressed by MS14-066 given anywhere yet AFAIK (the corresponding CVE is just listed as "reserved") I fail to see how a flaw in TLS could be remotely exploitable. By this, I mean really remotely exploitable. Exploits that require the user to open some web site do not qualify as such in my own vocabulary.
It'll probaly become obvious to me when details emerge but as of now... anyone wants to share knowledge here?
We're still in early days on this, but... any remote service on Windows is apparently exploitable if the s-channel is involved. Of note is that there hasn't been a bright line between the "desktop" and a "server" for some time. That's why there has been quite a bit of confusion as to both the severity and attack surface. Does your computer provide a remotely exposed *service* and if so, why haven't you applied the patch?
I wonder how many people are going to get bit who enabled RDP or IIS and just plain forgot about doing so?
Since the primary victims were the server versions of Windows, it stands to reason that the vulnerability is exploitable via services such as SMTP, MSSQL or IIS (to name but a few.) Any of these might be configured to use the SChannel stack. Pass an encrypted packet to these services, and they send it to SChannel to decrypt.
Essentially, if you've provisioned a network service on a Windows box, and thought you were making it safer by turning on encryption, you may have actually made it worse...
And it has lots of things that make it unnecessarily complicated like storing keys in ASN.1 which sounds like a good idea until you understand all the implications.
Maybe we need a simplified new attempt at TLS in which we take into account all the things we have learned. A protocol where attempts have been made to avoid people doing stupid things like choosing 15 as a "large prime number". (some stacks do accept that)
Maybe also one where we can use key pinning instead of that elaborate PKI which has so far turned out to not be exploited regularly by governments.
anyone know about MS?
David LeBlanc is still there; I don't know that he qualifies as a "full time (researcher) cryptographer", but at least some of his work is cryptographic research.
Microsoft Research has a cryptography group.
Microsoft's a big company with fingers in lots of IT pies and a significant research arm. Crypto is big business and has a lot of visibility in academia. It'd be very odd if they didn't employ some crypto researchers.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
