Programmer Hubris – Page 13 – Tales from the Crypto

Programmer Hubris

Signs your crypto is wrong.

Here are a few signs that you might be doing crypto the wrong way:



  1. You’re using a third-party library “because .NET keeps throwing exceptions”.
    Explanation: .NET’s cryptography routines throw exceptions when you are doing something wrong.  If you are getting exceptions, you need to figure out why.

  2. You are encrypting (or trying to encrypt) with the private key.
    Explanation: You encrypt with the public key, you decrypt with the private key.  You sign with the private key.  Yes, signing involves an encryption with the private key, but that’s the only time you should encrypt with the private key – and then, you should be doing the hash and sign together.  .NET will throw an exception if you try and encrypt data with a private key.

  3. You are decrypting (or trying to decrypt) with the public key.
    Explanation: see sign number 2.  If your protocol requires you to decrypt with the public key, except as part of a signature verification step, then it is broken.

  4. You are designing your own protocol, rather than copying from someone else.
    Explanation: Cryptography is hard to get right.  Cryptography needs to be done using published and analysed methods, to know that you are getting it right.  Everything you are trying to do with cryptography has already been done.  Copy from others.

  5. You have started writing your final program before finishing reading the book.
    Explanation: Most books discuss the simple concepts first, and the subtler concepts are left for further in the book.  If you start coding before you have met some of the subtleties, you will paint yourself into a corner, or you will release a half-finished piece of crypto.

  6. You are writing SSL code, but you do not know what “close_notify” means.
    Explanation: close_notify is part of the SSL protocol spec.  Without it, you don’t know if your session was interrupted by a forged closure.  It’s covered in chapter eight of the book I read.  See sign 5.

I expect to have more signs later.

IDE ate my source code

A tale to chill the blood of developers everywhere: “My IDE ate my source code” [For non-developers, “IDE” means “Interactive Development Environment”, and is how developers like to edit source code.]


My attention was drawn to the line “I’ve been using Borland IDEs on and off for the past 17 years or so, and nothing like that has ever happened before.”


Quite frankly, I gave up using Borland IDEs oh, a little over ten years ago, because the IDE I was using did exactly that – ate my source code.


I’d typed in a bunch of new code, and wanted to test it, so I pressed the button to debug my code.  Of course, the code crashed, and this being 1995, and on Windows 3.1x, it took the operating system with it.


After I rebooted, it became clear that my last several hours’ worth of work had not been saved.  Say whuh?


The Borland IDE of the time would happily compile code without first saving it.  [My first thought was “how can it even do that?  The compiler works from source files on the disk, surely?”, but I confirmed that you could create and compile an entire application without it ever hitting the disk except as object and executable code!]


[How is this security related?  Let’s say you fix a security flaw, and make a bug fix elsewhere.  You test the code – the security flaw fix works, the bug fix crashes when you test it.  So you reboot, and go make the bug fix in a different place, thinking your security fix is still in place…]

Programmer Hubris – I don’t run your software all the time.

Not only don’t I run your software all the time, but actually I run it about once every couple of weeks.


So why on earth does your software run all the time?


Okay, so this particular complaint is about Sun’s Java, which I use once every two weeks, to sign my timesheet so that I can get paid.  It stays memory resident even after I close the web browser that took me to the page.  But the complaint could equally well be made against RealPlayer (or whatever it’s called this week), which likes to remain in my system tray (down by the clock) even though I view .RAM files about once every two or three months.


Maybe Java and RealPlayer occupy very small amounts of memory, but when you combine them with every other program whose developers assumed that everyone would be using their software 24×7, you wind up with a lot of memory used by a lot of programs that are all plodding along unused, but stealing a little time here, a little network resource there, and a bucket of memory.


Every now and again, I rebel, and remove a bunch of applications that I rarely use.  But then, “rarely” comes around and I have to reinstall because there’s a persentation I want to hear in RealPlayer, or an algorithm demonstration in Java.  Then I have to uninstall again (and reboot) if I don’t want to waste my resources.

Think of it as the "janitor" account.

While I was at Microsoft, every so often the question would arise “how can we do more to prevent users from running all the time as administrator?”


There’s something sexy and powerful about being “administrator”.  Suggest taking administrator access away from someone who has it now – say, a developer, or a small business’ financial officer (thanks, Quickbooks!), or a home user (thanks, Turbotax! – by the people who brought you Quickbooks) – and you’ll get thrown the look of an alcoholic who’s just realised that you’ve figured out where he’s stashed his hooch.


Okay, so undeniably, there is power in that account – and that’s the main reason why you should spend as little time with that power as possible.  “Power corrupts”, remember, and in this case, the thing most likely to get corrupted, by that power being constantly “on”, is the important data you use to run your business.


In Vista and Longhorn, this has been significantly addressed by use of UAP / UAC / LUA or whatever it’s called this morning.


For some reason, nobody ever took up my suggestion, which was brought on by the observation that my kid thinks the guy with power at his school is the janitor.  He has the keys to every classroom, he knows where the secret tunnels are, and how to open up the locked cabinets with the electricity in them.  To those of us beyond secondary education (high school), the janitor is somewhat less cool – without him, the school couldn’t function, but we wouldn’t like to do his job unless it was absolutely necessary that we do so.


So, I think that we should rename “administrator” to “janitor”, at least in our minds, if not in our systems.


This highlights that administrator access should only be used when you need to work on the ‘plumbing’ of the system.  It’s not really the power-house, and the secret areas to which it has the keys are only the boiler-rooms and fuse-boxes of your system.


Where’s the harm in being administrator all the time?  It’s like leaving all those locked cabinets open, for any old virus to abuse as it pretends to be you; it’s like spending time in the boiler room, where you could drop your bottle of cheap whisky and set off a fire that burns down the whole school.


Okay, enough with the analogy, here’s some real reasons why.  If you run as administrator, a virus or trojan that you run (and you will run one, one day) will be allowed to destroy not just your immediate files, but the entire system on which you depend, or worse, install extra components that can be used to attack others, or to filch off your private information.  If you run as administrator, you will accidentally type a command that deletes an important system setting or another user’s important files.


Do I run as administrator?  No.  In my job I run as a Restricted User.  Not even “Power User” (another bad term that equates to “administrator”).  I spend my day as a Security Engineer, and Developer, in Restricted User mode, because I don’t trust that I can detect every virus or trojan, or that I can control my actions sufficiently well not to do something disastrous.  At times, it sucks, because there are programs I can’t run (but there are usually alternatives), and features I can’t access (but I can often open them up with appropriate tools and settings).  I still can’t debug as easily in Visual Studio .NET 2003 (but the 2005 version fixes this).


There will always be “Elevation of Privilege” attacks, sure, but the answer is not to give up on separation of privilege completely.  It’s tricky to right code to use least privilege, because you constantly have to think “what access do I have to this object, and what access do I need?”  Again, that’s no excuse for doing the wrong thing.  Any time you see a company whose software insists on unnecessarily running as administrator, think to yourself “I’m running a tool that is written by people who haven’t learned anything new since at least 1995”.

Programmer Hubris Part 2: I’ll get you, and your little dog, too.

Apple’s QuickTime (for Mac & Windows) vulnerable to flawed images.


Great – hot on the heels of a WMF vulnerability (“why does Microsoft keep having buffer overflows when the rest of the industry doesn’t?”), we get a TGA/TIFF/QTIF/GIF/media-file overflow vulnerability in QuickTime – the warning seems almost designed to get lost in the noise surrounding Microsoft’s regular updates – but that would be a cynical view.


When I visited the page referenced above, which is at Apple’s own site, I could not find a link to the patch, or to download the current version of QuickTime for Windows.  I’ve been doing this “computer thing” for a couple of decades now, and so has my cube-neighbour, who went looking for it as well, without success.  [Hopefully Apple will read this, and edit the page so that by the time you read this, the link is prominent and obvious, but if you can’t find it, read on…]


You can find the current version of QuickTime for Windows at http://www.apple.com/quicktime/download/win.html


<PThere are a number of disadvantages to this link, though:



  1. This is a full replacement, not a patch.
  2. The site does not say whether you are downloading the fixed 7.0.4 version, or an earlier version with the flaws still in it.
  3. The download includes iTunes, and while I can imagine QT to be necessary to view, say, presentations from vendors, iTunes is definitely not necessary for our corporate use. Nor do I want it for my personal use.
  4. The download file is called ‘iTunesSetup.exe’, and its version information declares it to be the setup program for iTunes – no mention of QuickTime is made here.
  5. Even after downloading the setup executable, you cannot tell what version you have downloaded without running it first. The version number on the setup file ‘iTunesSetup.exe’ is 6.0.2.23
  6. The setup program goes through a few unpacking steps before aborting if you are not an administrator, so a restricted user cannot tell if this is the current 7.0.4 version of QuickTime.
  7. If you only want QuickTime, you have to install iTunes and QuickTime and then remove iTunes. The installation itself doesn’t require a reboot – but removing iTunes does. So, effectively, if you want to install QuickTime, you must reboot, or you must accept iTunes.
  8. At no point in the installation are you told what version of QuickTime is being installed.

Finally, yes, the version of QuickTime at the Apple download link is 7.0.4, which is supposed to include the patches against remote exploit through image vulnerabilities.


The main thrust of this rant has been that this is really not so useful in terms of a security update – but there’s a subtle theme throughout – in order to get a tool that I want, I have to install and then remove a tool that I don’t want.  Bundling is a fine tradition – and if Apple was to bundle QuickTime and iTunes such that iTunes was required, I’d simply refuse to watch .mov files.  But this method of bundling – requiring it be installed, but allowing uninstallation afterwards – seems to be more like punishing people who want to view QuickTime format movies.

Programmer Hubris Part 1 – He’s Just Not That Into You

Programmers are, by nature, a very arrogant bunch. We know this – and it comes from the nature of what we do. In our own little world inside the computer, we are a god.

For this reason (and perhaps a few others), it becomes very easy for us to forget to think outside of our little world, and remember that we are also acting as servant to the people that own the box we’re writing our software for.

This is particularly true of developers of off-the-shelf software, who spend next to no time actually dealing with the people that use, or will use, their programs.

So, I’m going to start a topic on the arrogance of developers.

My first example is multiple – Real Networks, Apple Quicktime, and several other programs insist on placing their icons on the system tray – down in the bottom right-hand corner, with the clock.

Now, if these were just icons, that would not be such a bad thing – after all, your system is littered with icons that represent shortcuts, data files, executables, and so on.

Unfortunately, the icons in the system tray are special. Each one represents a running program. Each one is placed there by a programmer who believes that his or her program is so important to all users that it should remain permanently running.

Me, I play a Quicktime Movie, or a Real Audio file, about once every couple of months. It can be a month or more before I notice that the icon is on my system tray, taking up time, communicating who knows what, and exposing goodness knows how many application-related flaws to the Internet.

So, a plea to developers – unless your software positively requires to be run all the time in all its possible installation modes, make it go away when I’m done using it.

No offence, but I’m just not that into your program.