Re: Preventing Denial of Service Attack In IPC Serialization
On Jun 12, 1:51 am, jlind...@hotmail.com wrote:
But _why_ do you deserialize out of a socket, when it has
insurmountable problems like these associated with it?
Because several designers of serialization frameworks (including
myself until recently) either stated explicitly or implicitly that it
was a good idea. I have refrained from identifying the other, well-
known, serialization frameworks that suggest that it is a good idea to
use serialization code that was meant for, say, File, against a
Socket.
And even in secure mode, the problems remain. How do you handle a
misguided but wellmeaning sender who starts sending you a 1Gb string?
Does your receiver just stand there and say "This connection is
secured, so I will swallow every byte that comes down" ?
When I write my software, I make a distinction between the warm-bodied
human being that we call "the user" and "the client program" that the
user wrote. In addition, "security" has multiple meanings. There are
some connections where there is privacy against a connection. This
type of connection is will not help. There are other connections where
there is authenticity of the transmission units (packets), and in this
connects, once the connection is kick-started, we can then proceed
discuss the following fact:
*If* the connection is secure, meaning the server is certain of the
authenticity of packets received from client, and if the server-end of
the protocol by which the connection between client and server is
brought to a secure state abstains from invoking operator new()
against potentially large, arbitrary values that would cause excessive
memory allocation (!GB) on the server end, then once the connection
has entered the secure state, the sever and client can then relax and
continue. Note that I have been portraying the client as the
perpetrator and the server as the victim, but this distinct is
arbitrary - it could very well be vice-versa.
Now you might say, "But there are situation where DoS could still
happen where server has published the specification for serialization
sequence, and clients connect 'securely', but the set of clients allow
to connect is large and unknown at the time the server begins
executing."
To this I would say you are right. I had intended to mentioned this
problem, and a third serious problem on this issue in a forthcoming
post.
So despite the insurmountable problems you've found, you still find it
conceivable to serialize to/from a socket archive? In what context
would it possibly be legitimate?
No I guess I do not. As I mentioned, my gut feeling is that there is
no simple solution to this "problem". However, note that I am not the
only programmer who has created a serialization framework and
suggested, either implicitly or explicitly, that it is a good idea to
use the same code against a Socket as one has written to work against
a File. My point in writing this post is to at least make other
programmers aware that, if they want to use vanilla serialization code
against an un-secured or semi-secured socket, they are in trouble. I
know of at least one major financial company, with $1 Trillion (US) in
assests, who does this routinely for all their servers. If I wanted
to, I could probably write a program that would systematically crash
the machines 1 by 1, giving a block of IP addresses to start with,
assuming of course I managed to get past the firewalls.
IMO, the case were it is OK to use the same serialization code against
a Socket that has been written for, say, File, is when:
1. The Serialization code on client end matches that at the server
end, either by using a library or because the engineers at each end
were meticulous in getting the protocol correct.
2. The channel is secure in the sense of mutual certainty of
authenticity of the client and server, and the bootstrap procedure in
getting to a state of mutual certainty of authenticity strictly
abstains from using operator new() or anything that could result in
resource starvation.
If anyone says that you say that #1 is unrealistic if the client
programmer and the server programmer is disjoint, then I would say
that is the same issue as putting bad code in the market. For
instance, I have a device driver that I thought was pretty much bug-
free until I ran it under a virtual machine in Windows. It blue-
screens the virtual machine, each time, every time, though testing had
been done thoroughly on real machines. Who would have thought? So we
have to fix this, but once it is fixed, it is fixed.
What makes you think you can entwine serialization with storage/
network transmission/etc. , in the first place? Serialization is
conversion into a sequence of bytes, nothing more, nothing less.
Microsoft made me think that:
http://msdn2.microsoft.com/en-us/library/dya2hz72(VS.80).aspx.
Though I have never used their serialization framework, I believe that
CFile is derived from CArchive, an so..
http://msdn2.microsoft.com/en-us/library/dya2hz72(VS.80).aspx
Well, the problem you brought forth was stated like this:
"I means that, for all the applications on the Internet that uses
unprotected serialization of the kind provided by Boost,/etc...they
are all vulnerable to DoS attack."
, and is patently untrue. It only applies to frameworks that naively
conflate deserialization and network reception.
This statement is contradictory. I said that if a user does X, Y will
happen. And you're saying, "that's not true", it will only happen
when the user does X.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]