Re: Preventing Denial of Service Attack In IPC Serialization
On Jul 7, 4:44 pm, jlind...@hotmail.com wrote:
I continue this discussion for the same reason that the moderators
allow it to continue: I search for truth, and I, like you, implicit in
our privilege as posters to this group, have a responsibility to seek
it.
When you present your arguments, the they are not just for our
benefit. They are for the benefit of everyone who reads this group
and wants to gain insight to truth. That is why it is so important to
see truth.
Let's dispense with the sermonizing and try to get our facts straight.
1) The flaw in B.Ser was pointed out by Sebastian Redl, not you.
2) The simple fix for it was also pointed out by Sebastian Redl.
3) That simple fix is valid, as long as one only passes in bounded
amounts of data to the deserialization framework.
I think we can agree on those 3 points.
No we cannot.
1. I pointed out very early in my post that it was "highly likely"
that other serialization frameworks, not just mine, was doing the same
thing that mine was doing. My post showing Boost Serialization code
"misbehaving" was a refutation that Jeff was beating a dead horse,
that there was no issue.
2. The "simple fix" is not a fix, IMO.
3. It will be seen in the future, perhaps this thread, that the only
way to solve this problem, that the ideal way (so far), of solving
this problem, is to let the objects themselves participate in the
control of how much data is being received, _not_ pre-allocating any
buffers, nor doing any reallocation. I am willing to exercise as much
patience as necessary until everyone else sees this.
If you still think, as you did in your OP, that there is a general
problem with the use of C++ serialization frameworks in IPC
applications, then please specify exactly what that problem is.
Well, I have a solution to the problem that I illustrated in my OP. I
do not consider the "pre-allocate a 1MB buffer". My hands are tied
right now with administrative issues unrelated to engineering, but
someday soon I will normalize my solution and present it here, and it
will be seen that, aside from the arbitariness in specification of
limits on how much data can be received from a socket, the solution is
workable.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]