Re: Preventing Denial of Service Attack In IPC Serialization
On Jun 19, 6:36 am, jlind...@hotmail.com wrote:
A variation of this attack is the example of deserializing
vector<string>. You can't determine from the size of the vector how
much actual memory the vector and all of its strings will consume
until you've deserialized the whole thing. Why? Because string
requires a variable amount of memory. Deserializing a vector<string>
of 1,000,000 strings might be fine if the strings were all 10 bytes
long, but if they were all 32,000 bytes long, you're in trouble.
Trying to place limits on the count of a vector isn't a very good
solution.
And just how would an attacker be able to do that, if the receiver
only accepts messages whose total length is less than some
predetermined value?
Accepting a "message" whose length is of some predetermined value
would be ruinous to the whole serialization model. I must admit, I do
not (yet) see what you see.
Also, I re-read one of your earlier posts to try to understand what
you mean:
I wrote:
Also, how does one send count=1024x1024 elements in your scheme?
You wrote:
In exactly the same way. Serialize a count and then serialize each
element in the container.
If we're talking about a single-byte string with 1024*1024 characters,
the resulting data packet will be a little bit larger than 1Mb. The
sender doesn't worry about that, but if the receiver has its maximum
packet size set to e.g. 1 Mb, then the packet, and the TCP connection,
will be discarded as soon as the packet length field is read. What the
client has to do then, is to resend the string, in several sub-1Mb
packets, and inform the receiver that the strings are to be assembled.
I do not think this is a solution. Breaking the string into sub-1MB
"packets" will not solve the problem. In the end, there will receiver
will have still allocated 1MB data, which might turn out to be a DoS
attack. Furthermore, the allocate/deallocate/allocate/deallocate
method that you use for std::string and std::vector<string>
serialization probably takes a heavy toll on the memory allocator. In
my original post, I showed how the receiver could be tricked into
invoking operator new() on say, a bogus unsigned int sent by the
sender. But I should have showed that the problem is more general,
meaning that the goal is to prevent the sender from inducing the
receiver to "eventually" allocate too much memory, in this case, 1MB.
I have given detailed descriptions in earlier posts, apparently to no
effect, on how one would deserialize both std::vector and std::string.
The problems discussed in this thread are 100% due to the misguided
use of constructs like "socket >> s". If programmers use such flawed
constructs, of course they will have problems. The problems will be of
such a difficult nature that they might even be tempted to start a
thread here on clcm about them. And then invent complex "solutions".
As soon as you scrap the deserialization-out-of-a-socket idiom, all
the "problems" discussed in this thread just vanish.
First, surely you will admit that there are many programmers who think
that they can take their serialization code, write it once for a base
class (let's call it Archive), and then use it later against any class
that derives from Archive, including a Socket.
Also, there are some subtleties with your only-accept-less-than-1MB
scheme that I did not want to mention since this is new territory for
some of us. It involves, again, the serialization framework itself.
If we are to use any serialization at all against a socket, then the
code has to be "clean". The serialization code must be encapsulated
in a library. One cannot go back and twiddle with it after it exists
as a binary.
That said, it is not clear to me how you would define where one 1MB
message begins and the other ends. 1MB? What is that? Is it a TCP
segment? It is certainly not a UDP payload or Ethernet frame. The
latter is limited to 1500 bytes, and the former must be even smaller.
Furthermore, serialized data is boundary agnostic. Let us assume that
your 1MB buffer is 1024x1024 bytes. Then:
Socket s;
int i; // assume that sizeof(int) == 4, and char is 8-bit-byte
s >> i; // now we have taken 4 bytes from 1MB buffer.
char c;
for (i = 0; i < 1024*1024 - 17)
s >> c;
// Now we have 13 bytes left:
std::list<string> names;
s >> names; // Oooops...tried to read the "size" of one of the
strings in "names", failed.
Because a "weird" number of bytes were left, building one of the
strings in names failed. There was an underflow from insufficient
data. What do we do now IIUC, you stated that the way to check that
there is a DoS attack is when the buffer underflows.? How do we
distinguish between DoS attack and simply underflow?
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]