On Sat, Jun 29, 2013 at 10:24 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:

Cristian-Matei Toader:

...

Hello,

My name is Cristian Toader, and I feel very excited about designing and implementing a capabilities based sandbox for the central Tor project, as part of the GSOC program.

Welcome!

...

---- About myself:

I have been a Linux enthusiast for almost 6 years and have first started using Tor around 3 years ago.

I am currently studying in the UK. In approximately one month I will be graduating the Computer Science programme at the University of Surrey, and plan on pursuing a master's degree in Advanced Computer Science at the University of Cambridge for the following academic year.

I have completed a placement year at Qualcomm (UK) LTD which involved implementing and testing security solutions for the Linux Android OS. These were based on cryptography and the TrustZone run-mode of the ARM processors. Most of the development during the placement year was performed in C, with some tests written in Java and C++ for the upper layers.

That sounds great - I've been doing some work on Tor on ARM lately. I think this kind of experience is really useful - which ARM SOC boards are you familiar with?

I wouldn't say familiar, since there is so much to know about the architecture, but during the internship I have worked with 8660 and 8960 boards (early snapdragon builds). The only hardware interaction I had however was trace32 debugging and writing a bus driver for a prototype feature in trustzone. The team was mainly focused on the HLOS (only android during my internship) so I got to learn a bit about everything, it was a good experience. I would gladly help you if I can. Are you doing something like porting tor for android as a service using the NDK?

...

---- About the project:

The project I will be working on as part of GSOC is based on the "Run With Limited Capabilities" proposal [1] mentored by Nick Mathewson (nickm) and Andrea Shepard (athena). The project is still in the planning stage. I will start working on an appropriate design as soon as I finish my last exams, which is the 3rd of June.

As part of the project I will need to: - investigate research papers regarding capability based sandboxes - get familiar with the Tor code structure - decide on whether there should be different states starting from which the tor program only has a limited set of capabilities, depending on what syscalls it should be able to perform; or maybe have a more complex approach based on a trusted process representing a root of trust (with no network interactions) which controls the capabilities of the processes it launches - integrate an appropriate solution - develop and run tests for the project

This sounds great. I've experimented a bit with (lib)seccomp filters, seatbelt, AppArmor, SELinux and other related systems as they apply to TBB, tlsdate and tor itself. I'm happy to code review, to generally think over the designs and so on.

...

A constraint agreed with nickm, would be that once the program capabilities are set they should not be modifiable (otherwise a potential attacker could have the option of first enabling capabilities and then execute privileged code).

Sure - this is something seen with ROP gadgets - is there a write protected area of memory? First, mark it as unprotected, then carry on, etc.

Not sure what you meant with the protected area of memory, but what I meant was something like filter the syscall that changes capabilities such that it cannot be used, so if you did get a ROP attack it wouldn't be able to basically disable the sandbox.

...

Some additional details can be found in tickets #7005 [2], #5219 [3], and #5220 [4].

I will try to keep everyone updated. I am looking forward to advice and suggestions. If anyone needs to contact me, this is my primary email, my irc.oftc.net username is ctoader, and I am geographically located in GMT+2.

Sounds good - i'm 'ioerror' on #tor-dev - feel free to reach out to me or others.

Welcome to the Tor community!

All the best, Jacob

Thank you for the welcome, I've seen you around on #tor-dev and will definitely ask for advice if needed!

On 2013-07-01 16:59 , André Nunes Batista wrote:

Sorry, to bump in, I know you are busy, but being a tor-node I had to ask:

Some guy just posted on mailing list an conceptual attack on tor, which certainly would require the corruption of great deal of tor-nodes and data analysis, but something that appeared possible gor gov-alike:

http://pastebin.com/pRiMx0CW

And then someone pointed that this is part of tor model of security and known problem, but one that should raise flags if attempted. Could you point me some link where I can find more? Besides reading source code?

Note that "Tor developers" is not the set of people who control the directory authorities, though there is some overlap.

From the text:

Most interestingly, the public keys for every other node in the network is served without any form of signature or other form of integrity control.

Public-key authentication takes care of that, you can verify them yourself by connecting and seeing if they have the private one matching the public one they claim to have. also from that text:

As such, a rogue directory authority, which anyone can be simply with a configuration option and an IP

You can indeed locally configure a wrong directory authority, but then you are building your own tor network anyway, thus that is completely standard. Near-zero people do this though and all use the standard built-in authorities, against protected with pubkey infra and also by the consensus that is mentioned on the first line of that piece of text. Also please note that trusting a person who writes "think their competent" is him/her/itself exactly not that, especially from an anonymous source. FUD comes to mind ;) Note that there are a couple of papers out there (See http://freehaven.net/anonbib/ eg "Trawling for Tor Hidden Services") that do describe ways that it could be done to attack Tor given enough effort, the above does not describe any of that. And those attacks would only deny access, they would not be able to see the actual inner text of the data. Greets, Jeroen -- For archival purposes: http://pastebin.com/pRiMx0CW Untitled BY: A GUEST ON JUN 28TH, 2013 | SYNTAX: NONE | SIZE: 1.90 KB | HITS: 493 | EXPIRES: NEVER Tor LOL: directory authorities are the point of contact for clients to locate relays/exit nodes/guard nodes/etc. This is determined by a consensus document that goes through an elaborate process to ensure its integrity and cause bad directory authorities to be identified also via consensus. However, Tor developers are not the quickest lot, and this is basically the only document that they serve that has integrity control on it. Most interestingly, the public keys for every other node in the network is served without any form of signature or other form of integrity control. As such, a rogue directory authority, which anyone can be simply with a configuration option and an IP, can introduce path bias and other such tricks by serving the wrong keys for relays/guards/exits that it doesnt control. This can result in essentially directing clients through the network by causing decryption failures, thereby allowing determination of the source and end-point of a given tor connection with little more than a couple relays and some rogue directory authorities. Moreover, it can use the simple-minded metrics made to identify rogue guard nodes and couple that together with the behavior of public key cryptography to actually cause legitimate guard nodes to be flagged as having excessive extend cell failures causing it ultimately to be marked as bad. As such, this entirely mitigates the half-witted fixes guard nodes were intended to fix, by introducing rogue guards that work in conjunction with rogue directory authorities, whom serve bad public keys for all nodes except for their own giving them the ability to cause clients to reconnect to guard nodes at their leisure. These are design flaws in tor. Don't outsource your security, especially if its to people like appelbaum and other incompetents. The fact is the US government doesn't need to backdoor Tor, they just get to let the dunces think their competent.

Thank you both! -- Luther Blisset GNUPG/PGP KEY: 6722CF80 I challenge you to play the game in which there is no loser but everything is fun and worthwhile!