Frankly Speaking

var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-21976300-1']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })();

[frankspeech-blog]

Pivot: Fast, Synchronous Mashup Isolation Using Generator Chains

Last week, during the security seminar, James Mickens gave a talk on his Oakland IEEE S&P paper "Pivot: Fast, Synchronous Mashup Isolation Using Generator Chains." He is a researcher at MSR and currently a visiting professor at MIT. As usual, I will give a high level overview of his paper, and if you find it interesting and want more details, please refer to his paper (http://research.microsoft.com/pubs/210205/camera-ready.pdf).

For a webpage, there is always the problem of composition. The important question is why we should isolate Javascript libraries. The main problem is that prototypes are mutable. For example, someone could change functions, such as the string contains function by doing the following:

String.prototype.contains = function(){ return false; };

Now, whenever a string calls contain, it will always return false.

James developed Pivot, which is a mashup isolation system with synchronous RPCs and minimal source code rewriting. It layers a thread and RPC library on top of postMessage() and frames. Each library is a frame, and on each RPC invocation, Pivot pauses the caller until the reply is received. As a result, synchronous RPCs create an order of magnitude performance improvement over prior rewriting solutions.

The design of Pivot is simple. Iframes are used as isolation containers. Each library goes in a separate frame, so this leaves the bulk of security checks in the fast, browser-provided C++. Then, Pivot uses minimal rewriting to provide synchronous RPCs. The idea is to rewrite function call and returns + call sites, but not the property references. More specifically, rewrite preexisting function returns (return retVal -> yield retVal). Each RPC stub yields the special value Pivot.RPC_YIELD. Finally, Pivot rewrites function call sites. Then, it "suspends" the frame on RPC invocation and resumes on RPC return using the Javascript generator function. The generator function preserves its activation record across multiple invocations. 

One small detail is deferring asynchronous events. For example, what happens if a mouse click is generated while a Pivot RPC is in-flight? Pivot maintains atomic handler semantics. While the RPC is in-flight, Pivot queues interrupting events. When a handler ends, Pivot dispatches queued events. For more details, please refer to his paper.

Another detail is that they don't need to rewrite every function. They need to rewrite the trusted core which makes synchronous RPCs to satellites. Satellites are not rewritten because they don't make RPCs. They can just be simple event-driven RPC servers. 

In order to evaluate the system, he creates a Shard mashup application and compares it to Jigsaw. In terms of end-to-end performance, Shard on Pivot is 12.6x faster than Shard on Jigsaw. For a more detailed evaluation, please refer to his paper. 

I think this is a very interesting and simple way to isolate Javascript functions. This also allows us to think about composition of webpage components in a different way. 

[frankspeech-blog]

Code Pointer Integrity

Volodymyr Kuznetsov from EPFL came to MIT last week to give a talk at security seminar. This talk was also presented a couple days ago at the biggest systems conference of the year, OSDI. His talk is titled "Code Pointer Integrity." There is also a paper with more details (https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-kuznetsov.pdf)

His motivation for his project are control-flow hijack attacks. They have been known for over 50 years. However, the number of CVEs for them have only been increasing. There have been many solutions in the research literature, but it's usually a tradeoff between security/safety and flexibility/performance. However, his system guarantees safety AND flexibility/performance.

He has two types of protection: practical protection (lower overhead) and guaranteed protection (higher overhead). For practical protection, he guarantees that an attacker cannot forge a code pointer. He does this with instruction level isolation. He has "safe memory" with a safe heap and stack for code pointers where accesses are safe, and all non-code-pointer data is in regular memory, which contains a regular heap and stack as well as read-only code where accesses are fast. For more details, I refer you to the paper.

However, practical protection might cover most situations. It is not precise. A precise solution protects all sensitive pointers, which are code pointers and pointers used to access sensitive pointers. In order to capture these pointers, he uses an over-approximate type-based static analysis: is_sensitive(v) = is_sensitive_type(type of v). In SPEC2006, less than 6.5 percent of memory accesses are sensitive. He has the same layout as the practical protection except his safe memory contains sensitive pointers and metadata instead of just code pointers. His guarantee is that guaranteed memory safety for all sensitive pointers leads to guaranteed protection against control-flow hijack attacks enabled by memory bugs. 

The high level idea is that accessing sensitive pointers is safe and accessing regular data is fast. He has a correctness proof for the guaranteed protection, and both types of security prevent attacks from RIPE (https://github.com/johnwilander/RIPE), which is an intrusion prevention evaluator.

They have a LLVM-based prototype at (http://levee.epfl.ch), and plan to integrate upstream into LLVM. They implement this as a flag that can be included in the compilation process (cc -fcpi foo.c). The practical protection only introduces 0.5-1.9 percent overhead for their test cases, and the guaranteed protection only introduces 8.4-10.5 percent overhead. I refer you to the paper for details results. His key insight is memory safety for sensitive data only.

I think that this work solves an important problem, especially given the recent research papers on ROP (return oriented programming) attacks, and this is one of many steps to getting better memory safety for C programs. 

[frankspeech-blog]

PHY Covert Channels: Can you see the Idles?

Hakim Weatherspoon from Cornell University gave a talk at the security seminar on his work at NSDI 2014 called Chupja, PHY Covert Channels: Can you see the idles? I will give a brief summary of his talk. If you want more details about his work, I would consider reading his paper (http://fireless.cs.cornell.edu/publications/chupja_nsdi2014.pdf).

The important question he asks is whether an underground spy ring can exist and thrive within the Internet. Traditionally, covert channels are used to hide information through communication not intended for data transfer. Network covert channels hide information using legitimate packets (overt channel). Storage channels use packet headers, and timing channels use arrival times of packets. Their work focuses on timing channels.

The overall goals of covert channels to have high bandwidth, be robust, and be undetectable. Currently network covert channels are implemented in the TCP/IP layers and are extremely slow. Their Chupja system has a bandwidth of 10-100 kilobits per second, a bit error rate of less than 10 percent, and is invisible to detection software. One of the biggest tricks is to implement the covert channel in the physical layer.

The idea behind Chupja is that with a shared interpacket gap size (G) between a sender and receiver, a '1' is encoded as G_i = G + eps, and a '0' is encoded as G_i = G - eps. The idea is that the receiver will check the time between packets and if it is less than G, it will record a '0' bit, and if it is more than G, it will record the '1' bit. They implemented this in their SoNIC system, which allows control and access of every bit of PHY. 

Their evaluation shows that the covert bandwidth is equal to the packet rate of the overt channel. For robustness, they tested on a small network, and on the national lambda rail. The reason Chupja is so robust is that switches do not add significant perturbations to interpacket delays and switches treat '1's and '0's as uncorrelated. Using kernel timestamping, they could not detect Chupja. This is a brief overview of the results. For more details, I refer you to the paper.

This was an interesting talk that had a cool trick for effective covert channels.

[frankspeech-blog]

Can You Hide in an Internet Panopticon?

Bryan Ford from Yale University gave a talk at the MIT security seminar a couple weeks ago. Sorry, this blog post has been delayed. He gave an interesting talk about the anonymity work he has been doing. He went through many technical details that I'll leave out. If you want to know more about the details, I recommend that you read the papers available on his website (http://www.brynosaurus.com/).

When the Internet first started, there was a saying that "nobody knows you're a dog on the Internet." However, today, they actually know exactly what kind you are, who your friend are, and what's important to you. A host of people want to track you online (advertisers, vendors, thieves, stalkers, etc.).

What kind of anonymity do we need? People really need anonymity to obtain strength in numbers. Many people just need several, unlinkable hats. The state of the art is Tor, but there are many instances where Tor is broken or circumvented. 

He presents his project Dissent, which is a clean-slate anonymous communications design, which offers quantifiable and measurable anonymity and is built on primitives offering provable security. The goals of the project are to address the known classes of attacks that onion routing systems like Tor are vulnerable to, like global traffic analysis, active interference attacks, intersection attacks, etc. Some reasonable use cases are multicast/broadcast-oriented applications and hardened local-area anonymizing VPNS, but it won't scale to something that can replace Tor.

There is a traffic analysis problem, because most communication has a traffic pattern. The lengths and timings of packets in each direction are known and patterns can be fingerprinted without seeing content. Real users can be de-anonymized if an attacker can monitor an internet AS or IXP. One way to resist traffic analysis is to use DC-nets. The main problem is large anonymity sets, which is why DC-nets are hard to scale. In order to circumvent this issue, Bryan uses a client/multi-server model, where clients only share coins with servers and as long as one honest server exists, it yields ideal anonymity among all honest clients. 

Dissent also tries to protect you against active interference attacks. An attacker perturbs performance to inject traceable side-channel markers or beacons into flows. This is similar to the congestion attacks in Tor. Onion routing preserves individual flow properties, but Dissent output paced by collective control. 

Next, he prevents intersection attacks. The Harvard bomb hoaxer was de-anonymized by a particularly trivial intersection attack. The FBI intersected all Tor users worldwide with users online in/around Harvard. He develops this Buddies model. First, the focus is on what the adversary learns from online status. A policy oracle simulates an adversary's view, knows who's online each round and performs intersection attacks against Nyms. They compute anonymity metrics, such as possinymity and indinymity. The challenge is to form these buddy sets. We start with one big buddy set and when members go offline, split to regain use. Stop splitting when the set is "too small" to enforce lower bound on indistinguishability. He, then, goes into more details about how to form these buddies. For the sake of brevity, I refer you to his CCS '13 paper for more details.

This is some really interesting work, and it seems like a promising direction worth pursuing. It is still unclear how to create practical means of anonymous communication for various settings and poses cool research topics. More information about this project can be found at http://dedis.cs.yale.edu/dissent/.

[frankspeech-blog]

Proving the Security of a Simple Private Information Retrieval Protocol in EasyCrypt

Last Wednesday, we had a talk from Alley Stoughton from Lincoln Labs, who talked about "Proving the Security of a Simple Private Information Retrieval Protocol in EasyCrypt." There are a lot of technical details in the talk, but I'll leave a lot of that out for the sake of brevity.

The UCI APP Protocol is a three party Private Information Retrieval (PIR) protocol. Its verification required our learning about various sophisticated techniques. However, this is highly suboptimal given the complexity of the UCI APP protocol. As a result, Alley began proving the security of a simpler version of the UCI APP protocol named Mini-APP.

To start, the Mini-APP protocol is a three-party PIR protocol. The server takes in a database consisting of a list of attributes, hashes each attribute, producing a hashed database, and send the hashed database to the Third Party (TP). The Client works its way through a list of queries, hashing each query, and asking the TP for the number of occurrences of this hash tag in the hashed database. Hash tags are bit strings of the same length. Hashing is done under the random oracle model. The threat model is an honest but curious perspective. 

Now, Alley uses EasyCrypt to prove this protocol. EasyCrypt is a framework for interactively finding security proofs of cryptographic protocols using the sequence of games approach. EasyCrypt uses SMT solvers to free the user from proving everything manually, and it does not model computational feasibility.

Now, there needs to be some formalization of the Mini-APP protocol in the EasyCrypt framework. The Mini-APP client is formalized using a pair of cryptographic games. The "real" game is based on the protocol described above. (The server hashes the database and passes the result to the TP. The client hashes a query, passing the resulting hash tag to the TP. The TP returns the tag count.) The "idea" game is based on a variant of the protocol. ("A query counts map is computed from the database, and given to the client. There is no server or TP. The client hashes each query as usual but computes the query's count by consulting the query counts map, instead of interacting with the TP.) The difference is that the client in the ideal game learns nothing about the database but the counts of its queries.

In terms of security and adversarial model, the protocol is secure against the client iff the adversary can't distinguish between the real and ideal games defined above. Because EasyCrypt allows for computationally infeasible adversaries, and the adversary has access to the oracle at the beginning of the game, unless we restrict the adversary, it will be able to distinguish the real and ideal games. The way she does this is limit the number of distinct oracle calls the adversary may make in its initial call, and limit the sizes of the database and lists of queries that the adversary may return. She must prove the protocol itself keeps within its budget of distinct oracle calls. 

Then, she went on to the implementation details of her proof in EasyCrypt, which was very interesting. However, I will leave that out here.

This was a really interesting talk and gave an interesting way of thinking about how to prove cryptographic protocols using certain programming languages.

[frankspeech-blog]

Systems Thinking for Safety and Security

We had a different flavor of talk last Wednesday when Nancy Leveson and Bill Young from the Department of Engineering Systems came to give a talk at the security seminar. They discussed a systems thinking for safety and security. To place things in a bit of perspective, they are applying their security models to real world systems like airplanes, nuclear plants, train systems, etc. It applies primarily to these systems rather than computer systems like OSes and the web. It's important to view this summary from that perspective where the loss is a disaster of some sort (nuclear meltdown, airplane crash, etc.).

Nancy started by discussing a need for a new approach. Traditional safety engineering was developed for relatively simple system, but accidents in complex, software-intensive systems are changing their nature. The traditional approach is to view safety was a failure problem, which is a chain of directly related failure events that lead to loss. The tolerance for error should be close to zero.

There are two types of accidents.

Component Failure Accidents

Component Interaction Accidents

Component failure accidents are single or multiple component failures. Component interaction accidents arise in interactions among components. This is exacerbated by introduction of computers and software. 

They present a System Theoretic Accident Model and Processes (STAMP). They view safety and security as a control problem. The goal is to control the behavior of the components and systems as a whole to ensure safety/security constraints are enforced in the operating system. Instead of a chain of failure events, losses involve a complex, dynamic process, which arise in interactions among humans, machines, and the environment. They want to treat safety/security as a dynamic control problem rather than a reliability problem.

Controllers use a process model to determine control actions, and accidents often occur when the process model is incorrect. Loss events are the result of the inadequate control, resulting from lack of enforcement of safety/security constraints in system design and operations. We need to design a control structure to enforce constraints on system behavior and adaptation. 

They develop STPA, which is integrated into system engineering and works on social and organizational aspects of systems. It generates system and component safety/security requirements. It identifies flaws in system design and scenarios leading to violation of a safety/security requirement. They give a lot of examples about how STPA works. If you want to learn more, I encourage you to visit their website (http://sunnyday.mit.edu/), but I won't go into that many more details here.

They use STPA for cyber security. The crux of the approach is this top-down approach. It starts with identifying losses. Then it identifies vulnerabilities and system safety/security constraints. It builds functional control models and identifies unsafe/insecure control actions and causes for them. They did a real world evaluation of STPA-Sec and found that it worked well. The concepts are very similar to using STPA for safety, so I won't delve more into them. It elevates the security problem from guarding network to higher-level problem of assuring overall function of enterprise and includes managerial and social factors. 

This was a very different type of talk, looking at security in physical systems. There are a lot of interesting concepts in there and provides a different perspective on security in a world where failures cannot be tolerated at all.

[frankspeech-blog]

Nick Feamster on "Bots, Bubbles, and Bottlenecks: Safeguarding the User's Internet Experience"

Nick Feamster, a professor at Georgia Tech, came to give a talk about Bots, Bubbles, and Bottlenecks. There was a lot in his talk, so if you're interested more in his research, please visit his site (http://www.cc.gatech.edu/~feamster/).

In the beginning, the Internet was small. There were few stakeholders, one government, and no real security concerns. However, today, there are many ISPs, governments, and attackers. Protocols in the early days could guarantee good end-to-end performance, but now, the internet experience depends on economics, policy, security, psychology, and interfaces.

Nick talked about three major stakeholders: ISPs, attackers, and content providers.

User vs. ISP: Users want good, affordable, and reliable connectivity to content and services. ISPs care about profit. There is no single notion of performance. The conventional approach is to measure performance at the end host. However, Nick proposes using a home router. His work BiSmark is a broadband internet service benchmark. This allows for experience-driven experimental systems research that strives for simplicity, balances competing objectives, and debunks implicit assumptions.

These three implicit assumptions were debunked by his experiments:

Latency on Internet paths is dominated by speed of light propagation and queueing. 

To get better performance, simply upgrade your ISP serverice plan

When performance is poor, it's usually the ISPs fault

Latency is actually affected by access technology, DSL interleaving, peering, and equipment choice. Faster links don't help because page load times stop improving after a certain point, and last-mile latency hurts. Wireless bottlenecks are common.

These realizations lead to new research, such as approaches for reducing latency and new measurement tools. For specifics on the research he has done, I refer you to his home page (http://www.cc.gatech.edu/~feamster/)

User vs. Attack: Spam is 95% of all email traffic. Target attacks are steady. Conventional approaches use content filters and IP addresses to identify spam. His new approach is to detect spam based on network-level behavior (filter email based on how it is sent in addition to what is sent and who sent it). The goal is to go from axioms to practice.

Agility: Spammers must escape detection. Understanding network-level behavior and detecting agility (BGP, DNS)

Exposure: Spammers behave differently. Supervised learning based on features, but which features to use?

Coordination: Spammers behave like each other. Clustering based on common behavior, but what behaviors cluster well?

Finally, there are the content providers. Personalization is creating situations where we only see things that already suit our own tastes, but this can be exploited. There is a need to detect inconsistent results, and detect pollution attacks. His work Bobble bursts the filter bubble. 

Nick's talk contained a lot of interesting information. It really gives us a perspective on how the many stakeholders in the Internet affect the user experience. I could write several blog articles about them, but I thought I would just give a summary and have you visit his site if you are more interested in his work. 

[frankspeech-blog]

Jim Gettys on Embedded Systems Security

Jim Gettys, a programmer at Bells Labs, gave a talk at the MIT security seminar on embedded systems security. Jim has done a lot of interesting work in many spheres (http://en.wikipedia.org/wiki/Jim_Gettys).

Jim starts by talking about the following article (http://www.wired.com/opinion/2014/01/theres-no-good-way-to-patch-the-internet-of-things-and-thats-a-huge-problem/). In summary, Jim instigated this article and helped Bruce write it, but he believes there are many parts that are understated. In other words, the problem with security for embedded devices is worse than Bruce describes.

Jim refers to the following conference paper called "Familiarity Breeds Contempt: The Honeymoon Effect and the Role of Legacy Code in Zero-day Vulnerabilities." I read this article, and the real world implications are immense. There are two main takeaways. First, the length of time between the release of the product and the discovery of the first vulnerability is a function of the familiarity with the product. Second, legacy code re-use contributes to discovery rate of vulnerabilities and the number of vulnerabilities. For more details, I refer you to the actual paper (http://dl.acm.org/citation.cfm?id=1920299).

The idea is that you cannot leave software and devices unmaintained. Product must have secure update streams for the life of the product. We are getting better at doing this with automatic updates for operating systems, applications, and software, but how about home routers and modems? 

Home routers and modems are usually unmaintained and unpatched. They also start with four year old code, and the firmware is usually not updated after one year. Embedded devices like Nest thermostats are no different from routers except they don't route you from place to place on the Internet. There are major problems because research results show single vulnerabilities affect more than half tested routers. DNSchanger attacked home routers as well as hosts. There is TheMoon worm, and the problems go on and on. 

One of the biggest problems we have is the binary blob disaster. Silicon vendors design board support packages for their silicon to original device manufacturers (ODMs) for possible "design wins." They have a static version of Linux and its applications, and they write a device driver, usually a binary blob. The code for these blogs are poor. ODMs have no incentive for updates until the next generation silicon is shopped. ODMs cannot update to current software to fix vulnerabilities. 

There is a major disconnect of incentives. The silicon vendor has incentive for design wins, but software is an after-thought. ODMs have little software expertise and they are happy as long as the device doesn't crash or get bad reviews. 

What these devices really need is a secure boot loader. Users must be able to unlock them, and cost for this loader is minimal. OpenFirmware does all the required crypto, etc. The solution is to apply existing technologies to a real code base.

Some interesting open source router projects are OpenWrt/CeroWrt. If you're interested, I encourage you to check them out.

[frankspeech-blog]

User Managed Access Protocol

Thomas Hardjono presented "Consent Management using User Managed Access (UMA)"

The problem: There is a "data price" for being online because companies use your data for some form of profit (ads, analytics, etc.). This means that currently, users consent to releasing their data and information under unfavorable terms that usually involve oversharing. It's easy but unsuitable for really sensitive data. OAuth 2.0 is an example of current authorization framework to access data. It allows a client to get access to data at a resource server by getting an authorization token from an authorization server. This, of course, presumes authentication occurs somewhere else. However, this is not ideal for the user. 

Challenges: There are several design constraints. We need RESTful Web-APIs. It needs to work over HTTP/S. There needs to be minimal session management and interact with the browser.

Solution: We want a user centric web access control manager. There is a single point of policy/user configuration. This works for multiple protected resources across multiple resource servers. Finally, all of this should be "legally" owned by the user. The idea is to overlay on top of OAuth 2.0 with profile for OpenID and OAuth 2.0.

This is an ongoing effort to give users more control over their data and who accesses it. I think this is an interesting framework to integrate into the current web framework. To find out more information about the talk, you can access the slides here (http://www.findthomas.net/blog/papers/Introduction_to_UMA_CSAIL_Feb2014.pdf)

[frankspeech-blog]

Restarting the Blog

It's been a while since I have written anything security related on this blog. Being a MIT graduate student and adjusting to the cold weather in Boston have taken a lot of my time recently. However, I have been just given the role to run the MIT security seminar. We have some of the best security experts come and give talks! You can find past speakers and abstracts of the talks here (http://nms.csail.mit.edu/sys-security/). 

I plan to blog about most of the talks given at the security seminar. If you are around Boston and would like to give a talk, feel free to contact me! My contact information can be found on my website (http://web.mit.edu/frankw/www/). 

[parislemon]

[frankspeech-blog]

parislemon:

Apple’s vision for the future of computing versus Microsoft’s vision for the future of computing.

Any questions?

[frankspeech-blog]

Design Etiquette

This article provides good insight into design etiquette. There is a constant battle between developers and designers when really in reality, both would benefit from better collaboration and interaction. The article outlines common mistakes that irk both sides and some solutions for both developers and designers so that time is spent designing and implementing awesome interfaces rather than in disputes.

http://bit.ly/nLBl5S

[superhappyfunfungogofriends-blog]

[iheartfroyo]

[frankspeech-blog]

iheartfroyo:

Covers the basics of clean visual design.

[infoneer-pulse]

[frankspeech-blog]

infoneer-pulse:

There are computer security threats — and then there are computer security nightmares. Put sabotaged circuits firmly in the second category. Last week, retired Gen. Michael Hayden, the former CIA and NSA chief, called the hazard of hacked hardware “the problem from hell.”

“Frankly, it’s not a problem that can be solved,” he added. “This is a condition that you have to manage.”

» via Wired

[frankspeech-blog]

Tracking using HTTP redirects

One of the researchers in our security lab came up with a pretty interesting scheme that allows a website to track users that block cookies. The essence of the protocol involves using HTTP 301 redirects. More specific regarding URL redirection can be found at this wikipedia page. http://en.wikipedia.org/wiki/URL_redirection

The way that HTTP 301 redirects works is that when you visit a website such as one that uses bit.ly, it redirects the browser to a URL where the content is permanently located. This is done using a HTTP 301 header. In order to track users, when a user visits a webpage, the website checks to see if there is a unique identifier in the url (trackingwebsite.com/index.php?id=num). If there isn't, then it uses a HTTP 301 header to redirect to a URL that contains a unique identifier in the header. The browser then caches this website because it believes that the content is permanently located here. 

It is clear that this technique is subject to browser compatibility. More information regarding this scheme and regarding compatibility can be found at http://elie.im/blog/security/tracking-users-that-block-cookies-with-a-http-redirect/ . There are also other blog posts about security that are interesting at this researcher's blog.

[frankspeech-blog]

A Journey to Understanding Stuxnet

This is an interesting story from Wired of how Symantec security researchers along with a couple of German researchers initially discovered Stuxnet. It takes you through their discovery of the various complex and sophisticated components of the malware. It really illuminates why Stuxnet was such an interesting and unique piece of malware. Stuxnet used four zero-day vulnerabilities and had 2 forged valid certificates. I encourage anyone with an interest in security to read this article. 

http://www.wired.com/threatlevel/2011/07/how-digital-detectives-deciphered-stuxnet/all/1