Re: Preventing Denial of Service Attack In IPC Serialization
On May 27, 8:24 pm, John Moeller <fishc...@gmail.com> wrote:
Maciej Sobczak wrote:
Use hard limit on this count field and reject messages that do not
comply. Document this hard limit as part of the communication
protocol.
For those who want to take the responsibility on them, allow to modify
this limit by parameterizing the communication library (macro
definitions, configuration files, constructor parameters, etc.).
So you are saying for all 190 C++ classes that I have that are
serializable, I should find a way to specify hard limits on the size
of what is being serialized, including not only strings, but a family
of containers that includes at least 30 containers? Do I specify a
maximum number of elements that can be serialized to/from the
container?
The following library is an example of using this strategy:
http://www.msobczak.com/prog/yami
In general, don't think that you should allow everybody to do
everything - there is absolutely no need to do so. Just set up your
rules and reject everything that looks strange. If there is a genuine
need for sending longer packets, users can either reconfigure the
library by using the limit parameter (and then it's *their* business
if they get into DOS) or they can send long content by chopping it
into smaller parts.
Let's say that I specify the hard limit for class String<> to be 4096
characters, an arbitrary but reasonable value. Let's say also that I
specify the number of elements in a List<> to be 65,636 elements,
again, an arbitrary but reasonable value. Calculating the maximum
amount of memory that can be consumed by a DoS attacker, we get
2^16*2^12 = 256 MB. So an attacker, using the system in a "safe"
mode, could easily break the model. It should be intuitively obvious
that it is impossible to have both generalized plurality and defense
against this type of attack simultaneously. Even with
parameterization of how much memory can be allocated, there is still
the question of where the user of my library should specify (and how),
what limits should be set. It should also be intuitively apparent
that there comes a point where, if the user of the library is so busy
putting checks in the code to limit this type of attack, the ease-of-
use is destroyed. And again, whatever values chosen would be
arbitrary, and because objects are hierarchical, with unpredictable
level of nesting, the whole thing would quickly turn into a monstrous
mess.
I would be very curious to know what Boost Serialization does in this
situation, if anyone knows.
I absolutely agree. Another thing you may want to consider is to get
away from the idea of a "secure mode" and offer several "tunable"
parameters. If the user wants to mess with the hard limit, they can do
so, at their own risk, but can leave the other parameters at their
defaults that help secure your protocol.
The security mechanisms were not created for this problem. They were
created for the generalized problem of proving security in the
Internet (in a research sense). It is only by fortune that, if the
nodes are connected over a secure channel, the deliberate attacks are
no longer possible.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]