The EFF recently proposed to fix a major problem in the Internet’s Public Key infrastructure:
One of the main problems with the current PKI model is the lack of control over CAs and their subsidiaries. There are literally hundreds of organizations spread around the world that are allowed to issue certificates for any domain name and some of them are operated by governments that practice Internet surveillance and censorship.
Worth reading.
My previous post about Apple security focused on an article by Wil Shipley wherein he discussed signing apps written for Mac OS X with certificates. One of Shipley’s main points was that the two primary mechanisms for enforcing security on the Mac App store (sandboxing and auditing) are fundamentally flawed. Now we have a great example of how auditing fails:
Miller, a former NSA analyst who now works as a researcher with consultancy Accuvant, created a proof-of-concept app called Instastock to show the vulnerability. The simple program appears to merely list stock tickers, but also communicates with a server in Miller’s house in St. Louis, pulling down and executing whatever new commands he wants. In the video above, he demonstrates it reading an iPhone’s files and making the phone vibrate. Miller applied for Instastock’s inclusion in the App Store and Apple approved the booby-trapped app.
The rest of that article includes more details on the code signing flaw Miller exploited, but I want to focus on a slightly different aspect of this story: responsible disclosure. Essentially, in responsible disclosure, when a researcher discovers a flaw in proprietary software, they immediately report it to the company responsible and setup a reasonable timeframe for fixing the problem before publicly disclosing the flaw.
Miller first contacted Apple about this problem on October 14th. I’m not sure that three weeks is really enough time to resolve a problem like this. I know he didn’t give all the details, and I know Apple has a reputation for not fixing security bugs until they become public (or perhaps well after they have been public for months…). Still, Miller would have a lot more sympathy with me if he reported the problem to Apple privately and gave them time to resolve the error. Another thing that would have made me a little more sympathetic is if he and Apple had agreed to a timeframe on resolving this problem prior to disclosing the flaw, though I’m not sure Apple would ever agree to something like that. Publicly acknowledging flaws of this nature isn’t really in their DNA.
Despite the flaw in Apple’s code signing, they have been able to respond by removing the exploited app from their app store and canceling Miller’s developer license. (Note: There’s some hypocrisy on Apple’s part here since canceling a developer license is a bit different from their treatment of other iOS security researchers.) Is this good enough for security? Everything in security is a tradeoff, so where does this response fall? It annoys me that there’s a bug in Apple’s code signing, but maybe the setup of the iOS App Store is enough of a response.
The original article points out that a similar issue in Android has resulted in a spate of malware for that platform. I’m not sure a similar thing will happen with iOS. Sure, Apple won’t be able to detect these apps in their review process, but they can always just remove them from the store after they’ve been found in the wild. I would probably prefer to see the code signing exception resolved, but I’m not sure what the tradeoffs really are. It’s hard to make security decisions that way.
Lastly, I should mention that this story is rather one-sided as of now. I haven’t seen anything from Apple about all of this yet. If you’ve seen something from Apple, please leave a comment.
Well-known Mac developer Wil Shipley wrote a fantastic post about software security models on Mac OS X. Essentially, his argument is that proactive solutions to software security cannot be successful on their own; they must be supplemented with a reactive approach. On the surface, this seems counter-productive: wouldn’t you rather find security problems before they compromise anything than react to them after it’s happened? In an ideal world, this would obviously be the best result, but we don’t live in an ideal world. Here’s Wil:
Entitlements are a binary solution – if there’s a hole anywhere in it that malware authors find, then there’s really not much Apple can do until they issue a full operating system patch. We call this kind of solution “brittle” – it requires everything to have been written perfectly, for every contingency, or it fails completely.
Solving security problems proactively is extremely challenging. If there’s a single hole, then all your effort is for nothing. A quick, appropriate reactive response is often the best tradeoff for security. Here’s Wil again:
Code auditing and sandboxing are non-biomimicry – nature doesn’t try to audit every line of code, she tries to fail gracefully. Certificates alone offer a graceful failover – if a developer signs up with Apple and provides false info and manages to trick people into downloading her malware, well, we can just throw a switch and she’s done.
Security shouldn’t be all-proactive, but neither should it be all-reactive. Some proactive measures are worth the tradeoff. The fact that Apple performs a baseline examination of applications sold through their Mac App Store does eliminate obvious security problems, but such an approach is never going to catch every single security problem. For that, the best solution will be reactive, and an application white list enforced with certificates is a reasonable approach.
Flash is almost always the #1 target for hackers. It’s nearly ubiquitous and easy to break into. The only thing that might give Flash a run for it’s money is the Java runtime environment. Still, Flash is awful.
Because there are so many stories about how bad Flash is from a security standpoint, I haven’t really spent much time linking to them. However, Steve Bellovin, a computer security pioneer and a Professor of Computer Science at Columbia, wrote a fantastic post about the security problems caused by Flash:
From a technical perspective, it’s simply wrong for a design to outsource a critical access control decision to a third party. My computer should decide what sites can turn on my camera and microphone, not one of Adobe’s servers.
Definitely read the whole thing. Bellovin ends his post with this:
No wonder the NSA’s Mac OS X Security Configuration guide says to disable the camera and microphone functions, by physically removing the devices if necessary.
I’m not sure what role the operating system should play here, but it’s fascinating to think about. How should things like the camera and microphone be controlled? Webcams are clearly an important area for privacy.
Lastly, Bellovin’s post is based on research done by Feross Aboukhadijeh at Stanford, which is worth reading if only because it is a pretty compelling case of responsible disclosure.
I haven’t linked to many air travel stories recently in part because there are simply so many of them that picking one to link to over the others is a challenge in and of itself. Recently, I came across an article by LZ Granderson at CNN that sort of summarizes the situation well:
Given the physical requirements and inherent importance of an exit row seat, I would feel more comfortable if I knew the person sitting there could at least do a pushup and not just be collecting a reward for being a repeat customer.
These are the kind of systematic disconnects that just crack me up.
Flight attendants tell us to turn off all electronic devices under the guise they could interfere with the plane’s navigation system, meaning that if the terrorists really wanted to cause some damage, all they had to do was read their Kindle during takeoff.
Granderson sort of implies that we should at least attempt to enjoy the absurdity as the amusement that it is. I don’t agree. Waste and inconvenience on this scale isn’t amusing. Security is a tradeoff, and I don’t think we’re making the right decisions. The risk of being the victim of a terrorist on an airplane is ridiculously low.
There are reasons we’re not making rational decisions about airport security, and most of them are probably best explained by the fact that we’re all human. Humans just don’t make rational decisions about some types of risk. Dan Ariely has basically made his entire career about irrational decisions people make. Bruce Schneier’s next book is going to focus on how people make decisions involving trust.
Still, we don’t really understand why people do are so poor at making these decisions. Worse, we don’t know how to improve this sort of decision making. The absurdity of airport security isn’t amusing; the root causes of this problem are probably one of the most important research topics for the next few decades.
If you’re going to steal large amounts of personally identifiable information, then you’re almost always better off doing so digitally rather than attempting to steal paper records. People notice when boxes and boxes of records go missing. In fact, the entire plot of The Firm hinges on a rather intricate attempt to make paper copies of records that would comparatively trivial to steal in a digital world.
Because of the problems of paper records, it’s really rare that you see huge paper-based violations of HIPAA. But apparently, it’s not impossible:
When Athens native Bobby Roberts placed a bid of more than $1,000 for the contents of a delinquent storage unit in Florence, he said he thought he was buying medical equipment and maybe old office files.
But on Sept. 10, when he opened the 20 or so boxes in the unit at Climate Guard Self Storage on Florence Boulevard, he discovered the boxes were filled with personal medical records from Digital Diagnostic Imaging Inc. Some were from as recently as 2009, while others dated to 2002.
Included on those records were not just medical details but patients’ Social Security numbers, addresses, phone numbers, insurance information and driver’s licenses.
Obviously, Roberts didn’t steal the records, but this is still a violation of HIPAA and the fault of the company that abandoned the records. Covered entities can’t just abandon paper-based records in a storage facility. It looks like Roberts is attempting to do the right thing with the records, but imagine what would have happened if someone else had won that auction.
Joel Stein writes The Awesome Column for Time Magazine. He recently wrote about passwords in a column called Pimp My Password. You have to be a Time subscriber to read the article now, but it’s worth reading if you can. His views on passwords are probably very, very close to what the average layperson thinks.
Google has recently announced a new service called Page Speed Service. Here’s TechCrunch:
Page Speed Service is the latest tool in Google’s arsenal to help speed up the web. This service is also their most ambitious yet. When you sign up and point your site’s DNS entry to Google, they’ll enable the tool which will fetch your content from your servers, rewrite your webpages, and serve them up from Google’s own servers around the world. Yes, you read all of that correctly.
So my question is this: When will Google starts using a service like this to remove common security problems like Cross Site Scripting from websites?
In my last post, I talked about the inherent challenges in evaluating software for security flaws. One approach to this problem is to rate products on a vastly simplified scale using a rough checklist of the most egregious errors. The DHS and Mitre Corp. have built just such a system:
The Homeland Security Department and consulting firm Mitre Corp. on Monday unveiled a system for rating the protection of software products to help agencies, contractors and consumers ensure they are buying safe technology, in the same way the Energy Star labeling program helps guarantee eco-friendly purchases, DHS officials said.
The scoring reflects the degree to which software offerings defend against the most common programming flaws — which are widespread in agency systems as noted by a recent audit of Internal Revenue Service databases. Last week, the Treasury Department inspector general released a report that found software housing taxpayer information is not always protected against attacks.
I’m not convinced that programs like this will be successful at doing anything other than eliminating the obviously deficient. There’s some real value in eliminating the obviously deficient, but software security rating systems almost always imply that if a product has achieved the ‘best’ rating, then it’s ‘secure.’
Establishing that something is 100% secure is extremely difficult because of the nature of security, and any software security rating system needs to be clear about its limitations. This proposed system provides a metric-based rating from one to 100, which looks too much like a ‘percentage’ for security to me. I would prefer something different, perhaps even a binary rating to indicate that a product either has known security concerns or doesn’t have them.
Despite all their potential pitfalls, I suspect that software security ratings systems are the closest thing we’re likely to see as a way to quickly evaluate whether a product has serious security concerns.
Tim Lee has a great article up on Ars Technica about liability and software security:
If your code gets hacked, are you the one on the hook? In the early decades of the software industry, the answer was usually “no.” Software licenses routinely disclaimed liability, and until recently, security flaws were considered to be just another fact of life. When problems were discovered, companies were expected to fix them quickly, but they were rarely on the hook for the resulting damage.
That’s changing rapidly. Recently, Sony faced a class action lawsuit for losing the private information of millions of users. And this week, it was reported that Dropbox is already being sued for a recent security breach of its own.
Read the whole thing; it’s not long.
I do want to pick a nit with part of the interview with Professor Alex Halderman of the University of Michigan:
Ars asked Alex Halderman, a computer science professor at the University of Michigan, to help us evaluate these options. He argued that consumer choice by itself is unlikely to produce secure software. Most consumers aren’t equipped to tell whether a company’s security claims are “snake oil or actually have some meat behind them.” Security problems therefore tend not to become evident until it’s too late.
I don’t disagree with the conclusion, but I do disagree with the rationale. (Yeah, I’m really picking a nit here…) It’s true that most consumers aren’t equipped to tell wether a company’s security claims are snake oil or not, but that doesn’t necessarily mean that a consumer choice approach is doomed to fail. The fact of the matter is that most consumers aren’t equipped to differentiate a high quality product from a low quality one in any field. The difference is that for most products we can effectively rely on the few consumers who are able to make that differentiation. I don’t know a thing about the best window treatment for a house, but with just a little digging I can find some reliably good advice one way or the other about a given product. Unfortunately, security is one of those products for which even experts are unable to provide reliable advice. It’s just inherently challenging to evaluate the security of a product. (Halderman talks about this later in the interview.)
If you’re interested in more information on these topics, I recommend Bruce Schneier’s extensive writings about both the challenge of evaluating security and the value of liability as a motivator for companies providing products that should be secured. Liability is one of the first things he mentions in his book Secrets and Lies: Digital Security in a Networked World. Perhaps the best summary of his views for the uninitiated is his recent TED talk.
Except where noted, this work is licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.
RSS feed. This site uses the Basic Maths theme for WordPress, designed by Khoi Vinh & Allan Cole.