Tales from the Crypto

My MP3 player demands to administer my system

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.

FTP - Untrustworthy? I Don't Think So!

Lately, as if writers all draw from the same shrinking paddling-pool of ideas, I've noticed a batch of stories about how unsafe, unsecure and untrustworthy is FTP.

SC Magazine says so.

First it was an article in the print version of SC Magazine, sadly not repeated online, titled "2 Minutes On... FTP integrity challenged", by Jim Carr. I tried to reach Jim by email, but his bounce message tells me he doesn't work for SC Magazine any more.

This article was full of interesting quotes.

"8,700 FTP server credentials were being used to access and infect more than 2,000 legitimate websites in the US". The article goes on to quote Finjan's director of security research who says they were "most likely hijacked by malware" - since most malware can do keystroke logging for passwords, there's not much can be done at the protocol level to protect against this, so this isn't really an indictment of FTP so much as it is an indication of the value and ubiquity of FTP.

Then we get to a solid criticism of FTP: "The problem with FTP is it transfers data, including authorization credentials, in plain text rather than in encrypted form, says Jeff Debrosse, senior research analyst at security vendor ESET". Okay, that's true - but in much the same vein as saying that the same problems all apply to HTTP.

Towards the end of the article, we return to Finjan's assertion that malware can steal credentials for FTP sites - and as I've mentioned before, malware can get pretty much any user secret, so again, that's not a problem that a protocol such as FTP - or SFTP, HTTP, SSH, SCP, etc - can fix. There's a password or a secret key, and once malware is inside the system, it can get those credentials.

Fortunately, the article closes with a quote from Trent Henry, who says "That means FTP is not the real issue as much as it is a server-protection issue."

OK, But a ZDNet blogger says so, too.

Well, yeah, an article in a recent ZDNet blog entry - on storage, not networking or security (rather like getting security advice from Steve Gibson, a hard-drive expert) - rants on about how his web site got hacked into (through WordPress, not FTP), and as a result, he's taken to heart a suggestion not to use FTP.

Such a non-sequitur just leaves me breathless. So here's my take:

FTP Has Been Secure for Years

But some people have just been too busy, or too devoted to other solutions, to take notice.

FTP first gained secure credentials with the addition of support for SASL and SKey. These are mechanisms for authenticating users without passing a password or password-equivalent (and by "password-equivalent", I'm including schemes where the hash is passed as proof that you have the password - an attacker can simply copy the hash instead of the password). These additional authentication methods give FTP the ability to check identity without jeopardising the security of the identified party. [Of course, prior to this, there were IPsec and SOCKS solutions that work outside of the protocol.]

OK, you might say, but that only protects the authentication - what about the data?

FTP under GSSAPI was defined in RFC 2228, which was published in October 1997 (the earliest draft copy I can find is from March 1995), from a draft developed over the preceding couple of years. What's GSSAPI? As far as anyone really needs to know, it's Kerberos.

This inspired the development of FTP over SSL in 1996, which became FTP over TLS, and which finally became RFC 4217. From 1997 to 2003, those of us in the FTPExt Working Group were wondering why the standard wasn't yet an RFC, as draft after draft were submitted with small changes, and then apparently sat on by the RFC editor - during this time, several compatible FTP clients, servers and proxies were produced that compatibly supported FTP over TLS (and/or SSL).

Why so long from draft to publication?

One theory that was raised is that the IETF were trying to get SSH-based protocols such as SFTP out before FTP over TLS (which has become known as "FTPS", for FTP over SSL).

SFTP was abandoned after draft 13, which was made available in July 2006; RFC 4217 was published in October 2005. So it seems a little unlikely that this is the case.

The more likely theory is simply that the RFC Editor was overworked - the former RFC Editor, Jon Postel, died in 1998, and it's likely that it took some time for the new RFC Editor to sort all the competing drafts out, and give them his attention.

What did the FTPExt Working Group do while waiting?

While we were waiting for the RFC, we all built compatible implementations of the FTP over TLS standard.

One or two of us even tried to implement SFTP, but with the draft mutating rapidly, and internal discussion on the SFTP mailing list indicating that no-one yet knew quite what they wanted SFTP to be when it grew up, it was like nailing the proverbial jelly to a tree. Then the SFTP standardisation process ground to a halt, as everyone lost interest. This is why getting SFTP implementations to interoperate is sometimes so frustrating an experience.

FTPS, however - that was solidly defined, and remains a very compatible protocol with few relevant drawbacks. Sadly, even FTP under GSSAPI turned out to have some reliability issues (the data transfer and the control connection, though over different asynchronous channels, share the same encryption context, which means that the receiver must synchronise the two asynchronous channels exactly as the sender did, or face a loss of connection) - but FTP over TLS remains strong and reliable.

So, why does no-one know about FTPS?

Actually, there's lots of people that do - and many clients and servers, proxies and tunnels, exist in real life implementations. Compatibility issues are few, and generally revolve around how strict servers are about observing the niceties of the secure transaction.

Even a ZDNet blogger or two has come across FTPS, and recommends it, although of course he recommends the wrong server.

My recommendation?

WFTPD Pro. Unequivocally. Because I know who wrote it, and I know what went into it. It's all good stuff.

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

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:

1. Attacker persuades victim to ask for 1.example.com
2. Victim’s DNS server queries for an A record for 1.example.com
3. 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”
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:

1. Because the attacker tells the victim to search for a site, the attacker controls when the race with the authoritative DNS server starts.
2. 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.
3. 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.
4. 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:

1. 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.
2. 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.
3. 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.
4. Users are being advised to point their DNS server entries to OpenDNS. Single point of failure, anyone?

Metrics and statistics:

1. 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.
2. 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.
3. 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.

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.

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.

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:

1. Seriously, how many Windows Server 2003 users out there have such a high-capacity DNS server that they will notice the performance hit?
2. 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.
3. 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.
4. 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.

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:

1. 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.
2. 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 -
1. one is to create an EXE wrapper that calls the old CPL file. That's fairly cheap, and will probably be the first version.
2. 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.
3. 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.
3. 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.
4. Multiple languages
• There are two elements to support for multiple languages in FTP:
1. File names in non-Latin character sets
2. 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.
5. 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.
6. Install under Local Service and Network Service accounts
7. 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?

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:

1. 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.
2. 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.
3. 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.

Searching for Weak Debian / Ubuntu SSL Certificates

I've seen a number of people promote packages that have shipped for Debian and Ubuntu, which allow users to scan their collected keys - OpenSSH or OpenSSL or OpenVPN, to discover whether they're too weak to be of any functional use. [See my earlier story on Debian and the OpenSSL PRNG]

These tools all have one problem.

They run on the Linux systems in question, and they scan the certificates in place.

Given that the keys in question could be as old as 2 years, it seems likely that many of them have migrated off the Linux platforms on which they have started, and onto web sites outside of the Linux platform.

Or, there may simply be a requirement for a Windows-centric security team to be able to scan existing sites for those Linux systems that have been running for a couple of years without receiving maintenance (don't nod like that's a good thing).

So, I've updated my SSLScan program. I'm attaching a copy of the tool to this blog post, (along with a copy of the Ubuntu OpenSSL blacklists for 1024-bit and 2048-bit keys if I can get approval), though of course I would suggest keeping up with your own copies of these blacklists. It took a little research to find out how to calculate the quantity being used for the fingerprint by Debian, but I figure that it's best to go with the most authoritative source to begin with.

Please let me know if there are other, non-authoritative blacklists that you'd like to see the code work with - for now, the tool will simply search for "blacklist.RSA-1024" and "blacklist.RSA-2048" in the current directory to build a list of weak key fingerprints.

I've found a number of surprising certificates that haven't been reissued yet, and I'll let you know about them after the site owners have been informed.

[Sadly, I didn't find https://whitehouse.gov before it was changed - its certificate is shared with, of all places, https://www.gov.cn - yes, the White House, home of the President of America, is hosted from the same server as the Chinese government. The certificate was changed yesterday, 2008/5/21. https://www.cacert.org's certificate was issued two days ago, 2008/5/20 - coincidence?]

My examples are from the web, but the tool will work on any TCP service that responds immediately with an attempt to set up an SSL connection - so LDAP over SSL will work, but FTP over SSL will not. It won't work with SSH, because that apparently uses a different key format.

Simply run SSLScan, and enter the name of a web site you'd like to test, such as www.example.com- don't enter "http://" at the beginning, but remember that you can test a host at a non-standard port (which you will need to do for LDAP over SSL!) by including the port in the usual manner, such as www.example.com:636.

If you're scanning a larger number of sites, simply put the list of addresses into a fie, and supply the file's name as the argument to SSLScan.

Let me know if you think of any useful additions to the tool.

Here is some slightly modified output from a sample run of the tool (the names have been changed to protect the innocent):

The text to look for here is ">>>This Key Is A Weak Debian Key<<<".

Debian and the OpenSSL PRNG

[PRNG is an abbreviation for "Pseudo-Random Number Generator", a key core component of the key-generation in any cryptographic library.]

A few people have already commented on the issue itself - Debian issued, in 2006, a version of their Linux build that contained a modified version of OpenSSL. The modification has been found to drastically reduce the randomness of the keys generated by OpenSSL on Debian Linux and any Linux derived from that build (such as Ubuntu, Edubuntu, Xubuntu, and any number of other buntus). Instead of being able to generate 1024-bit RSA keys that have a 1-in-2^1024 chance of being the same, the Debian build generated 1024-bit RSA keys that have a 1-in-2^15 chance of being the same (that's 1 in 32,768).

Needless to say, that makes life really easy on a hacker who wants to pretend to be a server or a user who is identifed as the owner of one of these keys.

The fun comes when you go to http://metasploit.com/users/hdm/tools/debian-openssl/ and see what the change actually was that caused this. Debian fetched the source for OpenSSL, and found that Purify flagged a line as accessing uninitialised memory in the random number generator’s pre-seeding code.

So. They. Removed. The. Line.

I thought I’d state that slowly for dramatic effect.

If they’d bothered researching Purify and OpenSSL, they’d have found this:

http://rt.openssl.org/Ticket/Display.html?id=521&user=guest&pass=guest

Which states (in 2003, three years before Debian applied teh suck patch) “No, it's fine - the problem is Purify and Valgrind assume all use of uninitialised data is inherently bad, whereas a PRNG implementation has nothing but positive (or more correctly, non-negative) things to say about the idea.”

So, Debian removed a source of random information used to generate the key. Silly Debian.

But there's a further wrinkle to this.

If I understand HD Moore's assertions correctly, this means that the sole sources of entropy (essentially, "randomness") for the random numbers used to generate keys in Debian are:

1. The Process ID (from 1 to 32,767)
2. The contents of an uninitialised area in the process' memory
3. uh... that's it.

[Okay, so that's not strictly true in all cases - there are other ways to initialise randomness, but these two are the fallback position - the minimum entropy that can be used to create a key. In the absence of a random number source, these are the two things that will be used to create randomness.]

If you compile C++ code using Microsoft's Visual C++ compiler in DEBUG mode, or with the /GZ, /RTC1, or /RTCs flags, you are asking the compiler to automatically initialise all uninitialised memory to 0xcc. I'm sure there's some similar behaviour on Linux compilers, because this aids with debugging accidental uses of uninitialised memory.

But what if you don't set those flags?

What does "uninitialised memory" contain?

It would be bad if "uninitialised memory" contained memory from other processes - previous processes that had owned memory but were now defunct - because that would potentially mean that your new process had access to secrets that it shouldn't.

So, "uninitialised memory" has to be initialised to something, at least the first time it is accessed.

Is it really going to be initialised to random values? That would be such a huge waste of processor time - and anyway, we're looking at this from the point of view of a cryptographic process, which needs to have strongly random numbers.

No, random would be bad. Perhaps in some situations, the memory will be filled with copies of 'public' data - environment variables, say. But most likely, because it's a fast easy thing to do, uninitialised memory will be filled with zeroes.

Of course, after a few functions are called, and returned from, and after a few variables are created and go out of scope, the stack will contain values indicative of the course that the program has taken so far - it may look randomish, but it will probably vary very little, if any, from one execution of the program to another.

In the absence of a random number seed file, or a random number generator providing /dev/urand or /dev/random, then, an OpenSSL key is going to have a 1 in 32,768 chance of being the same as a key created on a similar build of OpenSSL - higher, if you consider that most PIDs fall in a smaller range.

So, here's some lessons to learn about compiling other people's cryptographic code:

1. Don’t ever compile cryptographic code in release mode, because you will optimize away lines that clear secrets from memory.
2. Don’t ever compile cryptographic code in debug mode, because you will initialize memory that is expected to be uninitialised and random.
3. Don't ever modify cryptographic code, even if it throws up warnings. You don't understand what you're doing.
4. Don’t ever compile cryptographic code, because you don’t know what you are doing.

Why I use CryptoAPI

This is one reason why I prefer to use Microsoft's CryptoAPI, rather than libraries such as OpenSSL. There are others:

1. It's not my fault if something goes wrong with the crypto.
2. The users will apply patches to the crypto, and I don't have to go persuading my users to apply the patches.
3. There's a central place where administrators will expect to find crypto keys, and it's well-protected.
4. The documentation for CryptoAPI is far better than the documentation for OpenSSL, which is at best confusing, and at worst, non-existent.

In fairness, there are reasons not to use CryptoAPI:

1. New algorithms are made available for new versions of Windows, and not backported readily to older versions. With a library you ship, you get to decide which version customers can run - unless someone else comes and installs another version.
2. Microsoft's documentation is better, but it's still not perfect. Once in a while, it's not even correct. At least if you have the source code, and are insanely motivated, you can find out what the truth of a matter is.

We'll still be learning lessons for a while...

The lessons to learn from this episode are almost certainly not yet over. I expect someone to find in the next few weeks that OpenSSL with no extra source of entropy on some operating system or family of systems generates easily guessed keys, even using the "uninitialised memory" as entropy. I wait with 'bated breath.

Change the Administrator account name?

Religious debates are rarely clean or pretty.

The same is true in all spheres, whether debating Christianity against Islam, Linux against Windows, or Cagney vs Lacey.

In security, there are a few divisive issues that are always going to crop up.

Is your datacentre network trustworthy enough to pump secret data around it at any speed?

Are virtual machines on the same host PC "separated" for segregation of duties purposes?

Is SHA-1 completely broken yet?

There's nothing more infuriating than arguing your position on one side of such a debate, only to see those infuriating people on the other side sit smugly in their assertion that what you state has no bearing on their view, which is still more correct than yours, nyaah nyaah.

I hope it doesn't get that way with a debate between two people I like to claim as friends - Jesper Johansson and Roger Grimes - who are currently waging their war of words in TechNet, in what I hope will become a regular series.

The current article is on the big debate between those who think it's a great security idea to rename the Administrator account to something else, and those who perceive little or no benefit in the practice - so little that it's not worth doing.

For those of you too lazy to follow the link and read the article, Jesper (and his Microsoft insider, Steve Riley) are on the "don't bother renaming Administrator" side, while Roger (with his own insider, Aaron Margosis) are on the side that renaming the Administrator account is a security win.

I really can't dispute the mathematics, which says that if you have a 10-character password, you have a 1-in-umpteen-thousand chance of someone guessing and logging in as Administrator; if you have a 10-character password and a renamed Administrator account, however, the chances rise to 1-in-umpty-thousand. A couple of orders of magnitude of benefit, yes?

Sure - but there's a couple of points I'd make here:

1. There's not much difference between zero and zero, and the two numbers representing the probability of a random guess succeeding are as close to zero as makes no realistic difference. At that level of difference between near-zeroes, you're as likely to find your password is weakened by poor choice of random number generator as you are to find that renaming the account protected you while the password did not. In essence, you're saying "we're already protected against the sort of guy with enough luck to win the lottery a million times in a row, but just in case, we want to protect ourselves against the guy with luck enough that he could win a million and one times."
2. You could get the same increase in probabilistic protection by lengthening the password. Even if all you did was to add into the password the name that you were going to give the Administrator account, you've provided yourself with just as much mathematical protection against random guessing as you would have by changing the Administrator account name.

Okay, so maybe you're not really getting orders of magnitude better protection - but surely it can't hurt security, and it feels enough like security that several people in the field recommend it.

To me, that's old-style security thinking, where the goal was to disable, disable, disable - when the web sites and applications were so full of holes that any time you saw something that looked like a hole, you immediately knew that the right thing was to plug it up.

Modern information security, though, should be more about enabling - enabling business and customers alike, to conduct business without unnecessary inconvenience. Without wishing to sound like Yoda, inconvenience leads to confusion; confusion leads to mistakes, which lead inexorably to insecurity.

If you rename the administrator account, you're asking for its name to be a part of the secret that secures its access. You won't get any cooperation in that, however, as the operating system and all of your applications are designed around the principle that the username is not a secret. You're also asking your system administrators - the people who are going to be using the Administrator account - to remember that it's been renamed, to remember what it's been renamed to, and to remember to not let anyone else know that.

So, yeah, I'm on the side that says "renaming the administrator account doesn't add any significant security benefit".

The one benefit I do see is that the "random noise" of random attacks on any account named Administrator can be separated from the log entries indicating that someone is attacking your Administrator account. I think this is a bit of a false saving, though - you really shouldn't be allowing any external access to the Administrator account. If your staff wants to access the Administrator account remotely, they should VPN in under their own account, and then use RDP, or some other protocol to connect to the machine they wish to administer.

I'm hoping to entice some of the Security MVPs to contribute to this debate - maybe even Roger and Jesper. There are two sides, here, and I doubt that I'll actually end up converting anyone to my side who wasn't already there to begin with.

In Defence of the Self-Signed Certificate

Recently I discussed using EFS as a simple, yet reliable, form of file encryption. Among the doubts raised was the following from an article by fellow MVP Deb Shinder on EFS:

EFS generates a self-signed certificate. However, there are problems inherent in using self-signed certificates:

• Unlike a certificate issued by a trusted third party (CA), a self-signed certificate signifies only self-trust. It’s sort of like relying on an ID card created by its bearer, rather than a government-issued card. Since encrypted files aren’t shared with anyone else, this isn’t really as much of a problem as it might at first appear, but it’s not the only problem.
• If the self-signed certificate’s key becomes corrupted or gets deleted, the files that have been encrypted with it can’t be decrypted. The user can’t request a new certificate as he could do with a CA.

Well, she's right, but that only really gives a part of the picture, and it verges on out-and-out recommending that self-signed certificates are completely untrustworthy. Certainly that's how self-signed certificates are often viewed.

Let's take the second item first, shall we?

"Request a new certificate" isn't quite as simple as all that. If the user has deleted, or corrupted, the private key, and didn't save a copy, then requesting a new certificate will merely allow the user to encrypt new files, and won't let them recover old files. [The exception is, of course, if you use something called "Key Recovery" at your certificate authority (CA) - but that's effectively an automated "save a copy".]

Even renewing a certificate changes its thumbprint, so to decrypt your old EFS-encrypted files, you should keep your old EFS certificates and private keys around, or use CIPHER to re-encrypt with current certificates.

So, the second point is dependent on whether the CA has set up Key Recovery - this isn't a problem if you make a copy of your certificate and private key, onto removable storage. And keep it very carefully stored away.

As to the first point - you (or rather, your computer) already trust dozens of self-signed certificates. Without them, Windows Update would not work, nor would many of the secured web sites that you use on a regular basis.

Whuh?

Hey, look - they've all got the same thing in "Issued To" as they have in "Issued By"!

Yes, that's right - every single "Trusted Root" certificate is self-signed!

If you're new to PKI and cryptography, that's going to seem weird - but a moment's thought should set you at rest.

Every certificate must be signed. There must be a "first certificate" in any chain of signed certificates, and if that "first certificate" is signed by anyone other than itself, then it's not the first certificate. QED.

The reason we trust any non-root certificate is that we trust the issuer to choose to sign only those certificates whose identity can be validated according to their policy.

So, if we can't trust these trusted roots because of who they're signed by, why should we trust them?

The reason we trust self-signed certificates is that we have a reason to trust them - and that reason is outside of the certificate and its signature. The majority (perhaps all) of the certificates in your Trusted Root Certificate Store come from Microsoft - they didn't originate there, but they were distributed by Microsoft along with the operating system, and updates to the operating system.

You trusted the operating system's original install disks implicitly, and that trust is where the trust for the Trusted Root certificates is rooted. That's a trust outside of the certificate chains themselves.

So, based on that logic, you can trust the self-signed certificates that EFS issues in the absence of a CA, only if there is something outside of the certificate itself that you trust.

What could that be?

For me, it's simple - I trust the operating system to generate the certificate, and I trust my operational processes that keep the private key associated with the EFS certificate secure.

There are other reasons to be concerned about using the self-signed EFS certificates that are generated in the absence of a CA, though, and I'll address those in the next post on this topic.

Apple Changes Update Policies - Still No Biscuit

As I have mentioned in other posts (Retro-bundling - another suck of the Apple, MacBook Air debuts; iTunes Pesters Me Again, Removing Apple Mobile Device Support, I didn't want iTunes - now I've got iPod, too?, etc, etc), this has long since stopped being an issue for me, because I've removed all the Apple software from my machine as a bit of a protest against Apple's inability or unwillingness to provide me the means to manage my own systems.

Now, I understand that Apple has finally heard some of the complaints from various blogs around the world, and has done something about it.

They have separated the updates from the new software. The new dialog looks like this:

But it still marks the new software by default to be installed.

This is the behaviour that is wrong - okay, so it's now clear as to the difference between an update and a new software, but the key again is that Apple is marking new software for installation from an update tool.

An update tool should be a piece of software that most users say "yes, do whatever", and that doesn't then cause significant additions to the software. By automatically checking new software, Apple is eroding the trust that users will have in the update tool.

Again, I don't mind that they're encouraging users to install Safari - I don't even mind them spending time persuading their existing install base to use it. What I'm perplexed at is that Apple feels that they have to slide it in under the door, rather than sell it to users on its own merits.

And, yes, I'm quite well aware that you could also say the same of any browser that ships with an operating system - except, really, you've got to have a browser shipping in your operating system these days. Yeah, the guys who ship the operating system have an advantage - and they worked hard to build that advantage in the first place. They have a certain momentum behind anything they offer, and even if the system is as open and transparent to all application vendors as it is to the OS vendor, the default installed applications will generally have a larger market share than the 'after-market' tools, just because of users' inertia.

[Note that the paragraph above applies to Apple / Mac / Safari, just as well as it does to Microsoft / Windows / Internet Explorer]

However, I don't think that users' inertia is a cause for sleight-of-hand tactics like retro-bundling.

Think like a bad guy? It's a start.

Cool new site (and blog) from Microsoft - http://securedeveloper.com - and it has a tag line I've heard many times before:

Like that old maxim that "you need to stop fighting fires long enough to tell the architects to stop building things out of wood", thinking like a bad guy is just the first step to developer security.

It's a necessary step, but it's not the final goal.

It's a start - in fact, it's a great start, and I think every developer needs to go through that phase. Many have yet to do so - particularly, it seems, those fresh out of college or programming school.

But I think it's really a catch-phrase for the beginning of becoming a secure developer. It's what you have to tell yourself when you're used to writing code for the sole purpose of implementing features, so that you can get over that mind-set and into the sort of thinking that accepts that your code can be attacked.

But the bad guy has it easy.

He only has to find one way in. He can afford to become an expert on one part of your software, and zero in on it.

Thinking like a bad guy will widen your awareness to the point that you know that incursions can and will happen, and you'll occasionally take better care in your coding. That's a good thing.

But what if you start thinking like someone building a defensive structure?

The defence builder has to find (and limit) all the ways in, and just in case he missed one, he has to find all the ways you can get further in once you're in - he has to become an expert on all parts of the software, as well as something of an expert on the external dependencies - libraries, network equipment, database components, etc.

[After all, we've seen this past week how many sites can get exploited through SQL Injection attacks - and the primary cause for those seems to be web developers who don't know SQL, yet who send SQL statements to be executed at the database.]

You could start thinking like a defender - what alarms should signal the presence, or possibility, of an intruder? What information could an active defender use to verify the intent of a potential intruder? How could you slow down a possible attacker to the point where it's feasible for a human responder to outpace a mechanical attacker?

Maybe you could start thinking like an investigator - once you believe someone has got in, what clues would you like to be left, showing you where the holes were? How can you tell what defences have been useful and what defences were useless? Where was the attacker actively assisted or resisted by your system and software?

Perhaps you could even think like a defence component builder - how can you ensure that you learn lessons from tried and true defences in order to build those lessons in to the next system, or to teach the next set of builders?

Think like the architect of a mediaeval castle - we've gotten used to the idea that mediaeval castles were places of defence, that they sought to be impenetrable bastions behind which the local king, thane, lord or whatever could take refuge and survive. Yet they were also places of business, places of government, places with a function. We need to design programs like mediaeval castles - capable of functioning for business as well as for defence.

SecureDeveloper.com hasn't really gone beyond the first stage of its launch yet, so it will be a while before these advanced topics will be discussed - and I am eager to see that happen.

Can You Write Good Code for an OS you Despise?

No, this isn't another of my anti-Mac frothing rants.

This is one of my "here's what I hate about many of the open-source projects I deal with" rants.

I'm trying to find an SFTP client for Windows that works the way I want it to.

All I seem to be able to find are SFTP clients for Unix shoe-horned in to Windows.

[Perhaps the Unix guys feel the same way about playing Halo under Wine.]

What do I mean?

Here's an example - Windows has a certificate store. It's well-protected, in that there haven't been any disclosures of significant vulnerabilities that allow you to read certificates without first having got the credentials that would allow you to do so.

So, I want an SFTP client that lets me store my private keys in the Windows certificate store. Or at least, that uses DPAPI to protect its data.

Can't find one.

Can't find ONE. And I'm known for being good at finding stuff.

PuTTY is recommended to me. It, too, requires that the private key be stored in a file, not in the certificate store. Its alternative is to use its own certificate store, called Pageant (it's an authorization "Age-Ant" for PuTTY, get it?) Maybe I could do something with that - write a variant of Pageant that directly accesses certificates stored in the certificate store.

But no, there's no protocol definition or API, or service contract that I can see in the documentation, that would allow me to rejigger this. I could edit the source code, but that's an awful lot of effort compared to building a clean implementation of only those parts of the API that I'd need.

What I do find in the documentation for Pageant are comments such as these:

• Windows unfortunately provides no way to protect pieces of memory from being written to the system swap file. So if Pageant is holding your private keys for a long period of time, it's possible that decrypted private key data may be written to the system swap file, and an attacker who gained access to your hard disk later on might be able to recover that data. (However, if you stored an unencrypted key in a disk file they would certainly be able to recover it.)
• Although, like most modern operating systems, Windows prevents programs from accidentally accessing one another's memory space, it does allow programs to access one another's memory space deliberately, for special purposes such as debugging. This means that if you allow a virus, trojan, or other malicious program on to your Windows system while Pageant is running, it could access the memory of the Pageant process, extract your decrypted authentication keys, and send them back to its master.

I'll address the second comment first - it's a strange way of noting that Windows, like other modern operating systems, assumes that every process run by the user has the same access as the user. Typically, this is addressed by simply minimising the amount of time that a secret is held in memory in its decrypted form, and using something like DPAPI to store the secret encrypted.

The first comment, though, indicates a lack of experience with programming for Windows, and an inability to search. Five minutes at http://msdn.microsoft.com gets you a reference to VirtualLock, which allows you to lock 4kB at a time into physical memory, aka non-paged pool. Of course, there are other options - encrypting the Pagefile using EFS also helps protect against this kind of attack, and the aforementioned trick of holding the secret decrypted in memory for as short a time as possible also reduces the risk of having it exposed.

Now I'm really stretching to assert that this single author despises Windows and that's why he's completely unaware of some of its obvious security features and common modes of use. But it does seem to be a trend prevalent in some of the more religious of open source developers - "Windows sucks because it can't do X, Y and Z" - without actually learning for certain whether that's true. Often, X and Y can be done, and Z is only necessary on other operating systems due to quirks of their design.

Back when I first started writing Windows server software, the same religious folks would tell me "don't bother writing servers for Windows - it's not stable enough". True enough, Windows 3.1 wasn't exactly blessed with great uptime. But instead of saying "you can't build a server on Windows", I realised that there was a coming market in Windows NT, which was supposed to be server class. So I wrote for Windows NT, I assumed it was capable of server functionality, and any time I felt like I'd hit a "Windows can't do this", I bugged Microsoft until they fixed it.

Had I simply walked away and gone to a different platform, I'd be in a different place - but my point is that if you believe that your target OS is incapable, you will find it to be so. If you believe it should be capable, you will find it to be so.

Security Koan #3

The security guard phoned his boss in a panic.

"There's been a break-in to the site, sir. The intruders aren't anywhere to be seen, but they've got away with a bunch of equipment."

"Understood - go and look at the perimeter fence, find out where they broke in, and keep watch. I'll be there shortly."

The boss arrived at the site, to find the guard pacing up and down in front of the fence.

"Did you find the hole yet?" asked the boss.

"Not yet, sir."

"Never mind, I'll help you look."

For the next half-hour, they went up and down, searching for a hole in the fence.

Then the boss spoke up:

"Are you sure this is where they got in?"

"No, they got in on the other side of the site."

"Then why are you looking over on this side?"

"Because the light's better here, so we can see more."

Question: Are you monitoring the places most suited for attack, or simply the places easiest to monitor?

UAC - The Emperor's New Clothes

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.

Silently fixing security bugs - how dare they!

Over in "Random Things from Dark Places", Hellnbak posts about reducing vulnerability counts by applying the SDL (Security Development Lifecycle), and makes the very reasonable point that vulnerabilities found prior to release by a scan that is part of the SDL process cannot be counted as failures of the SDL process. What's more, those vulnerabilities can be silently fixed by the vendor before shipping / deploying the product being reviewed. [Obviously, not fixing them would be a really bad idea]

What intrigued me, though, was this line:

But, as Ryan [Naraine] said — issues found in public code that are fixed silently are a real issue.  While I have picked on Microsoft specifically for this practice the sad reality (that I quickly learned after publicly picking on MS) is that pretty much all vendors do this.

So, let's see now... this is talking about a patch, hotfix, or service pack, that removes a security vulnerability from a product, but where the vulnerability (and its fix) does not get announced publicly.

There are two reasons not to announce a security vulnerability, in my view:

1. You don't want to.
2. You can't.

Let's subdivide reason 1, "You don't want to":

1. You feel it would adversely affect public opinion, stock price, user retention...
   Well, that's kind of bogus, isn't it? Given some of the vulnerability announcements that have appeared, what on earth could be worse than remote execution, elevation of privilege, and complete control over your system? The only way to make this accusation is to assert that the vendor randomly picks vulnerabilities to announce or not announce, to somehow reduce the overall numbers - and then manages to do so in such a way that noone else notices the vulnerability that was fixed.
   That's not security, and any vendor who did that would find its security staff soon revolting against that practice. There isn't enough of a glut of security workers to be engaging in a practice that assumes you can hire more to replace the disgusted ones that quit.
2. You're tired of going through the process of documenting the bug, its workarounds and/or mitigations, and would rather be doing something else, like, oh, I don't know, fixing more vulnerabilities.
   That's not good security - create a more streamlined and automated process for creating the announcements, and do both - find and fix more vulnerabilities and make announcements for the ones you find. If you're too busy to announce all the vulnerabilities in your product, you're too busy to fix them all.
3. You found the vulnerability internally, and would like to prevent it from being exploited, by releasing the patch along with an announced fix and hoping people install it.
   That's not terribly reliable as a patching policy. It makes some small sense for related fixes, but then why wouldn't you announce that as a related fix in the related announcement? Perhaps it makes sense for architectural fixes, where the only good fix is to go to the next level of service pack, but then wouldn't you want to publicise workarounds for those who can't apply the next service pack for one reason or another?
   But the biggest reason not to do this is that when you release a patch, people will reverse-engineer it, to figure out how to exploit the unpatched version - and they'll find the change you didn't mention as well as the one you did, and will exploit both of them. But your users will only be aware of one problem that needs patching, and may have decided that they can mitigate that without patching.
   So, pretty much bad security on that approach, too.

So, "You don't want to" comes out as bad security, and it's the sort of bad security that you would have to fix to employ - and continue to employ - a halfway decent security team.

What about "You can't" - how could that come about?

1. You have a legal judgement or contract requirement forbidding you from disclosing vulnerabilities. Hey, Microsoft has some of the best and most expensive lawyers on the planet, but even they get stuck with tough legal decisions that they have to abide with, and can't do anything about. If a security vulnerability was considered to be a "threat to national security", the current administration (and possibly many others) would be only too quick to deem it so secret that no-one could reveal its presence. And once you accept that possibility, it isn't hard to think of too many circumstances where a company might be forced to keep a vulnerability quiet.
2. You know enough to fix the code, but not enough to classify the vulnerability or explain its workarounds or mitigations.
   Yeah, that's pretty much the truth for all the announced vulnerabilities, too - how many times have you seen a vulnerability announcement that says "this cannot be exploited remotely", followed by one a few days later with updated information that reveals that, oh yes it can. This doesn't appear to be a good reason not to announce a vulnerability.
3. You don't know the vulnerability is there, or you don't realise that you fixed a vulnerability.