Re: Preventing Denial of Service Attack In IPC Serialization
On Jul 11, 9:22 am, jlind...@hotmail.com wrote:
Again, could you explain? If I understand your idea right, then the
application code sets an overall limit on how much data is read, then
the
objects can specify sublimits for how much they will read, and
subobjects
can specify further sublimits, and so on, but these sublimits can not
exceed the overall limit specified by the application. Is that right?
What
does it buy you, in terms of DoS protection, to have the objects specify
sublimits?
As Jeff mentioned in one of his earlier posts (I cannot find it), it
allows the receiver to tell more quickly if the sender is trying to
induce DoS. For example, if at some deeply nested level, a string is
being serialized into, and that particular string as a byte-limit of
say, 512 bytes, and the sender is declaring that the string is going
to be 4MB, then the receiver can immediately throw an exception
because the limit will be breached. Note that the exception is thrown
before any memory allocation of any kind at the receiver. So if the
sender wants to do a DoS attack, it will have to actually send the
data that would induce the attack while being deprived of the
simplicity of declaring that "much data is coming."
You are missing one crucial detail. Le Chaud Lapin does not impose an
overall limit *at all* ! That is why he finds himself forced to patch
his serialization framework with sublimits.
Not true.
My model prescribes both micro and macro imposition of limits. The
micro limits are needed for reasons above.
Also, as I mentioned before, the end-all pseduo-solution to this
problem will involve Little's Thereom and micro macro timers. I will
abstain from discussing why for now, but I mention it so that no one
can claim later that I was not thinking of it. ;)
When his senders send data, they don't specify up front how much data
they are sending. That is a major error, and stems directly from his
use of "socket archives". If he dispensed with that flawed concept,
and serialized a whole message to an intermediary buffer before
sending it, he could prefix a message length, and it would be a piece
of cake for the receiver to decide if the message should be accepted
or not.
The intermediate buffers do not help. In my model, the specification
of how much data is coming is done by the sender anyway, for objects.
The pseudo-solution is to let receiver apply limits to the socket
object using push_limit()/pop_limit(), both at a micro level, inside
of objects, and at a macro level, external to the serialization
library, with the external limits computed as a function of the
effective average arrival rate of connections, and the effective
average length of time that memory is retained on behalf of the
connections, but with hard minimum thresholds on memory to allow,
using Little's Thereom (http://en.wikipedia.org/wiki/Little
%27s_theorem).
For simple servers, it suffices to not use Little's Thereom, but
simply make a guess, hence the arbitrariness I mentioned.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]