Windows 7 – Page 2 – Tales from the Crypto

Windows 7

Comcast aims for the future

I’m visiting the in-laws in Texas this weekend, and I use the SSTP VPN in Windows Server 2008 R2 to connect home (my client is Windows 7, but it works just as well with Vista). Never had many problems with it up until this weekend.

Apparently, on Friday, we had a power cut back at the house, and our network connectivity is still not happening. I’ve asked the house-sitter to restart the servers and routers where possible, but it’s still not there.

So I went online to Comcast, to track down whether they were aware of any local outage. Sadly not, so we’ll just have to wait until I get home to troubleshoot this issue.

What I did see at Comcast, though, got me really excited:

Comcast is looking for users to test IPv6 connectivity!

Anyone who talks to me about networking knows I can’t wait for the world to move to IPv6, for a number of reasons, among which are the following:

  • Larger address space – from 2^32 to 2^128. Ridiculously large space.
  • Home assignment of 64 bits to give a ridiculously large address space to each service recipient.
  • Multicast support by default. Also, IPsec.
  • Everyone’s a first-class Internet citizen – no more NAT.
  • FTP works properly over IPv6 without requiring an ALG.
  • Free access to all kinds of IPv6-only resources.

So I can’t but be excited that my local ISP, Comcast, is looking to test IPv6 support. I only hope that it’ll work well with the router we have (and the router we plan to buy, to get into the Wireless-N range). Last time I was testing IPv6 connectivity, it turned out that our router was not forwarding the GRE tunneling protocol that was used by the 6-in-4 protocol used by Hurricane Electric’s Tunnel Broker.

Who knows what other connectivity issues we’re likely to see with whatever protocol(s) Comcast is going to expect our routers and servers to support? I can’t wait to find out

Windows 7 Explorer may corrupt MP3 files

I tried to find a less … alarmist tone to take in the title, but when I think of the consequences of this particular bug, I can’t see that I’m going over the top.

Quite simply, occasionally Windows 7 Explorer will corrupt files when you copy and/or move them using drag/drop. [So far, I’ve only seen this twice, and each time, I was moving MP3 files]

Last night, I dragged a group of files – over a thousand, totaling about 45GB of data, to move them to a network server.

This morning, one of the files was still on the original source. And on the destination.

That alone would be an unsettling bug, but not too much to worry about.

Out of sheer curiosity, I compared the two files (using “FC /B C:File1 Y:File1”).

Sure enough, although the beginning of the file was the same, starting at byte 0x480000 (there may be one too few, or one too many, zeroes there), the target file consisted of nothing other than nulls (zero byte, ‘’ if you’re a C developer).

This doesn’t only happen on files sent to the network, however.

Searching for files with large numbers of nulls at their end, I was shocked to find that over thirty of the files on my hard drive consisted of nothing but null characters. All these files were dated July 27 2009, so clearly that was a bad day for my computer.

That’s unsettling, because these particular files I had assumed to be safely moved. I had first copy-dragged them to my Podcasts folder, and then move-dragged them to a different folder, both of which actions were on my hard drive only. Having listened to these files out of my Zune (using the Podcasts trick I referred to earlier), I wiped them from the Podcasts folder, and now won’t be able to listen again, because the ‘backup’ copy is corrupted.

image

Mind you, they do compress well when there’s nothing in the file but nulls. 🙂

And, just in case anyone’s thinking my system itself is corrupt, or has a bad disk driver or something like that, I should note that I have completely wiped and reinstalled the system from scratch in the last few months, so the first (major) destruction of data was on a Windows 7 installation that was upgraded from Vista, and which had a number of the laptop manufacturer’s drivers on it; the second (less huge) destruction was on a fresh Windows 7 installation with almost no manufacturer’s drivers loaded.

I have yet to find any details of others experiencing this same problem. If you want to scan your own files (MP3 or otherwise) for vast quantities of null bytes at the end, I’ve uploaded the program here – it’s written in C#, and I’ve provided the source code as FindNulls.cs, and the executable as FindNulls.exe in the zip file. I won’t claim it’s a sample, or that it’s particularly good, but it will find files that end with several nulls in sequence.

Bad Names: Windows Phone Mobile Compact Edition Seven Series Pocket PC

OK, admittedly, the name isn’t really that long, but even though I’m spending this week on Microsoft’s home turf, I can’t say that I’ve met two people who can trip off their tongue the proper name of the new version of Windows Mobile:

Windows Phone Seven Series zhone1

Seriously? Every single word there is a generic term, and will have large numbers of inappropriate matches when you go searching for them.

Right now, while the hype is high, a search for those terms brings back mostly matches for the Windows Phone, but in a few weeks, it’s anyone’s guess what you’ll find.

ipadprototype Search for iPhone, or iPad, by comparison, and although you’ll find a pile of parody sites, at least those parodies are parodies of the products in question. Every search result is relevant to the iPhone.

Why can’t Microsoft come up with a simple, single, searchable brand name for their products? We see this all the time, with Bookshelf, Access, Excel, Word, Windows, Bob, etc.

What would be so difficult about picking up on the idea that this is, essentially, a Zune phone? Call it a “Zhone”, give it an interesting pronunciation (think “Zh is to Sh as Z is to S” – like the french “J” sound), and you’ve made for immediate cool, cemented the link with the Zune (hmm… could depend on how people like the Zune – personally, I’m so impressed by the Zune HD that I wish I could justify one to the wife), and made the product immediately searchable and identifiable. (Or if that name’s taken, Zuphone, Phozune, Phune, etc)

But no, seriously dorky names are en vogue at Microsoft, always have been and probably always will be. Of course, why should you listen to me, a security guy who dabbles in development and has no marketing ability, when instead you’ve got all those highly paid marketers who tell you that “Windows Phone Seven Series from Kyocera [or Dell, Samsung, etc]” will sell?

The bottom line

Notice, however, that the only thing I have to diss this phone on is its name. Having briefly played with a Zune HD, if it follows the promise of being the same kind of device with phone capabilities added on, this will be a trouser-changing experience. [I’m told the expression to use is “game-changing experience”, but the Zune HD combined with phone would simply be that good.]

TLS Renegotiation attack – Microsoft workaround/patch

Hidden by the smoke and noise of thirteen (13! count them!) security bulletins, with updates for 26 vulnerabilities and a further 4 third-party ActiveX Killbits (software that other companies have asked Microsoft to kill because of security flaws), we find the following, a mere security advisory:

Microsoft Security Advisory (977377): Vulnerability in TLS/SSL Could Allow Spoofing

It’s been a long time coming, this workaround – which disables TLS / SSL renegotiation in Windows, not just IIS.

Disabling renegotiation in IIS is pretty easy – you simply disable client certificates or mutual authentication on the web server. This patch gives you the ability to disable renegotiation system-wide, even in the case where the renegotiation you’re disabling is on the client side. I can’t imagine for the moment why you might need that, but when deploying fixes for symmetrical behaviour, it’s best to control it using switches that work in either direction.

The long-term fix is yet to arrive – and that’s the creation and implementation of a new renegotiation method that takes into account the traffic that has gone on before.

To my mind, even this is a bit of a concession to bad design of HTTPS, in that HTTPS causes a “TOC/TOU” (Time-of-check/Time-of-use) vulnerability, by not recognising that correct use of TLS/SSL requires authentication and then resource request, rather than the other way around. But that’s a debate that has enough clever adherents on both sides to render any argument futile.

Suffice it to say that this can be fixed most easily by tightening up renegotiation at the TLS layer, and so that’s where it will be fixed.

Should I apply this patch to my servers?

I’ll fall back to my standard answer to all questions: it depends.

If your servers do not use client auth / mutual auth, you don’t need this patch. Your server simply isn’t going to accept a renegotiation request.

If your servers do use client authentication / mutual authentication, you can either apply this patch, or you can set the earlier available SSLAlwaysNegoClientCert setting to require client authentication to occur on initial connection to the web server.

One or other of these methods – the patch, or the SSLAlwaysNegoClientCert setting – will work for your application, unless your application strictly requires renegotiation in order to perform client auth. In that case, go change your application, and point them to documentation of the attack, so that they can see the extent of the problem.

Be sure to read the accompanying KB article to find out not only how to turn on or off the feature to disable renegotiation, but also to see which apps are, or may be, affected adversely by this change – to date, DirectAccess, Exchange ActiveSync, IIS and IE.

How is Microsoft’s response?

Speed

I would have to say that on the speed front, I would have liked to see Microsoft make this change far quicker. Disabling TLS/SSL renegotiation should not be a huge amount of code, and while it has some repercussions, and will impact some applications, as long as the change did not cause instability, there may be some institutions who would want to disable renegotiation lock, stock and barrel in a hurry out of a heightened sense of fear.

I’m usually the first to defend Microsoft’s perceived slowness to patch, on the basis that they do a really good job of testing the fixes, but for this, I have to wonder if Microsoft wasn’t a little over-cautious.

Accuracy

While I have no quibbles with the bulletin, there are a couple of statements in the MSRC blog entry that I would have to disagree with:

IIS 6, IIS 7, IIS 7.5 not affected in default configuration

Customers using Internet Information Services (IIS) 6, 7 or 7.5 are not affected in their default configuration. These versions of IIS do not support client-initiated renegotiation, and will also not perform a server-initiated renegotiation. If there is no renegotiation, the vulnerability does not exist. The only situation in which these versions of the IIS web server are affected is when the server is configured for certificate-based mutual authentication, which is not a common setting.

Well, of course – in the default setting on most Windows systems, IIS is not installed, so it’s not vulnerable.

That’s clearly not what they meant.

Did they mean “the default configuration with IIS installed and turned on, with a certificate installed”?

Clearly, but that’s hardly “the default configuration”. It may not even be the most commonly used configuration for IIS, as many sites escape without needing to use certificates.

Sadly, if I add “and mutual authentication enabled”, we’re only one checkbox away from the “default configuration” to which this article refers, and we’re suddenly into vulnerable territory.

In other words, if you require client / mutual authentication, then the default configuration of IIS that will achieve that is vulnerable, and you have to make a decided change to non-default configuration (the SSLAlwaysNegoClientCert setting), in order to remain non-vulnerable without the 977377 patch.

The other concern I have is over the language in the section “Likelihood of the vulnerability being exploited in general case”, which discusses only the original CSRF-like behaviour exploited under the initial reports of this problem.

There are other ways to exploit this, some of which require a little asinine behaviour on the part of the administrator, and others of which are quite surprisingly efficient. I was particularly struck by the ability to redirect a client, and make it appear that the server is the one doing the redirection.

I think that Eric and Maarten understate the likelihood of exploit – and they do not sufficiently emphasise that the chief reason this won’t be exploited is that it requires a MITM (Man-in-the-middle) attack to have already successfully taken place without being noticed. That’s not trivial or common – although there are numerous viruses and bots that achieve it in a number of ways.

Clarity

It’s a little unclear on first reading the advisory whether this affects just IIS or all TLS/SSL users on the affected system. I’ve asked if this can be addressed, and I’m hoping to see the advisory change in the coming days.

Summary

I’ve rambled on for long enough – the point here is that if you’re worried about SSL / TLS client certificate renegotiation issues that I’ve reported about in posts 1, 2 and 3 of my series, by all means download and try this patch.

Be warned that it may kill behaviour your application relies upon – if that is the case, then sorry, you’ll have to wait until TLS is fixed, and then drag your server and your clients up to date with that fix.

The release of this advisory is by no means the end of the story for this vulnerability – there will eventually be a supported and tested protocol fix, which will probably also be a mere advisory, followed by updates and eventually a gradual move to switch to the new TLS versions that will support this change.

This isn’t a world-busting change, but it should demonstrate adequately that changes to encryption protocols are not something that can happen overnight – or even in a few short months.

Why .NET apps keep crashing on your Tablet PC

I’ve been struggling with this issue for some time.

I have a small, simple .NET application I wrote in Visual C# a few months ago – I’ve tentatively titled it “iFetch”, because it fetches radio shows from the BBC iPlayer.

It really is very little more than a simple data grid view that displays the details of the shows and allows users to select them for downloading and later listening.

Despite that, I’ve had some terrible trouble with it. Sometimes it’ll work perfectly, other times it’ll just suddenly crash, and apparently without warning and for different reasons – sometimes when I click on a row, other times when I select to sort on a column heading.

The crash seems to be intermittent, but doesn’t reproduce on other computers; even computers of the same configuration.

For those who want technical details, here we go – the crash is a System.StackOverflowException error, and appears to be due to an unchecked infinite recursion in System.Windows.Forms.dll!System.Windows.Forms.DataGridViewRow.DataGridViewRowAccessibleObject.Bounds.get().

The clue here is that this is a “DataGridViewRowAccessibleObject” – not a mere DataGridViewRow. These “AccessibleObject” versions of common .NET components only come into existence and spread their effect when an “accessibility application” is active on the system. Apparently, in addition to text-to-speech readers, braille devices, etc, a Tablet – whether external like mine, or internal like those in a Tablet PC – classifies as an accessibility application.

That’s why this bug was intermittent for me – sometimes I had my external graphics tablet plugged in, other times I didn’t. To make matters worse, it seems to only trigger when one or more rows in the DataGrid are hidden.

If you get this error, first try checking to see if Microsoft have fixed the flaw – check for .NET service packs – and then, if there is no direct fix for the flaw, try either unplugging your tablet, if you can, or temporarily stop the Tablet PC Input Service, while running the program.

So far, I have received no feedback from Microsoft about when this will be fixed.

Windows 7 – what it’s missing

Unless you’ve been living under a rock, you’ll be aware that today was the release of Microsoft’s latest operating system version, Windows 7.

So, everyone else has their own ideas of what’s missing in Windows 7, here’s my list, and it’s not the same petty focus that everyone else seems to have. Mine is based on what I want, rather than what’s remotely close to being reasonably achievable.

  1. Media Center devices to provide support for DirecTV.
  2. Trimmable transparent screen overlays supporting multi-touch input.
  3. IPv6 support from my home ISP.
  4. A web browser that opens quickly enough that I don’t forget what I was about to browse to.
  5. A tool to answer “why is the system so slow right now?” – especially on those occasions when the CPU is not being over-taxed.
  6. A free Zune HD. (Why not, since I’m dreaming here.)
  7. Simple facilities to allow electronic commerce to operate on ‘zero knowledge’ principles, so that I would share my credit card account number only with my credit card provider, rather than with every merchant I might do business with. (Maybe Infocard or something like it could come close to fulfilling this wish)
  8. An “Expert” mode, where menus are visible, files and file extensions are not hidden in Explorer. (For that matter, file extensions should not be hidden in Explorer. Ever.)
  9. MSN – excuse me – Windows Live Messenger that works in a somewhat rational way, back in the system tray, rather than as a minimised icon.

So, what are the things in your twisted imaginings that would turn Windows 7 from this kind of Seven:

Seven, from Married with Children

into this kind?

Seven of Nine, from Star Trek Voyager

[Note: Having said all of this, it should be clear by now that I think Windows Seven is well worth having. But I still want more!]