Cells that don't get inserted into cell queues can clog connection flushing
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