When customers try to be programmers: 'I want this CHANGED TO A ZERO ASAP'

Line Break Welcome to the first proper installment of Line Break, the weekly column in which Reg readers share truly horrifying code they've seen in the wild.

We started you off last week with a pilot episode involving some close encounters of the absurd kind – and we've had fantastic responses from Vulture fans, which we'll roll out over the coming weeks. If you want to pitch in your tales and source code snippets, just fire off an email in this direction.

Trust me, I'm the expert

Let's start with this tale from Nick, who had to deal with a frightening form: the ex-programmer-turned-customer.

In IT support, we have an adage that there's no customer so unpleasant and dangerous as someone who used to be a programmer at the company, who has moved on and then ends up calling support in their illustrious new role as a 'consultant' for some other company, a customer of the first.

They're arrogant, they think they know it all, are unsympathetic to newbies, know how the internal support systems work, know the escalation procedures, and as such know how to shout and skew the support in favour of themselves.

Now, understand that we used to customize our product for individual customers, so we maintained a DAT tape of the source code specific to each customer. This means the source code files might be quite different from one customer to the next.

So I get a call from a hot-shot know-it-all wanting a "bug" fixed:

"I'm sick of calling in to get this code changed. I used to program there, you know, and I can tell you the bug is at line 345 in processac.c. There is a 1 there, instead of a 0. I WANT THIS CHANGED TO A ZERO ASAP. It is the obvious source of this bug. Maybe you should employ some decent developers for once."

So I get the DAT tape out and un-cpio the code. I open the file in question and go to line 345, and find a comment, which, of course, is stripped out of the compiled binary. This read:

/* To whom it may concern.  You will find, over the coming months, years or decades that some idiot will call up and demand that the 1 below in the code is changed to a zero. DO NOT UNDER ANY CIRCUMSTANCES DO THIS. These people are morons. They are fools of the first order. If this number is changed, it will appear to fix a small glitch in the short term, but will wreak havoc long-term with this company's accounts and payroll data, leading to catastrophic data corruption that will be impossible to undo, and, I wager, when it happens, lead to the downfall and insolvency of the company concerned. YOU HAVE BEEN WARNED. */

So I show the code comment to my boss. He shrugs his shoulders and says:

"Well, go do it – it's what the customer wants..."

Nick tells us the company in question, true to the source code comment's warning, is no longer in business. Lesson: Customer is always right.

I'll do whatever you say

I'll tell you what isn't always right, and in fact is never right: passing commands directly to a CGI script from the URL. Owen tells us he once spotted this link in an organization's web app that cleaned the software's cache:

<a href="https://www.example.com/admin?action=rm%20-rf%20/tmp/cache">Clear Cache</a>

Your jaw hit the floor, too, huh? That's a rm -rf /tmp/cache being passed directly to the server to execute – so if you wanted to execute arbitrary commands, just change the string to whatever you want.

"Instead of just linking to a clear cache action on the backend, the backend server would just take commands on the query string and execute them," Owen explained.

"To make it worse, the server was running as root, as was running on port 80 without an Apache in front, and so you could change the link to execute any command on the server as root."

Lesson: Don't run web apps and servers as root, and more importantly, don't pass commands directly to the operating system to execute. Sanitize inputs, and make the user send a request string or object, which should be used to look up which action needs to be taken – then you, the programmer, are in control of the action, not someone randomly walking in off the internet.

Nothing succeeds like SUCCESS

OK, let's finish on a lighter note. Jonathan writes in to say:

The most annoying issue I ever ran into was a section of code, and we could not work out why it would not exit the loop when status stopped being SUCCESS. It was something like:

  int SUCCESS = 1;
  int status = getStatus();
        
  logger.debug("Got Status:" + status);
  while(SUCCESS) {
    //Do all the clever things
            
    status = getStatus();
    logger.debug("Got Status:" + status);
  }

"I'm ashamed to say this took a good week and two engineers to work out," Jonathan added. Lesson: We'll let you work this one out, if you haven't already spotted it.

More next Wednesday: keep your submissions coming in, please. We love to hear from you. ®

Click here to see all Line Break columns