Initech's latest offering, IniPrints, was a secure automation system for document management. The target audience was the banking industry, which meant that the system was sold as having robust and fine-grained role-based access control systems. As far as any one could tell, that was exactly what Initech was shipping, which meant IniPrints gained a reputation within IniTech as being a "good product", with "low maintenance".
When Alan was assigned support on IniPrints, he expected it to be pretty quiet. So he was surprised when three of the veterans of the project, Carole, Larry, and Arthur desceded on his cube with grim tidings.
"We've got some concerns about IniPrints. You should probably take a deeper look at the code."
With that ominious warning, the Fates vanished back into the cube farm. The trio had migrated from development to technical sales support roles, which meant they mostly interacted with customers anymore. They were not to be any help to Alan when it came to understanding the software.
Unfortunately, neither was the documentation. There was none in the code, none in the commit history, and the code itself was incomprehensible. There was one Word document which was meant to be "the documentation", but it was less clear than the code. When Alan complained about the lack of documentation, his request eventually got back to the Fates, who replied: "check the big red filing cabinet for a hard copy of the documentation".
Alan found the hard copy: it was the same incoherent Word document, printed out, and decorated with a series of coffee stains which did nothing to make the meaning more clear.
Alan did his best to understand the software anyway. When it came to roles, it shipped with two roles: User and Manager. These two roles were used in the sales demo, and 99% of their customers never dove deeper into the security model than that. Those two roles worked perfectly and had well understood behaviors.
Unfortunately, the Fates had just landed a contract with a new bank. And this bank was in the 1%- they needed a role-based access control system with much more advanced functionality. That's what IniPrints claimed to have, but the reality was different.
The bank sent them a pile of security issues. Alan was the one person doing support, which meant Alan needed to triage and prioritize. He grouped the issues into four categories:
- Works as designed, documentation needs revision to make the function clear to the customer
- Works as designed, but the design needs to be amended
- Actual implementation defect, but one that can be fixed with a small patch
- [incoherent screaming and profanity]
There were a handful of issues in the first group, and shockingly only one in the last. But groups (2) and (3) had enough work for an entire team. Still, Alan dove in and started checking them off. The Fates went back to the client, smoothing over the problems and making promises about what the future would hold. With each issue Alan fixed, the customer got calmer about their needs… until there was only one issue left. The category (4) storm of crap.
The specific problem was that this was an automation system. It was scriptable, and those scripts logged out the commands being executed. Unfortunately, the part of role-based security that controlled access to the logged messages didn't work. Any user, including unprivileged ones, could read those logging messages. And, due to the messed up architecture of the whole thing, it would require a ground up re-write of the entire logging engine to fix.
So Alan communicated back to the client, through the Fates: "This would be a pretty massive upheaval. Could I have more information about why it's required? There may be a better way to meet the goal."
The Fates did their best to get that information. Management got involved, and generally did get the sense that "well, this is a lot of work for only one customer, but they're a very BIG customer." The customer kept trying to raise the severity of the issue, claiming that simply logging the commands executed was a critical security vulnerability.
Eventually, this escalated to a video conference. The bank's security team, including everyone from the CSO all the way down to a junior analyst was on the call. The Fates were on the call. And Alan, of course, was on the call.
"Could you tell us," Alan said as diplomatically as possible, "what exactly makes this use case so important to you? The easiest fix might be to perform some sort of transformation on the data we're logging, like filtering standard-in or something."
The bank security team sat in an uncomfortable silence for a long moment, before the CSO said "It's just surface area that shouldn't be exposed."
"Right, but we didn't design the system to support this. It's just a log of commands executed and some informational output, so it shouldn't contain anything confidential. I understand that it's not ideal, but we're not logging out passwords or anything, right?"
Alan laughed at his own joke. The bank's security team sat in silence. The silence stretched out to a length beyond awkward.
"Right?" Alan asked again.
It was the junior analyst who caved. "Almost all of our commands take clear-text passwords as arguments." The CSO stared daggers at the junior analyst, but the junior analyst didn't care- they were pleased to have confessed their sins.
The Fates also relaxed. Arthur, especially, looked pleased. "Ah," he said, "our documentation celarly states that nothing confidential should be contained in the input scripts, specifically because of this risk. This is no longer a critical issue, but we'll keep it on the backlog for a potential future release."
"But we need this," the CSO complained.
"It seems like you need to re-evaluate your password handling," Carole said.
"In any case, is there anything else on the agenda for this call?" Arthur said. "No? Larry can document our findings and follow up in email. Thanks Alan, for your time."
This post originally appeared on The Daily WTF.