[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #2324 [Tor Client]: realloc should check SIZE_T_CEILING too?
#2324: realloc should check SIZE_T_CEILING too?
-------------------------+--------------------------------------------------
Reporter: arma | Owner:
Type: defect | Status: needs_review
Priority: major | Milestone: Tor: 0.2.1.x-final
Component: Tor Client | Version: Tor: 0.2.1.26
Resolution: | Keywords:
Parent: |
-------------------------+--------------------------------------------------
Comment(by nickm):
>then it must be [...]
fixed.
> Why 25? Why not 20, 30? How it was calculated?
More or less arbitrarily. We only use zlib on our own file formats, and
all our current documents all compress around 2x-3x at best, so I figured
that anything that compresses an order of magnitude better than that is
either a very badly designed file format, or a zlib bomb.
More generally: There needs to be _some_ means to prevent zlib bombs.
The options I can think of are: a hard limit on how large something is
allowed to uncompress to (e.g, "The result of an uncompress operation may
not be larger than X") or a limit on the ratio of uncompressed to
compressed size (e.g., "out_size/in_size must be less than Y").
I prefer the second approach, since it more generically captures what is
is bad about zlib bombs: that they provide an attack multiplier where an
attacker can waste lots of your effort with relatively little bandwidth.
Given that, picking a value for Y is a trade-off: you want Y to be small
to limit the attack multiplier, but you also want Y to be large enough so
that no legitimate document --even ones we might invent in the future --
ever compresses by a factor of greater than Y. Within those parameters,
there's a reasonably large range of possible values. IMO, anything over
8 is probably safe; IMO anything under 50 is probably sufficient.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2324#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