Tales from the Crypto

How's that for a deadline?

"The Bush Administration is giving federal civilian agencies just 45 days to comply with new recommendations for laptop encryption and two-factor authentication." - http://www.securityfocus.com/brief/239

45 days. Man, I hope they've already started, because 45 days to analyse the field, pick a vendor, test proof of concept, agree on licences, buy the software, deploy a pilot, train staff, and roll out to everyone without making day one into a mass "hey, guys, I forgot my password, can you decrypt me?" phone-tag game - wow, that's tight.

Like I say, I hope they've already started - and quite frankly, I already hoped they'd already started, because to not do so... that's crazy.

Of course, the other tack to take - at the same time, I hope, is to stop storing the damn data on the portable devices. Wherever possible, those laptops (and other portable data storage devices, let's not forget thumb drives) need to have nothing more damning on them than a copy of Windows (or, I don't know, Fisher Price's "My Little Sony", whatever you other people use), and the VPN client to connect back to the home base. Sure, sometimes, you have to carry data around with you, but good luck getting approval to do so, or avoiding a tongue-lashing if you're found to have that data on your laptop without significant reason to do so.

I wish Larry hadn't written that...

Oh, Larry, Larry, Larry...

Articles 1 and 2 were great - really necessary reading to a lot of would-be network programmers.

But article 3... where to start with the corrections?

I'm not going to. It's an article you shouldn't read, because you're not going to use the right terms for the right things, and when you go asking for help from networking experts, they'll look at you in much the same way as security experts look at Steve Gibson. [The look is "how the hell do you get anything done, knowing so little about the field?"]

I've met Larry, and he's a nice guy, so I really thought twice about making this post - and I apologise if I hurt Larry's feelings by saying it... but I have been on a fifteen-year march to persuade people to stop writing crap networking apps, by getting them to understand what they're doing, and I can't stop now.

At the risk of opening myself up to abuse similar to that which I'm heaping on Larry now, I'll point you to my earlier article, where I describe the interaction between delayed ACKs and Nagle - it's much, much simpler than Larry stated, and I think I've got it more accurately described.

Finally, in the case that perhaps I don't have it correct, I'm going to retro-edit it if mistakes are pointed out, because the worst thing you can do is have someone search for the answer, and the first text they come back with is wrong.

BluRay - a bad name for high-definition?

My attention was drawn to a graphic this morning that seemed to read "BLURRY"

Turns out, it's just a slightly out-of-focus and small picture of a logo for "Blu-Ray", one of two competing standards for high definition DVDs.

Seems like a bad idea to make its logo so easily misreadable as something that is the antithesis of its design.

But it's fun to point and laugh at.

Kurzweil's DRM killer

Okay, so it's really a device for allowing blind people to read signs, menus, receipts, etc, without having to drag the print to a scanner.

But consider that this will effectively scan and read any print that is visible anywhere, and you realise that this device is a handy little DRM beater.

Mind you, so is a digital camera with good resolution - or a non-digital camera, for that matter.

Or a person with a notepad and pen.

Once again, this just underlines that DRM is workable only in the situation where you have extra, non-technological controls over the people with whom you share the DRM-protected material.

DRM is nothing more than a reminder to honest participants that they should not be passing copies around.

It is sad that many in the publishing industry are convinced that it is a panacea, and will prevent copyright infringement. The pirates simply continue to copy the bits (DVDs have DRM, but if you simply copy the bits exactly, the DVD created plays without complaint), and it's only those people that want to move content to different devices (i.e. non-DVD storage, such as a laptop hard-drive, for power-friendly viewing) that are prevented from doing so.

What do you call a "security measure" that has no effect on security, but substantially reduces usefulness for people who are legitimate users?

DRM.

Neat little RunAs one-liners - ADHERE and ADFILE

ADHERE.BAT

Short for "Admin Here", I've been enjoying this little one-line batch script:

@runas /u:%1 "cmd /k cd /d %cd%"

What's it do?

First, it's important to note that it takes a parameter, the username that you want to run as.

It'll open up a new CMD window - a command prompt window - in the directory that you're currently in. This prevents you from arriving in the C:\Windows\System32 directory every time you realise that you need an administrator account to run a few commands.

ADFILE.BAT

Short for "Admin File", here's the obvious next step:

@runas /u:%1 "cmd /c cd /d %cd% & start %2"

Takes two parameters, the first being the user you want to runas, and the second being the file you want to run / open.

Enjoy.

[Of course, you may want to hard-code the admin user name into the batch file.  Be my guest]

[Update 7/7 - added the "/d" parameter, so you can "ADHERE" and "ADFILE" from directories on other drives.]

First Scoble, now Gates...

Clearly, Bill Gates took Scoble's departure hard.

I'm now taking bets as to whether this makes the stock go up or down.

Prosopagnosia - why face-based password schemes won't work for all.

I'm frequently here blogging about biometrics and accessibility - too many biometric methods get confused when you don't have the credential.  Aniridia means you don't have an iris, a lack of thumbs (congenital or accident-induced) means you don't have a thumbprint.

Here's another biometric that's going to cause problems, and I may have blogged about it before - prosopagnosia. Yeah, it's a long word, and difficult to type, so I'll use the common abbreviation, "proso".

I have a relatively mild, but noticeable, case of proso. I'll tell a little story about myself, but first there's a great, short, article in yesterday's Boston Globe. Read it - I'll wait.

Okay, so here's the story of the Starbucks Trinity.

Back when I was a stay-at-home dad, I would frequently trip off to Starbucks, for a drink and a chat, and to work on my laptop away from the Internet and phones.

One of the barristas there was studying Networking at the local college, so I'd chat with her every now and again, but her behaviour confused me - about two times out of three, she'd look at me like I was talking Greek.

After several weeks of this behaviour, I found out why - of course, you've guessed by now - they were three different women, each of different heights, weights, and hair colours. But because they all had long hair and wore glasses, I lumped them all in as the same person. This wasn't a case of simply not bothering to look and pay attention - this (or one of these) was a person with whom I was talking about my field of interest.

One thing I take from the Boston Globe article is that this is more common than previously thought - to some extent maybe up to 1 in 50 people has this condition.

So, when you consider the "biometric" schemes that offer a pile of faces to choose from, and the user has to select the same person every time, bear in mind that one in 50 people will have trouble with that.

Zero-day sessions at Tech-Ed.

Okay, so I'm really talking about the TechEd keynotes here, not sessions on zero-day attacks.  The keynotes were on the day before the first day, hence "zero day".

While I didn't recognise the actress that they dragged out to impress us, because I never watched "24", she was far nicer eye-candy than the MS execs, so I guess that MS got their money's worth.

My big complaint - a company that has repeatedly expressed concern over staff turnover, is asking us to believe that they can advise us, their customers, how to be "people ready"?  I'm not sure I can get behind that.

That, and they had the guy from Groove, Ray Ozzie, stand up and give us a twenty minute talk about his history prior to Microsoft, and telling us that his staff has used Groove to improve medical conditions in a remote region of Afghanistan.  All good stuff, but I still have no over-arching view of what Groove does.

Some day, I think Microsoft ought to put up a list of all of their products, and a single paragraph that explains what the product does.  Something like this:

IIS: "It's a Web server, and comes bundled with Web-style remote execution services like ASP, ASP.NET"

IE: "It's a Web browser"

Sharepoint: "It's a web site that your team goes to when they want to share files, documents, discussions, etc"

There are still far too many Microsoft products that I couldn't identify if you gave me a description, or describe if you gave me their names.

Few people in my TechEd group

I'm a little disappointed to see that the Tech-Ed group I created, "Ex-Initech Employees", has only three members so far.

I'm sure that there are many people here who have, at one time or another, worked for Initech, the company featured in the movie "Office Space".

It may not have been called Initech while you were there, but if you recognise the staff, the management, the policies, the consultants - join the group!

Tech-Ed fan clubs.

Steve Riley and Jesper Johannson each have fan clubs at the Tech-Ed communications page.  I'd link, but you have to have a TechEd registration to see it.  Steve's fan club has 10 members, Jesper's has 7 - but we actually count Steve at 9, because he has joined his own fan club.

Those of us who know Steve are unsurprised by this. :-)

Jesper has an edge, though, since his photo is feature in the slide-show they're presenting prior to the keynote.

Yes, I'm sad enough to be posting this live from TechEd!

More Tech-Ed news as we go along.

Sandi brings up the question of responsible disclosure.

Over in Sandi Hardmeier's blog, I see again that a site was hacked following a public disclosure of an exploit, but prior to the availability of a patch. Sandi says:

This makes me ponder the ongoing argument about "responsible disclosure". Should Gulftech have publicly announced the exploit?

Of course Gulftech should have publicly disclosed the exploit ... after Invision released a patch, and after a majority of Invision's aware customers had a chance to apply it.

If these companies really care about "I was first" bragging rights, they can cryptographically sign and timestamp the document, release the signature when they first have a private document describing the exploit; then they can release the document after the patch, and we can all recognise that their signature matches the description of the exploit, and marvel in how smart they are to have found the exploit before anyone else.

There is one concern here, though - when public disclosure happens, the discloser can throw up their hands and say "it wasn't us that wrote the virus - must have been some member of the public". If the researchers stop public disclosure until after the patch, any pre-patch virus that comes out might cause the researchers to be suspect number one.

I don't think that's a reasonable fear, though, because such researchers would be beyond reproach, compared with researchers who publicly disclose prior to vendor patches, who are quite definitely and deliberately giving the exploit details to virus authors.

Making secure programming hard through bad documentation.

I ran into a little confusion when tracking down a bug in one of my programs today.

Direct quote from the sscanf_s formatting fields documentation (as of the time of posting, maybe it'll be corrected soon):

"The secure versions (those with the _s suffix) of the scanf family of functions require that a buffer size parameter be passed preceding each parameter of type c, C, s, S or [."

Uh... that should be "following"(or even "after", because people understand short words better), not "preceding", and an example would be good to make this distinction clear:

This reminds me - I take a lot of time impressing on developers the difference between _countof and sizeof.

The sizeof operator (it's not a function - don't get confused by "sizeof x", and expect "sizeof(x)") has the advantage of being straight C, but it has the disadvantage of frequently returning 4 (the usual size of a pointer), or in Unicode programming, twice the amount you're looking for.

_countof() is a compile-time evaluation through smart use of C++ templates - when you accidentally pass it a pointer instead of an array, you get a compile error (a good thing!), and it always returns the value you're looking for in order to use the secure _s functions.

The documentation for those secure "_s" string functions could be far clearer on this point, too - so much of the documentation refer to phrases like "the count parameter is a count of bytes for char, and a count of characters for wchar", or "Parameters: sizeInBytes, sizeInWords" - no, it's always a count of characters, and if you think of it in such an unambiguous way as "count of characters", you will be less confused.

IMHO, sizeof should be reserved for the strict exact case of requiring to know how many bytes in memory an object will occupy - for when you're treating the destination as a pointer to memory, not characters of any sort (not even one-byte characters). _countof, where available, should be used in preference, to get the number of elements.

This ties into my earlier topic on SAL - _ecount should be used in preference to _bcount in SAL annotations, because you are dealing with the elements of an array, not the bytes at a memory address.

I know C++ allows you to think and code in the lowest levels, but that is not an invitation to always do so - take advantage of high-level constructs when dealing with high-level concepts ("string" is a significantly higher concept that "pointer to byte sequence").

You can lead a horse to water, but you can't make him think. Part 2.

In the interests of balance to my last post, maybe I should tell a story about a Microsoft developer not getting it, either.

When I was working for Microsoft, I was sent on a day-long mandatory course to hear, from Michael Howard himself, how to do secure development. I was also given a copy of Writing Secure Code, Second Edition. This is, as Bill Gates says on the back blurb, "required reading at Microsoft".

So it was a surprise to hear another developer on another team(*), in a cross-team meeting, talking about how they were going to implement file canonicalisation.

In my usual diplomatic style, I asked what the hell they were thinking, didn't they learn anything from our team's previous - public and embarrassing - run-ins with canonicalisation issues, as described in the Michael Howard lecture, and in the WSC book?

"Maybe you guys had problems with canonicalisation when you implemented it, but we're going to get it right." was the answer.

Developers are pretty much all a bunch of arrogant type-As, and it's sad to note that you can't teach them anything they don't want to learn.  Unless you've "seen the light" over secure development, you'll keep ignoring the mistakes that other people have made, because you'll assume those mistakes were made by idiots.

Every buffer overflow ever created, every elevation of privilege, was created by a smart guy who thought he was doing the right thing, the clever thing, the obvious thing, and the right thing.

Crafting secure code is as much about admitting and accepting that your code will break, as it is about preventing it from breaking.

Elimination of faults is not the most important thing - toleration of faults (in the sense that you can make mistakes, get messy and recover) is hugely important, too. Overflow a buffer, and you need to detect that and drop; don't just assume that you aren't going to ever overflow because you're too damn smart.

(*) No, I will not name the team - for all I know, they had a quick chat after the meeting, slapped a couple of heads, and got the right answer - which is, "let the file system do the canonicalisation".

You can lead a horse to water, but you can't make him think. Part 1.

Years ago, the Open Source and Linux/Unix crowd (most of whose members are in both camps) jumped up and down on how stupid MS Office's developers were for including a macro language (at all, in many people's minds) in Word, among other applications in that suite.

Wind forward to today, and F-Secure comes out with the following announcement:

"One of our researchers, Sami Rautiainen, produced a paper for the Virus Bulletin Conference in September of 2003 on the topic of OpenOffice Security. The conclusions that he reached: The macro language and the API of OpenOffice are very powerful, but unfortunately the power can be abused for malicious purposes. The security settings in the default installation of OpenOffice much resembles older versions of Microsoft Office."

Okay, so that's from 2003 - old news.

Then they go on:

"That was then, and now… we have a sample of a proof-of-concept macro-virus for OpenOffice.org named Stardust.A. This thing is very proof-of-concept and is not something in the wild, but it's interesting to note that the waters are indeed being tested."

Unless I'm missing something here, that's yet another demonstration that, as far as developer security goes, there's no lesson like the one you learned first-hand.  Apparently, OpenOffice didn't learn from Microsoft's Word macro virus woes, and then didn't learn sufficiently from F-Secure's paper.

Update: As if that wasn't enough, I read this story from an Australian IT news web site. I don't know that I can even comment on the stunningly dangerous naivete shown by the Linux / Open Source advocate there. Read it for yourself - what do you think?

Apparently, I've made it as a blogger.

Finally, after goodness knows how long, I am getting blog spam.

I figure this means that I have arrived, as a fully-fledged blogger.

Now I get to join everyone else who complains about blog spam.

I think spammers are a strange bunch - they expend effort and thought on trying to get rich quick by engaging in an activity that seems pretty damn stupid.

They'd get rich far quicker, I think, if they put that much effort and thought into something that takes only a little hard work and thought to become successful.  And people wouldn't execute them, gang-land style.

I think it's a new breed of sociopathy.  It goes way beynd selfish, well into the realm of wanting to screw with people.

Don't think I'm simply ranting - I've been following the behaviours of spammers for oh, about a decade.

It's just getting boringly predictable.  The Internet creates a place for sane and moderately on-topic discussion, then come the spammers to piss in the pool.