It’s been a busy year for Capsicum, practical capabilities for UNIX, so a year-end update seemed in order:
The FreeBSD Foundation and Google jointly funded a Capsicum Integration Project that took place throughout 2013 — described by Foundation project technical director Ed Maste in a recent blog article. Pawel Jakub Dawidek refined several Capsicum APIs, improving support for ioctls and increasing the number of supported capability rights for FreeBSD 10. He also developed Casper, a helper daemon that provides services (such as DNS, access to random numbers) to sandboxes — and can, itself, sandbox services. Casper is now in the FreeBSD 11.x development branch, enabled by default, and should appear in FreeBSD 10.1. The Google Open Source Program Office (OSPO) blog also carried a September 2013 article on their support for open-source security, featuring Capsicum.
Capsicum is enabled by default in the forthcoming FreeBSD 10.0 release — capability mode, capabilities, and process descriptors are available in the out-of-the-box GENERIC kernel. A number of system services use Capsicum to sandbox themselves — such as the DHCP client, high-availability storage daemon, audit log distribution daemon, but also command-line tools like kdump and tcpdump that handle risky data. Even more will appear in FreeBSD 10.1 next year, now that Casper is available.
David Drysdale at Google announced Capsicum for Linux, an adaptation of Linux to provide Capsicum’s capability mode and capabilities, in November 2013. David and Ben Laurie visited us in Cambridge multiple times this year to discuss the design and implementation, review newer Capsicum APIs, and talk about future directions. They hope to upstream this work to the Linux community. Joris Giovannangeli also announced an adaptation of Capsicum to DragonFlyBSD in October 2013.
Over the summer, Mariusz Zaborski and Daniel Peryolon were funded by Google Summer of Code to work on a variety of new Capsicum features and services, adapting core UNIX components and third-party applications to support sandboxing. For example, Mariusz looked at sandboxing BSD grep: if a vulnerability arises in grep’s regular-expression matching, why should processing a file of malicious origin yield full rights to your UNIX account?
In May 2013, our colleagues at the University of Wisconsin, Madison, led by Bill Harris, published a paper at the IEEE Symposium on Security and Privacy (“Oakland”) on “Declarative, Temporal, and Practical Programming with Capabilities” — how to model program behaviour, and automatically transform some classes of applications to use Capsicum sandboxing. We were very pleased to lend a hand with this work, and feel the art of programming for compartmentalisation is a key research challenge. We also collaborated with folk at SRI and Google on a a workshop paper developing our ideas about application compartmentalisation, which appeared at the Security Protocols Workshop here in Cambridge in March 2013.
Google and the FreeBSD Foundation are committed to further work on Capsicum and its integration with applications, and research continues on how to apply Capsicum at several institutions including here at Cambridge. We hope to kick off a new batch of application adaptation in coming months — as well as integration with features such as DNSSEC. However, we also need your help in adapting applications to use Capsicum on systems that support it!
December 20th, 2013 at 23:02 UTC
Next year’s Workshop on the Economics of Information Security (WEIS 2014) will be at Penn State on June 23–24. The call for papers is now out; papers are due by the end of February.
It will be fascinating to see what effects the Snowden revelations will have on the community’s thinking about security standards and regulation, the incentives for information sharing and cooperation, and the economics of privacy, to mention only three of the workshop’s usual topics. Now that we’ve had six months to think things through, how do you think the security game has changed, and why? Do we need minor changes to our models, or major ones? Are we in the same policy world, or a quite different one? WEIS could be particularly interesting next year. Get writing!
December 15th, 2013 at 17:17 UTC
Your medical records are now officially on sale. American drug companies now learn that MedRed BT Health Cloud will provide public access to 50 million de-identified patient records from UK.
David Cameron announced in 2011 that every NHS patient would be a research patient, with their records opened up to private healthcare firms. He promised that our records would be anonymised and we’d have a right to opt out. I pointed out that anonymisation doesn’t work very well (as did the Royal Society) but the Information Commissioner predictably went along with the charade (and lobbyists are busy fixing up the new data protection regulation in Brussels to leave huge loopholes for health service management and research). The government duly started to compel the upload of GP data, to join the hospital data it already has. During the launch of a medical confidentiality campaign the health secretary promised to respect existing opt-outs but has now reneged on his promise.
The data being put online by BT appear to be the data it already manages from the Secondary Uses Service, which is mostly populated by records of finished consultant episodes from hospitals. These are pseudonymised by removing names and addresses but still have patient postcodes and dates of birth; patient views on this were ignored. I wonder if US purchasers will get these data items? I also wonder whether patients will be able to opt out of SUS? Campaigners have sent freedom of information requests to hundreds of hospitals to find out; so we should know soon enough.
November 22nd, 2013 at 10:40 UTC
Yesterday the heads of “MI5″, “MI6″ and GCHQ appeared before the Intelligence Security Committee of Parliament. The uncorrected transcript of their evidence is now online (or you can watch the video).
One of the questions fielded by Andrew Parker (“MI5″) was how many terrorist plots there had been over the past ten years. According to the uncorrected transcript (and this accords with listening to the video — question starts at 34:40) he said:
I think the number since… if I go back to 2005, rather than ten years… 7/7 is that there have been 34 plots towards terrorism that have been disrupted in this country, at all sizes and stages. I have referred publicly and previously, and my predecessors have, to the fact that one or two of those were major plots aimed at mass casualty that have been attempted each year. Of that 34, most of them, the vast majority, have been disrupted by active detection and intervention by the Agencies and the police. One or two of them, a small number, have failed because they just failed. The plans did not come together. But the vast majority by intervention.
I understand that to mean 34 plots over 8 years most but not all of which were disrupted, rather than just discovered. Of these, one or two per year were aimed at causing mass casualties (that’s 8 to 16 of them). I find it really quite surprising that such a rough guess of 8 to 16 major plots was not remarked upon by the Committee — but then they were being pretty soft generally in what they asked about.
The journalists who covered the story heard this all slightly differently, both as to how many plots were foiled by the agencies and how many were aimed at causing mass casualties!
November 8th, 2013 at 13:08 UTC
Today we’re presenting a new side-channel attack in PIN Skimmer: Inferring PINs Through The Camera and Microphone at SPSM 2013. We found that software on your smartphone can work out what PIN you’re entering by watching your face through the camera and listening for the clicks as you type. Previous researchers had shown how to work out PINs using the gyro and accelerometer; we found that the camera works about as well. We watch how your face appears to move as you jiggle your phone by typing.
There are implications for the design of electronic wallets using mechanisms such as Trustzone which enable some apps to run in a more secure sandbox. Such systems try to prevent sensitive data such as bank credentials being stolen by malware. Our work shows it’s not enough for your electronic wallet software to grab hold of the screen, the accelerometers and the gyro; you’d better lock down the video camera, and the still camera too while you’re at it. (Our attack can use the still camera in burst mode.)
We suggest ways in which mobile phone operating systems might mitigate the risks. Meanwhile, if you’re developing payment apps, you’d better be aware that these risks exist.
November 8th, 2013 at 12:19 UTC
Three of our clients have been acquitted of tampering with curfew tags after the Ministry of Justice and G4S were unwilling to have an independent forensic team examine their evidence. This brings to five the number of tag-tampering prosecutions that have been withdrawn or collapsed when the defence says “Right, prove it then.” I reported the first case here.
The three latest matters were high-profile terrorism cases, involving three of the nine men tagged under the new Terrorism Prevention and Investigation Measure (TPIM) – a kind of national-security ASBO handed out by MI5, and which had already been criticised by David Anderson QC, the government’s independent reviewer of terrorism legislation, for low standards of proof. Unlike a normal ASBO which a court gives “on the balance of probabilities”, you can get a TPIM if the Home Secretary declares she has a “reasonable suspicion”.
The Ministry of Justice should perhaps, when they let the tagging contracts, have read our 1994 paper on the John Munden case, or the post here about the similar case of Jane Badger. If you’re designing a system one of whose functions is to provide evidence, you’d better design it to withstand hostile review. “Trust us” doesn’t cut it in criminal trials, and neither does “I’m afraid that’s commercially confidential.”
November 3rd, 2013 at 10:24 UTC
Britain has just been hit by a storm; two people have been killed by falling trees, and one swept out to sea. The rail network is in chaos and over 100,000 homes lost electric power. What can security engineering teach about such events?
Risk communication could be very much better. The storm had been forecast for several days but the instructions and advice from authority have almost all been framed in vague and general terms. Our research on browser warnings shows that people mostly ignore vague warnings (“Warning – visiting this web site may harm your computer!”) but pay much more attention to concrete ones (such as “The site you are about to visit has been confirmed to contain software that poses a significant risk to you, with no tangible benefit. It would try to infect your computer with malware designed to steal your bank account and credit card details in order to defraud you”). In fact, making warnings more concrete is the only thing that works here – nudge favourites such as appealing to social norms, or authority, or even putting a cartoon face on the page to activate social cognition, don’t seem to have a significant effect in this context.
So how should the Met Office and the emergency services deal with the next storm?
October 28th, 2013 at 12:38 UTC
We have a vacancy for a postdoc to work on the economics of cybercrime for two years from January. It might suit someone with a PhD in economics or criminology and an interest in online crime; or a PhD in computer science with an interest in security and economics.
Security economics has grown rapidly in the last decade; security in global systems is usually an equilibrium that emerges from the selfish actions of many independent actors, and security failures often follow from perverse incentives. To understand better what works and what doesn’t, we need both theoretical models and empirical data. We have access to various large-scale sources of data relating to cybercrime – email spam, malware samples, DNS traffic, phishing URL feeds – and some or all of this data could be used in this research. We’re very open-minded about what work might be done on this project; possible topics include victim analysis, malware analysis, spam data mining, data visualisation, measuring attacks, how security scales (or fails to), and how cybercrime data could be shared better.
This is an international project involving colleagues at CMU, SMU and the NCFTA.
October 9th, 2013 at 08:05 UTC
ICANN have now published a draft for public comment of “A Study of Whois Privacy and Proxy Service Abuse“. I am the primary author of this report — the work being done whilst I was collaborating with the National Physical Laboratory (NPL) under EPSRC Grant EP/H018298/1.
This particular study was originally proposed by ICANN in 2010, one of several that were to examine the impact of domain registrants using privacy services (where the name of a domain registrant is published, but contact details are kept private) and proxy services (where even the domain licensee’s name is not made available on the public database).
ICANN wanted to know if a significant percentage of the domain names used to conduct illegal or harmful Internet activities are registered via privacy or proxy services to obscure the perpetrator’s identity? No surprises in our results: they are!
However, it’s more interesting to ask whether this percentage is somewhat higher than the usage of privacy or proxy services for entirely lawful and harmless Internet activities? This turned out NOT to be the case — for example banks use privacy and proxy services almost as often as the registrants of domains used in the hosting of child sexual abuse images; and the registrants of domains used to host (legal) adult pornography use privacy and proxy services more often than most (but not all) of the different types of malicious activity that we studied.
It’s also relevant to consider what other methods might be chosen by those involved in criminal activity to obscure their identities, because in the event of changes to privacy and proxy services, it is likely that they will turn to these alternatives.
Accordingly, we determined experimentally whether a significant percentage of the domain names we examined have been registered with incorrect Whois contact information – and specifically whether or not we could reach the domain registrant using a phone number from the Whois information. We asked them a single question in their native language “did you register this domain”?
We got somewhat variable results from our phone survey — but the pattern becomes clear if we consider whether there is any a priori hope at all of ringing up the domain registrant?
If we sum up the likelihoods:
- uses privacy or proxy service
- no (apparently valid) phone number in whois
- number is apparently valid, but fails to connect
- number reaches someone other than the registrant
then we find that for legal and harmless activities the probability of a phone call not being possible ranges between 24% (legal pharmacies on the Legitscript list) and 62% (owners of lawful websites that someone has broken into and installed phishing pages). For malicious activities the probability of failure is 88% or more, with typosquatting (which is a civil matter, rather than a criminal one) sitting at 68% (some of the typosquatters want to hide, some do not).
There’s lots of detail and supporting statistics in the report… and an executive summary for the time-challenged. It will provide real data, rather than just speculative anecdotes, to inform the debate around reforming Whois — and the difficulties of doing so.
September 25th, 2013 at 14:57 UTC
I was pleased to contribute to a recent blog article by Ben Laurie, a frequent collaborator with the Cambridge security group, on the Google Open Source Programs Office blog. We describe open-source security work OSPO has sponsored over the last couple of years, including our joint work on Capsicum, and its followup projects funded jointly by Google and the FreeBSD Foundation. He also talks about Google support for Certificate Transparency, OpenSSL, Tor, and Libpurple — projects focussed not just on communications security, but also communications privacy on the Internet.
Over the last decade or so, it has become increasingly (and painfully) apparent that ACLs and MAC, which were originally designed to protect expensive mainframes from their users, and the users from each other, are failing to secure modern cheap machines with single users who need protecting from the software they run.
Instead, we need fine-grained access control and strong sandboxing.
September 15th, 2013 at 09:39 UTC