Re: TCP stack attack?

[coderman <coderman@xxxxxxxxx>]

On Sat, Oct 23, 2010 at 5:59 PM, Robert Ransom <rransom.8774@xxxxxxxxx> wrote:
> On Sat, 23 Oct 2010 12:42:11 -0700
> Julie C <julie@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/