therning.org/ magnus

I’ve just uploaded two small tools that makes it a little easier to deal with SDDL (Security Descriptor Description Language, this is a good resource for SDDL):

1. saddle-ex - “extract” the security descriptor for a number of different kinds of objects
2. saddle-pp - a pretty printer for an SDDL string

Full build instructions are included. Download the archive here.

The tools are written (mostly) in Haskell and I’ll probably upload it all to hackage at some point in the future. I’m holding out for a fix to ticket 2097 since a fix for it will allow me to add a third tool which I feel belong in the package.

Suggestions for improvements are always welcome, patches even more so

After the recent cock-up by HMRC I find myself a bit more hopeful for the future.

Hopefully the politicians will start asking themselves if it really is such a good idea to collect information in huge databases. Should we really have ID cards? Is it a good idea to have a huge database with details of every child in the country?

I’m still wondering why it’s possible to “steal someone’s identity” by knowing only what HMRC knows about a parent that receives child support…

Almost three years ago Bruce Schneier posted a blog entry on Computer Security and Liability. Since then he has repeated his opinion several times; one of the more high-profile occasions was in front of the House of Lords. Some people agree, others disagree.

Until just a few days ago I disagreed with him on this particular issue. After the four learned hosts of LugRadio brought up the issue in episode 3 I had another think and I’ve now changed my opinion. I am now in favour of holding companies financially liable for damages resulting form security vulnerabilities in software products.

The software business is interesting because there’s a very obvious asymmetry in what is known about a product between the people who write and sell software and the people who use and buy software. Bruce Schneier has touched on that as well in his post on Security Lemons. Basically the buyer of software knows nothing of the ilities of what they are being sold, so there is very little to hang an informed decision on.

I think that introducing financial liability for software producers should take into consideration whether a buyer can make an informed decision before buying or not. This means that in cases where the buyer has full access to the sourceⁱ there will be no financial liability on the developer. It would be enough to offer all source code under an NDA to a buyer before the deal is finalised. Basically liability would be the price a software vendor has to pay to keep the buyer in the dark regarding how secure the product is.

1. Note that the source doesn’t have to be free as in having all four freedoms granted by e.g. the GPL.[back]

I think it’d be better if Microsoft’s security specialists concentrated on improving security in their products (and possibly write about how they do it) rather than trying to make the rest of the world feel sorry for them. I’m sorry, but full disclosure is the fairest we have at the moment.

Microsoft sits on a reported vulnerability for months, releases patch when it becomes a 0-day. As I write this Microsoft is sitting on a few publically known vulnerabilities in Office (0-days as well) that have been known for a while now.

So, until companies start behaving I think full disclosure is fair. It seems to be the only way of forcing delivery of security to paying customers at the moment. When there’s a sign that the business as a whole can function without FD I’ll be the first to argue against it; at the moment though it seems to be our only hope.

FD ⇒ bad PR ⇒ declining share price and sales ⇒ security fixes

Some companies seem to be on the verge of understanding this and taking it to heart. (Microsoft has understood it, but doesn’t seem to have found its heart just yet.)

I just noticed a post by Joanna Rutkowska on a very handy little tool—chml.

For the record I’d like to point out that this tool further highlights how confused the MIC is in Windows Vista. A no-read-up policy in integrity control? I rest my case.

Lately I’ve spent some time looking at Windows Vista security. Basically just trying to catch up with some of the changes introduced and mostly done through reading whatever I come across. I’ve spent only a little time actually playing with Vista though, and I’ve not gotten to the nitty-gritty since I haven’t written any code at all.

So, what is my impression so far?

Well, they’ve done a reasonable job given where they started. Already on a very high level it’s clear that Microsoft still prefers to offer convenience over security in their UI. I was shocked to see that the dialogue for creating a new user didn’t promote entering a password. No, to do that you have to press the mouse a few extra times. Since local escalation often is a walk in the park I had expected Microsoft to strongly encourage users of Vista to create accounts with passwords. Then on to details. First integrity levels, or MIC (mandatory integrity control). Steve Riley says they’ve based it on the Biba-model. I think “based” in this context really only entails using some of the terminology. A model of read-any, write-down already suggests a bastardisation of Biba and once you add the rules for process-execution integrity you really do take a huge step away from Biba. This is what I’ve found so far:

(I haven’t found a way to create a user on the low level so that line is missing.)

Spot the strange things in the bottom line? Yes, they seem to have mixed up min and max I do see the point though, usability and convenience. However, to still call this model “based on Biba” requires quite a lot of hallucinogens.

I also noticed that the integrity level of an executable doesn’t seem to be passed on to the files it’s creating. At least not at all times. I was running a high-level notepad and created medium-level files. I should note that a low-level notepad creates low-level files though. Not really insecure or anything, just a little unexpected.

So far my impression of MIC in Vista is that the people commenting on Steve Riley’s blog post are onto something. Microsoft has taken MIC and in the implementation somehow got it mixed up with MAC. I almost suspect they really wanted MAC but decided it was too intrusive and picked the closest thing, acronym-wise. The conspiratorist in me finds evidence of that in the API AddMandatoryAce where ACE stands for Access Control Entity.

Based on what I’ve found so far, and also inspired by Rutkowska’s recent rant on UAC I think Vista security is a classical case of CYA. Microsoft is blamed for all Windows problems and the security added in Vista makes it possible for Microsoft to deflect some of that blame and put it on applications, where it often belongs.

So, am I impressed? Only mildly impressed so. Five years and this is it? As so often I get the feeling Microsoft is controlled by people who just don’t get it. Recently I saw a presentation on ZeroConf and the presenter had a quote (I paraphrase):

You are done, not when you can’t think of anything more to add but when you can’t think of anything more to remove.

There are many companies in the software field who’d benefit from applying that. Microsoft more than most!

Brilliant clip from Family Guy:

Here’s a sure-fire way to make sure users choose bad passwords:

• Force passwords to have a minimum length.
• Come up with some arbitrary rules regarding “complexity” of the password. E.g. that it contains at least one upper-case character and one digit.
• Keep a history of passwords. Make it huge, say at least 20.
• Force users to change passwords every 3 months.
• Prevent users from changing passwords for a number of days after a change. 5 days is good, it translates to a full week in most cases, plenty of time for the user to forget the password.
• Make sure that you hire only lazy people for the corporate helpdesk. “Lazy” in this case means that they invariably choose passwords like Acme123ⁱ when your users call in saying that they’ve forgotten the password they chose yesterday.
• Layer this on top of a centralised user database like ActiveDirectory to make it really difficult for your lazy helpdesk personnel to temporarily change the no-change-in-5-days rule for a specific user.

1. Change Acme to whatever company you work for.[back]

I wonder what howto on codex.wordpress.org Wolfgang’s talking about. I’ve been trying to get an SSL certificate onto my blog as well, but that didn’t seem possible at the time.

(I would have left a comment on the entry itself if I didn’t have to log in. Why on earth would I want to create an account of another person’s blog?)

Elmo is right, Britain really is the 51st state. I’ve noticed the very strange and one-sided relationship with the US before but this article on Britain’s nuclear weapons put that in a whole new light.

Britain has just been blessed with a system of threat levels. Bruce Schneier isn’t impressed and I can’t help but wonder what should we do now that the threat level is SEVERE?

RFID seems to be the rave at the moment for securing things, which means it’s the rave in circles that break stuff. Here’s an interesting story on how secure signal-emitting chips in car keys are. It seems the RFID in passports has been cracked as well.

To end on a lighter note, you can now get your computer to do useful stuff by hitting it.