June 2003

June 2003; Volume 4, Number 5
Loose Lips Sink Ships

From SARS to Mars

The Whiteboard

DARPA quietly cuts OpenBSD's funding, but the secure OS still sails.

This is a tale of two stories: First, making the most news, is the April 21, 2003 cancellation of Defense Advanced Research Projects Agency funding for the remainder of the OpenBSD project's contract through the University of Pennsylvania for its work on secure operating systems; second, and less-noticed, is the May 1 release of OpenBSD 3.3. While the first story has all the right elements—politics, free speech and military intrigue—there's no smoking gun. Meanwhile, the second story received cursory attention, though its impact is likely to be extensive.

The Quote that Ended It All
"I actually am fairly uncomfortable about [the DARPA funding] ... I try to convince myself that our grant means a half of a cruise missile doesn't get built," Theo de Raadt, OpenBSD's 35-year-old founder, told Canada's Globe and Mail newspaper in late March. Just a few days later, funding for the project's annual "hackathon" in de Raadt's home base of Calgary, Alberta, was canceled—though at press time, some 55 programmers were still planning to meet in May for nine days of intense, venison-fueled programming.

"It just sickens me," Open BSD founder Theo de Raadt told a Canadian reporter who asked his opinion of the war in Iraq.

"Foreign entities often receive grants if they're capable of doing the work described in the solicitation," Walker says, explaining that while some solicitations also contain restrictions about who may qualify to do research on the topic, this one did not. "We were not funding OpenBSD—we are continuing to fund the POSSE project at the University of Pennsylvania. We were interested in stopping work only on that particular area [the hackathon]. Our communications were the same as always. In certain communities, high-tech communities, the word gets out faster."

Meanwhile, de Raadt is still fuming: "Air Force Material Command told the university to cease all operations, and they went aggressively after the funds. The contracting company I work for did the absolute least they could for me. Numerous lawyers from Pennsylvania and the Air Force went after the $8,000 that was left in the account for me." And de Raadt's frustration extends to Professor Smith: "Jonathan Smith told me not to exercise my right to free speech. A tenured professor's job is to, one, get grant money; two, recognize when the rights of his researchers are being trampled on; and three, use his tenure to protect them."

Walker refused to confirm or deny speculation about de Raadt's comments, what dangers might have been posed by the hackathon, or who ordered operations to cease.

Walker disagrees that the reasons are ever arbitrary: "DARPA is a very hands-on management activity. As our name implies, we fund specific projects. There's a start point and an end point. Our goal is not to build infrastructure at universities. Most of the time, we award funding in phases; the first phase is usually 18 months. Our milestones are set up at the outset, and the researchers know what they are."

DARPA's motivation remains murky, but OpenBSD is not, says Spafford: "It's full-featured, stable, free, well maintained and well documented." Though he won't review the anti-buffer overflow advances in version 3.3 until the summer, "I've read about what they've done, and it's fully appropriate. OpenBSD is one of leading candidates [as a platform] for two major research projects here: One is a sensor-based intrusion detection system; the other is a software server architecture."

"The bigger problem," Spafford notes, "is that the open-source community doesn't give OpenBSD as much attention and use as it does other operating systems that aren't as reliable."

A Canary on the Stack
Like finches, each of the three free BSDs has evolved according to its strengths: FreeBSD focuses on mass appeal, NetBSD runs on everything from Sega Dreamcast to generic x86, and OpenBSD (which split from NetBSD in 1995 after "they kicked me out," says de Raadt) strives for Spartan security. Version 3.3 incorporates IBM researcher Hiroaki Etoh's ProPolice, which improves on the buffer overflow prevention ideas in Crispin Cowan's StackGuard system.

At compilation time, "ProPolice places a random canary on every stack frame, snuck in at exactly the right place on the stack. If the value's unmodified, everything runs fine, but if it's modified, the program is terminated," explains de Raadt, and this complicates attacking attempts to change a function's return address. To avoid pointer corruption, Etoh's approach reorders local variables to place buffers after pointers and copies pointers in function arguments to an area preceding local variable buffers. To speed performance, it omits instrumentation code from some functions.

For those architectures that can support it, OpenBSD offers a "fine-grained memory permissions layout" called W^X (and pronounced "W xor X"). In de Raadt's words, "It's a policy for mapping processes so that you never have a page that's both writable and executable. Most buffer overflows rely on being able to write to a piece of memory and then jump to it." Finally, other security enhancements include heavy use of chroot, privilege separation for the X window server and xconsole, default RSA blinding in OpenSSL, and widespread replacement of strcpy(), strcat() and sprintf() with the safer strlcpy(), strlcat(), and snprintf() or asprintf().

"The idea of removing implementation bugs like buffer overflows is always a good start," says Gary McGraw, CTO of Cigital, a software quality firm. "You can do this statically or place dynamic checks in the code. However, removing buffer overflows alone won't suffice. You need to get the architecture right from a security perspective, too. The open-source guys have a harder time controlling architecture in the chaos."

That, and playing politics.

—Alexandra Weber Morales

A high-tech brainstorm can only take you so far.

I recently had lunch with a friend, a computer science researcher whom I met years ago at a conference. He was lamenting about what he should do if Sudden Acute Respiratory Syndrome (SARS) was still at epidemic levels when he was to attend a workshop in Japan in a few months. "Should I go, or shouldn't I?" he wondered. "Is there any doubt?" I asked, remembering his deathly brush with pneumonia. Then I started thinking—I'd just attended a conference where a keynote speaker from China was unable to attend a meeting in San Diego, perhaps for SARS-related travel reasons. His remote, big-screen presentation wasn't so bad—he even took questions afterwards. "But I don't want that to happen," my friend said, "I want to go to Japan. The real value is in the exchange of ideas with other researchers in the field"—not to mention his love of traveling.

THE WHITEBOARD Introducing a periodic challenge to SD readers. May Challenge: From SARS to Mars The threat of disease is dampening travel around the globe and cutting attendance at international conferences. Teleconferencing technology can convey a keynote, but much of the value in any conference is the networking that happens in the spontaneous human interaction that occurs before, between and after the planned talks. Your assignment? Envision the technological underpinnings of an ideal virtual conference. Consider these four points in your scenario: 1. Presenting papers and question-and-answer sessions. 2. Meeting with other members in different zones. 3. Solving latency and time zone problems. 4. Providing intimacy in the networking experience. The most novel solution will win a Software Development t-shirt and publication in the magazine. Please do not mention specific products. Send your approach document (no more than 500 words) or diagram to [email protected].

We then explored all sorts of alternatives to personal attendance. Continental meeting points running identical conference sessions could be patched into a hosting site, allowing you to network outside of your region—not as fluidly as an international face-to-face would, but perhaps a viable option. Networking kiosks at events with huge screens transmitting live video from locations around the world could be set up around a cocktail lounge with long-distance "pagers." If you wanted to converse with someone on the video conference screen, you could beep him by entering his number (each member would wear an identifier of some sort) and go to a private kiosk to conduct a screen-to-screen interaction.

We laughed. It could be real fun, but what if you were interested in "meeting" someone? "There would be lots of potential for small talk-and with less inhibition," I mused. "Forget about the technical world—this could be a fantastic new dating model!"

My friend had one more objection: "How about the latency?" You know, that annoying, protracted, question-response delay that's ubiquitous with remote video and TV communication,dashing any hope for a truly spontaneous, productive interaction. "Not a problem," I answered. "In fact, it's a great opportunity. If light travels around the globe seven times in one second, it seems like we should be able to solve that one." I could see dollar signs on the horizon for technical start-ups that addressed these sorts of teleconferencing problems with giant towers, faster data compression, asynchronous messages and any number of other tricks.

Then, my friend offered a final, devastating objection—however recursive: "What if we hadn't both been at that conference in Palo Alto in the '80s? We never would have met!"

Well, back to the drawing board.

—Rosalyn Lum