Re: Preventing Denial of Service Attack In IPC Serialization

On May 31, 8:21 am, "Nevin :-] Liber" <n...@eviloverlord.com> wrote:


Actually, it does. If you have ever created a serialization
framework, you'd probably know that validation is not possible.

I am surprised at some of the responses here to be honest. It is
intuitively obvious to me that "validation" is not possible, and the
grab-and-realloc method facings the same issues - when is too much
memory too much? And given that class objects can be nested, per-
object limitations on allocated memory are completely arbitrary. This
should be evident from a container of objects.

map<int, map<int, map<int, map<int, Foo> > > > valid_object;

Socket s;

s << valid_object;

This is a reasonable piece of code in terms of the model it implies.
One can imagine how serialization for map<> might be implemented. If
Foo contains a string that is say, 800 bytes long, that is a
reasonable value for some strings. If the count of elements in a
map<> is 3500, that is a reasonable value for some map<>'s. But I can
take this structure and easily make its overall memory consumption on
the order of Gigabytes.

Then what? Should the internal map<>'s be artificially-intelligent
and say, "Uh oh...I detected that I am inside of something big and bad
going on..." Obviously they cannot. This will blow up at the server.

Furthermore, there is another problem that is insurmountable, I
think. It is highly reasonable that one legitimate client might
induce the server to allocate, say, 20 megabytes, on behalf of the
client. That 20 megabytes does not have to be allocated in one array-
chunk. It could be distributed over, say, the last 2000 objects
created by the server on behalf of the client.

I am going to repeat myself here because I can feel that, when I write
the last sentence, there are some reading this who are thinking, "Just
put limits on what's done."

I cannot do that. :) This is a serialization framework. I must be
able to provide a means of serializing an object, then hands off. If
I parameterize the allocation size, the size becomes arbitrary. And
given the nested map<>'s up above, it should be evident that, if I
make the per-array size too small, I deny legitimate clients. If I
make it too large, the malicious client can successfully attack. If I
choose something "reasonable", a malicious client can still attack.

An to reiterate, I have a secure-mode of operation where this issue is
not a problem.

The problem is when the link is insecure. And there are cases where
it is a legitimate necessity that the link be insecure.

I am beginning to think that a poor "solution" might be for the kernel
of the OS to allow per-thread quotas on allocated pages.

For those who keep saying, "Put a limit..", I encourage you to write C+
+ code to show how you would serialize a List<> template, and tell me
what limits you would use.

-Le Chaud Lapin-

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]