Re: Preventing Denial of Service Attack In IPC Serialization

On Jun 28, 8:15 pm, jlind...@hotmail.com wrote:


Jeff is not beating a dead horse.

[Note to mods: I am resending this message because the original
message was apparently lost.]

I am going to show in the Boost serialization framework where the
author of that framework is doing almost exactly what I pointed out as
a DoS vulnerability in my original post. But first, to restate the
most serious problem briefly, with current serialization frameworks,
including MFC, Boost, and my own, and probably many others, without a
fundamental change in the model, the sender of a serialized object can
artificially induce the receiver to allocate a large amount of memory,
creating a denial-of-service attack. It should be noted that there are
other problems beyond the one I am about to demonstrate that would
arise without a fundamental change in these serialization frameworks,
but I choose this problem because it illustrates the general principle
quickly and does not require much insight into serialization to
recognize as faulty.

At the sending end of a connection, a programmer would write something
like:

int main ()
{
  Socket s;
  std::vector<int> v;
  s << v;
  return 0;
}

At the receiving end of a connection, a programmer would write
something like:

int main ()
{
  Socket s;
  std::vector<int> v;
  s >> v;
  return 0;
}

In both cases, a Socket is a type of "Archive".

This second main() function, in the line s >> v, is where the problem
occurs. The essence of the problem can be seen in pieces of the
serialization framework, ignoring non-essential elements. We will
dissect the framework, starting from the bottom up, with a simple
piece.

In File http://www.boost.org/boost/serialization/collections_load_imp.hpp,
one will see:

template<class Container>
class reserve_imp
{
public:
    void operator()(Container &s, unsigned int count) const {
        s.reserve(count);
    }
};

The purpose of class "reserve_imp" is to invoke the member function
".reserve()" against an STL container. It will be used in the
following code:

In File http://www.boost.org/boost/serialization/collections_load_imp.hpp,
one will see:

template<class Archive, class Container, class InputFunction, class R>
inline void load_collection(Archive & ar, Container &s)
{
    s.clear();
    // retrieve number of elements
    unsigned int count;
    unsigned int item_version(0);
    ar >> BOOST_SERIALIZATION_NVP(count);
    if(3 < ar.get_library_version()){
        ar >> BOOST_SERIALIZATION_NVP(item_version);
    }
    R rx;
    rx(s, count); // <----- THIS IS THE PROBLEM. -Le Chaud Lapin-
    InputFunction ifunc;
    while(count-- > 0){
        ifunc(ar, s, item_version);
    }
}

As can be seen from the code above, load_collection is the main
function for serializing into several STL collections, including
vectors. The "R" parameter to this template function is a
"reserve_imp" class just mentioned. load_collection, for each STL
collection, including vector<>, does the following:

1. empties the container with s.clear()
2. declares an unsigned int "count"
3. declares a version number
4. Reads "count", taking care that the "stuff" read in includes not
only "count", but the literal word 'count'
5. If library version is less than 3, then read in the item version
6. Instantiates a "reserve_imp" object, "rx".
7. Invokes operator () against rx, supplying the container and count
as arguments. << ***THIS IS THE PROBLEM***
8. Declares input function object.
9. Reads in each element of container "count" times using input
function.

It can be seen that the size of a std::vector<> will be sized by rx
arbitrarily to what the sender says the vector size should be (count),
even 50MB. It does not matter whether the count is stored in a tiny
32-byte buffer or a huge 1MB buffer. The vector will still be
unwittingly resize to whatever the sender says the size should be,
which could happen if the sender is malicious.

-Le Chaud Lapin-

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