Gallery

Your printer vs the hackers

Posted on 18 Jun 2009 at 11:26

Steve Cassidy has never seen a furore like that caused by HP's admission that networked printers retain hackable documents.

I don't think I've ever seen such a furore over a simple statement before. Hewlett-Packard's security announcement admitting that its networked printers retain the last few documents printed - and that these can be retrieved by skilled network hackers to read at their leisure - seems to have struck a deep chord. I'm getting emails from worried business owners and small network-support companies. This announcement has even flushed out a few one-man "circuit-riders" from their usual habitat (that's the chic industry term for guys who spend a day or less a week traversing the "circuit" of companies they support). Everyone wants to know what to do and from the emails, forum and blog posts you'd think this is a security breach on a par with the Russians getting into our banking system. Let's take a look at the issue from the ground up.

Step one is simple enough - any networked printer (and HP is only one of about 20 brands that offers networked printers) contains a very small brain that handles the process of receiving a stream of bytes from the network and throwing them onto paper. This brain may not be terribly sophisticated, but at least it's well behaved when compared to the dog's breakfast that's been created by combining Microsoft's manky Windows spooler process with over-developed, bling-heavy vendor printer drivers. I'm shocked by the number of sites I visit where printing is still arbitrated by a central server, with workstations connecting to a shared printer queue for access. This might have the redeeming feature that you can see who else is printing and when their jobs have run out of paper or otherwise messed up your own job, but these days it's quite unusual to find any team - be it a small firm or just a division of a large corporation - where sharing a printer is not a matter of face-to-face negotiation anyway, so that the centralised spooler queue display COM interface becomes more of a source of irritation ("why can't I delete that silly woman's job from the queue? Mine's more important!") than a facilitator of workflow.

Yes, thanks chaps, I do know about setting up queue operator status in Active Directory: that's one of those richly-textured office politics nightmares that I find almost impossible to write down on my timesheet and therefore to charge money for proposing. It's far safer to treat your users as guilty until proven innocent, and not give them any local administration roles at all. I know what the traditionalists will say, too - all this security nonsense wouldn't be a problem if only people bought a cheap printer and hooked it off the back of the PC or the server, with USB as its only link to the network. Here we're teetering on the verge of a generation gap, where the young folk are seduced by concepts such as "web printing" - an initiative to connect printers more via HTTP than any other protocol - while the oldies among us reminisce pointlessly about LPT port capture using TSR drivers. The thing is, both the old and the new capabilities simply shuffle the underlying problem around from pillar to post.

The problem is that printer drivers are intrinsically untrustworthy - not from a security perspective, but rather from an OS-stability perspective. It's true that putting a centralised printer driver installation onto your server means that whenever an update arrives, you have to put it up only once. However, after that update is applied, any crash will take out every PC and the server they're connected to, which is hardly a desirable state of affairs.