The Ptech Incident [LWN.net]

[Editor's note: this article was contributed by LWN reader Tom Owen.]

Federal and state agents who visited Quincy, Mass. software house Ptech last week were probably mostly looking for financial links to al-Qaeda. So perhaps it's just an unfortunate co-incidence that by Wednesday morning the Ptech customer list had been removed from their web site. It was still cached at Google, though, and the names on it are a testament to the lure of the product and efficiency of the Ptech sales team. How happy the US Air Force, NATO, Mitre and the FBI are to discover that their knowledge management software comes from a firm under such detailed investigation has yet to emerge, but officials for the White House and the US Attorney in Boston have certainly been quick to say that the software presents no obvious risk. Which raises the question: how do they know?

Sensitive government and defense agencies probably won't load their operational information on to a knowledge management system without some sort of scrutiny of the software. There's no need for an Open Source license -- any client with sufficient clout can cut a deal for source access. The trouble is that a $1000 per day security consultant, faced with half a million lines of Visual Basic and a non-disclosure agreement, is going to need extraordinary powers to find twenty lines buried in, say, user management, which phone home with a document index. Source access or not, it still comes down to trust, of the company and each individual developer.

A true open source project is a very different matter. It's not possible to fool the whole developer community -- a secret like that just won't keep. It might be possible to corrupt individuals, and it's certainly possible for terrorists to join and contribute code. But the bent code is there for all to see, and the folks reading it are developers intimately familiar with the purpose and structure of the system. A trapdoor or a leak is still possible, but it's much more likely to be spotted.

Wired quotes Michael Wendy of the Initiative for Software Choice:

"It's important to note that a development model is only a process," Wendy said. "It does not guarantee, in and of itself, that a product produced under one type of model will be any better than another product produced under a different model. In other words, no single development mode inherently produces safer, more secure software."

It's not bad for a first try, but the ISC will have to do better than that.

(Log in to post comments)

The Ptech Incident

Posted Dec 12, 2002 6:02 UTC (Thu) by proski (subscriber, #104) [Link]

I believe that the quoted comment by Michael Wendy makes more sense than the LWN story. Even if those "half a million lines of Visual Basic" were released under an Open Source license, that would not make them significantly more secure any time soon. If the "good guys" are not interested to read that junk, who is going to find the wholes?

The question boils down to the definition of Open Source methodology. Is it just having an OSI approved license or using specific procedures to guarantee that the code will be sufficiently reviewed?

I haven't seen any document describing how an Open Source project should be maintained, how the contributed code should be reviewed and what criteria should be met to call the code stable or secure. If we consider for example GNU Coding Standards, it has a different objective, namely to guarantee that the code remains free and that it's not obfuscated, so that the modifications and even code forks can be made easily when the need arises.

One could argue that unmanageable code could not be written by independent developers. While it's probably true for the aforementioned "half a million lines of Visual Basic", I've seen a lot of Open Source projects that a poorly written and very hard to understand, especially when the code has no comments or unhelpful comments, like "that's ugly, I should really do it right some day".

Open Source projects differ wildly in their quality. Neither the license not the number of contributors are defining factors when security of the system is at stake. If the software was written without security in mind, it should not be trusted, whether it's Open Source or proprietary.

While openness of the source code is important to examine its quality and the development process throughout the history of the project, one should not expect being Open Source per se to ensure software quality, stability and security.

The Ptech Incident

Posted Dec 12, 2002 8:07 UTC (Thu) by Mithrandir (subscriber, #3031) [Link]

> I've seen a lot of Open Source
> projects that a poorly written and very hard to understand, especially
> when the code has no comments or unhelpful comments, like "that's ugly,
> I should really do it right some day".

Do you really beleive that security-concious organisations would let this cruft anywhere near their mission-critical systems? On the other hand, I'd feel _much_ safer with well-written open-source code than closed-source code that could be of _any_ quality; you just don't know.

The point is that OS code is the ultimate in full disclosure. It _can_ be good, and you can know if it is or not. And it _can_ be audited. With closed-source, you just don't get the option.

> Open Source projects differ wildly in their quality. Neither the
> license not the number of contributors are defining factors when
> security of the system is at stake. If the software was written
> without security in mind, it should not be trusted, whether it's
> Open Source or proprietary.

Yep, that's fine. Who was saying that it should be? And there is plenty of OS code that IS written for security, and again, I would argue that it's just that much more trustworthy. PGP gives me the creeps. GPG doesn't. Go figure.

The Ptech Incident

Posted Dec 16, 2002 5:56 UTC (Mon) by proski (subscriber, #104) [Link]

Do you really beleive [sic] that security-concious [sic] organisations would let this cruft anywhere near their mission-critical systems? On the other hand, I'd feel _much_ safer with well-written open-source code than closed-source code that could be of _any_ quality; you just don't know.

I just found the following piece of code in the source of GNU Midnight Commander. This software is distributed by almost every [GNU/]Linux distibution, including Red Hat. I'm sure that some "security-concious organisations" are using Red Hat, not some obscure "hardened" distribution.

/* This function is really broken */
int
mc_chdir (char *path)
{
    char *a, *b;
    int result;

There is no comment about what that function does, only a comment that it's broken! And that's not an exception, it's a pattern.

The real question

Posted Dec 20, 2002 17:17 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link]

Dear Proski-san:

Sorry for the tardy response---I've been distracted lately...

You noted:

I just found the following piece of code in [a Free Software app]
[...]

/* This function is really broken */ int mc_chdir (char *path)
[...]
There is no comment about what that function does, only a comment that it's broken! And that's not an exception, it's a pattern.

To which I must agree. Unfortunately, in most of the proprietary code I've seen, either the same comment/lack of comment can be found, or the comment is omitted because the coder is ashamed to say so in public. Only in work I've done for life-critical systems have I ever seen the development process rise above this level as company policy.

But on what basis can you assert that this isn't also the case for any given chunk of proprietary software? The point isn't ``Can some Free Software be bad?'', it's ``Is this piece of proprietary software good?''

We can have no knowledge which allows us to assert that one particular proprietary application is any better than another. With Free Software, you can at least see and avoid the bad examples.

--

Best wishes,

Max Hyre

The Ptech Incident

Posted Dec 14, 2002 3:16 UTC (Sat) by taro (guest, #6163) [Link]

Even if those "half a million lines of Visual Basic" were released under an Open Source license, that would not make them significantly more secure any time soon. If the "good guys" are not interested to read that junk, who is going to find the wholes?

Just releasing it for sure won't make them more secure, or bring any other open source benefit. Closed source code that's moved to open source -- Mozilla? openoffice.org? -- seems to need a year or two in the chrysalis before emerging even as brown hairy moth, let alone a butterfly. It takes that long to gather interest and familiarity, and then to fix the grosser horrors. And, yes, if it was visual basic source there's a likelihood that the interest would never happen. Open source can't do much for a project that no-one cares about. The eyeballs aren't there. And nobody who minds their security will use code from an inactive project except as the basis for a re-write.

So, why do I claim that an open source project is likely to be more secure against source backdoors? I agree it's almost nothing to do with the licence.

The build and version control has to be robust. Many proprietary development shops would have trouble delivering source and instructions in a form that would build on any host other than than their own compile engine. With Open Source the security auditors know that the code they review is the code they'll be running, and is the code the developers wrote. They can find and take extra care with the changes that went in the days and hours before the release.
Those eyeballs. They're real. Few people, often none, reviews the whole system, but co-operative devlopers do read the code they interface to: it's quicker and less disruptive to resolve questions that way than to bother the developer. That situation is different if you expect to find him at the water cooler in five minutes.
The developers are volunteers. There's no penalty for nosiness. More eyeballs.
The risk of exposure is greater. Open source systems care less for their reputation. The dodgy hacks of a dodgy coder will be exposed and puzzled over on the lists. A proprietary shop will likely want to pay him off under ND, clean up as best possible and pray that no-one tells the customers. If he fears arrest, the terrorist will prefer to pervert an open source project he can join under a pseudonym from a safe location, but if he's making clandestine preparations he would prefer the second outcome: his motive remains secret and it lets him try again.

There's more to say on this. I have to be a bit more cautious about projects where one developer is central -- I think they undermine my view.

The whole cyberwar/terrorism thing is one of the ways that it's easy to get far fetched when discussing security risks. It's a question of the effect/resources/danger balance that potential cyber-aggressors face. Coming back to Ptech, it's a bit unlikely that someone will set up a well capitalised software firm and then spent eight or nine years developing software which has obviously found a good market, on the off chance of getting a trojan into government offices. However, as a money laundry and source for visas, banking counterparties etc., it's got obvious potential, and that's after all what the feds said they were after.