On Fri, Feb 8, 2013 at 7:54 AM, Student Jr [email protected] wrote:
Well, if you want me to be explicit, I can.
Certainly if you accept arbitrary user input for parsing, you have an
automatic DOS vector by dint of sending a very large packet. Fine.
But if someone can make a thousand connections, and over the course of
the thousand connections PERMANENTLY chew up 100k of member per
connection, you start of have a problem of a very different sort.
That can be achieved with any bad coding.
It is in that sense–the sense of a memory leak–that symbols are
different in this regard.
Yes and no: yes, because Symbol has the property to aggregate in
memory, no because it is the programmer’s choice which allows bad
things to happen. You cannot simply for a YAML.load() on a program
via a network connection,
And before you come back with “don’t do that”, remember that the ability
to create arbitrary objects is a prime feature of YAML. There needs to
be a way to scope that feature, and this is one option.
OK, now we’re cooking! I can see where YAML is an issue because I
couldn’t find a way to customize Symbol deserialization for YAML. If
that way existed, fairly easy measures could be taken to prevent
excessive Symbol creation. For the time being one would have to patch
the library to prevent this DOS OR modify the input before throwing it
OTOH I cannot remember having read of a DOS via YAML Symbol
deserialization on this list.