Tales from the Crypto : Windows Vista

Why .NET apps keep crashing on your Tablet PC

Alun Jones — Sat, 07 Nov 2009 23:24:29 GMT

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.

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

Alun Jones — Thu, 25 Dec 2008 21:52:25 GMT

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.

Redmond Report says “Vista Kernel Flawed”

Alun Jones — Wed, 10 Dec 2008 04:52:22 GMT

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.

Windows 7 officially has a name

Alun Jones — Tue, 14 Oct 2008 17:41:39 GMT

So, what’s the scoop?

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

[Is it just me, or does Mike Nash look a little like the chef who got into trouble for inflating his resume in the opening credits to “Dinner: Impossible”? ]

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.

HTML Help in MFC

Alun Jones — Mon, 13 Oct 2008 04:36:11 GMT

I recently got around to converting an old MFC project from WinHelp format to HTML Help. Mostly this was to satisfy customers who are using Windows Vista or Windows Server 2008, but who don’t want to install WinHlp32 from Microsoft. (If you do want to install WinHlp32, you can find it for Windows Vista or Windows Server 2008 at Microsoft’s download site.]

Here’s a quick round trip of how I did it:

1. Convert the help file – yeah, this is the hard part, but there are plenty of tools, including Microsoft’s HTML Help Editor, that will do the job for you. Editing the help file in HTML format can be a little bit of a challenge, too, but many times your favourite HTML editor can be made to do the job for you.

2. Call EnableHtmlHelp() from the CWinApp-derived class’ constructor.

3. Remove the line ON_COMMAND(ID_HELP_USING, CWinApp::OnHelpUsing), if you have it - there is no HELP_HELPONHELP topic in HTML.

4. Add the following function:

void CWftpdApp::HelpKeyWord(LPCSTR sKeyword)
{
    HH_AKLINK akLink;
    switch (GetHelpMode())
    {
    case afxHTMLHelp:
        akLink.cbStruct = sizeof(HH_AKLINK);
        akLink.fReserved=FALSE;
        akLink.fIndexOnFail=TRUE;
        akLink.pszKeywords=sKeyword;
        akLink.pszMsgText=(CString)"Failed to find information in the help file on " + sKeyword;
        akLink.pszMsgTitle="HTML Help Error";
        akLink.pszWindow=NULL;
        AfxGetApp()->HtmlHelp((DWORD_PTR)&akLink,HH_KEYWORD_LOOKUP);
        break;
    case afxWinHelp:
        AfxGetApp()->WinHelp((long)(char *)sKeyword,HELP_KEY);
        break;
    }
}

5. Change your keyword help calls to call this new function:

((CWftpdApp *)AfxGetApp()->WinHelp((long)(char *)"Registering");

Becomes:

HelpKeyWord("Registering",HELP_KEY);

6. If you want to trace calls to the WinHelp function to watch what contexts are being created, trap WinHelpInternal:

void CWftpdApp::WinHelpInternal(DWORD_PTR dwData, UINT nCmd)
{
TRACE("Executing WinHelp with Cmd=%d, dwData=%d (%x)\r\n",nCmd,dwData,dwData);
CWinApp::WinHelpInternal(dwData,nCmd);
}

This trace comes in really, really (and I mean REALLY) handy when you are trying to debug “Failed to load help” errors. It will tell you what numeric ID is being used, and you can compare that to your ALIAS file.

7. If your code gives a dialog box that reads:

---------------------------
HTML Help Author Message
---------------------------
HH_HELP_CONTEXT called without a [MAP] section.
---------------------------
OK
---------------------------

What it means is that the HTML Help API could not find the [MAP] or the [ALIAS] section - without an [ALIAS] section, but with a [MAP] section, this message still will appear.

8. Don’t edit the ALIAS or MAP sections of your help file in HTML Help Editor – Microsoft has a long-standing bug here that makes it crash (losing much of your unsaved work, of course) unpredictably when editing these sections. Edit the HHP file by hand to work on these sections.

9. Most of your MAP section entries are automatically generated by the compiler, as .HM files, which hold macros appropriate for the specific control in the right dialog. Simply include the right HM file, and all you will need to do is create the right ALIAS mappings.

10. The MFC calls to HtmlHelp discard error returns from the function, so there’s really no good troubleshooting to go on when debugging access to help file entries.

Let me know if any of these helpful hints prove to be of use to you, or if you need any further clarification.

Weak point against Vista

Alun Jones — Sun, 12 Oct 2008 00:49:06 GMT

First rule of demonstrative writing – lead off with an undeniable example of the point you’re trying to make.

Case in point – Dan Lyons’ article in NewsWeek on “A Gloomy Vista for Microsoft”, meant to be a piece defining how bad Vista is.

“Last year I was meeting with the CEO of a PC company who offered to give me a demo of his company's gorgeous new top-of- the-line notebook, a machine that cost several thousand dollars and came loaded with Windows Vista, the latest version of Microsoft's operating system. He flipped open the laptop, pressed the power button, and … nothing. We waited. And waited. It was excruciating. He tried control-alt-delete. He tried holding down the power button. Finally he removed the battery and snapped it back into place. The machine started up—slowly—while the CEO sat there fuming.”

Um, yeah, OK, that sounds bad and all, but seriously, if you’re pressing the power button on a turned-off machine and nothing’s happening, that’s hardware. And if you blame hardware faults on the operating system, well, that’s just a CEO trying to ignore the fact that his hardware system and its developers aren’t providing a totally balanced view of their work.

So, let’s carry on reading. What else is a problem with Vista?

“It was sluggish. It had trouble going to sleep and waking up. It wouldn't work with some printers and accessories.”

I didn’t see “sluggish”, but then again, I bought a higher spec machine than my three-year-old laptop in order to run Vista, because it’s a significant update to the OS. Many of its major features expect there to be lots of memory and a fast 3D video card.

The “trouble going to sleep and waking up” part I definitely had some experience with – but then, I have those problems in XP, too: over 1MB in my machine, and XP decided it was going to turn my laptop bag into a pizza oven – to judge from the popularity of my blog post on the issue, I’m far from alone in this. Laptop manufacturers really haven’t had the best of luck in XP or Vista persuading individual devices – let alone the whole system – that it’s nighty-night time, or that it’s time to wake up when you punch the “wake-up” key. Recent updates from Lenovo made my life a little easier, but the machine will still sometimes go to sleep never to wake up again. Really irritating when I’m in the middle of working as the bus arrives at its destination and I have to press the sleep button, praying that the machine will make it through the nap. And I can guarantee to hang the system if I press the sleep button and then close the lid.

And, as for printers and accessories, it’s clear that any number of device drivers weren’t actually used for any significant length of time in the Vista environment, or they’d have shown their incompatible designs. My HP printer, for instance, pops up this ugly dialog whenever I print from Internet Explorer:

Now, I don’t know much about drivers, but I suspect that this could be fixed by signing the driver. My other HP printer continually offers up a new version of its drivers on Windows Update, and then the installation refuses to start, because the printer isn’t plugged in to my machine. Well, of course not, it’s a network printer.

As has been pointed out by numerous other writers, XP had this same sort of flack when it released (although I don’t remember it going on for quite this long), and then as now, most of the problems were to do with software and hardware developers who weren’t paying even limited attention to the statements Microsoft put out as to features that were deprecated (i.e. made obsolete, going away, or otherwise disappearing).

Of course, my wife hates Vista, and at some point I’ll be able to point you to her ideas on the topic, because she has some actually valid arguments as to why Vista sucks. And none of those arguments are represented in Dan Lyons’ Newsweek article.

My MP3 player demands to administer my system

Alun Jones — Tue, 26 Aug 2008 06:22:35 GMT

Thanks to the excellent http://www.woot.com, I upgraded to a new MP3 player - this one, the Sansa e250 from SanDisk, has a little screen and shows video at an almost completely unacceptably small resolution. But I don't mind that, I didn't really buy it for the video. I don't mind the big fat "REFURB" label stuck on the back, nor do I really mind all that much that it's already lost a screw from the back.

What I do mind is that the developers of the software accompanying this player haven't figured out that I might want to use it as a consumer device, rather than an Information Technology Administration Tool. Quite honestly, I can't see how a media player - even if you count its ability to do video the size of my thumb - can be used to administer my system, but clearly that's the intent of the designers, because the software all insists on running as administrator.

The software at fault is at least the following:

Sansa Dispatcher - runs at logon, insists on running as administrator, therefore gets blocked on my Vista system. I'm still not quite sure what it's supposed to do, because I can use the Sansa acceptably well without this tool running, and when I do run it unblocked as admin, it does nothing more useful than causing my laptop to repeatedly crash with a blue-screen of death. Not very impressive.
Sansa Media Converter - allegedly this is required to put photos and videos onto the device - this, too, requires that I run it as an administrator (why? all it's supposed to do is convert movies and graphics from one format to another, and then copy them to the USB drive that the Sansa pretends to be when plugged in)
As if that wasn't infuriating enough, the Sansa Media Converter requires Apple QuickTime, my old nemesis. Yes, that means I'm back on the Apple Update thrill-ride to distraction.

It almost makes me want to wipe the firmware in the device and replace it with the Open Source software "Rock Box". Maybe then I can use ordinary tools to move my media onto the device, as an ordinary user.

We developers clearly have a loooong way to go before we grasp this concept that "administrator means the guy who makes changes to the configuration of the operating system", and "standard user means the guy who spends his life actually using the operating system".

I would love to be able to sort this out with technical support, but they insist on not talking to me in email, but requiring me to log on to a third party "eBox" from "customernation.com" - which sends out exhortations to visit your eBox as soon as Sansa's support has put a message in it. These invites come with your user name and password - over unencrypted email. Nice.

I'd tell you what's in my eBox, and what Sansa's support said, but I haven't been able to keep a connection up long enough for the painfully slow customernation.com web site to actually display anything. This is not a pleasant customer experience.

Kaminsky Black-Hat Webcast: "By Any Other Name: DNS has doomed us all."

Alun Jones — Fri, 25 Jul 2008 09:03:00 GMT

Okay, so the talk’s official title was “Dan Kaminsky’s DNS Discovery: The Massive, Multi-Vendor Issue and the Massive, Multi-Vendor Fix”.

Arcane details of TCP are something of a hobby of mine, so I attended the webcast to see what Dan had to say.

The Past is Prologue

A little history first – six months ago, Dan Kaminsky found something so horrifying in the bowels of DNS that he actually kept quiet about it. He contacted DNS vendors – OS manufacturers, router developers, BIND authors, and the like – and brought them all together in a soundproofed room on the Microsoft campus to tell them all about what he’d discovered.

Everyone was sworn to secrecy, and consensus was reached that the best way to fix the problem would be to give vendors six months to release a coordinated set of patches, and then Dan Kaminsky would tell us all at BlackHat what he’d found.

Until then, he asked the security community, don’t guess in public, and don’t release the information if you know it.

Now is the winter of our DNS content (A records and the like)

Fast forward a few months, and we have a patch. I don’t think the patch was reverse-engineered, but there was enough public guessing going on that someone accidentally slipped and leaked the information – now the whole world knows.

Kaminsky confirmed this in today’s webcast, detailing how the attack works, to forge the address of www.example.com:

Attacker persuades victim to ask for 1.example.com
Victim’s DNS server queries for an A record for 1.example.com
Attacker forges a response that says “I don’t know 1.example.com, but the DNS server at www.example.com knows, and it’s at 1.2.3.4”
Victim’s DNS server accepts this response, queries 1.2.3.4 for 1.example.com, and now the attacker knows that the victim can be directed to www.example.com at 1.2.3.4, allowing the attacker to steal cookies, represent as a trusted web site, etc, etc.

Note that this is a simple description of the new behavior that Kaminsky found – step 3 allows the DNS server’s cache to be poisoned with a mapping for www.example.com to 1.2.3.4, even if it was already cached from a previously successful search.

If that was all that Kaminsky could do, even on an unpatched server, he’d have a 1 in 65535 chance of guessing the transaction ID to make his forgery succeed. However, old known behaviours simply make it easier for the attacker to make the forgery work:

Because the attacker tells the victim to search for a site, the attacker controls when the race with the authoritative DNS server starts.
The attacker can tell the victim to search several times, and can forge several possible responses, using the birthday paradox to be more likely to guess the transaction ID (and source port), so that his forged response is accepted.
Because this attack overwrites cached entries, the attacker can try again and again (picture a site with a million 1-pixel images each causing a different DNS query) until he is successful. Stuffing the cache won’t protect you.
The attacker can insert an obscenely huge TTL (time-to-live) on the faked entry, so that it remains in cache until the DNS service is flushed or restarted.

Kaminsky’s tests indicate that a DNS server’s cache can be poisoned in this way in under ten seconds. There are metasploit plugins that ‘demonstrate’ this (or, as with all things metasploit, can be used to exploit systems).

The patch, by randomizing the source port of the DNS resolver, raises the difficulty of this attack by a few orders of magnitude.

The long-term fix, Kaminsky said, is to push for the implementation of DNSSEC, a cryptographically-signed DNS system, wherein you refuse to pass on or accept information that isn’t signed by the authoritative host.

A port, a port, my domain for a port

One novel wrinkle that Kaminsky hadn’t anticipated is that even after application of the patch to DNS servers, some NATs apparently remove the randomness in the source port that was added to make the attack harder. To quote Kaminsky “whoops, sorry Linksys” (although Cisco was one of the companies he notified of the DNS flaw, and they now own Linksys). Such de-randomising NATs essentially remove the usefulness of the patch.

Patching is not completely without its flaws, however – Kaminsky didn’t mention some of the issues that have been occurring because of these patches:

ZoneAlarm decided that DNS queries from random source ports must be a sign of attack, and denied all such queries, essentially disconnecting the Internet from users of ZoneAlarm. I guess I can learn to live with that.
BIND doesn’t check when binding to a random port to see if that port is already in use – as a result, when the named server sends out a DNS query, there’s a chance the response packet will come back to a service that isn’t expecting it. Because the outgoing query punches a return hole in most firewalls, this could mean that a service blocked by the firewall from receiving Internet traffic is now opened up to the Internet. The workaround is to set the avoid-udp-v4-ports configuration setting, listing any ports that named shouldn’t use.
Windows’ DNS service takes a different tack, binding to 2500 (the number is configurable) random ports on startup. As with BIND, these ports might conflict with other services; different from BIND, however, is the behavior – since the ports are already bound by the DNS server, those other services (starting later than DNS, because most IP components require it) are now unable to bind to that port. As with BIND, the workaround is to tell the DNS server which ports not to use. The registry entry ReservedPorts will do this.
Users are being advised to point their DNS server entries to OpenDNS. Single point of failure, anyone?

Metrics and statistics:

When Kaminsky’s vulnerability detection tool was first made available at doxpara.com, 80+% of all checks indicated that the DNS server was vulnerable. This last week, 52% of all checks showed vulnerable servers. Patches are getting installed.
The attack is noisy – output from the metasploit framework showed “poisoning successful after 13250 attempts” – that’s thirteen thousand DNS queries and 260,000 forged DNS responses. IDS and IPS tools should have signatures for this attack, and may be able to repel boarders.
Metasploit exploits for this are at http://www.caughq.org/exploits/CAU-EX-2008-0003.txt if you want to research it further.

Tomorrow, and tomorrow, and tomorrow...

The overall message of the webcast is this:

This attack is real, and traditional defences of using a high TTL will not protect you. Patching is the way to go. If you can’t patch, configure those unpatched DNS servers to forward to a local new (patched) DNS server, or an external patched server like OpenDNS. Scan your site for unexpected DNS servers.

Whoops - Information Wanted to be Free Again.

Alun Jones — Tue, 22 Jul 2008 05:09:51 GMT

Picture the scene at Security Blogs R Us:

"We're so freakin' clever, we've figured out Dan Kaminsky's DNS vulnerability"

"Yeah, but what if someone else figures it out - won't we look stupid if we post second to them?"

"You're right - but we gave Dan our word we wouldn't publish."

"So we won't publish, but we'll have a blog article ready to go if someone else spills the beans, so that we can prove that we knew all about it anyway."

"Yeah, but we'd better be careful not to publish it accidentally."

>>WHOOP, WHOOP, WHOOP<<

"What was that?"

"The blog alert - someone else is beating us to the punch as we speak."

"Publish or perish! Damn the torpedoes - false beard ahead!"

"What? Are you downloading those dodgy foreign-dubbed pirated anime series off BitTorrent through the company network again?"

"Yes - I found a way around your filters."

"Good man."

It's true (okay, except for all of the made-up dialog above), a blog at one of the security vulnerability research crews (ahem, Matasano) did the unthinkable and rushed a blog entry out on the basis that they thought someone else (ahem, Halvar Flake) was beating them to it. And now we all know. The genie is out of the bag, the cat has been spilled, and the beans are out of the bottle.

Now we all know how to spoof DNS.

Okay, so Matasano pulled the blog pretty quickly, but by then it had already been copied to server upon server, and some of those copies are held by people who don't want to take the information off the Internet.

Clearly, Information Wants To Be Free.

There's an expression I never quite got the hang of - "Information Wants To Be Free", cry the free software guys (who believe that software is information, rather than expression, which is a different argument entirely) - and the sole argument they have for this is that once information is freed, it's impossible to unfree it. A secret once told is no longer a secret.

There's an allusion to the way in which liquid 'wants to be at its lowest level' (unless it's liquid helium, which tends to climb up the sides of the beaker when you're not looking), in that if you can't easily put something back to where it used to be, then where it used to be is not where it wants to be.

So, information wants to be free, and Richard Stallmann's bicycle tyre wants to have a puncture.

But back to the DNS issue.

I can immediately think of only one extra piece of advice I'd have given to the teams patching this on top of what I said in my previous blog, and that's something that, in testing, I find the Windows Server 2003 DNS server was doing anyway.

So, that's alright then.

Well, not entirely - I do have some minor misgivings that I hope I've raised to the right people.

But in answer to something that was asked on the newsgroups, no I don't think you should hold off patching - the patch has some manual elements to it, in that you have to make sure the DNS server doesn't impinge on your existing UDP services (and most of you won't have that many), but patching is really a whole lot better than the situation you could find yourself in if you don't patch.

And Dan, if you're reading this - hi - great job in getting the big players to all work together, and quite frankly, the secrecy lasted longer than I expected it to. Good job, and thanks for trying to let us all get ourselves patched before your moment of glory at BlackHat.

DNS Server Reserves 2500 Ports.

Alun Jones — Sat, 19 Jul 2008 07:02:00 GMT

After applying the patch for MS08-037 - KB 953230 (the multi-OS DNS flaw found by Dan Kaminski), you may notice your Windows Server 2003 machine gets a little greedy. At least, mine sucks up 2500 - yes, that's two thousand five hundred - UDP sockets sitting there apparently waiting for incoming packets.

This is, apparently, one of those behaviours sure to be listed in the knowledge base as "this behavior is by design" - a description that graces some of the more entertaining elements of the Microsoft KB.

Why does this happen? I can only guess. But here's my best guess.

The fix to DNS, implemented across multiple platforms, was to decrease the chance of an attacker faking a DNS response, by increasing the randomness in the DNS requests that has to be copied back in a response.

I don't know how this was implemented on other platforms, but I do know that it's already been reported that BIND's implementation is slower than it used to be (hardly a surprise, making random numbers is always slower than simply counting up) - and maybe that's what Microsoft tried to forestall in the way that they create the random sockets.

Instead of creating a socket and binding it to a random source port at the time of the request, Microsoft's patched DNS creates 2500 sockets, each bound to a random source port, at the time that the DNS service is started up. This way, perhaps they're avoiding the performance hit that BIND has been criticised for.

There are, of course, other services that also use a UDP port. ActiveSync's connection to Exchange, IPsec, IAS, etc, etc. Are they affected?

Sometimes.

Randomly, and without warning or predictability. Because hey, the DNS server is picking ports randomly and unpredictably.

[Workaround: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ReservedPorts is a registry setting that lists multiple port ranges that will not be used when binding an ephemeral socket. The DNS server will obey these reservations, and not bind a socket to ports specified in this list. More explanation in the blog linked above, or at http://support.microsoft.com/kb/812873]

DNS, you see, is a fundamental underpinning of TCP/IP services, and as such needs to start up before most other TCP/IP based services. So if it picks the port you want, it gets first pick, and it holds onto that port, preventing your application from binding to it.

This just doesn't seem like a fix written by someone who 'gets' TCP/IP. Perhaps I'm missing something that explains why the DNS server in Windows Server 2003 works this way, but I would be inclined to take the performance hit of binding and rebinding in order to find an unused random port number, rather than binding before everyone else in an attempt to pre-empt other applications' need for a port.

There are a couple of reasons I say this:

Seriously, how many Windows Server 2003 users out there have such a high-capacity DNS server that they will notice the performance hit?
Most Windows Server 2003-based DNS servers are small caching servers for businesses, rather than Internet infrastructure servers responsible for huge numbers of requests per second - even if you implement this port-stealing method, it shouldn't be the default, because the majority of users just don't need that performance.
If you do need the performance, get another server to handle incoming requests. Because the cost of having your DNS server's cache poisoned is considerably greater than the cost of increasing the number of servers in your pool, if you're providing major DNS service to that many customers.
A major DNS service provider will be running fewer services that would pre-empt a DNS server request to bind to a random port, whereas systems running several UDP-based services are going to need less performance on their outgoing DNS requests.

I'd love to know if I'm missing something here, but I really hope that Microsoft produces a new version of the DNS patch soon, that doesn't fill your netstat -a output with so many bound and idle sockets, each of which takes up a small piece of nonpaged pool memory (that means real memory, not virtual memory).

Vistafy Me.

Alun Jones — Fri, 11 Jul 2008 05:07:25 GMT

I have a little time over the next couple of weeks to devote to developing WFTPD a little further.

This is a good thing, as it's way past time that I brought it into Vista's world.

I've been very proud that over the last several years, I have never had to re-write my code in order to make it work on a new version of Windows. Unlike other developers, when a new version of Windows comes along, I can run my software on that new version without changes, and get the same functionality.

The same is not true of developers who like to use undocumented features, because those are generally the features that die in new releases and service packs. After all, since they're undocumented, nobody should be using them, right? No, seriously, you shouldn't be using those undocumented features.

So, WFTPD and WFTPD Pro run in Windows Vista and Windows Server 2008.

But that's not enough. With each new version of Windows, there are better ways of doing things and new features to exploit. With Windows Vista and Windows Server 2008, there are also a few deprecated older behaviours that I can see are holding WFTPD and WFTPD Pro down.

I'm creating a plan to "Vistafy" these programs, so that they'll continue to be relevant and current.

Here's my list of significant changes to make over the next couple of weeks:

Convert the Help file from WinHelp to HTML Help.

WinHelp is not supported in Vista - you can download a WinHelp version, but it's far better to support the one format of Help file that Windows uses. So, I'm converting from WinHelp to HTML Help.

Changing the Control Panel Applet for WFTPD Pro.

CPL files still work in Windows Vista, but they're considered 'old', and there's an ugly user experience when it comes to making them elevate - run as administrator.
There are two or three ways to go here -

one is to create an EXE wrapper that calls the old CPL file. That's fairly cheap, and will probably be the first version.
Another is to write an MMC plugin. That's a fair amount of work, and requires some thought and design. That's going to take more than a couple of weeks.
A third option is to create some form of web-based interface. I don't want to go that way, because I don't want to require my users to install IIS or some other web server.

So, first blush it seems will be to wrap the existing interface, and secondly I'll be investigating what an MMC should look like.

Support for IPv6.

I already have this implemented in a trial version, but have yet to fully wire it up to a user interface that I'm willing to unleash on the world. So that's on the cards for the next release.

Multiple languages

There are two elements to support for multiple languages in FTP:

File names in non-Latin character sets
Text messages in languages other than English

The first, file names in different character sets, will be achieved sooner than the second. If the second ever occurs, it will be because customers are sufficiently interested to ask me specifically to do it.

SSL Client Certificate authentication

SSL Client Certificate Auth has been in place for years - it's a secret feature. The IIS guys warned me off developing it, saying "that's really hard, don't try and do anything with client certs".
I didn't have the heart to tell them I had the feature working already (but without an interface), and that it simply required a little patience.

Install under Local Service and Network Service accounts
Build in Visual Studio 2008, to get maximum protection using new compiler features.

/analyze, Address Space Layout Randomisation, SAL - all designed to catch my occasional mistakes.

As I work on each of these items, I'll be sure to document any interesting behaviours I find along the way. My first article will be on converting your WinHelp-using MFC project to using HTML Help, with minimal changes to your code, and in such a way that you can back-pedal if you have to.

Of course, I also have a couple of side projects - because I've been downloading a lot from BBC 7, I've been writing a program to store the program titles and descriptions with the MP3 files, so that they show up properly on the MP3 player. ID3Edit - an inspired name - allows me to add descriptions to these files.

Another side-project of mine is an EFS tool. I may use some time to work on that.

The difference between liking and hating UAC?

Alun Jones — Wed, 11 Jun 2008 04:17:51 GMT

Totally unscientifically, I have carried out a poll of people who like UAC (okay, a few security geeks like myself), and those who hate UAC - mostly my wife.

Something struck me as both a surprising common factor, and also a rather obvious explanation of why the two opinions are so polarised.

[Note for the pedants - yes, I'm using the term "UAC" here to mean "Elevation" - there are other portions of UAC that I'm not discussing, such as Protected Mode in Internet Explorer, and so on.]

We use UAC for different purposes

UAC-lovers

The UAC-lover seems to have 'got least-privilege religion' at least several years ago, and runs most of the time as a standard, restricted user. Most UAC-lovers do not seem to be "Administering the system all the time" types.

As a result, they use UAC as a means to elevate privilege on those occasions when they need to do something administrative, or when they need to run a program that has not yet been coded to run with least privilege.

When they're doing something administrative, they're comparing the UAC "Over-the-shoulder" (OTS) prompt against the methods that used to be available to them:

Log off and back on - to do this, you have to close out all your applications, saving the documents you were working on, log off, log on as the administrator account, do the admin thing, log off, and log back on as your regular account.
Fast User Switching (FUS) - not available on a domain, and anything but fast. The only advantage it has over logging out and back in is that you maintain your application state in the restricted user - the documents are still open, the programs are still running, etc.
RunAs - this used to be how you elevate in Windows prior to Vista, but now you have to find another tool to do the same job for you, because RunAs won't elevate your session even if you provide it with administrator credentials. [I use Jesper's Elevate Explorer Tools from the Windows Server 2008 Security Resource Kit.]

Given these as alternatives, it's no wonder that UAC and OTS elevation prompts are considered better.

UAC-haters

The UAC-hater is fundamentally disinterested in least-privilege, at least as it applies to users. Least-privilege is an obvious and good programming strategy, a program shouldn't ask for more privileges than it needs, but to this user, that's something that the programmers should care about.

This user wants to be instantly, and automatically, elevated whenever she calls on a feature that would require it. This is how she's used to running the computer, because she's always called on to do administrative tasks - and she's careful and knowledgeable enough to have avoided causing damage through doing so.

To this user, UAC is an impediment to that process - now, instead of merely running the administrative tool she wants, she has to ask to be allowed to run it as administrator.

With UAC set to automatically elevate for administrators, however, she's far happier. Still not perfectly happy, because there are still occasions when she has to ask specifically to run elevated - when the program is capable of running as non-administrator, for instance. Such programs run as non-administrator by default, and don't elevate themselves. These programs are irritating to such a user.

Typically, such programs appear to break when run with UAC disabled (or set to automatically elevate) - they fail to run, sometimes with bizarre error messages, often just crashing through failure to execute some action that the developers expected would succeed.

Other causes of breakage could be when an application is registered to a user, and the licence information is written to a file in the Program Files folder - when you're running under UAC's protection, files in the Program Files folder may be virtualised (i.e. the program thinks it's accessing the file in the Program Files folder, but it's really accessing a file in the user's home directory tree), and when you're running elevated, those same file accesses are not virtualised.

So, voila, instant loss of licence information, saved settings, or any number of other files that the program expected to find in Program Files.

What can we learn from this?

So, the message is clear - for installations with administrators who like the system to let them be administrators, don't disable UAC, make UAC elevate silently for administrators instead.

This system works, too, for the restricted users. It allows them to operate as restricted users, except when they absolutely know they need to elevate. Over-the-shoulder elevation prompting is still available for them, should they need it.

What still needs to be fixed?

What this option doesn't do is cover what appears to be Microsoft's reason for creating the elevation prompts in the first place. Without UAC prompting at random points, the administrators in control of a system have no clear sign that they've just fired up "Mary Kate and Ashley's Dance Party of the Century" only to be forced to run it as an administrator.

Even supposing you figure out that there's a program you're using which doesn't adequately run in restricted user mode, or which doesn't elevate itself where necessary, where can you go to get assistance from the developers of the application?

Call support?

Microsoft's own support is an example of how off-putting such a process can be. Microsoft Money refused to update on one of our systems, and I eventually determined it was because the update needed to be elevated, but was expecting to find some files that were virtualised by UAC. It failed with a meaningless error message. To call support costs $25 for Microsoft to even pick up the phone - and if the support tech believes that this is an "advanced" issue, he may charge about ten times that much. Perhaps later, after they realise the problem is their own fault, Microsoft will refund you the money - but many small businesses and individual users don't have that sort of money to loan to Microsoft, or other vendors.

So, is there any good way to persuade developers to quit their bone-headed "start with most privilege" behaviour? Maybe Visual Studio and compilation tools should refuse to run in an administrator session. Okay, so perhaps that's not tenable, because there are development projects that do require you to be an administrator, because you're developing something administrative - but what measure would make developers do the right thing for security (and for their users) naturally?

File and registry virtualisation appears to be a messy kludge on top of the sledge-hammer of UAC elevation, whose primary design goal appears to be to irritate end-users enough to persuade developers to stop doing the kind of things that requires virtualisation as a workaround, and the kind of things that requires administrator accounts in the first place.

Perhaps it's time that, instead of kludging for these bad developers, Microsoft simply said "It stops. Now." - if it's not registered (at install time, or by manifest) as an administration tool, it doesn't get administrative access - or virtualised access to HKLM or Program Files. Yes, that will mean admins will have two links to regedit, and similar tools - one to run in an administrator's session, giving access to HKLM, another to run in their user's session, giving access to HKCU.

UAC - The Emperor's New Clothes

Alun Jones — Thu, 24 Apr 2008 23:47:38 GMT

I heard a complaint the other day about UAC - User Account Control - that was new to me.

Let's face it, as a Security MVP, I hear a lot of complaints about UAC - not least from my wife, who isn't happy with the idea that she can be logged on as an administrator, but she isn't really an administrator until she specifically asks to be an administrator, and then specifically approves her request to become an administrator.

My wife is the kind of user that UAC was not written for. She's a capable administrator (our home domain has redundant DCs, DHCP servers with non-overlapping scopes, and I could go on and on), and she doesn't make the sort of mistakes that UAC is supposed to protect users from.

My wife also does not appreciate the sense that Microsoft is using the users as a fulcrum for providing leverage to change developers to writing code for non-admin users. She doesn't believe that the vendors will change as a result of this, and the only effect will be that users get annoyed.

But not me.

I like UAC - I think it's great that developers are finally being forced to think about how their software should work in the world of least privilege.

So, as you can imagine, I thought I'd heard just about every last complaint there is about UAC. But then a new one arrived in my inbox from a friend I'll call Chris.

"Why should I pretend to be different people to use my own PC?"

I must admit, the question stunned me.

Obviously, what Chris is talking about is the idea that you are strongly "encouraged" (or "strong-armed", if you prefer) by UAC to work in (at least) two different security contexts - the first, your regular user context, and the second, your administrator context.

Chris has a point - you're one person, you shouldn't have to pretend to be two. And it's your computer, it should do what you tell it to. Those two are axiomatic, and I'm not about to argue with them - but it sounds like I should do, if I'm going to answer his question while still loving UAC.

No, I'm going to argue with his basic premise that user accounts correspond to individual people. They correspond more accurately - particularly in UAC - to clothing.

Windows before NT, or more accurately, not based on the NT line, had no separation between user contexts / accounts. Even the logon was a joke - prompted for user name and password, but if you hit Escape instead, you'd be logged on anyway. Windows 9x and ME, then, were the equivalent of being naked.

In Windows NT, and the versions derived from it, user contexts are separated from one another by a software wall, a "Security Boundary". There were a couple of different levels of user access, the most common distinctions being between a Standard (or "Restricted") User, a Power User, and an Administrator.

Most people want to be the Administrator. That's the account with all the power, after all. And if they don't want to be the Administrator, they'd like to be at least an administrator. There's not really much difference between the two, but there's a lot of difference between them and a Standard User.

Standard Users can't set the clock back, they can't clear logs out, they can't do any number of things that might erase their tracks. Standard Users can't install software for everyone on the system, they can't update the operating system or its global settings, and they can't run the Thomas the Tank Engine Print Studio. [One of those is a problem that needs fixing.]

So, really, a Standard User is much like the driver of a car, and an administrator is rather like the mechanic. I've often appealed to a different meme, and suggested that the administrator privilege should be called "janitor", so as to make it less appealing - it really is all about being given the keys to the boiler room and the trash compactor.

It's about wearing dungarees rather than your business suit.

You wear dungarees when working on the engine of your car, partly because you don't want oil drops on your white shirt, but also partly so your tie doesn't get wrapped around the spinning transmission and throttle you. You don't wear the dungarees to work partly because you'd lose respect for the way you look, but also because you don't want to spread that oil and grease around the office.

It's not about pretending to be different people, it's about wearing clothes suited to the task. An administrator account gives you carte blanche to mess with the system, and should only be used when you're messing with the system (and under the assumption that you know what you're doing!); a Standard User account prevents you from doing a lot of things, but the things you're prevented from doing are basically those things that most users don't actually have any need to do.

You're not pretending to be a different person, you're pretending to be a system administrator, rather than a user. Just like when I pretend to be a mechanic or a gardener, I put on my scungy jeans and stained and torn shirts, and when I pretend to be an employee, I dress a little smarter than that.

When you're acting as a user, you should have user privileges, and when you're acting as an administrator, you should have administrative privileges. We've gotten so used to wearing our dungarees to the board-room that we think they're a business suit.

So while UAC prompts to provide a user account aren't right for my wife (she's in 'dungarees-mode' when it comes to computers), for most users, they're a way to remind you that you're about to enter the janitor's secret domain.

CS-RCS Pro on Vista

Alun Jones — Tue, 26 Feb 2008 19:55:06 GMT

I've been trying back and forth to get CS-RCS Pro, a version control suite, to work on Windows Vista.

I like CS-RCS Pro for a number of reasons:

Files stored in CS-RCS Pro are kept in a simple format, open and well-documented. As a result, if I ever have to move away from CS-RCS Pro (say, for instance, if they go out of business, or stop supporting it), I stand a good chance of reconstructing my versioning information completely in whatever product I move to, if only by re-creating files at each epoch and then checking them in to the new tool.
CS-RCS Pro integrates with Visual Studio. I can check files in and out while I'm editing them.
CS-RCS Pro integrates with Explorer, as a Shell Extension, so that you can right-click on source files, and check them in from there.
Of course, most important is that for single users, it's free.

But that last point is the cause of a big problem.

Here's the sequence I have to deal with:

I have the single-user version of CS-RCS Pro.
I use best practices for development of secure applications, particularly as regards running my software and my development tools as a restricted user unless it is strictly necessary to become an admin to test admin-level features, or to install / uninstall software or services, or to debug code that is running a different user context from my own.
CS-RCS Pro insists that the user who installs it is also the user who runs it.
CS-RCS Pro must be installed by an administrator.

I had originally intended to follow the appropriate installation practice for an enterprise application - that it should be installed by a recognised administrator, and then any post-install setup to customise for the end-user would be carried out by that end-user for themselves.

This didn't work, as CS-RCS Pro configured the version control tree to be used by the administrative user, making it impossible for my restricted user to access the files.

I tried simply editing the ownerships and ACLs - that didn't work - and then to additionally edit the configuration files, where it mentioned the name of my administrative user. That worked for a short while, but I noticed that every time I used MSTSC - Remote Console - also known as the Terminal Services Client - to access the system, the shell extension that CS-RCS Pro installs took up 100% CPU, and required that I restart Explorer. There are still a few applications that don't work well when you kill Explorer from underneath them, and so this was somewhat of an untenable position.

Besides, this was an awful lot of effort to go through in order to get version control going.

Finally, it hit me how I should do this properly. It's not clean and it's not clever, and ComponentSoftware, the folks behind CS-RCS Pro, should consider how to change their installer to avoid this issue.

The simple five-step process is as follows - let's say Wayne, an administrator, wants to install the software for Sharon, a restricted user:

Wayne adds Sharon to the Local Administrators group on the machine to which Wayne will be installing CS-RCS Pro.
Wayne logs on as Sharon (*)
Wayne installs the application.
Wayne logs off Sharon's account.
Wayne removes Sharon from the Local Administrators group.

(*) Note that asterisk - that's the troubling part. Actually, step 1 is troubling too, but only because Sharon may have other processes trying to log in with elevated rights, should they ever be granted.

Step 2 requires either that Wayne allows his user, restricted though she is meant to be, to log on as an administrator - what if she quickly runs some tool that you don't want her to run?

Okay, so you drag her away from the console immediately after she types her password - but what if she's got startup items to add an administrative user on her behalf, or simply to stay in memory (as a service, say) and run with those enhanced privileges, to allow exploit later?

Alright, so what's the safest way? The only good way I can think of is this:

Wayne resets Sharon's password.
Wayne adds Sharon's account to Local Administrators. Note that Sharon can't log on at this point.
From a command prompt in Wayne's restricted user account, Wayne uses the runas command to execute the installation script in Sharon's new administrative context. Runas reduces, and possibly eliminates, the chance that this administrative context will have the ability to run Sharon's own code (unless the installation script does so).
Wayne removes Sharon from the Local Administrators account.
Wayne sets Sharon's account to force a password change after the next logon.
Wayne tells Sharon her new password.
If this is not a domain environment, Sharon must change her password back to what it used to be, so that it is possible for her to access her protected data.

Some of you are probably reading this and wondering why I bother - after all, in many environments, developers insist on running as administrator all the time, because their development tools don't support anything else.

Well, it's time your developers - and their tools - grew up. Yes, I can quote, just as any other developer can, a number of cases where administrative access is required - although many developers actually get this wrong. You can run Visual Studio 2005 as a non-administrator. You can debug your own code running in your own logon session as a non-administrator.

Developers are very often the only people to run some sections of the code that they build, until it reaches the hands of the users. As such, developers need to spend as much time as possible, when they run their code, working in the same kind of user context as their users will have.

In general, developers should follow the same principle as other administrators - their day-to-day tasks (e-mail, web browsing, and yes, development) should be done in restricted user accounts; administrative user accounts should be available, but their use should be restricted to those operations which absolutely require administrative access, and those operations should be reviewed often enough to ensure that they need administrative access. Tools and environments grow and change, and a tool which yesterday required administrative access may run tomorrow without. LogonUser, for instance, used to require complete system access - today it can be called by any user.

Vista's Secret Windows Firewall hole

Alun Jones — Fri, 25 Jan 2008 05:19:00 GMT

First, the good news - it's not a flaw in the operation of Windows Firewall on Windows Vista. It's a design feature, it makes sense, and it fits in with the principle that the firewall should keep out unsolicited traffic. It's not really a hole, but I thought I'd grab your attention.

The symptom first came up in a Usenet posting (thanks, Jesper, for bringing me in) about Vista and a third-party FTP client:

When I do a directory listing, and a PORT command is issued, and the
server attempts to connect, it works, but at the same time a dialogue
appears telling me it's blocked, and I can keep blocking or unblock.
I choose keep blocking but it doesn't actually block it once.

Here's how it looks.

First, if you haven't got a third-party FTP client let's fake it, by copying Microsoft's command-line FTP client from the Windows System32 directory to another directory:

C:\users\MyMe> copy %windir%\system32\ftp.exe
1 file(s) copied.

The FTP client will not display prompts to you, but that's a minor issue - if it upsets you, try downloading a third-party client and trying it.

Anyway, here we go - let's try the issue in question:

Type ftp ftp.microsoft.com
After you see the "220" greeting message, enter ftp as the user - press enter.
Now you're prompted for a password - enter anything and press enter.
Once you're logged on, enter dir - again, press enter.
You'll see the directory listing succeed, but you'll also see a warning that a connection is being blocked:

Wow - that's freaky - at the same time you're being told that the connection used for the file listing will be blocked, it allows the connection through!

What's more, even if you specify Keep Blocking, and then go issue another dir command, that one succeeds.

Huh? And why on earth did you make me use a copy of FTP?

Let's go look at the Windows Advanced Firewall Rules for Inbound, and see if this sheds any light:

[That means click the Start button, type Firewall into the search box, and right-click on Windows Firewall with Advanced Security - select Run as Administrator

and accept the elevation prompt from UAC. If you don't have an elevation prompt, then you should really re-enable UAC. Now select Inbound Rules in the left-hand pane]

Me, I've got a few rules labeled File Transfer Program:

That first (and fourth) rule is set to block any listening ports opened by the File Transfer Program in C:\users\myme\ftp.exe, the second two seem to be allowing any listening ports created by the one in C:\windows\system32\ftp.exe.

Obviously, that's why I asked you to copy ftp.exe to a new directory, so that any previous allowance by the firewall rules wouldn't get in the way.

So what's happening here? Is the "Allow" rule somehow overriding the "Block" rule, even though it's not dealing with the same executable?

We can test that simply by deleting both sets of rules - go ahead and do that, I'll wait for you.

Didn't make a bit of difference, did it? It still allowed the traffic, then prompted you if you wanted to block it. Even if you selected to "Keep Blocking", the next and subsequent transfers still worked, right?

Okay - let's consult the Big Book of Knowledge (alright, what I can vaguely remember after mumbleteen years in the networking world). Some routers and firewalls use an Application Layer Gateway (ALG) to translate FTP commands, and open ports. Is that what's going on here?

Let's take a peek at the services on this machine (as an administrator, run services.msc):

Bingo - there it is, the Application Layer Gateway Service. And when you have Internet Connection Sharing running, that's what translates IP addresses in FTP commands for you, and what opens up port mappings and holes in the NAT that ICS hosts.

Oh, but wait a moment - what's that in the "Status" column?

That's right, nothing. This service isn't running.

Something must be happening to open this port up - it's not just a case of "port left open", nor is it an outbound port. Those ports are closed tight until the FTP client starts listening for incoming data connections, and then they're opened up.

Here's where I go into MVP-mode, and start searching in all the nooks and crannies of the web and whatever documentation it holds.

Net result - Windows Firewall in Windows Vista includes something called a "connection inspection engine".

Sounds like something from "Schoolhouse Rock".

No, seriously, there's a "connection inspection engine" for FTP - if you connect to port 21, the firewall monitors your communications on that channel, looking for PORT commands. When it finds one, it opens up a hole in the firewall for the incoming data connection.

So why the scary dialog warning that something's going to block traffic?

Probably because the dialog pops up whenever an application starts listening, whereas the connection inspection engine only opens a hole when it sees a PORT command. And an FTP client can't actually give the PORT command until it's started listening.

So, the process goes something like this:

Start the FTP client.
Connect to the FTP server on port 21, waking up the connection inspection engine.
Log on, then type dir
The FTP client knows that it needs to open a data connection.
To start the data connection, the FTP client binds to port 0, and starts listening.
The firewall says "Oh no, an unknown program has started listening - better warn them that they won't get any traffic."
The FTP client checks what port it actually got, and sends a matching PORT command.
The connection inspection engine says "PORT command? That's my cue!" and opens a hole in the firewall to incoming data connections.

Well, that's easy, but what if I don't ever want to do an FTP connection? How do I stop this from becoming a potential hacker tool?

Okay, apart from the obvious - that if a hacker could connect out to a server on port 21, nothing's stopping that hacker from transferring data in - you might want to cripple this functionality.

No problem - just set the following DWORD registry value to 1:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ SharedAccess \ Parameters \ FirewallPolicy \ DisableStatefulFTP

The default setting for this value on Windows Vista is 0. [It remains to be seen what value will be the default on Windows Server 2008]

How could Microsoft make this better?

I'd really like to see this documented. Just so that it's not a surprise to anyone.
I'd like to know how many other connection inspection engines there are (at least one, judging from the DisableStatefulPPTP value - but I don't know enough about PPTP to know how that affects operation).
I'd like to know if I can add my own connection inspection engine to the firewall.
Above all, I'd like to do away with the rather confusing and clumsy "We're going to block your incoming ... wait, what just happened?" dialog. If the connection inspection engine is monitoring a command channel, and the process that owns the socket for that command channel starts listening, perhaps we could wait a quarter of a second for a PORT command before calling this a blocked connection?

Finally, is this a vulnerability, a hole, or anything outside the correct operation of a firewall?

No, because the firewall is documented as blocking unsolicited incoming connections - and by any reasonable definition, the data connection requested by a PORT command is solicited.

Waiting for Vista SP1?

Alun Jones — Fri, 18 Jan 2008 05:24:31 GMT

In a previous article, I wrote about how to sound stupid by saying "let's wait for Service Pack 1 before we deploy Windows Vista".

Now here are a few ways to sound clever, by pointing to specific issues that will be fixed by Windows Vista SP1.

GPMC.MSC (the Group Policy Management Console) gets removed, and the Group Policy Editor will default to editing the local group policy only. Okay, that's not really an advantage - but you will be able to download a newer group policy editor later.
Allows Remote Desktop Protocol (RDP) files to be signed. Complains when they aren't (though this does cause a problem for Remote Web Workplace users in SBS land, because there's no way to actually sign the RDP files!)
Improved cryptographic random number generator, leveraging the TPM if you have one on your computer. (Not sure there was that much wrong with the old one... but this one's better, and more ... cryptographicky)
BDE + TPM + USB + PIN - need I say more? Oh, okay then - for the truly security paranoid, you can use Bitlocker Drive Encryption with the Trusted Platform Module, and have it require a USB key and a PIN before the system will start.
Also with BitLocker, there is support for encryption of drives other than the main boot volume (which is the volume that has the system software on it, not the system drive, which is the one you boot from). Still can't encrypt the system drive - because that would be just plain stupid.
Performance improvements - really, what's not to like with an update that makes your computer go faster?
exFAT file system for flash memory storage - you probably haven't exactly been drooling about this.
SSTP - allows VPN over HTTPS to Windows Server 2008 systems. Yeah, because if you're holding off installing Vista until SP1 ships, you've got loads of those ready to use, right?

I don't know - were any of those features worth waiting for? I know there's performance and reliability improvements, but those are somewhat nebulous and indistinct.

My advice is still to test Vista as it shipped, test Vista with the Service Pack 1 Release Candidate - report bugs to Microsoft quickly, before they lock it down - and then when SP1 releases, and then test with Vista SP1 RTM when it comes out... and stop letting vendors get away with saying that "all you need to do to run our software on Vista is to disable UAC, or make all users administrator" - that's just plain bad.

What do I wish was in SP1?

Some provision for solving the EFS incompatibility between XP and Vista (maybe XP SP3 will help, I don't know)
The ability for a standard user to back up his own files, including EFS encrypted files, so that a user can export encrypted data to removable physical media (like a CD-R). Too much data still travels unencrypted, and it might help to have the ability to put encrypted files on CD-Rs using only what comes with the OS.
A server administration toolkit that allows me to administer Windows versions 2000, 2003 and 2008 from Vista.
An ability to switch sound output devices on already-running applications. When my wife comes into the office, I want to stop using the built-in speakers and start using the Bluetooth headset, so that she can't hear me playing Halo.

So, tell me, what are you waiting for?

Why you don't run as root

Alun Jones — Sat, 12 Jan 2008 05:03:12 GMT

[... or administrator, or whatever]

I like Roger Grimes, he's a nice guy, and he generally makes me think about what he has to say. That's a good thing, because otherwise he'd either be part of the same choir as me, or he'd be the sort of guy whose ideas I dismiss with a wave of the paw and a barely audible "Pah."

Today, though, I think he's missing something fundamental - and perhaps you are too.

He writes in the InfoWorld Security Adviser column that "UAC will not work", on the simple basis that malware can still do all the things it wants to do without having to execute under a privileged account.

That's true, and it always will be - the day that a computer can see my attempt to "delete the Johnson account, and forward that instruction to the following addresses", and determine whether it's malicious or appropriate, is the day when the computer can do the whole job for me, by simply choosing all possible actions and seeing which are malicious and which are appropriate.

However, what I can rely on, if the malware has been held out of privileged accounts, is the integrity of the system, and (unless they were prone to activating the same malware) the other users on that system. [By system, I may mean one machine or several networked together to perform a function.]

So while it's true that the old cross-platform virus "forward this message to everyone in your address book, then delete all your data" is still going to function if the user stays out of administrator roles, at least the operation of the system can be restored, as well as whatever data has been backed up.

You don't run as a restricted user to prevent viruses from happening - you run as a restricted user to prevent viruses from happening to the people and systems with whom you work. You run as a restricted user, so that when some system falls over, you can say "it couldn't possibly have been me". You run as a restricted user because if there is a bug in the program you run, its effects will be limited to only that portion of the OS and its data to which you are restricted.

Sure, least privilege is somewhat of an artificial construct - but the alternative is that users get more privileges than they need. That quickly boils down to "everyone can do anything".

I've been on that kind of a network before, and when we found one guy's stash of truly offensive porn (this wasn't the occasional Rubens painting) on the server, we had no way of finding out who it was, let alone punishing them by firing them. The company I worked for was fortunate that whoever found it didn't sue for fostering the creation of a hostile workplace.

So, no, UAC won't stop malware - but then that's not its purpose. It's purely a beneficial, incidental, and temporary side-effect that it will stop much of today's malware.

Is a NAT a security device?

Alun Jones — Sat, 29 Dec 2007 19:23:12 GMT

I've been working lately on a couple of IPv6-related projects. First, there's a chapter for an upcoming book, and second, there's the effort to make WFTPD and WFTPD Pro work on IPv6, since it's enabled by default in Windows Vista and Windows Server 2008 [more on that in a future post].

A big argument to my mind, as an old-school Internet user, for enabling IPv6 is that every one of your hosts becomes a fully-fledged Internet participant, like it used to be with IPv4 back in the '90s.

What do I mean by that?

I mean that every machine is reachable at its own address on every port that it chooses to open, rather than requiring someone to tinker with a NAT to open port mappings for specific applications.

IPv6 removes the need for a NAT at all.

Wow. To a security professional, that's a shocking statement. It feels rather like saying that living in a tent removes the need for locks. How on earth do you protect your stuff without a NAT?

The answer is that a NAT was never intended to be a security device - it just happened, somewhat accidentally, that requiring address translation and port mapping to be statically configured created a security barrier.

Unfortunately, NATs also killed a lot of protocols (H.323 for webcams, FTP for file transfers - particularly when secured, IPsec) that quote IP addresses in their traffic.

To some extent this was fixed with ALGs - Application Layer Gateways - but never very satisfactorily (particularly in the case of secured FTP). What would be far better is to have a device that had the blocking advantages of a NAT, but didn't require IP addresses and ports to be altered in transit.

There's a name for such a device:

A firewall.

[Only if the firewall is configured by default to list all ports as "closed". An open-by-default firewall is not a firewall, it's a router.]

And a firewall is a far simpler program than a NAT (even if it's in hardware, it's the program's simplicity that matters most). If it matches incoming traffic to ports that are opened, it allows that traffic in. If outgoing traffic occurs on a port that was closed, the firewall usually opens that port for the reverse traffic, so that clients on the inside of the firewall can get a response.

So, when the time comes that your network is required to transition to IPv6, don't beg for an IPv6 NAT. I actually hope such a device doesn't actually exist, and that nobody's stupid enough to develop one. What you should insist on is an IPv6 firewall.

"But what about the problem that the layout of my network inside of the firewall will be revealed?" you might ask.

It won't, because IPv6 addresses are sparsely allocated.

"How about machines that won't ever need to be accessed by, or access out to, anything outside my company? What's the IPv6 equivalent of an RFC 1918 address?"

No problem - there's a standard for link-local and site-local (Unique Local Unicast, technically) addressing, which will never be routed outside of your site.

Any other reasons you're clinging to the idea that a NAT is a security device?

Why complain about UAC prompts?

Alun Jones — Tue, 04 Sep 2007 03:51:00 GMT

Jesper's article in TechNet Magazine on the purpose and future of UAC in Windows Vista and beyond reminded me that there's a whole slew of behaviours more annoying than UAC's prompting (which, as Jesper points out, is only the most visible portion of a system-wide and company-wide approach to the future of Windows development), and which users apparently don't hate enough for vendors and IT departments to cry for changes.

UAC elevation prompts from tools that shouldn't need elevation.

Seriously, this is just a sign that the developer was an administrator, and the tester was an administrator, and nobody bothered to make the program work for non-administrators by removing requests for privileges that aren't actually needed.

So, instead of fixing the product to remove the demands for administrative rights, the developers simply added a manifest to make the software insist on elevation.

If you've got non-administrative software that prompts for elevation as soon as it starts up, you should be asking your vendor whether this is their long-term fix, or whether this is just a temporary workaround while they engage in what can be a long process of removing elevation.

UAC elevation prompts for administrators running administrative tools

While performing their administration function, these users should be in an administrator session, and should have enabled silent elevation through Group Policy; while not performing their administration function, they should not be in an administrator session, and elevation should be disabled.

While that may have been awkward and cumbersome in Windows XP and before (although "runas" goes a long way towards providing this sort of separation), in Windows Vista, Fast User Switching is enabled for even domain-joined computers, allowing you to choose whether to be in a restricted user session or an administrative user session.

Spending most of your time as a non-admin means that when someone comes looking for the admin user who infected the company with an Outlook worm, you can point to the fact that your admin account isn't set up to run Outlook, so it couldn't possibly be you - phew!

Requests to re-identify myself

This is the big one for me, though - why aren't people complaining the same way about applications that ask the users to authenticate themselves again?

Why haven't these applications been fixed to use other methods of authentication?

When I fill in my time-sheet, I'm required to provide my user name and password. Again.

When I connect to the company training web page, I'm required to provide my user name and password. Again.

Every place I've worked, it's the same thing - there's a pile of applications that are necessary to, or related to your work - whether it's training, time-sheets, benefits checking, prescription filling under the company-provided insurance plan, or whatever - they've all required that I identify myself to them - again - even though I've already identified myself to the domain on this computer.

Maybe this is acceptable and appropriate for those operations where you want to make sure that somebody hasn't stepped in to the user's cube while the user was away - but those operations should generally be limited to unlocking the locked workstation, changing the user's password, starting up an elevated process - not routine operational work.

After all, if you start requiring the user to enter their password everywhere, you're teaching the user that he should be blasé about repeatedly entering his password several times during the work day - then when the phishing email comes along, with a request to log on to an external web site, that user will happily give up his user account and password (which will most likely be the same as his password on every other system he's used).

There are good alternatives.

A couple of obvious approaches for web-based applications are Windows Integrated Authentication (which, admittedly, does require IE and IIS), and SSL client certificates.

Thick-client applications are also usable, as long as they aren't against your company's religion.

Let's just wait for Service Pack 1

Alun Jones — Thu, 30 Aug 2007 13:08:19 GMT

Every so often, I'll hear it said, and frequently not in jest, "let's wait until Service Pack 1 before we deploy Vista", or sometimes "Server 2008".

While it's true that Microsoft has indeed announced plans to test, and then release, Windows Vista SP1 early in 2008, I have to say that I don't find this thinking any smarter than the old "let's buy IBM" idea, based on the "Nobody Ever Got Fired For Buying IBM" principle.

Even if it were true, someone's eventually going to realise that if it's your job to specify what the IT budget gets spent on, and you say things like "we'll deploy it after Service Pack 1", you're just not acting as if you're doing your job.

Somebody, one day, will call your bluff, and say "Why? What bug is a showstopper for deploying Vista RTM, and why do you believe it's fixed by SP1? Why didn't you find that bug out while you were beta testing the operating system? Weren't you beta testing the operating system?"

And you're going to look foolish, because you don't have anything in particular to point to (UAC? That's a bit generic - you have to say what you don't like about UAC, and why you think SP1 will make it all better) in order to defend your mindless parroting of "let's wait for SP1".

For the record, there are reasons to anticipate SP1 - it adds an SSL-based VPN capability, through the SSTP, and it allows you to encrypt multiple drives using BitLocker through the UI (you can use manage-bde.wsf to encrypt multiple drives using BitLocker from the command prompt).

There are other features in SP1, and you should definitely consider whether you can use those features. But there really isn't any break-fix that makes it important for you to stop testing and planning to deploy Vista RTM while you wait for SP1.