back to article 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 …

Anonymous Coward

Just goes to show the problem with open source. Even commercial implementations may refer to the open source code and just copy bits of it rather than actually think about the algorithm and consider any weaknesses.

0
56
Anonymous Coward

Downvoted because it's utter tosh.

32
0
Joke

I read on here that making it proprietary meant it was secure?

22
1

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?

23
0
Trollface

You guys fall for it every time.

Icon, because it's appropriate.

1
2

Supposed to be internal testing.

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.

10
0

Re: Supposed to be internal testing.

An article I read, I believe the BBC one, said that it was found by IBM researchers.

3
0

Re: Supposed to be internal testing.

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.

1
0

Re: Supposed to be internal testing.

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.

0
0

Re: Supposed to be internal testing.

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.

0
0
Silver badge

Re: Supposed to be internal testing.

Oh well, it sure beats reading pcaps all day.

Rubbish. Nothing is better than reading pcaps.

Mind you, these newfangled TCP-based protocols aren't a patch on our old SNA ones. LU6.2 BIND RUs, say - there was some good readin' on those!

1
0

Re: Supposed to be internal testing.

SNA ?? Pah. BSC3 was so much more fun. Found & fixed a bug in Olivetti's implementation of that in, oh, 1982 or so.

1
0
Silver badge

SSL is ok...

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.

4
0

Re: SSL is ok...

There's a reason why K.I.S.S was a good idea.

(Not the band)

7
0
Silver badge

Re: SSL is ok...

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.

2
0
Facepalm

Don't bash it.

"I felt a great disturbance in the Force, as if millions of MS users busily running down open source, and were suddenly silenced. I fear something terrible has happened."

15
2
Anonymous Coward

Re: Don't bash it.

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...

6
12

This post has been deleted by its author

Silver badge

Re: Don't bash it. @A/C

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?

0
0

Remote execution? huh?

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?

0
0

Re: Remote execution? huh?

You're thinking about the client being vulnerable. The article is talking about servers being vulnerable.

0
0
Silver badge

Re: Remote execution? huh?

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...

1
0
Silver badge

Re: Remote execution? huh?

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?

1
0
Holmes

So...

Affects Windows Server 2012, Windows Server 2008 R2 and Windows Server 2003

I thought 2012 was a rewrite of 2008 which in turn was a rewrite of 2003.

Funny then how all of those 'serious' issues always affect the best windows version yet plus all the older ones.

0
1
Stop

Re: So...

S-channel is a security library. Windows versions are kernel rewrites and UI updates (appallingly ham-fisted ones in the case of W8). Why would a kernel rewrite require you to re-write all the supporting libraries?

0
0
Silver badge

Top marks for the title, El Reg.

10/10 would read again

0
0
Silver badge

TLS is to complicated

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.

1
0

Not enough people are employing full time (researcher) cryptographers. I know Google and Apple do, anyone know about MS?

0
0

"Not enough people are employing full time (researcher) cryptographers. I know Google and Apple do, anyone know about MS?"

Yeah, but the NSA stole them all away.

0
0
Silver badge

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.

1
0

Late yesterday evening

I saw a neat, new attack coming out of one of the vulnerability scanners, null string logon attempts.

How 1980's...

0
0
WTF?

Shouldn't that rather be

«anus horribilis» ?...

Henri

0
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2018