Boeing's New 787 May Be Vulnerable to Hacker Attack

Boeing's new 787 Dreamliner passenger jet may have a serious security vulnerability in its onboard computer networks that could allow passengers to access the plane's control systems, according to the U.S. Federal Aviation Administration.

The computer network in the Dreamliner's passenger compartment, designed to give passengers in-flight internet access, is connected to the plane's control, navigation and communication systems, an FAA report reveals.

The revelation is causing concern in security circles because the physical connection of the networks makes the plane's control systems vulnerable to hackers. A more secure design would physically separate the two computer networks. Boeing said it's aware of the issue and has designed a solution it will test shortly.

"This is serious," said Mark Loveless, a network security analyst with Autonomic Networks, a company in stealth mode, who presented a conference talk last year on Hacking the Friendly Skies (PowerPoint). "This isn’t a desktop computer. It's controlling the systems that are keeping people from plunging to their deaths. So I hope they are really thinking about how to get this right."

Currently in the final stages of production, the 787 Dreamliner is Boeing's new mid-sized jet, which will seat between 210 and 330 passengers, depending on configuration.

Boeing says it has taken more than 800 advance orders for the new plane, which is due to enter service in November 2008. But the FAA is requiring Boeing to demonstrate that it has addressed the computer-network issue before the planes begin service.

According to the FAA document published in the Federal Register (mirrored at Cryptome.org), the vulnerability exists because the plane's computer systems connect the passenger network with the flight-safety, control and navigation network. It also connects to the airline's business and administrative-support network, which communicates maintenance issues to ground crews.

The design "allows new kinds of passenger connectivity to previously isolated data networks connected to systems that perform functions required for the safe operation of the airplane," says the FAA document. "Because of this new passenger connectivity, the proposed data-network design and integration may result in security vulnerabilities from intentional or unintentional corruption of data and systems critical to the safety and maintenance of the airplane."

The information is published in a "special conditions" document that the FAA produces when it encounters new aircraft designs and technologies that aren't addressed by existing regulations and standards.

An FAA spokesman said he would not be able to comment on the issue until next week.

Boeing spokeswoman Lori Gunter said the wording of the FAA document is misleading, and that the plane's networks don't completely connect.

Gunter wouldn't go into detail about how Boeing is tackling the issue but says it is employing a combination of solutions that involves some physical separation of the networks, known as "air gaps," and software firewalls. Gunter also mentioned other technical solutions, which she said are proprietary and didn't want to discuss in public.

"There are places where the networks are not touching, and there are places where they are," she said.

Gunter added that although data can pass between the networks, "there are protections in place" to ensure that the passenger internet service doesn't access the maintenance data or the navigation system "under any circumstance."

She said the safeguards protect the critical networks from unauthorized access, but the company still needs to conduct lab and in-flight testing to ensure that they work. This will occur in March when the first Dreamliner is ready for a test flight.

Gunter said Boeing has been working on the issue with the FAA for a number of years already and was aware that the agency was planning to publish a "special conditions" document regarding the Dreamliner.

Gunter said the FAA and Boeing have already agreed on the tests that the plane manufacturer will have to do to demonstrate that it has addressed the FAA's security concerns.

"It will all be done before the first airplane is delivered," she said.

Loveless said he's glad the FAA and Boeing are addressing the issue, but without knowing specifically what Boeing is doing, it is impossible to say whether the proposed solution will work as intended. Loveless said software firewalls offer some protection, but are not bulletproof, and he noted that the FAA has previously overlooked serious onboard-security issues.

"The fact that they are not sharing information about it is a concern," he said. "I'd be happier if a credible auditing firm took a look at it."

Special conditions are not unusual. The FAA publishes them whenever it encounters unusual issues regarding a plane's design or performance in order to communicate on record that it expects the manufacturer to address the issue. It's then up to the manufacturer to demonstrate to the FAA that it has solved the problem. Gunter said the FAA has issued eight special conditions on the Boeing 787, but that not all of them pertain to the plane's computer systems.

History of Linux

a. In The Beginning

It was 1991, and the ruthless agonies of the cold war were gradually coming to an end. There was an air of peace and tranquility that prevailed in the horizon. In the field of computing, a great future seemed to be in the offing, as powerful hardware pushed the limits of the computers beyond what anyone expected.

But still, something was missing.

And it was the none other than the Operating Systems, where a great void seemed to have appeared.

For one thing, DOS was still reigning supreme in its vast empire of personal computers. Bought by Bill Gates from a Seattle hacker for $50,000, the bare bones operating system had sneaked into every corner of the world by virtue of a clever marketing strategy. PC users had no other choice. Apple Macs were better, but with astronomical prices that nobody could afford, they remained a horizon away from the eager millions.

The other dedicated camp of computing was the Unixworld. But Unix itself was far more expensive. In quest of big money, the Unix vendors priced it high enough to ensure small PC users stayed away from it. The source code of Unix, once taught in universities courtesy of Bell Labs, was now cautiously guarded and not published publicly. To add to the frustration of PC users worldwide, the big players in the software market failed to provide an efficient solution to this problem.

A solution seemed to appear in form of MINIX. It was written from scratch by Andrew S. Tanenbaum, a US-born Dutch professor who wanted to teach his students the inner workings of a real operating system. It was designed to run on the Intel 8086 microprocessors that had flooded the world market.

As an operating system, MINIX was not a superb one. But it had the advantage that the source code was available. Anyone who happened to get the book 'Operating Systems: Design and Implementation' by Tanenbaum could get hold of the 12,000 lines of code, written in C and assembly language. For the first time, an aspiring programmer or hacker could read the source codes of the operating system, which to that time the software vendors had guarded vigorously. A superb author, Tanenbaum captivated the brightest minds of computer science with the elaborate and immaculately lively discussion of the art of creating a working operating system. Students of Computer Science all over the world pored over the book, reading through the codes to understand the very system that runs their computer.

And one of them was Linus Torvalds.

Wireless Keyboard "Encryption" Cracked

Security researchers have cracked the rudimentary encryption used in a range of popular wireless keyboards.

Bluetooth is increasingly becoming the de-facto standard for wireless communication in peripheral devices and is reckoned to be secure. But some manufacturers such as Logitech and Microsoft rely on 27 MHz radio technology which, it transpires, is anything but secure.

Using nothing more than a simple radio receiver, a soundcard and suitable software, Swiss security firm Dreamlab Technologies managed to capture and decode the radio communications between a keyboard and a PC. The attack opens the way up to all sorts of mischief including keystroke logging to capture login credentials to online banking sites or email accounts.

Dreamlab cracked the encryption key used within Microsoft Wireless Optical Desktop 1000 and 2000 keyboards. As most products in Microsoft's wireless range are based on the same technology other products are likely to be insecure. Max Moser and Phillipp Schrödel of Dreamlab Technologies succeeded in eavesdropping traffic from a distance of up to ten meters using a simple radio receiver. More sensitive receivers may make it possible to capture keystrokes over larger distances.

Sniffing traffic between wireless keyboards and their base stations was possible because of the weak encryption used, as explained in a white paper from Dreamlab:

To our surprise, only the actual keystroke data seems to be encrypted. The Metaflags and identifier bits aren't encrypted or obfuscated. The one byte USB Hid code is encrypted using a simple XOR mechanism with a single byte of random data generated during the association procedure.

This means that there are only 256 different key values possible per keyboard and receiver pair. We did not notice any automated key change interval and therefore assume that the encryption key stays the same until the user reassociates the keyboard. 256 key combination can be brute forced even with very slow computers today. We did not analyze the quality of the random number so far because it was not needed to successfully break the encryption.

"Wireless communication is only as secure as the encryption technology used. Due to its nature, it can be tapped with little effort," said Dreamlab's Max Moser.

A Brief History of Slashdot Part 1, Chips & Dips

As part of our 10 year anniversary celebration, I've decided to post a story here telling the tale of the transition from Chips & Dips to Slashdot back in 1997. For those of you who are new here (cough), CnD was the precursor to Slashdot, hosted on my personal homepage on the CompSci cluster of Hope College. Along with a number of random Linux related webpages, themes for window managers, random bits of code I wrote, this page was read by a great number of folks, mostly from the IRC scene. Hit the link below to read the tale of its transformation into an Internet superstar (and maybe later I'll write the the sequel where I talk of the transformation into sellout mega corporate evil and eventually irrelevant blemish on the history of the net ;) And don't forget to check for a Slashdot 10 year anniversary party in your area.


In the summer of 1997 I was contacted by a stranger out of the blue with a kind of random offer. During the previous school year Nate Oostendorp (who now works with SourceForge, Inc. while working on his Masters) had coded a Space Invaders clone. He wrote a Java sprite library, and I wrote the game and illustrated the alien armada. This guy had an old DEC Alpha Multia 166, and a client that wanted to remake the game with popcorn instead of aliens. So I drew the popcorn up, replaced the gifs, and he mailed me my first non x86 box since the 286 I got in middle school. (Later Sun sent me legal threats forcing me to take the game offline since it was called Java Invaders, and clearly this was an evil crime against the universe. My hatred for Java has never died since that moment.)

I immediately installed Red Hat on it. I was working at an ad agency called The Image Group at the time as a webmaster. I coded whatever needed doing and handled various admin tasks to keep their clients happy. At the time they needed full control over email addresses on the domains they built. Since they shared their mailserver with their ISP, there were frequent name collisions -- if the client wanted bob@theirdomain.com but there already was a bob on the system, they couldn't do it. They agreed to let me move my little Alpha onto their network to host their email... and I could use it to fart around with on my personal hobbies.

I named the box Ariel. It sat under my desk. I learned enough Perl to write a stupid simple CMS to replace the functionality of Chips & Dips, which up until that point was just a text file. Dave DeMaagd wrote a simple comment system. Since we both had a long history with BBSes, it seemed obvious to us that there needed to be a discussion system. There were no user accounts -- you entered whatever name you wanted each time you posted. If you left it blank, it auto-filled the space with the name 'Anonymous Coward', a title that stuck and spread throughout the net.

The original system was written in Perl because I wanted to learn more Perl. All the data storage was flat text files. (We lost most of the original stories during a data import a year or so later) The files were named like 0000001.shtml and so forth and were all rendered at time of page request. Best of all, since the system was written as a CGI, the whole script needed to be compiled every time there was a page request. It was months before I ported the whole thing to use MySQL and mod_Perl.

I registered the domain name Slashdot.org as a joke. It was 'org' because I didn't want a .com -- those were so common. I always thought org would be cooler, and besides, I had no commercial plans in mind. (Years later this bit me on the ass since someone else registered the .com. Doh!) The URL was meant to be unpronounceable by anyone -- a joke ultimately that has backfired on me countless times when I'm called and asked what the URL is to the damn thing. Jeff 'Hemos' Bates (now a VP of something or other with SourceForge, Inc.) was in the living room when I was registering the domain name. We all wanted email addresses with a unique domain name that wasn't attached to our school, so he chipped in on the registration fee.

When it came time to design the website's look, I took elements from a theme we had designed at The Image Group -- Paul Hart and I spent hours on it -- that was supposed to be the new website for the company, but it was passed on for another look. I still liked it, so I redesigned it more to my personal aesthetics (choosing #006666 as the dominant green replacing an earth tone green) and putting drop shadows all over everything (a habit I still haven't broken, and for which I am still mocked). Within days, most of the design elements you see on Slashdot were in place... the curves, the greens, the polls, the vertical list of stories so common in 2007, and, of course, discussions on each story.

And Slashdot was born. At first it had just a few thousand daily readers migrating over from Chips & Dips, but in a matter of weeks it had grown so fast that we started really having fun with it. One night we put up a poll asking how many shots Kurt 'The Pope' DeMaagd should drink. (Kurt later became our defacto HR man when we formed Blockstackers... today he is a professor at MSU.) But that night, Slashdot readers told him to take a dozen shots of alcohol -- he failed, but he tried.

I remember around the same time just watching 'tail -f' on the access_log. My world was rocked over and over again as I watched the domain names... mit.com! ibm.com! redhat.com! Hell, even microsoft.com kept scrolling through the log. I knew we had something... people from around the world, from the highest institutions in the land, from the biggest companies in the tech sector and to the most influential in the Linux world were all reading Slashdot. In fact, they were posting comments... as were a lot of people. It became commonplace to see hundreds of comments on stories, and the so-called 'Slashdot Effect' slowly grew into our lexicon as site after site buckled under our links.

In those days the content was a lot more personal then it is today. Stories would frequently refer to alcohol-related activities. I'd constantly mention that I had to leave to go to class so there wouldn't be more stories posted for a few hours. And when a professor in my pottery class assigned homework of to mass produce and sell some pottery as a lesson in being a commercial artist, I posted it, and ended up getting over 100 requests to buy my shitty mugs (all glazed teal ;) In the end I never did sell them -- I fulfilled the assignment locally. I think I still have one of those mugs left but I'm not sure- over the years my mediocre ceramics have been filtered out of a home increasingly tastefully decorated by my wife.

I continued to go to class and work my part time job. Ariel soon had loads so great that the machine was unusable during the day. And occasionally I would accidentally kick it and knock out a cable, bringing the machine offline. Soon after it saturated the office T1, I started realizing that there was no way I was going to be able to do this as "Just" a hobby. Essentially, every second of my life was consumed without time for a break. I'd go to class -- and often just work on Slashdot in the back row. (This was the first year we had computers at our desks in the CS dept at Hope.) My classwork suffered. On the upside, I became far more proficient at webwork, which really helped the part time job. I'd go home and code, post stories, reply to email until 2-3 a.m. and repeat it the next day. It was going to eventually be a full time job, requiring revenue and infrastructure that didn't exist back then. But I guess that's another story.

Parallel programming environments: less is more

The single most important paper for programming language designers to read came out in 2000. It wasn’t written by a computer scientist, mathematician, or physical scientist. It was written by a couple professors studying social psychology:

“When Choice is Demotivating: Can One Desire too Much of a Good Thing?” Iyengar, S. S., & Lepper, M. Journal of Personality and Social Psychology, 79, 995-1006. (2000).

This paper explored the phenomena of “choice overload.” Here is what they did.

They created two displays of gourmet jams. One display had 24 jars. The other had 6. Each display invited people to try the jams and offered them a discount coupon to buy the jam. They alternated these displays in a grocery store and tracked how many people passed the displays, how many people stopped and sampled the jams, and how many subsequently used the offered coupon to buy the jam.

The results were surprising.

• 24 jar display: 60% of the people passing the display sampled the jam, 3% purchased jam.
• 6 jar display: 40% of the people passing the display sampled the jam, 30% purchased jam.

The larger display was better at getting people’s attention. But the number of choices overwhelmed them and they just walked away with out deciding to purchase a jam. In other words, if the goal is to attract consumers, less is more. Too much choice is demotivating. Admittedly, selecting a gourmet jam is insignificant. Maybe for more important issues, “choice overload” is not relevant? The authors of this paper, however, went on to consider more important choices such as 401K plans, and once again, a clear choice overload effect was found. Choice overload is real. When people are faced with too many choices, the natural tendency is to “not make a choice” and just walk away (probably in frustration).

Why is this relevant to parallel programming?

Think about it. We (that is, computer companies) want to sell hardware. To do that, we need software. We display our platforms and hope software developers will spend their valuable development dollars porting to our platform.

So what is the situation today with multi-core processors? A software vendor walks up to “our display.” We show them our nice hardware with its many cores and we tell them they will need to convert their software so that it will scale. And then we show them the parallel programming environments they can work with: MPI, OpenMP, Ct, HPF, TBB, Erlang, Shmemm, Portals, ZPL, BSP, CHARM++, Cilk, Co-array Fortran, PVM, Pthreads, windows threads, Tstreams, GA, Java, UPC, Titanium, Parlog, NESL,Split-C … and the list goes on and on. If we aren’t careful, the result could very well be a “choice overload” experience with softwre vendors running away in frustration.

Think about the impression this glut of choices creates. If we “experts” can’t agree on how to write a parallel program, what makes us believe parallel programming is ready for the masses? In our quest to find that perfect language to make parallel programming easy, we actually harm our agenda and scare away the software developers we need.

We need to spend less time creating new languages and more time making the languages we have work. This is why anytime I hear someone talk about their great new language, I pretty much ignore them. Tell me how to make OpenMP work. Tell me how to fix MPI so it runs with equal efficiency on shared memory and distributed memory systems. Help me figure out how to get pthreads and OpenMP components to work together. Help me understand solution frameworks so high level programmers can create the software they need without becoming parallel algorithm experts. But don’t waste my time with new languages. With hundreds of languages and API’s out there, is anyone really dumb enough to think “yet another one” will fix our parallel programming problems?