Windows Vista

Immutable Security Laws and Windows Sidebar Gadgets

Immutable Security Law number 1: If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore

I love the Immutable Security Laws – they strike a chord deep within me, and they’re a “go to” resource every time I want to decide if I’m making a good security decision.

I also like my Windows Sidebar Gadgets. Not a whole lot of them, mind you, just one or two that I’ve written myself. And I can’t say that I’ve gone very deep in developing them.

So I’m deeply conflicted when I see “Microsoft Security Advisory (2719662) – Vulnerabilities in Gadgets Could Allow Remote Code Execution” – this seems to be saying that because there are a number of vulnerabilities in common Sidebar Gadgets, you should disable Sidebar Gadgets completely.

But the descriptions I see of Sidebar Gadgets and their security suggest that these Gadgets are exactly like other executables, in terms of the protection you get when running them (essentially, none).

So, in essence, this boils down to “a class of executables that you can download and run are known to have vulnerabilities. So we are disabling that class of executables.” And apparently, this isn’t an architectural flaw in Sidebar Gadgets, because the wording indicates only that a lot of Gadgets have common vulnerabilities – but not all of them.

Can you imagine if the same had been done for, say, Java? If all Java apps were disabled, not because of a flaw in Java, but because many Java developers had written poorly-secured code? What about other frameworks? C++? .NET? PHP?

Uh, yeah, OK, I can see it for PHP. I’m all for disabling PHP on the basis that [almost?] nobody seems able to reliably write secure code using it.

Obviously, I’m writing this from the perspective of someone who hasn’t seen information on the sort of vulnerabilities being described, so it’s entirely possible that there’s an actual architectural weakness that warrants disabling Gadgets completely. I’m just not reading that into what’s been said so far, and I’d like to think that we’re capable of making security decisions on the basis of security truth, rather than some random measure of “disable this framework, because it’s not that important, and many of its developers are writing bad code”.

Clearly I have to wait for the revelation at the BlackHat talk (I’m not going to BlackHat, but I’m on vacation right now – in Vegas) to see what the threat actually is, but I will state up front that I am confused.

Posted in General Security, Windows 7, Windows Vista | Leave a comment

The power of stupidity

I just spent a couple of days trying to figure out why logon-related code that worked in Windows XP failed in Windows Vista and Windows 7.

hToken = NULL;
if ( LogonUser( g_sUser, bIsUPN ? NULL : g_sDomain, g_sPass, LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, &hToken ) )
{
    // Re-populate the g_sUser and g_sDomain values from the token!
    TOKEN_USER tUser;
    DWORD nLength;
    // Get the user / domain information from the token.
    if (GetTokenInformation(hToken,TokenUser,&tUser,sizeof tUser,&nLength))
    {
        SID_NAME_USE eUse;
        DWORD dwUserSize = _countof(g_sUser);
        DWORD dwDomainSize = _countof(g_sDomain);
        LookupAccountSid(NULL,&tUser.User.Sid,
            g_sUser, &dwUserSize,
            g_sDomain, &dwDomainSize,
            &eUse);
    }
    CloseHandle(hToken);
}

[Note that some error handling has been removed for clarity and brevity.]

So what was going wrong? This totally used to work – it’s designed to validate the username and password, as well as to provide me with the canonical form of the user name.

I had a look through the APIs, and sure enough, there was a more up-to-date version of one of them – LogonUser has a colleague, LogonUserEx, and that function returns the Logon SID as well as verifying the logon works. Cool, I thought, I can get rid of GetTokenInformation, which seems to be failing anyway, and use LogonUserEx.

No dice.

LogonUserEx claimed to be working, and yet LookupAccountSid returned an error, signifying ERROR_NONE_MAPPED (1332 decimal, 0x534 in hex, “No mapping between account names and security IDs was done.”)

A little searching on ERROR_NONE_MAPPED led to a blog post by David LeBlanc, indicating that logon SIDs will cause this error, because they are entirely ephemeral SIDs, used mainly to protect securable items that should not be available to processes running outside of this logon session (and, by the same measure, allowing access to be provided, where appropriate, across different processes in the same logon session).

And then I realised, after a few hours of experimentation, the answer was staring me in the face, in the documentation – LogonUserEx returns the Logon SID in ppLogonSid, which is a Logon SID. Does not have a name, only a SID.

So, that explained the failure of LookupAccountSid with LogonUserEx, and I returned to using LogonUser – which left me with the conundrum of what was failing there.

It often turns out to be the simplest of things.

TOKEN_USER is a structure containing a pointer to the SID. As such, GetTokenInformation has to put the SID somewhere. Cleverly, it asks you to build your TOKEN_USER structure a little bit long, and places the SID at the end of the structure, before setting the pointer in the structure to point to the SID. So, sizeof(TOKEN_USER) is not big enough to pass to a GetTokenInformation call requesting a TokenUser.

The big question is, not why this failed, but why it worked ever at all! I’m not too fussed in finding that answer, because I’ve now changed my code to do it properly, and everything still works – on Windows Vista and XP. But I do feel stupid that debugging this code took me part of Sunday and a little of Monday evening.

Now the code looks like this (again, some error handling has been removed for brevity – don’t skimp in your production code!)

hToken = NULL;
if ( LogonUser( g_sUser, bIsUPN ? NULL : g_sDomain, g_sPass, LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, &hToken ) )
{
    SecureZeroMemory(g_sPass,sizeof g_sPass);
    TOKEN_USER *ptUser;
    DWORD nLength;
    GetTokenInformation(hToken, TokenUser, NULL, 0, &nLength);
    ptUser = (TOKEN_USER*)new char[nLength];
    // Get the user / domain information from the token.
    if (GetTokenInformation(hToken,TokenUser,ptUser,nLength,&nLength))
    {
        SID_NAME_USE eUse;
        DWORD dwUserSize = _countof(g_sUser);
        DWORD dwDomainSize = _countof(g_sDomain);
        LookupAccountSid(NULL,ptUser->User.Sid,
            g_sUser, &dwUserSize,
            g_sDomain, &dwDomainSize,
            &eUse);
    }
    delete [] (char *)ptUser;
    CloseHandle(hToken);
}

Note that the fix is to request the length of the TOKEN_USER structure with an initial call to GetTokenInformation, followed by a second call to fill it in.

Posted in Alun's code, Programmer Hubris, Windows 7, Windows Server 2008, Windows Vista | Leave a comment

Starting to build your own Credential Provider

If you’re starting to work on a Credential Provider (CredProv or CP, for short) for Windows Vista, Windows Server 2008, Windows Server 2008 R2 or Windows 7, there are a few steps I would strongly recommend you take, because it will make life easier for you.

0. Read Dan Griffin’s article in MSDN Magazine.

The article, "Create Custom Login Experiences With Credential Providers For Windows Vista" by Dan Griffin in January 2007’s MSDN Magazine on Credential Providers is a truly excellent source of information, gleaned largely by the same exhaustive trial and error effort that you will be engaging in with your own CP.

0.1 Read it again.

0.2 And again, and again and again.

As you work on your CP, you will keep running into questions and new insights as to what it is that Dan was telling you in that article.

Keep a printed copy next to you when developing your CP, so that you can keep looking back to it.

If you have met Dan and asked his permission, keep him on speed-dial.

1. Test your Credential Provider in a Virtual PC environment.

You will screw something up, and when you do, the logon screen will most likely cycle over and over and over (what, Microsoft couldn’t provide a “this Credential Provider has failed eighteen times in a row and will be temporarily disabled” feature?), preventing you from logging back on to change out your broken CP. At this point, you really want to revert back to a previous working session.

To my mind, the easiest way to do this is to create one Virtual PC environment with a base Windows 7 system, patched up to current levels, and with a few test users installed. You can burn an MSDN licence up on this test installation, if you like, but quite frankly, I’m likely to want to refresh it from scratch every so often anyway, so the activation timeout is no big deal.

Once you have created this base image, create another virtual machine, based off the virtual hard disk (VHD) of the base image, and be sure to enable undo disks. This way, when things go wrong, you can shut down this second virtual machine, telling Virtual PC to discard the Undo Disk data, and you will be able to restart the machine immediately and continue to work on it.

2. Enable the kernel debugger against your VM.

This is a little tricky.

2.1 First, edit the settings on your VM.

Enable COM1 to point to a Named Pipe, such as “\\.\pipe\credprov”:

2.2 Now, enable kernel debugging on the VM itself

Log on to the VM, and use the bcdedit tool, from an Administrator Command Prompt to change the debugging option in the boot database. You can go the long way around, reading Microsoft’s instructions on how to do this, or you can simply use the following two commands:

bcdedit /dbgsettings serial debugport:1

bcdedit /debug {current} on

Notice that Microsoft suggests creating a separate environment for debugging on and off, but I don’t see that as being terribly useful. I will always be debugging this test environment, and it really doesn’t slow me down that much. You can always use “bcdedit /debug {current} off” to turn debugging off later.

This setting will take effect at the next reboot of the VM, but don’t reboot yet.

2.3 Enable the Debug Output Filter so OutputDebugString works.

Windows Vista and later don’t output debug messages to the kernel debugger by default. Those messages are filtered. You can spend a lot of time trying to figure out why you are staring at a blank screen when you have filled your code with OutputDebugString and/or TRACE calls. Or you can change the registry entry that controls the Output Debug Filter:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter\DEFAULT

Create the “Debug Print Filter” value, if it isn’t there, and then create the DEFAULT value as a DWORD, and set it to the value 8.

2.4 Save these settings

Since you’ll want these settings to come back after a restart, you’ll want to commit them to the VHD. Easily done, but takes some time. Shut down the VM, and when you are prompted what you want to do, select that you wish to commit changes to the virtual hard disk.

Expect this to take several long minutes. While you do that, go read Dan’s article again.

2.5 Create a shortcut to the debugger

I use WinDBG (is that pronounced “Windbag”?), and the shortcut I use points to:

"C:\Program Files\Debugging Tools for Windows (x64)\windbg.exe" -k com:port=\\.\pipe\credprov,baud=115200,pipe,reconnect,resets=10

Remember to start the VM before starting the WinDBG shortcut, so that the VM has a pipe for WinDbg to connect to.

3. Start from the CredProv samples

Play around with the credential provider sample, or samples, that are closest to your eventual design goal, and add features to move them towards your desired end-state, rather than building your own from scratch.

Don’t just play with the one sample – looking at, or testing, the other samples may give you a little more insight that you didn’t get from the sample you’re working with.

3.1 Build often, and test frequently

Random errors and occasional misunderstandings (“gee, I didn’t realise you can’t call SetFieldString from GetStringValue”) will cause you to crash often. A crash in your CP means an infinite loop, and some inventive use of Anglo-Saxon.

Building often, testing frequently, and backing out disastrous changes (use version control if you have it!) will lead to a better process.

3.2 Later, build your own CP

Once you have a good understanding of the Credential Provider and its mysterious ways, you may decide to throw out Microsoft’s code and build your own from scratch. Keep comparing against your modified sample to see why it isn’t working.

3.3 Before deployment, change the GUID!

The GUIDs used by the sample code are well-known, and will tie in some systems to other, more shoddy, developers’ versions of those samples. If you forget to change the GUID on your code, you will have a CP-fight.

4. Go back to Dan’s article every time you reach a bottleneck

Occasionally a twist of phrase, or a reinterpretation of a paragraph is all it takes to wring some more useful knowledge out of this article. Don’t forget to use the online help Microsoft provides, as well as searching the MSDN, but remember that this is not a very frequently-trod path. It may be that you are doing something the credential provider architects didn’t consider. In fact, it’s highly likely.

5. Stop mailing credprov@microsoft.com

Nobody monitors that email address any more, and there seems to be something of a black hole associated with questions related to Credential Providers in general. It’s as if nobody really truly understands them. A few of the MVPs (particularly Dan Griffin, Dana Epp, and perhaps myself) have a good understanding, so read their blogs, and perhaps post to the Microsoft Forums, if you can manage to do so.

6. Enumerate, and test, the scenarios your customers might run into

domain-joined and non-domain
administrator, non-administrator, guest
with and without user names being supplied (Secpol.msc –> Local Policies –> Security Options –> Interactive Logon: Do not display last user name)
default domain, other domain, local accounts
logon, switch user, unlock workstation, access from Remote Desktop Connection / MSTSC (as we old-timers call it)
change password
If you’re of a mind, test the credential user interface mode, too.

Posted in Alun's code, General Security, Programmer Hubris, Windows 7, Windows Server 2008, Windows Vista | 7 Comments

Weird virus / anti-virus behaviour

My wife and I pent a while this weekend trying to figure out how to rescue a Media Center that seemed to be going a little loopy.

The Windows Media Center application itself worked fine, as did Windows Media Player, Calc, etc.

Only Internet Explorer was failing.

If you press Ctrl-C from most Windows dialog boxes like the one above, it will copy the text of the dialog into the clipboard.

Here’s what I get if I do that (this is mostly aimed at people using search engines):

[Window Title]
C:\Program Files (x86)\Internet Explorer\iexplore.exe

[Content]
C:\Program Files (x86)\Internet Explorer\iexplore.exe

The parameter is incorrect.

[OK]

[Had the Media Center been on 32-bit Windows, those paths would simply be “C:\Program Files\Internet Explorer\iexplore.exe” – the error message would still be “The parameter is incorrect”]

So, what on earth does this mean?

It seems bizarre, partly because there isn’t a parameter I’m supplying to Internet Explorer, but mostly because it gives me chills whenever Internet Explorer dies so quickly – I’ve seen so many viruses that disable Internet Explorer (so you can’t download a fix), that an IE issue like this sends a shiver down my spine.

My wife had the first go at fixing this, trying not only removing and re-adding IE as a Windows Feature (in “Turn Windows Features On or Off”), but also reinstalling Windows 7 on top of itself, as a repair. No fix.

Meanwhile, I downloaded Mozilla Firefox and Google Chrome on a different computer, moved them over to this one, and installed them each.

Both of them, when I tried to run, came up with the same “The parameter is incorrect” message. Worrisome.

I fire up Regedit, which is almost always also disabled by viruses that want you not to fix them. Strangely enough, that works – but I’m not done with my virus theory.

I updated Microsoft’s Security Essentials – which is already running on this system. A Quick Scan finds nothing. Trend Micro’s HouseCall is another “download and run this” virus scanner, much like the Microsoft Malicious Software Removal Tool, which arrives monthly with your Windows Updates.

Still nothing detected.

I get by with a little help from my friends

Fortunately, my friend and fellow MVP, Susan Bradley, is online, and although I don’t think she has the bandwidth to answer everyone’s questions, I think I’m rather special, so I call on her time to see if she has any suggestions.

“try malwarebytes.org?” she asks.

Sure enough, I hadn’t, and I know that several of the Consumer Security MVPs swear by it. So I download it and run it.

It finds four infections (I never get excited about the number of infections these tools find, because some of them are really aggressive as to what they think are “infections” – I’m one of those strange people that thinks tracking cookies are “mostly harmless”).

Reviewing what they are, I can see exactly how the behaviour comes about, but I’m still at a little of a loss as to how that happened.

The four entries it finds are under Registry settings, in the registry tree HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options, and under keys called “iexplore.exe”, “chrome.exe”, “firefox.exe” and “opera.exe” (Opera is another browser you can download).

The value, in each case, is as follows (using RegEdit to see):

The value name is “Debugger”, and although you can’t see it clearly there, the value is “ -sb” – that is a single space, followed, by a hyphen, and the two letters “sb”.

This is a variation on a classic method for killing Internet Explorer – or rather, for sidelining it, or prepending it with your own code. The functionality has a good purpose – for developers who want to run their debugger every time they open an application. I use it a lot myself.

I haven’t seen anyone do exactly this, though – it seems like they screwed up somehow.

The Fix

Fixing this is really simple. You just have to remove the value named “Debugger” from that key. Watch that you don’t make other changes, in case those cause other behaviours you don’t want. Oh, and do this as an administrator, or you won’t actually make any changes.

In my case, since this was the only value in the key for Internet Explorer, Firefox, Chrome and Opera, I deleted the keys themselves, just to be safe.

No reboot required – suddenly, I can start up my browsers – all of them. Thank you, Susan, and thank you, MalwareBytes!

The cause?

I’m always keen to find the cause of issues like this – especially since this could still be a virus that caused this, and if it is, I think the Microsoft Security Essentials team would like to know about it.

Searching leads repeatedly to the same possible target – a ROGUE antivirus program, which calls itself “AVG Antivirus 2011”, but which actually has nothing to do with the real AVG Antivirus. I’ve heard of this before, and I’ve seen it at a couple of sites I’ve visited for “research purposes”, but each time I’ve simply closed down IE before it had a chance to run its alleged scan.

[Hint: no web site should be scanning your computer and finding viruses. If a web site says it’s found a virus, it’s referring to the one it’s about to install on your system.]

So, it could have been me, it could have been a family member – but no real harm done. My guess is that it started to install itself, and Microsoft Security Essentials started to remove it, but didn’t quite manage to complete the job. That’s just a guess. I don’t have nearly the resources or the interest to try and re-stage the incident to test! I’m putting this blog entry out in the hope that it’ll be a search engine hit when someone else runs into the same issues.

Posted in General Security, What my wife knows, Windows 7, Windows Vista | 1 Comment

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

Posted in FTP, Miscellany - not security, TCP/IP, Windows 7, Windows Server 2008, Windows Vista | 2 Comments

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.

Posted in General Security, Things I learned at Microsoft, Why is PKI so hard?, Windows 7, Windows Server 2008, Windows Vista | Leave a comment

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.

Posted in Alun's code, Miscellany - not security, Windows 7, Windows Vista | Leave a comment

Running out of disk space? How’s your logs?

I ran out of disk space today.

This is not entirely a new issue for me, because I like to listen to BBC Radio from back home, and my only way to do that is to download the shows overnight so I can listen to them the next day. [I’m not allowed that sort of bandwidth at work]

I start troubleshooting this in the obvious way – where are my largest individual files, and are they useful? Windows Vista’s Search is great for this – you can ask for files over a certain number of bytes:

Whoa, over a gigabyte in that mysterious file called “setupapi.app.log”? Ah, but it’s in that C:\Windows\inf directory that I really shouldn’t mess with, so I’d better check to see that it’s alright to get rid of the file. Let’s see what the Microsoft Support Knowledge Base has to offer on the subject of huge files created by the Setup API.

http://support.microsoft.com/default.aspx/kb/958909 – “It may take a long time to log on to a Windows Vista-based computer that has antivirus software installed” – well, I haven’t really noticed that logons are that slow, and I don’t actually have antivirus software installed. But visiting the article, I see that this is only the first half of the title. The full title is:

It may take a long time to log on to a Windows Vista-based computer that has antivirus software installed, and you may notice that the file size of the Setupapi.app.log file is very large

So, to use a medical metaphor here, the large setupapi.app.log is the internal haemorrhaging caused by some injury or illness, and the slow logon (or in my case, the inability to use my disk space) is the externally visible symptom – the loss of consciousness, the fainting fit, the going-into-shock. Now that we’ve got the diagnosis, let’s see if the KB article has anything useful to say.

“This problem occurs because the verbose logging policy for the Setupapi.app.log file in Windows Vista is set to the most verbose setting (0x20000FFFF).

“…

“To work around this problem, remove or adjust the value of the following registry entry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\LogLevel”

Hmm… my value is set to 0x20000000. What value should it be?

“Type 0x00000020 in the Value data box.”

OK, that’s a little pedantic – instead, how about you click the “Hexadecimal” radio button, and enter “20”:

There is a hotfix mentioned in the article, but I rarely like to apply hotfixes to my machine if I am sure that the workaround will suffice. I may revisit the hotfix if I can’t see this work to reduce my log file size.

So, how did this happen? How did the setting get put to such a bizarre value?

Quite frankly, I don’t know – and as long as the problem goes away, I’ll just put it down to one of the many programs that I’ve installed or uninstalled. Judging from the fact that this log seems to have been in detail mode ever since November 2007, it’s likely that this setting was chosen (either by me or Microsoft) to gauge how successful the new install of Vista was going.

I now have a gigabyte of my file-space left, and I can go and download “Crisp and Even, Brightly”, one of my favourite Christmas shows from Radio 4. I only wish I could get the TV, because there are some excellent BBC shows that never make it across to this side of the Atlantic – and I just can’t wait for Doctor Who Season 4 – the next Doctor (or is he?), Cybermen, and a Victorian Christmas.

Posted in Miscellany - not security, Programmer Hubris, Windows Vista | 5 Comments

Redmond Report says “Vista Kernel Flawed”

This is just some lovely reporting:

Vista Kernel Ready To Pop?

Vista, due largely to its lockdown of user rights, is far more secure than XP. But it’s not 100 percent safe. In fact, the kernel itself has an issue that could lead to buffer overflow attacks, or so says security company Phion.

Well, that’s hardly surprising, we know how common buffer overflow attacks are, and how difficult they are to prevent. Go on…

The exploit, which does require admin privileges, is pretty well-documented by Phion. And there’s no patch — just a workaround from the company. Hmm. Is Phion looking for new customers?

Uh… if the ‘exploit’ needs admin privileges to start with, exactly how is it an "exploit"? It’s a bug. By the time you have admin privileges, you can replace the operating system with one that does your bidding anyway, so how is it an ‘exploit’ that you can do so without replacing the OS core?

Pre-announcing this kind of flaw is like giving bullets to insurgents before our soldiers have a chance to put on helmets and bulletproof vests: dangerous.

No, it’s rather like suggesting that there’s a flaw in that if the Commander-in-Chief is secretly supporting the terrorist cause, he can order our soldiers to be needlessly sent into a dangerous war zone without sufficient arms or armour.

There are other bugs where I would agree that it’s important to avoid announcing the flaw before the vendor has been given a reasonable chance to fix it for find a workaround – this isn’t that case, though.

The flaw in question is worth noting, though, in that it’s something that can be abused by members of the Network Operators group – and there are many sites that put users into this group simply so that they can turn off or on the wireless networking card on their laptops (for those that don’t have a simple hardware switch). So, while Microsoft may assert that "Network Operators are just like administrators", there are many ordinary users who have been dropped into the Network Operators group.

Posted in General Security, Windows Vista | 2 Comments

Windows 7 officially has a name

So, what’s the scoop?

It’s going to be called “Windows 7”, according to Mike Nash posting at the Windows Vista Blog.

How sneaky of Microsoft, to fool us into thinking that “Windows 7” was just the code name, when in fact it was also the release name!

Me, I think it’s because there was just no good way to include hints of the code-name in the final release name, like Microsoft have done in the past.

Think about it – “Cairo” spawned “Windows XP” – the Greek letters chi and rho are written: “ΧΡ” (lower-case is “χρ”) (if you don’t have the Greek font, that looks almost indistinguishable from “XP”). I’ll always think of it as “Windows No Parking”.

Windows 6 became Windows Vista – get it, six is “vi” in roman numerals?

So, Windows 7 should have been Windows Viista. Or maybe the name could have made obscure art-house movie references, and been called “A Vee and two ones”. Ah, but anything with VII in it might be perilously close to Intel’s VIIV product (currently residing in our “where are they now” file).

Perhaps this should make us think back to the last time a Windows client operating system was referred to by the word “Windows” followed by its version number – yes, “Windows 7” is designed to hearken back to “Windows 3.11”. Ah, yes, those were the days, indeed.

I can’t wait to see what’s coming in Windows 7, particularly things like Multi-touch support (though I have yet to purchase a system that has even single touch support).

Seven also marks Windows’ transition from an acid into a base.

Posted in Bad Names, Miscellany - not security, Windows Vista | Leave a comment