[tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Oct 25 09:18:22 UTC 2017
#23512: Bandwidth stats watermark can be induced using OOM killer
-------------------------------------------------+-------------------------
Reporter: asn | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| 0.3.3.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-bug-bounty, congestion-attack, | Actual Points:
research, watermark, tor-stats, guard- |
discovery-stats |
Parent ID: | Points:
Reviewer: | Sponsor:
| SponsorQ
-------------------------------------------------+-------------------------
Comment (by Jaym):
Replying to [comment:6 arma]:
> Mike: I talked to Jaym about this topic at PETS. I think at the time I
was under the impression that we are incrementing the *write* counter,
that is, the outbound connection, even though we never actually push the
bytes out to the network because we kill the outbuf in the oom killer.
>
> So I had thought that the bug was "we say that we wrote out the bytes
even though we didn't", which allows an attacker to queue up a bunch of
bytes for us to outbuf, and generate an artificially large signal.
>
Yes, because of the first version of the paper you reviewed I considered
the wrong counter. This counter actually behaves exactly like you describe
above but this was not the counter used to report bandwidth in the extra-
info descriptor. With your review, you made me realize that this problem
actually happens with the read counter.
The up-to-date version of the paper I sent you in the beginning of
September corrects the explanation and gives more details (given to asn
too, which explains why you see difference in asn's description with you
original thoughts). I also added chutney experiments to observe the
difference in read/write that can be reproduced with this code
(https://github.com/popets18dropping/code_and_data/tree/master/hs_drop_attack).
> If that is the issue (which contradicts asn's summary above I think),
then there would be a second piece to the fix, since if we only
decremented the write count to stop including the bytes we didn't actually
write, then we would have an asymmetry between the (still much higher)
read count and the (now corrected) write count. So the second part of the
fix would be to decrement the read count by the corresponding amount too,
so things match up.
Yep. If needed I can help testing the fix with the code linked above.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23512#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list