Tales from the Crypto

Ten reasons Dr J wants to go to Amazon.

10. Tired of working at a desk, wants to work at a door on breeze blocks instead.

9. Commute to Downtown Seattle is better than commute to London, New Zealand, Japan, Barcelona, Amazon Basin, Tsurinam, Atlantis, etc.

8. Tired of dealing with all those damn MVPs and their incessant fawning.

7. Feels the need to do security, rather than just travel the world talking about it.

6. Techies don't appreciate being labeled "marketing".

5. The Dr J fan-club is still smaller than Steve Riley's.

4. After giving the same talk for the last three years, surely the industry has gotten the point by now, or is beyond help.

3. Wants to hack Amazon's system to improve the sales of his books.

2. Microsoft is no place for a family man [but is Amazon really all that much better?]

1. Office closer to the water; water means scuba.

[Other friends of mine say "good luck" in their own ways:

Sandi "Spyware Sucks" Hardmeier

Susan "E-Bitz" Bradley

Joe "Joeware" Ware]

So, why do you think he left?

How hard do you want to make this?

So, I'm beta testing Outlook 2007, and it's got some really pretty "ribbons" that indicate that they've gone to great lengths to improve the user interface.

Today, I'm creating a distribution list from a number of people that have emailed me.

This should be easy.

Here we go...

Create a new distribution list, give it a name, and then drag the messages into it - it's smart enough to know what I'm trying to do, right?

Wrong. No drop operation gets performed.

Okay, so maybe if I open the message up, I can drag the individual sender's address into the distribution list, yes?

No.

What about clicking "Add Member", and then dragging the sender's address into the Add Member dialog? That should work, right?

No.

Worse still, the "Add Member" dialog is application modal - I cannot even change focus to the message to read the email address that I'm typing.

Right now, I'm resorting to dragging the address from the message into wordpad, then copying and pasting portions of the address into the appropriate fields in the "Add Member" dialog.

And I have to do this for a couple of dozen messages.

The ribbons are all very pretty, but really, Microsoft, "pretty" should always take second place to "usable". [Yes, my own interfaces aren't exactly pretty, but I like to think that they are usable - your constructive criticism is very welcome!]

Outlook has always given me the impression that the team that writes it - or at least, the team that designs it - has not spent a good deal of time actually using it.

I may have commented before that it's common practice within Microsoft to apologise for missing meetings by saying that "Outlook ate the meeting invite".

[Yes, commenting on beta software is probably technically in breach of some NDA, but the useless behaviour I'm talking about here was useless before, and it looks like being useless for some time to come.]

Backing up the data is not sufficient - you have to restore it, too

When was the last time you restored from your backups?

If you answer "never" (or even anything approaching "quite some time ago"), your backups might well be completely useless, for all you know.

Without testing the restore procedure once in a while, your backup process is a waste of time. Literally - you're replacing one random risk (the chance that something will destroy your data) with another (the chance that something will destroy your data, and you've been backing up only the zeroes(*)) that's only slightly better.

When you need to restore from a backup, that's the worst time to find out that you can't restore from a backup.

(*) Now, watch, as someone links to this article and tells the world that I'm advocating cutting your backup time and space in half by only backing up the ones. What I'm really advocating is that you backup your zeroes to one tape, and your ones to another.

Error: Insufficient system resources exist to complete the API.

This message ("Insufficient resources exist to complete the API", along with an event log event ID 26 from "Application Popup") has been popping up on my laptop from time to time, along with the rather troublesome issue that the machine refuses to hibernate. I had it set up so that I could close the lid, and the laptop would stand by for a few minutes, then hibernate.

Suddenly, it seems, the laptop is unable to hibernate, and only this confusing message appears on the screen.

Realisation dawned this morning that I had recently installed an extra 512MB of memory into my laptop.

Of course there are no system resources for hibernating, because my hiberfil.sys space is 512MB smaller, having been created with the previous size of memory.

The solution is simple - open the power properties (right-click the battery / power icon in the notification area, and select "Adjust Power Properties"), click the Hibernate tab, and then uncheck the "Enable Hibernation" box.

Click "Apply", to delete hiberfil.sys, then re-check the "Enable Hibernation" box, and click "Apply" or "OK" to recreate it.

So, if your computer cannot hibernate, and you get this message, try disabling and re-enabling the Hibernation feature, and don't think it's as random-sounding a process as other articles make it out to be. If you've changed your memory size, you need to change your hibernation file's size.

Just in case this doesn't fix you right up, there is another issue that it might be - a hotfix is available for Windows XP SP2, XP Tablet Edition 2005, or XP Media Center Edition 2005; there's also an earlier hotfix for Windows XP, for a different issue on multi-proc machines.

"Steam will save the world"

I was reminded last night, that there are always going to be some constructs that your static analysis tools won't save you from. [A point made by Microsoft's Michael Howard, in his blog and in his new book on the Secure Development LifeStyle... er... LightCycle... er... LifeCycle]

For instance, here's a piece of code:

#include <windows.h>
int main(int argc, char **argv)
{
    char buff[5];
    strcpy(buff,"1234567890");
    return 0;
}

Yep, that's a really short program that makes for a buffer overflow.

And yet, "cl /analyze" won't complain, except to tell you that strcpy is deprecated.

So, what do you do?

The right first step, of course, is to replace strcpy - as a deprecated function, it's kind of dangerous.

So, let's say we replace strcpy with strcpy_s, and here's the output I get from running "cl /analyze":

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 8.00.50727.42
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
test.obj

So, clearly, we're still not detecting the overflow.

"Isn't strcpy_s safe? Do we care that it's not detecting the overflow?"

Sure, it's safe - but it really depends on what you call 'safe'. Using strcpy_s like that will simply kill your process right there, with an exception:

---------------------------
test.exe - Application Error
---------------------------
The exception unknown software exception (0xc000000d) 
occurred in the application at location 0x0040108f.

[So, you did know you can press Ctrl-C in most dialogs to get the text of the message in the clipboard, right? Try it next time you need to report a dialog box error - much better than sending a graphic!]

But if you ship an application that does this, you'll get a reputation for shipping crap.

Possibly deservedly.

What to do? I've known some authors who handle this by catching, and then ignoring, the exception, in somewhere like their main loop.

Quite simply, that's the wrong thing to do - it may even be the worst thing to do. Why? Because the exception you ignore may be the test packet that gets thrown at you prior to the successful exploit. You definitely want to fail on unexpected exceptions - and a buffer overflow, even when it's detected, should not be expected.

But, you say, this exception is expected, and will be handled in some other way - say, by telling the user that he's entered a bad value, and requesting his input again.

Well then, it's not an exception, and you shouldn't use a function that makes an exception out of a commonplace occurrence. Look instead to StringCchCopy, which will return an error result when you overflow. Handle the error result correctly, and you avoid the mess and overhead of exception handling. Or, use strncpy_s with the "_TRUNCATE" parameter for the count value, and get a similar kind of handling.

Programmer Hubris Part 3: Microsoft Knows I'm Not That Into Them

In Programmer Hubris Part 1, I described that frequently I'd come across applications that impinge on my consciousness far more than is justified by my infrequent use of them.

I expressed it rather simply as "I'm just not that into you". You, the developer, may believe that your app is the most important thing in the world - to me, it's something I use once every six months, and not because I want to. Don't give me even more reason to remove your application.

Maybe Microsoft gets this, because they've just released "Windows Principles: Twelve Tenets to Promote Competition".

Some of the highlights relevant to this topic:

1. Installation of any software

2. Easy access

3. Defaults

4. Exclusive promotion of non-Microsoft programs

I also like:

6. APIs

9. No exclusivity

10. Communications protocols

12. Standards

Go and read the document - I hope to hold Microsoft to these principles in the years to come.

Defence in death

"Defence in depth" (or "defense in depth", if you're American) is a frequently misunderstood term in security.

It refers to designing your software with the assumption that layers above you that were supposed to protect you have failed to do so - in whatever manner is most inconvenient to your application.

As Steve Riley points out, it's not the same as simply applying the same measure at a couple of different places - it's about assuming that the measure above you failed.

An example is "my firewall restricts external traffic from reaching me" - that's a first layer of defence. The second layer of defence might be "my application requires a user-name and password". It's defence in depth, because even if an attacker can fake traffic through your firewall, he'll have to come up with a password that works.

I'm starting to think about laptop encryption as being "defence in death".

It's long been a statement in computer security that "if the attacker has physical access, it's 'game over'".

That's true - if you're talking about a system that provides a service - as usual, you have to talk about what you are securing.

Your server rooms are generally susceptible to a guy with a chainsaw - physical access means loss of service; ergo, security problem. You fix this problem with strong physical security.

Your servers, if they can be stolen, are susceptible to being cracked open by hackers who want to pull the data from them; ergo, security problem. You fix this with strong physical security (plus an appropriate hardware retirement procedure that includes degaussing the disks, shredding them, and lightly sprinkling them with thermite).

Your laptops can be stolen even more easily, and can be similarly opened up to hackers who want to read their data. Again, this is a security problem.

You can't solve it with physical security.

In fact, with security designs for laptops, you pretty much have to start with the assumption that physical security is impossible - and what can software security do for you, if the hacker can simply prevent your software from running?

This is where "defence in death" comes about - by making the system only usable while it is alive and running, by encrypting it with a key that is not stored locally, you make it functionally impossible to use or read the system unti you have brought the system to life.

And while the system is alive, it can actively protect itself.

Encryption is a lovely thing. Be careful to understand how you use it.

Where did Private Folders go?

Wow - yesterday, you could download "Microsoft Private Folders" (if you were attested as Genuine) from Microsoft's downloads site.

Today, it's gone.

There's a brief synopsis of the story at the Seattle P-I's site here - as usual, I'm patient enough to wait while you go and read it.

As a security engineer at a company that cares to manage its domain environment, I'm very comfortable with the argument that it's not something our users should be installing it - but it's a service, and our users are not local admins, so they can't install a new service.

What bothers me, though, is the argument that this is dangerous because "It also didn't offer a way to retrieve a forgotten password, raising the possibility of effectively losing access to files if people forgot the phrase they chose."

People, this is encryption.

That's what it's supposed to do.

You encrypt data that you would rather lose than leak.

You want to lose the data if it falls into the hands of people who don't know the password, even if that means you.

If you can't handle that, then encryption is not what you want - you want "protection", or "concealment", where there's a back-door for people with powerful tools, a little training and some time.

Your security is my inconvenience.

I'm reminded again, this weekend, that many companies engage in security practices that are, at best, inconvenient to their customers, and at worst, a poor attempt at security.

As an example, consider my son's use of his computer.

Every so often, he'll damage or break a CD of one of his favourite games.

OK, for most people, this would simply be a learning experience.

But my son's autistic. A broken favourite CD is cause for an absolute screaming, inconsolable meltdown that will last for hours, and will cause recurrences throughout the week.

So we adapted - we make copies of every CD-ROM, and we work from the backup.

When a disk gets damaged, it's the copy, so we can make another copy from the original, and there's no loss.

But there's always that bugbear of "copy protection". We first encountered it with a Thomas the Tank Engine game. Seriously, Thomas the Tank Engine needs copy protection?

Today, it was Frogger 2. This game is so old, it's for Windows 95 and 98.

So, there's no chance to replace it, and without the ability to copy it ahead of time, this was the original disk that was shattered.

Did I ever mention how much I hate copy protection, and how stupid I think it is?

Pirates in Singapore (or pick some other country - Italy, whatever) simply make a bit-for-bit copy, and the copy protection doesn't even give them pause.

Real users at home, on the other hand, are unable to make backup copies for their own use.

Once again, I am reminded that I didn't buy the game - I bought the plastic CD, and the game just happened to be on it. When I break the CD, I have no right to the game.

That just plain sucks.

Is a denial-of-service a vulnerability?

I always like to ask questions that make everyone answer immediately with what they are sure is the right answer, and then tell them that they haven't thought it through.

The title of this post is one such question. The answer is "yes", right?

Sometimes, yes, but sometimes, no.

Let's think about it a little.

The obvious vulnerability related to a denial-of-service is when you're trying to provide a service to numerous users, and an outage will cost you (money, usually).

But what about a browser denial-of-service?

If I visit some hacker's web site, and it closes my browser, what happens, really?

Unless you're particularly hard of thinking, you simply don't visit that web site again.

Yes, you have to go further into that "it closes my browser" mention, because that might just be a null-pointer dereference, which just stops the browser cold, or it might be an exploitable buffer overflow that you can only exploit occasionally.

But if it's really just a denial-of-service - and the only thing it does is to stop or close the browser - it's not really a security issue. It's a pain, and a reminder not to visit that site again, but it's not a threat to your security, and you can wait to apply that patch.

Am I wrong?

If only programmers would spend less time conspiring together...

This post by Bruce Schneier, the post it refers to, and the comments on Bruce's page, illustrate that there are people who have some very strange beliefs indeed.

The belief goes something like this:

Programmers happily spend a lot of their time, en masse, deliberately putting bugs in to programs.

As a programmer myself, I'm amazed that people believe that programmers have so much extra time, and so much extra ability of thought, that they're going to choose to add bugs to programs.

An email while I was at Microsoft expressed the obvious response to me - this software is in use by our friends, our families, our doctors, the people who make our buildings and roads safe, everyone we rely on - it's vitally important to our own continued happiness and survival to make sure that the software works as well as we can make it.

I think that the reason this sort of conspiracy theory takes hold is that programming is, to most people, a magical and strange practice. There is no equivalent to it in most people's everyday lives. For all that people come up with analogies of how computers are like cars, or like this or that, a computer is, to most users, a device to which you provide input, and which provides output back to you.

What goes on in between is magic.

Obviously, it's not - it's no more magic than is the process by which you turn the key in your car's ignition and it starts the engine. (To me, that's magic - I don't care to understand how a car works)

There's a few orders of magnitude more moving parts in a program, which is where complexity makes it look like magic, but an early lesson in digital electronics teaches you that you can build any computer - and any program - from a device that does one operation (NAND - it produces 1 if either of its two inputs are 0, and produces 0 if both of its inputs are 1).

The reason bugs appear in software is, quite frankly, because programmers are human. We don't always manage all of the complexity correctly.

That's it.

It's not about raising profits, or ruling the world, or trying to make your lives hard. We just occasionally screw up.

Security is not like parmesan cheese

You can't get a can of the stuff and shake it on top to make your meal complete.

[Security is more like "kosher" - it's something that you have to include in every ingredient, or the final dish won't qualify.]

Whenever I talk to the religious platform adherents - and because of the sphere in which I work, they're always Linux adherents - I have to ask them what the Linux developers are doing, that Microsoft isn't.

Security obviously cannot be granted by merely labeling something as Linux, nor even by releasing the source code (I would argue that Microsoft, with its various source code licences, may have more people devoted to passing eyeballs over their code than Open Source does!) - so if Linux / OS X / Unix is more truly secure, it must be because something is done differently when developing the code, or reviewing it before including it in the source base.

Anything that happens after the build - testing, code inspection, user behaviour - is going to affect the released code in no way whatsoever. It may provide reason to re-visit the code and change a few things for the next build, but it can't make the existing code more secure - and judging from the people who complain about Windows 98 reaching "end of life", existing code spends a long time in active use before being retired to pasture!

I will readily admit that Unix users are ahead of the game in one respect - they are more accustomed to thinking in terms of "root" versus "non-root". Give them an application program that only runs as root, or which requires permissive sharing of executable directories, and they are (on aggregate) just as meek in accepting it.

But again, that's something that's applied after the build is released, and therefore cannot be something that demonstrates how Linux itself is inherently more secure. If the merry marching morons that are often depicted as the majority of Windows' users were to follow the advice of the religious adherents, and switched to Linux tomorrow, they'd bring all their stupid "must be administrator all the time" application vendors with them, and they'd cause just as much damage to themselves on Linux.

Do any of you see a process that I'm missing, that gets applied prior to a Linux build being released, that makes it more secure, and that isn't currently being done by Microsoft?

Say bye-bye to the twentieth century...

Operating systems built in the last millennium - are you still running them?

Windows 95, Windows 98, Windows 98SE and Windows ME officially drop completely off Microsoft's support services today.

Non-Affected Software:

•	Microsoft Windows 98, Microsoft Windows 98 Second Edition (SE), and Microsoft Windows Millennium Edition (Me)

You won't see that any more.  Perhaps more worryingly, you won't see this any more, either:

Affected Software:

•	Microsoft Windows 98, Microsoft Windows 98 Second Edition (SE), and Microsoft Windows Millennium Edition (Me)

Any time a new bug comes up, Microsoft simply will not be interested in finding whether it does, or doesn't affect any of these operating systems.

You can't even pay them to be interested.

Are you interested in finding that out?

Why? Really, why?

You should be more interested in how you can get your system and its associated applications to run successfully on a modern, supported, operating system - and quickly!

I don't sell Microsoft software, and I don't have my income tied to them in any significant way, so if you choose to use this as an opportunity to go to another OS manufacturer, that's fine, and good luck to you - but please, dump that old OS. It's probably already infected with a couple of dozen viruses anyway :-)

[Okay, yeah, so technically, Windows 2000 is an operating system designed and built in the last century. So why not upgrade before Microsoft says "sorry, you can't even pay us to support that rusting pile"? Waiting on your applications' vendors? Kick their sorry backsides into gear, before you have to!]

New ActiveSync - still not going to upgrade to it.

Microsoft just released a new version of ActiveSync - version 4.2.

It has some Outlook improvements, proxy improvements, partnership improvements, and VPN connectivity improvements.

So why am I still not going to bother installing this?

Because it still doesn't support syncing via wireless.

I'm sticking with ActiveSync 3.8, which allows syncing via wireless and/or VPN.

Isn't that unsecure? Yes, but it works, and I need it to work. I generally don't carry my sync cable with me, and I generally don't plug in except to charge - and then, I just want to charge, and may be away from my sync partner.

How difficult is it for Microsoft to write an ActiveSync tool that exchanges a huge shared key (or certificate, whatever they feel is most appropriate), to securely identify a sync partner, so that wireless and VPN network synchronisation can be securely supported? I must be missing something, because it doesn't seem that hard to me.

Here's a better laptop theft story...

It'd be nice if the press handled this story a little better.

After all, it's what we want - the stolen laptop had all its private data encrypted.

So why do I still get the impression that the authors are trying to push the angle of "sure, they say it's encrypted, but really, what protection is that?"

I really want them to say "sure, the laptop may have data on it, but it's all encrypted, so unless this was an inside job, that data is safe".

If there's no PR benefit to encrypting laptops, then we are relying on businesses to do the right thing simply because it's right - and do we really trust business that much?

Supporting businesses that do the right thing, congratulating them for it, is the best way (short of patronising their outlets) to make sure they continue to do it.

Of course, since this is the Red Cross, perhaps what's better is a donation of time and/or money.

[Since posting this, and similar content elsewhere, I've received a few messages that basically say "the laptop shouldn't have had data on it in the first place". I totally agree, but I'm pragmatic enough to realise that people will occasionally / frequently slip up on policy, requiring you to put extra measures in place. Given that the policy says "no data on laptops", laptop encryption is still necessary.]