Free software and malevolent code [LWN.net]

The CEO of Green Hills Software, a proprietary embedded software company, has sent out an amazing press release on how the use of free software in defense systems "violates every principle of security." The PR tells us about how "developers in Russia and China" are contributing to Linux, and the horrible fate that awaits us:

Linux in the defense environment is the classic Trojan horse scenario -- a gift of 'free' software is being brought inside our critical defenses. If we proceed with plans to allow Linux to run these defense systems without demanding proof that it contains no subversive or dangerous code waiting to emerge after we bring it inside, then we invite the fate of Troy.

The strident tone of the release, combined with the focus on threats from Russia and China, makes it look like something from the Reagan administration. It's hard to take this thing seriously.

The press release has been quickly written off as a desperate outburst from a proprietary company that is losing business to Linux. And that is probably exactly what it is. It would be interesting to hear how Green Hills would explain this Cisco security alert which came out on the same day as the anti-Linux press release. Some of Cisco's products, it would seem, were shipped with a back door which gives attackers full access; "there is no workaround." It is also worth noting that the InterBase backdoor existed in the proprietary product for years, but was discovered when the product went open source. The remote shutdown "feature" found in a number of software products is also relevant here. Proprietary software is not immune to backdoors and Trojan horses; indeed, the opaque nature of closed-source programs would seem to encourage that sort of misfeature.

Another point worthy of note: attempts to place back doors in free software have mostly been carried out via the distribution network. Last year's kernel backdoor attempt tried to slip the code in after compromising a CVS server. Trojan horse attacks on tcpdump, sendmail, OpenSSH, and others have worked by corrupting distribution files, again via a compromised server. On the other hand, it is very hard to find any record of an attempt to insert any sort of back door via the free software development process. Such an attack, it would seem, is not that easy to carry out; if it were, why would attackers prefer direct assaults on infrastructure and distribution files - an approach which is certain to lead to quick detection?

The free software development process is, perhaps, more robust than its detractors would have people believe. But, once we're done patting ourselves on the back (and let's not be too long about it) we have to face a fundamental fact: code containing security vulnerabilities is committed to project repositories every day. These vulnerabilities do not result from deliberate attacks; they are, instead, simple bugs. But they get into the code base, despite our heavily promoted review process.

It is also true that, sooner or later, somebody will certainly attempt to get bad code accepted by a free software project. That code may contain a back door, or it may be one of those "intellectual property" violations that some people would so dearly love to find in Linux. Given that we prove on a daily basis that insecure code is able to survive our development process, how confident are we, really, that we'll trap a deliberate, well-hidden hole? There are reasons to believe that our processes are better than the proprietary variety; at least some outsiders are looking at the code, and the chances that a backdoor will lurk for years are small. But we cannot simply write off this threat; sooner or later, it is going to come back to us.

(Log in to post comments)

Free software and malevolent code

Posted Apr 12, 2004 23:31 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]

The FSF approach to this problem is to require copyright assignment, as well as an employer disclaimer in cases where the company does not hold the copyright. This, together with change-log information naming the originator of each bit of code, makes it quite likely that an attempt to introduce malware or to plagiarize from someone else's copyrighted work can be traced back to the source.

Some object to the requirement to assign copyright to the FSF, and that's not really a vital part of the process from a security point of view. However, other high-profile projects would be advised to cover their legal asses by at least insisting on some legal paperwork from contributors, and their employers where appropriate, authorizing the distribution of their contributions under the GPL or whatever license the project uses.

People might not appreciate that if some US grad student submits a really cool new scheduler to Linus without getting permission from his department, serious legal trouble could result. That's because many US universities are now trying to squeeze out additional money by patenting their research and licensing it, and if the grad student is getting paid even a pittance by a CS department, the department might be able to claim the patent rights (and force Linus and everyone else to rip it out of the kernel). That's why the FSF insists on employer disclaimers even from students.

Free software and malevolent code

Posted Apr 13, 2004 1:57 UTC (Tue) by mbp (subscriber, #2737) [Link]

The FSF is probably right; at any rate theirs is the safer course. However, it comes at a cost of delaying or discouraging contributions.

It is certainly very wise to insist on contributions containing copyright notices and (on new files) the three-para GPL header. I do this for my projects. When people send large changes without copyright, I tell them to add it.

I am not a lawyer, but I think if someone sends me a file where they claim copyright and they offer a licence to use it, it's reasonable for me to believe them. If someone claims copyright to work their employer owns then that is primarily a problem between them and their employer. Likewise if they release code their employer didn't want to release. If it turns out that they lied then as you say I might need to reverse the patch. I don't think it would be wilful infringement.

If I accept a thousand patches and it turns out that one of them was bad and must be removed, then I'm still ahead. That seems to be Linus's strategy.

malevolent code

Posted Apr 13, 2004 9:54 UTC (Tue) by The_Flatlander (guest, #19245) [Link]

I agree, (indeed the evidence is overwhelming), that bugs get introduced to source code, be it free and open or closed. I submit, however, that actual malevolent code, as *source* is not trivial to insert. And on that notion hinges part of the problem with Green Hills' stupid statement.

Source code is not magic. It is a near-human language form of what we programmers are asking the computer to do. Yes, it can be written such that it is so far from human language that it is unintelligable. The Linux development process tends, (based on the practice so far), to reject code that can not be easily understood. Is the review process perfect? Maybe not. But this is beside the point inasmuch as closed source gets far less review. And code review is the only currently known answer, I believe.

Against the sort of attack Green Hills describes, Green Hills' own software is far, far more vulnerable than Linux ever had a chance to be, because the number of Green Hills reviewers is smaller, (unless Green Hills is much larger than I understand), than the number of Linux reviewers.

Ken Thompson's back-door, mentioned by Green Hills' CEO, was inserted through closed-source software. Sure, in the end it could compromise even open source, but it started with closed source. Today, we need never start with a closed solution, since there are so many open source compilers available. So Thompson's exploit, while interesting and clever, need not concern us over-much.

Further, even though Windows source remains mostly a secret the script-kiddies and spammers seem to have no trouble at all coming up with expliots. One wonders how they do that. Could it be they just start hammering away at a given port/service and see what breaks? I do not spend much time at that particular sport myself, but I have always assumed that people are out there, even now, trying to break into Linux. When they succeed we hear about it; and the patches are available almost instantly.

Green Hills' FUD only helps Linux, because logical fallacies are not effective long-term sales techniques. And this particular one will backfire so fast it won't even look good in the short-term.

I believe open source operating systems, are our best, and only hope, of having secure systems.

</rant>

The Flatlander

malevolent code

Posted Apr 14, 2004 21:41 UTC (Wed) by bhurt (guest, #3281) [Link]

You say:

Further, even though Windows source remains mostly a secret the script-kiddies and spammers seem to have no trouble at all coming up with expliots. One wonders how they do that. Could it be they just start hammering away at a given port/service and see what breaks?

It's not that difficult to reverse engineer binaries- anyone with a halfway decent understanding of assembler and a disassembler can do it. And I know of at least one disassembler shipped with every linux box- objdump -D. NASM's ndisasm is also nice. Others are kicking around. The dirty little secret of software engineering: simply because you've hidden your source doesn't mean I can't figure out how the code works.

I comment that these tools are usefull even ignoring their "illegitimate" uses. I routinely disassemble my own source code just to see how the compiler handles various constructs.

Ken Thompson's back-door, mentioned by Green Hills' CEO, was inserted through closed-source software.

If this is what I think it was (insert a backdoor in the ur-C compiler to add a backdoor to Unix), I wouldn't worry about it. At all. Consider for a moment what would be required for that initial backdoor. It'd have to recognize that it was compiling a compiler, and correctly insert itself into the new compiler without breaking the new compiler. And not just C compilers, either, as people write C compilers in other languages. I think IBM's xlc for AIX/POWER is written in PL-8, for example- so this backdoor would have to recognize that it's compiling a PL-8 compiler, and modify it so it recognizes that it's compiling a C compiler so it can modify that so it can recognize it's compiling Unix and insert the backdoor. And remember that it has to recognize compilers and Unixs for and on platforms that hadn't been invented yet. Failure to do this means all we have to do is cross compile a compiler to some new architecture, and then over on the new architecture cross compile back. Viola- no more backdoor.

At this point, even the people wearing tinfoil hats are starting to have doubts. Even the grays themselves would have a hard time pulling this off. And I think those of us who disassemble our own code would start noticing something odd- unless of course your backdoor also recognizes that it's compiling a disassembler, and inserts code in the disassembler to stop it from displaying the backdoor code...

Pardon me- there are some men in black at my door. Be right back...

malevolent code

Posted Apr 15, 2004 3:49 UTC (Thu) by mbp (subscriber, #2737) [Link]

Nice point.

You can now compile the Linux kernel and some other software using Intel's proprietary icc compiler. So even if somebody had inserted a trojan into gcc binaries, it could be disabled by rebuilding gcc with icc. Assuming you knew it was there...

It's not out of the question to audit the assembly of the most security-critical programs. (In Richie's case, the login program.) I might do that if I worked for the NSA and had semi-infinite public funding.

malevolent code

Posted Apr 15, 2004 4:05 UTC (Thu) by iabervon (subscriber, #722) [Link]

I'm personally not worried about anything intentionally bad getting into
a mainline Linux kernel. There is a good review process by a lot of
really skillful people in place, which is likely to catch most anything
that isn't extremely subtle, and the kernel's level of clarity continues
to improve, such that subtle issues are more and more obvious.

I'm actually somewhat worried about the GNU tools, however. The coding
style is much less clear, there is a whole lot of special case code,
there is a lot that isn't documented these days, and a lot of library
functionality is replicated in programs. I've personally made a change to
code that most LWN readers run as root, and the ChangeLog entry about it
gives little evidence that the maintainer really understood the
correctness of the patch. And I'm not surprised; the surrounding code
contains comments which are wrong, and structure members which are reused
for undocumented purposes in the case I cared about. I don't think it
would be possible for someone to introduce a serious problem with a patch
of the brevity of mine (which switched the order of two tests, neither
introducing nor removing code), but it probably wouldn't take much more.

Free software and malevolent code

Posted Apr 13, 2004 17:03 UTC (Tue) by Ross (subscriber, #4065) [Link]

They can find _some_ of those. If they find all of them then they will be
reporting more false positives than anybody would care to sift through.
There's no need to purchase commercial products as there are plenty of open
sourced products with similar features. This goes way back to lint (lclint
is a freely distributable version). There's FlawFinder, and I think that
the smatch tool was even mentioned in reference to this article.

Free software and malevolent code

Posted Apr 13, 2004 17:51 UTC (Tue) by scripter (subscriber, #2654) [Link]

I wasn't specific enough: These new tools have a low rate of false positives. They are FAR better than flawfinder, RATS, etc. I know -- I use the free tools, and I've tried the commercial ones.

Free software and malevolent code

Posted Apr 14, 2004 0:12 UTC (Wed) by lakeland (subscriber, #1157) [Link]

So... which one should I buy? :-)

Free software and malevolent code

Posted Apr 14, 2004 15:38 UTC (Wed) by scripter (subscriber, #2654) [Link]

As of today, the Coverity tool is better, although it is limited to understanding C code (no C++). Later this year, both tools should be much farther along.

Free software and malevolent code

Posted Apr 14, 2004 20:06 UTC (Wed) by lakeland (subscriber, #1157) [Link]

Cool, thanks

Free software and malevolent code

Posted Apr 15, 2004 3:59 UTC (Thu) by mbp (subscriber, #2737) [Link]

Mr Ranty does make one possibly-valid point:

"Linux software, including contributions from Russia and China, is spreading rapidly through the Defense Department because it can be freely downloaded from the Internet without a license agreement or up-front fees, bypassing legal, purchasing and security procedures."

Downloading random software onto mission- or security-critical systems is just a pretty dumb idea regardless of the country of origin or licensing conditions.

A banner on another news site offers me Windows download to show a pretty girl on my taskbar: even if it's written by good old Americans I would hope it's not going to get installed on any air-traffic control computers.

Saying that Linux is more likely to be installed because it doesn't need a licence agreement is a furphy. Plenty of people download commercial software by either putting it on a credit card or getting a trial edition. Or for that matter getting a pirated copy, opening up even more risks.

So: defense employees should not install random stuff on their computers without having it checked and approved. Thankyou very much.

about the covert cisco backdoor account

Posted Apr 15, 2004 23:36 UTC (Thu) by stock (guest, #5849) [Link]

In 1988 The name Echelon is defined : "Eavesdropping on Europe" [wired.com] :

October 1998 : "In October, Europe's governing body will commission a full report into the workings of Echelon, a global network of highly sensitive listening posts operated in part by America's most clandestine intelligence organization, the National Security Agency."

"British investigative journalist Duncan Campbell was the first to report about Echelon in a 1988 article in The New Statesman. He believes that there is a very thin line between intelligence gathering and commercial espionage."

Wasn't that the guy who was put behind bars by the British Queen?

Some time ago Cisco announced IOS was highly vulnerable to hack attacks, so they said : "download new fixed IOS version today!" But didn't they announce a press release that future IOS releases would contain FBI Fed hookups?

The story on that is here : "More on Cisco Building Surveillance into Routers" [slashdot.org] and "Inside Cisco's eavesdropping apparatus" [news.com]. They talk about Eavesdropping 'must be undetectable, and such. Well now! Not so long ago a customer wanted a more powerfull cisco router, basilcy going from a 1603 to a 2600 series router.

We already had a cisco 2610 running which has 64 MB RAM in its default configuration. I checked but only the cisco 2610XM was avaliable (now 6 months ago), which highly interesting has 128 MB in its default configuration. The best part was, that a brand new cisco 2610XM at cisco's was even cheaper in price as the older cisco 2610, which cisco didn't sell anymore, but was only available on ePAy or refurbished cisco resellers.

Robert

Rigth and wrong

Posted Apr 20, 2004 20:15 UTC (Tue) by ekj (guest, #1524) [Link]

If we proceed with plans to allow Linux to run these defense systems without demanding proof that it contains no subversive or dangerous code waiting to emerge after we bring it inside, then we invite the fate of Troy.

That is actually sensible. We should indeed demand proof that security-critical programs are written in a secure manner, and that they do not contain malevolent code, backdoor or similar.

But he's shooting at the wrong target. The typical open source project comes with *much* better such proof than the equivalent proprietary one. Lots of people from all over the world has looked at it and messed with it, none of them has noticed anything untoward. If that's not enough to satisfy your requirements you're free to hire any number of independent review-teams to do review according to whatever standards you require.

With proprietary stuff it's frequently different. Often the only "proof" you've got is that some company, with a financial interest in saying so, says that the sofware is secure. You're not allowed to check it out for yourself, you're not allowed to have an independent third-party check it out on your behalf, and you most certainly are not allowed to let the software undergo free and open peer-review.

So he's delivered a pretty convincing argument why proprietary software should be avoided in any setting where security is paramount.