Tales from the Crypto

In Defence of the Self-Signed Certificate

alunj — Sat, 10 May 2008 17:49:13 GMT

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

alunj — Sat, 10 May 2008 04:32:34 GMT

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.

alunj — Wed, 07 May 2008 00:33:57 GMT

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?

alunj — Sat, 03 May 2008 23:57:20 GMT

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

alunj — Sat, 03 May 2008 03:24:57 GMT

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

alunj — 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.

Silently fixing security bugs - how dare they!

alunj — Tue, 22 Apr 2008 22:06:30 GMT

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:

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

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

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.
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.
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?

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.
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.
You don't know the vulnerability is there, or you don't realise that you fixed a vulnerability.

Okay, that last one's the topper, isn't it? How can you announce a fix for a vulnerability that you don't know about?

Clearly, you can't.

Just as clearly, perhaps you're thinking, you can't fix a vulnerability that you don't know about, right?

Wrong. You can very easily fix a vulnerability about which you know nothing. Here's a couple of hypothetical examples:

After we moved into our new house, we changed all the locks on the doors. Why? Because the new locks were prettier. In doing so, we fixed a vulnerability (the former owner could have kept the keys, and exploited us through the old locks) - but we didn't intend to fix the vulnerability, we just wanted prettier locks.

Years ago, I needed a piece of functionality that wasn't provided by the Win16 API, so I wrote my own routine to do file path parsing. A couple of years back, I dropped support for Windows 3.1, and in a recent code review, I spotted that the file path parsing routine was superfluous. So I removed it. In removing it, I didn't spend a lot of time looking at the code - there was a vulnerability in there, but who does a code review of a function they're removing? So now, I've fixed a vulnerability that I didn't know existed.

Too many times, we assert evil intent for those actions that we disagree with. Ignorance is a far better explanation, along with incompetence, expediency, and just plain lack of choice. Note that ignorance is no bad thing - as in my hypothetical case, a genuine attempt to improve quality leads to a security improvement of which the developer was wholly ignorant.

Whether vendors don't want to disclose all of their vulnerabilities when patching, or simply can't, because they didn't realise the scope of a fixed vulnerability, it's important to stay current with patches wherever that would not interfere with your production applications. Because one day there will be a flaw patched, which your company will be attacked through. If you didn't apply that patch, you will be owned.

Retro-bundling - another suck of the Apple

alunj — Sat, 22 Mar 2008 04:15:47 GMT

I thought I was done blogging about Apple Software Update, having removed QuickTime from my system completely, and sworn never to install it again or watch another QT or MOV file.

But nooo, someone had to spoil it by telling me what Apple Software Update did next.

If you're unfortunate enough to have QuickTime installed with Apple Software Update, you'll already have seen it.

Not only is Apple going to offer you iTunes and QuickTime as an "update" (despite you not actually having iTunes installed in the first place), they're also going to offer you Safari, the feature-light Apple web browser, as an "update" (again, even though you haven't installed it). And they're going to check the box, so if you think you're just updating components you fetched for yourself, you'll accidentally install this one, too. And they're going to ask you every boot until you disable the check - and then they'll just re-enable the prompt next time they have a patched version to release.

What next, "we suggest you update to Bootcamp and Mac OS X, please wait while we install, and don't mind the reboots"?

Seriously, Apple, this just makes you look seriously unethical. You can't get people to install Safari legitimately, by enticing them to voluntarily download and install it, so you have to sneak it in by implying it's an update to QuickTime. What does that say about Safari? You can't even give it away? You have to foist it on the unwilling?

Grow up.

I suggest we call this behaviour Retro-Bundling.

Bundling, of course, is when you buy a piece of software, or download it for free, and along with it comes Firefox or the Google Toolbar. Irritating, especially if you don't want them, because half of your time in getting the software down was taken up in downloading something that you're going to say "no" to. But at least you only have to say no that one time - or when you download the next version.

Retro-Bundling, then, would be when, after you already have the software of your choice installed, its manufacturer decides that they'd like to have bundled something else onto your system, so they try to slip it in the back door without you noticing.

I am glad to say, to judge from comments at other blogs, that I'm not the only one that thinks this is utterly reprehensible behaviour. Perhaps this is the way things are done in the Apple world - you just sit happily back as your vendor dumps more and more product into your lap.

Consider this - how would you have reacted, if next time Office for Mac was checking for updates, it came back and offered to update Word, Excel Internet Explorer and Silverlight? Even though you didn't have those last two on your system. Oh, and they were selected automatically, and the default button press would install them all.

Update: Someone mentioned to me that Microsoft does indeed offer Silverlight on Windows Update to Windows users even if you don't have Silverlight installed already. That sucks, too. It's not quite as heavy an application as Safari and iTunes, but it's still wrong to offer "updates" that consist of an application you don't have. Actions like this will cause people to stop accepting updates as a regular part of their computing schedule - and that can't help the health of their computers.

Random leap-day events.

alunj — Sat, 01 Mar 2008 02:47:24 GMT

A semi-hobby of mine is that of date- and time-related issues with computers. Something that we all take for granted, and assume to be easy, is actually incredibly complex, with rules that depend on where you are, when you are, which laws you follow, which religion you believe in, and any number of other steps.

I knew there'd be one or two events for leap day to comment on - here's a selection for your amusement:

"Software Snafu delays United's Leap Day check-ins" - a spokesman "says United didn't have any such problems with the software on Leap Day four years ago." - not much thought given, I suppose, as to whether there might have been an update or patch in those four years.

Microsoft's SQL Server 2008 - two days after the product launch in Los Angeles:

“We have recently discovered an issue with SQL Server 2008 CTPs that result
in SQL Server 2008 not starting on Feb 29 GMT only. We recommend that you do
not run or install this CTP on Feb 29 GMT to minimize any impact in your
environment. You can install starting on March 1 GMT. If you have already
encountered issues, contact sqlbeta@microsoft.com before taking any further
steps.”

Microsoft's Windows Small Business Server can't issue itself a certificate today, because when it creates the certificate, it makes it valid until today's date, five years from now. That would be 2/29/2013, which isn't a valid date. Splat.

South Carolina's DMV brought down because of "a bug in one of the programs that calculates the date".

Electronic Arts give their employees a day off for Leap Day - I was going to make some weak joke about "an EA spokesman said that as the following day was a Saturday, they expected everyone in the office as normal" - but then I read the spokesman's comments from the article: “The next leap year isn't until 2012, but the company is trying to come with a reason to give its employees another day off in 2009.” So there you are, if you work at EA, you get another day off work next year. Write down family members' names and addresses so you can contact them again when next you get to leave the office and go out into the "big blue room".

CS-RCS Pro on Vista

alunj — 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.

Dealing in Vulnerabilities - Denying the Vendor

alunj — Thu, 07 Feb 2008 20:20:00 GMT

Full disclosure, responsible disclosure, malicious exploit use, there are so many ways to act when you find a vulnerability.

What about disclosure to a select band of people (selected only by their ability to pay you a bucket of money every year), and demonstrating the vulnerability publicly, while simultaneously withholding details of the vulnerability from the vendor in whose product you found the hole?

That's what Russian Security research company Gleg is doing right now with RealNetworks, according to an Analysis piece in this week's eWeek (sorry, eWeek, I'd link to the article, but I couldn't find it online).

The researchers at Gleg found a vulnerability that allows them to execute their choice of code on any system whose user they can convince to play a song in RealPlayer - and there's not a lot of convincing that needs to go on.

RealNetworks have contacted Gleg and requested, on a number of occasions, to receive details of the vulnerability. Gleg refuses. Repeatedly.

Why?

"We need an exclusive time period to protect our customers..." and "We tried to work with vendors in the past and received a very negative experience."

If this "negative experience" is the usual complaint of vulnerability researchers, it is that vendors are non-responsive when vulnerabilities are reported - clearly in this case, that's not true. RealNetworks are asking Gleg to allow them to respond to the vulnerability.

Subscriptions to vulnerability researchers' "services" already seem rather like a protection racket - "pay us every month, so we can tell you how to prevent your systems from being exploited by something that we found".

With this refusal to disclose to the vendor without them becoming a customer first, this seems more like blackmail.

As Dave Aitel of Immunity states, for RealNetworks to subscribe to Gleg's service might very well be "a drop in the bucket for them", but consider that it's Gleg that discovered this vuln, it might be Immunity for the next vuln, you can't predict who's going to find the next vulnerability in your software. A few drops and you've overflowed your bucket. [For those of us vendors with a thimble-sized bucket, a single such drop is going to be too much.] How do you go to the CFO and ask for more money because there's another dozen security research companies starting up this month? How do you classify the return on investment?

Oh yeah, Immunity... "Immunity does not share its findings with affected vendors" either, according to the article.

I understand that security researchers have to feed their families, but there has to be a better way than protection rackets and blackmail.

I've often stated that I got into security because I wanted in some small way to help save the world - I don't like people who are apparently in this business solely to make money, and with no interest for improving the world around them. It's a short step from there to developing malware for pay.

Update: Just to prove I'm not making this one up (eWeek, where's that article online?), the story is also reported at DaniWeb.

MMR vs Autism - Amateur Epidemiology

alunj — Tue, 05 Feb 2008 19:20:23 GMT

Once again, the headlines declare, "No link between autism and MMR vaccine".

The story, however, is a different matter:

The study, published on Tuesday in the Archives of Disease in Childhood, found no evidence of any abnormal biological response from the shot that could point to a link between the vaccine and autism.

Hmm... an absence of evidence of a link does not mean evidence of the absence of a link.

"This study really supports the view these are safe vaccines," said David Brown, a researcher at Britain's Health Protection Agency who worked on the study. "The evidence is now so solid there really isn't a need for further studies here."

Same old guff that's been said at the conclusion of a number of other studies, all of whom appear almost deliberately to have been set up to provide statistics that imply the absence of a link. Perhaps the most famous is the "Danish study". The study demonstrated that there was actually a higher risk of autism among those who did not receive the MMR. What was not noted in that study is that it occurred at a time when the suggestion of an MMR / autism connection was big news, so those children already at risk of autism were more likely to turn up in the group of children whose parents refused to give their children MMR. A self-selecting study is no study at all.

As Jackie Fletcher of JABS puts it:

It is making a leap from having the actual data on the antibodies and saying MMR does not cause autism.

Persistent measles infection is only one of the theories on why there appears to be a connection between the MMR vaccination and autism - my favourite explanation by far is that there are children at risk from autism, and that every time their bodies are put under significant stress (such as the high fevers associated with vaccination), there is a chance that a regression will be triggered. That's a very loose theory, granted, but there are others - one very interesting suggestion is that the study quoted in today's news articles focuses on children aged 10 - 12, and if those children had persistent measles infection from vaccination at or around 2 years old, it would not be evident from antibodies in the bloodstream, but in the spinal column. I don't know how true that claim is, though.

Now, you might say that the studies that have suggested a link between MMR and autism are also biased in their construction, and designed to give the results that would imply such a link.

I agree.

An appropriate study, in my opinion, would be to select candidates who are "at risk" from autism - where a member of the family has autism, or where a member of the family is an engineer, or where there is higher-than-average incidence of college education - and follow their babies from birth through age five or so. Some of the group would be given the MMR in one visit, as is the current method of operation, others would be given separate Measles, Mumps and Rubella shots in three visits, several weeks apart. A little tricky to do this as a double-blind study, but not impossible - the MMR patients would simply receive a saline shot instead for two of their three visits.

Such a study would get over the issue that, with an incidence rate of 1 in 150, and only a fraction of that being suggested as related to MMR vaccination, autism causes disappear into statistical noise; such a study also allows for possible weighting factors to be recognised and balanced (by assigning study members such that particular combinations of weighting factors appear more or less equally in each cohort), in a way that has not been possible, or not been tried, with other studies.

While there are many irrational views on both sides of this debate, sadly it seems as though these are the views that make the loudest noise.

A scientific approach to this discussion has not yet been considered, in my opinion.

Most parents of autistic and at-risk children I have spoken to (and granted, that's not in the hundreds that would be required for a good sample) are not looking to make the choice between MMR or not vaccinating their children - they are artificially limited by the government to making that choice. The lack of availability of individual vaccines for Measles, Mumps and Rubella makes the choice one of "MMR and possible-to-likely autistic regression" versus "possible measles, mumps or rubella infection - maybe in someone else's kid". I think that particularly when it comes to illnesses like Rubella, where the risk is to the in-utero fetus of an infected mother-to-be, perhaps we ought to consider whether it is safer to vaccinate girls as they approach their fertile years, rather than vaccinating everyone a year or two after birth, in an attempt to provide "herd immunity".

Another thing I'm not looking for is to blame all (or even most!) cases of autism on the MMR vaccine, or thimerosal, or any of a number of other causes. There are so many stories of autistic onset, from the kid who "everyone could see he was different from the moment he was born", to the kid who develops normally into a babbling toddler and then suddenly shuts up and retreats into his mental cocoon over the course of a few days. Clearly, there's a genetic component that at least creates a susceptibility, but for something to happen so suddenly, and so coincidentally "on time", it seems like there has to be an environmental component that acts like a trigger.

With the government continually feeding us crap science, and no physical method to reliably screen for a majority of autism cases, it's no wonder many parents feel like emulating their children at their worst autistic moments, repeatedly banging our heads against the wall, because it's better than not knowing why our heads hurt.