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:
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
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.
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.
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:
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.
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?
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.]
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:
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.
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.
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.
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.
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.
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.
Iâve been struggling with this issue for some time.
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.
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.
So, what are the things in your twisted imaginings that would turn Windows 7 from this kind of Seven:
into this kind?
[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!]