This weekend the Apache Software Foundation suffered a security breach. The post-mortem from the Apache Infrastructure Team is worth reading, because the attack was vsophisticated and they explain exactly how it worked.
Nelson Minar blames problems with passwords for the Apache security breach this weekend. Paul Querna blames Internet security as a whole. I’m still waiting for someone to blame URL shorteners, as they played a role in the attack as well.
I’ve been captivated this week by the ongoing Pwn2Own security competition. Pwn2Own offers prizes to security researchers for demoing zero-day exploits for popular software. On Day 1, researchers demonstrated holes in Firefox, Internet Explorer, Safari, and the iPhone. The unwritten rules of legitimate security research demand that before disclosing security holes publicly, security researchers notify the vendors so that they have a reasonable opportunity to release patches. The story I linked to says as much:
So far, little is known about the successful exploits. Until vendors have been informed of the flaws and those flaws have been patched, details will not be made public.
Three time winner Charlie Miller is going with a different approach this time around. He’s not going to disclose the holes he found in hopes of motivating the vendors to get better at finding bugs themselves.
I once had a contract job in which I was on a team that audited Web applications for potential security holes. Nearly all of the problems we found were related to poor input validation and sanitization. Unsurprisingly, that’s how Miller finds bugs as well. He has a program that generates a wide range of bad input and looks for the applications to break in interesting ways.
Sounds like Apple, Microsoft, and Mozilla should invite him over to give some guest talks.
Web developers have hated Internet Explorer 6 for a long time. If you design Web sites or write Web front end code, you know all too well how much work it is to support IE6 on all but the simplest Web sites. What we’ve recently learned is that IE6 is much more insecure than its successors, and now Microsoft admits that IE6 has security holes that they cannot fix.
Getting rid of the last vestiges of IE6 is going to require a three pronged attack. IT departments that still require it are going to have to be educated on the security risks of sticking with it. Or, more likely, the executives who have the power to tell the IT department what to do are going to have to be educated. I imagine that in the near future, we’re going to see a lot of IE6-remediation work. Web applications that support only IE6 are going to have to be upgraded so that IE6 can be abandoned.
Users who haven’t upgraded due to indifference are going to have to be made to suffer. Web sites need to start dropping support for IE6. When sites like Facebook and YouTube no longer support IE6, those users will upgrade Internet Explorer or find another browser.
And finally, Microsoft is going to have to take more steps to induce users to upgrade. Microsoft has waffled on phasing it out completely to placate companies with applications that depend on IE6, but it seems like today is the day that policy has to be revised.
I’ve been reading Bruce Schneier for more than a decade now, so very little of Joel Johnson’s piece, President Obama, It’s Time To Fire the TSA, is news to me. The more interesting question to me is, is there any reasonable path to changing how we think about security? Schneier hammers the TSA repeatedly for protecting against tactics that have been used previously rather than trying to think more systematically about the shape of future threats, but given human nature, it’s not surprising that we handle things that way.
The canonical example of security theater is the requirement that everyone remove their shoes before passing through security. We all know why that rule exists — Richard Reid tried to blow up an airplane with a bomb in his shoe on December 22, 2001 (yes, we’ve been removing our shoes at the airport for 8 years). There’s nothing special about secreting a small bomb in your shoe. As we learned this week, you can stuff a bomb into your underwear just as easily. But imagine the political casualties if someone were to blow up an airplane with a shoe bomb now. The opposition and the media would crucify everyone they could get their hands on for not protecting against a tactic we know that the terrorists use.
In fact, if a politician even tried to stop the shoe removal process, they would be attacked for not taking terrorism seriously. Many of us wish for more political courage from our politicians, but the incentives of every political system serve to diminish political courage and to cull out the truly courageous as quickly as possible. So I’m all for firing the TSA and restoring sanity to airport security, but I’m not optimistic that it’ll happen.
Leave it to Bruce Schneier to come up with a reasonable explanation for why the video downlink from Predator drones is not encrypted. His theory is that it’s because it would be a key management nightmare, given the way the military manages encryption keys. Basically, the audience for the UAV downlinks changes frequently and has a wide variety of security clearances, and military encryption is for data is for top secret stuff.
Letters of Note has a really cool example of steganography in practice — a letter from a British revolutionary war general that includes a secret message readable by placing a mask over the letter. The mask and letter were sent to the recipient via different routes.
© 2024 rc3.org
Theme by Anders Noren — Up ↑
Designing a no-fly list
One news item arising from the arrest of accused Times Square bomber Faisal Shahzad was that Emirates Airlines didn’t update their copy of the no-fly list soon enough after Shahzad’s name was added to prevent him from buying a ticket or boarding a flight out of the country. A non-programmer friend of mine was wondering why the airlines keep their own copy of the no-fly list rather than accessing some centralized resource that always has the most up-to-date list of names, and I thought I’d take a stab at explaining a few of the reasons why that may be the case.
The first question is, what’s a no-fly list? In short, it’s a list of names that airlines use some algorithm to match against. I have no idea how this part works, but it’s not really important. When someone tries to purchase a ticket or board a plane, the system should run their name against the list and return some kind of indication of what action should be taken if there’s a match. In matching against this kind of list, fuzzy matches will return more false positives, and stricter matches will do a poor job of accounting for things like alternate spellings and people adding or leaving out their middle names.
The question at hand, though, is how best to provide access to the no-fly list. These days, a developer creating a no-fly list from scratch would probably think about it as a Web service. Airlines would simply submit the names they wanted to check to the service, which would handle the matching and return a result indicating whether the person is on the list, or more specifically, which list they’re on. There are a number of advantages to this approach:
Given the strengths of this approach, why would the government instead allow each airline to maintain its own copy of the list, distributing updates as the list changes? I can think of a few reasons.
If the access to the list is provided by a centralized Web service, every airline endpoint must have the appropriate connectivity to communicate with that service. For reasons of security and cost, most airline systems are almost certainly deployed on private networks that don’t have access to the Internet. To get this type of system to work, the airline would have to provide direct access to the government service, an internal proxy, or some kind of direct connection to the government network that bypasses the Internet. All of those solutions are impractical.
Secondly, communicating with a central service poses a risk in terms of reliability. If the airlines can’t connect to the government service, do they just approve all of the ticket purchases and boarding requests that are made? If not, do the airline’s operations grind to a halt until communication is restored? The government probably doesn’t want to make all of the airlines dependent on the no-fly list service in real time.
And third, a centralized service opens up the airlines to a variety of attacks that aren’t available if they maintain their own copies. Both denial of service attacks and some man in the middle attacks could be used to prevent airlines from accessing the no-fly list, or to return bad information for requests to the no-fly list.
From an implementation standpoint, it’s easier for the airlines to maintain the lists themselves and to integrate that list into their own systems. Doing so is more robust, and the main risks are buggy implementations and out of date data. I wonder what sorts of testing regimes the government has in place to make sure that consumers of the no-fly list are using it properly? How do they test the matching algorithm that compares the names of fliers to names on the list?