[tor-bugs] #7912 [Tor]: Cells that don't get inserted into cell queues can clog connection flushing

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

#7912: Cells that don't get inserted into cell queues can clog connection flushing
-----------------------+----------------------------------------------------
 Reporter:  asn        |          Owner:                    
     Type:  defect     |         Status:  new               
 Priority:  normal     |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor        |        Version:                    
 Keywords:  tor-relay  |         Parent:                    
   Points:             |   Actualpoints:                    
-----------------------+----------------------------------------------------
 Reported by `oftc_must_be_destroyed`.

 IIUC, the idea is that if you force a relay to send a big amount of
 destroy cells you might be able to clog its `connection_or_flushed_some()`
 because destroy cells get sent directly to the outbuf instead of a cell
 queue.

 {{{
 < oftc_must_be_destroyed> ok. new attack is about privilage cell types
 thats going to outbuf dicetly bypass cell queues
 < asn_> are cell queues there for rate limiting etc.?
 < oftc_must_be_destroyed> no it's about flushing of cells
 < oftc_must_be_destroyed> connection_or_flushed_some it can't flush any
 cells from queues if connection_get_outbuf_len <= 16KB
 < oftc_must_be_destroyed> >=
 < oftc_must_be_destroyed> if we can trigger filling buf with special cells
 then queues nevr flushes
 < oftc_must_be_destroyed> cell queues was implemented to prevent huge
 growing outbut and fregmanting memery and linux malloc
 < oftc_must_be_destroyed> and to fix this keyboard
 < oftc_must_be_destroyed> exploiting it'so easy with create cell and
 proper handling truncated circ
 < oftc_must_be_destroyed> you choose two relay that need to stop circuit
 from a to b
 < oftc_must_be_destroyed> connect to b create, extend with some defect
 < oftc_must_be_destroyed> a answer with destroy, b convert it to truncated
 < oftc_must_be_destroyed> client handle and repeats
 < oftc_must_be_destroyed> dozen such circs and buffer filled with destroy
 cells only
 < oftc_must_be_destroyed> what do you think?
 < asn_> why does it flush only if datalen < OR_CONN_LOWWATER?
 < asn_> why doesn't it always flush some data?
 < oftc_must_be_destroyed> so no fragm memory
 < oftc_must_be_destroyed> no need too low no need too high
 < oftc_must_be_destroyed> problem is cell types that never queued
 < oftc_must_be_destroyed> not a such func
 < oftc_must_be_destroyed> at lease destroy cell type
 < oftc_must_be_destroyed> least
 < oftc_must_be_destroyed> all another can't be triggered remotely for
 enomurous number
 < asn_> which function queues cells?
 < oftc_must_be_destroyed> and you can't it append to queue so easy
 < asn_> i would like to see why destroy cell doesn't get queued
 < oftc_must_be_destroyed> append_cell_to_circuit_queue
 < oftc_must_be_destroyed> bcs it never queued
 < oftc_must_be_destroyed> connection_or_send_destroy
 < oftc_must_be_destroyed> destroy cell mast be sent even if circ already
 freed
 < asn_> is this the case even for 0.2.4.x where the channel code is
 implemented?
 < oftc_must_be_destroyed> yes
 < oftc_must_be_destroyed> why not?
 < oftc_must_be_destroyed> it's about out of bound logic for destroy cell
 < oftc_must_be_destroyed> never like destroy cell
 < oftc_must_be_destroyed> it can be delivered before any data
 < oftc_must_be_destroyed> and that data must be cleared
 < asn_> so you think you can fill 16KB of the outbuf of a relay with
 destroy cells?
 < asn_> if each destroy cell is 512bytes
 < asn_> you will need 32 cells or something
 < asn_> you think you can create that many cells without any of them
 getting flushed first?
 < oftc_must_be_destroyed> repeating of creating req (extend)
 < oftc_must_be_destroyed> dozen circs
 }}}

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7912>
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