On Fri, Feb 8, 2013 at 7:54 AM, Student Jr <[email protected]> wrote: > Well, if you want me to be explicit, I can.
Good. :-) > 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 at YAML.load(). OTOH I cannot remember having read of a DOS via YAML Symbol deserialization on this list. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ -- [email protected] | https://groups.google.com/d/forum/ruby-talk-google?hl=en --- You received this message because you are subscribed to the Google Groups "ruby-talk-google" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
