Tales from the Crypto

The difference between liking and hating UAC?

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

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

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

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

We use UAC for different purposes

UAC-lovers

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

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

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

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

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

UAC-haters

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

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

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

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

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

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

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

What can we learn from this?

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

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

What still needs to be fixed?

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

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

Call support?

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

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

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

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

Searching for Weak Debian / Ubuntu SSL Certificates

Alun Jones — Fri, 23 May 2008 03:02:00 GMT

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

Alun Jones — Fri, 16 May 2008 00:55:01 GMT

[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:

The Process ID (from 1 to 32,767)
The contents of an uninitialised area in the process' memory
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:

Don’t ever compile cryptographic code in release mode, because you will optimize away lines that clear secrets from memory.
Don’t ever compile cryptographic code in debug mode, because you will initialize memory that is expected to be uninitialised and random.
Don't ever modify cryptographic code, even if it throws up warnings. You don't understand what you're doing.
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:

It's not my fault if something goes wrong with the crypto.
The users will apply patches to the crypto, and I don't have to go persuading my users to apply the patches.
There's a central place where administrators will expect to find crypto keys, and it's well-protected.
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:

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

Alun Jones — Thu, 15 May 2008 02:27:23 GMT

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:

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

Alun Jones — 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

Alun Jones — 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.

Alun Jones — 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?

Alun Jones — 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

Alun Jones — 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

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

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

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

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

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

But not me.

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

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

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

I must admit, the question stunned me.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Silently fixing security bugs - how dare they!

Alun Jones — 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

Alun Jones — 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.

Alun Jones — 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

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

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

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

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

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

Here's the sequence I have to deal with:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dealing in Vulnerabilities - Denying the Vendor

Alun Jones — 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

Alun Jones — 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.

Google on Microsoft / Yahoo! Deal: "Wah!"

Alun Jones — Mon, 04 Feb 2008 20:21:00 GMT

In case you've been under a rock, Microsoft appears to be trying to take advantage of Yahoo! Inc's recent poor performance to make an unsolicited offer (as far as I can tell, it's not a hostile bid until and unless Yahoo! officers declare that they will be fighting against it by offering a deal they think their stockholders will prefer) to buy the company.

Clearly, given Microsoft's intent to compete with Google, this is a great move for Microsoft - the Microsoft search engines have always lacked popularity compared to Google, and Yahoo!'s engines are still hugely popular. With Yahoo!'s large user base for other web pages, this acquisition amounts to a huge number of eyeballs to which Microsoft can expose their Internet product strategies.

Google, obviously, is a little perturbed by this.

How do they choose to express their concern?

By pointing to the openness and innovation which has underscored the Internet's development throughout the years, and which has been the reason that the Internet has remained popular and usable.

Now, I will definitely agree that Microsoft is known for locking up many of their most interesting innovations inside of patents.

However, the company is also very well known for contributing technical standards to the Internet body of knowledge as expressed in the Internet RFCs.

Let's see how innovative and open Google has been, by searching for "Google" in the Internet RFCs - let's see how many employees have written these open and innovative documents.

RFC 4473: "...search engines such as Google." is the only occurrence - so it's not written by a Google employee.
RFC 4646: Tags for Identifying Languages - authored by Yahoo! and Google employees.
RFC 4647: Matching of Language Tags - essentially part II of RFC 4646, by the same authors.
RFC 4657: Contributors include a Google employee
RFC 4772: Notes that Google was searched.
RFC 4693: An administrative note about the IETF, written by a Google employee.
RFC 4838: Delay-Tolerant Networking Architecture - technically, Vint Cerf was a Google employee at the time, but appears to have done this as work for JPL.
RFC 4954: An authentication extension for SMTP, co-written by a Google employee.
RFC 4959: Authentication extension for IMAP, co-written by a Google employee.
RFC 4981: Refers in passing to Google.
RFC 4990: Use of addresses in GMPLS Networks, co-written by a Google employee.
RFC 5023: The Atom Publishing Protocol, co-written by a Google employee.
RFC 5034: POP3 Authentication extension, co-written by a Google employee.
RFC 5050: Vint Cerf of Google is listed as a contributor.

So, the number of RFCs listing Google employees as authors or co-authors is nine. If you are ruthless in your search for originality, and cut out RFCs that appear to be copies or extensions of other Google employee RFCs, as well as those that were written for other employers than Google, you get five. And one of those is a note about the way in which the IETF operates.

What about Microsoft - when have Microsoft employees ever contributed time to the development of Internet RFCs?

Compared to Google's fourteen matches in the RFCs, "Microsoft" is found hundreds of times. So I tried to limit my search to RFCs that were likely written by Microsoft employees - a good search term for this is to find those RFCs in which either "Microsoft" or "Microsoft Corporation" is at the end of a line. I further limited the search to documents where this match was found in the first 25 lines.

175 RFCs.Okay, so maybe some of those were duplicates, or unimportant ones, and Microsoft have certainly been doing this longer than Google.

Google's first employee-written RFC came in September 2006, so in eighteen months, they've written at most nine, at a rate of one every two months; Microsoft's first is dated December 1995 - that's 146 months ago, so that Microsoft employees are producing RFCs at a rate of slightly more than one every month - more than twice as fast as Google.

I think that if Google wants to cry "shame" that Microsoft is not open or innovative, and that this will cause the Internet to shrivel, they should perhaps start with a little introspection.

Buying an Internet founder does not make you into a founder of the Internet.
Buying an RFC author does not make you open and innovative.
Complaining that a competitor's proposed acquisition will stifle openness and innovation only makes sense if you are, by comparison, a champion of those two qualities - by comparison through the reading of RFCs, Google appears somewhat secretive and dull.

P.S. Please don't comment in this entry about "embrace and extend" - let's face it, openness and innovation as they apply to the Internet are all about "embrace and extend" - Internet standards are published so that they can be adopted and advanced. This discussion is not about whether Microsoft copies from other companies - after all, if this is all about openness and innovation, copying is a good thing.

Get Well Scotty McLeod

Alun Jones — Fri, 01 Feb 2008 06:46:44 GMT

I could have titled this "adversity shows how small our world truly is".

I had no idea that so many of my friends, acquaintances, MVPs and Microsoft staff are also friends with Scotty McLeod - until he got hit by a train last week.

He is recovering, and I hope to see him sitting up and arguing the toss with me when I visit the UK in a couple of weeks.

Until then, I'm left amazed at how many familiar names pop up when I search for "Get Well" and "Scotty McLeod".

Here's hoping he's quickly on the mend.

Steve Jobs' head in a box

Alun Jones — Tue, 29 Jan 2008 16:44:00 GMT

Apple's latest product announcement - you can now buy Steve Jobs' head in a box.

Here's a picture of an unnamed Apple salesman demonstrating the lightness of Steve Jobs' head in a box:

Perhaps if any of you have heard about features of the Steve Jobs' head in a box (presumably later to be called the "iHead"?), please list them in comments below: