Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs