On Sat, Oct 23, 2010 at 5:59 PM, Robert Ransom <rransom.8...@gmail.com> wrote: > On Sat, 23 Oct 2010 12:42:11 -0700 > Julie C <ju...@h-ck.ca> wrote: > >> Has anyone come across any TCP stack implementation vulnerability research? >> ... At this point in my education it strikes me that the TCP stack >> on any Tor node could be altered to do malicious things, and no one would >> ever know, or be able to know. > > Roughly every attack that can be performed in a Tor node's TCP stack > can also be performed by anyone that can stick his own hardware between > the Tor node and the Internet. There are some attacks that can be > performed there, but an attacker who can modify a Tor node's kernel > would be able to do more damage by reconfiguring or modifying Tor > itself.
long of it short: given the spectrum of OS level remote ring0 exploits in network device and protocol attack surface, there is a potential risk here. given all of the other risks [0][1], this is probably the least of your many concerns... best regards, 0. if I were to rank broad category, a. application level arbitrary execution or side channel attack. so many, so frequent to reify and persist, so easy to leverage for full privileged arbitrary execution, so many additional clauses to add but omitted for brevity. (remote w/ priv. escalation, direct remote root/ring0, local escalation, vm break-out, many others) b. Tor deployment weaknesses as commonly built, distributed, and used on various platforms, primarily Windows, Mac and various Linux and Unix like systems to a lesser extent for everyone but node operators. (ex. Unauthenticated control port access with cross protocol vector - implementation / deployment vulnerability) c. Tor usability or correctness deficiencies including the application layer (ex. Firefox with Tor Button Extension - application usability, Transparent Virtualized Privacy Router - configuration correctness: IP and DNS side channel elimination) d. everything else, including mundane issues like not using trojaned hardware out to exotic risk models with chained professional multi-0day targeted efforts or state agency actors. but not the risks that exist outside your threat model, or the un-identifiable and un-conjecturable unknown risks we can't predict or reason about. :/ i mentioned the "Threat Model", right? because this entire topic of conversation requires the presumptive act of you having pointed out the threat model you are assumed to be operating under and that we are both discussing. :) 1. remote ring0 do happen, c.f. CORE-2007-0219: OpenBSD's IPv6 mbufs remote kernel buffer overflow. fortunately these are rare, extremely valuable (likely to be exposed once propagating), and relatively infrequent compared to most other operating system vulnerability concerns. stuxnet is a good example of the exotic end of this spectrum; unless "you" yourself are a very well funded or state level actor you're pretty much fucked/ entirely and inevitably fucked. :P *********************************************************************** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/