News for hackers. Stuff that matters.
Re:Denial of Service and Unsafe Object Creation Vulnerabilit... by lkrubner on Monday February 11, 2013 @03:22PM (#5202987)
I apologize for the ignorant question, but how does Ruby survive this in normal operation?

"Since Ruby symbols are not garbage collected, this can result in a denial of service attack."

If you have a long running Ruby app,and it does not garbage collect symbols, then those symbols are... constants I guess?That survive till the app stops operating? So I guess the assumption is that no app should use too many symbols (and they don't use much memory anyway?)

Re:Denial of Service and Unsafe Object Creation Vulnerabilit... by oinksoft on Monday February 11, 2013 @03:49PM (#5203110)
This is not an ignorant question. Any half-experienced Erlang developer can tell you that you use `list_to_existing_atom' rather than `list_to_atom' if you are ever doing dynamic things with atoms. So, if you're trying to accomplish dynamic module lookup and foo_baz.beam is in your code path, default startup will create the `foo_baz' atom, and you know that this atom will exist at runtime.

Symbols in Ruby are atoms (the term "atom" spans languages), and GC/space issues plague any persistent term like an atom, in any language.

And thus I arrive at a key question: Does Ruby have something like `list_to_existing_atom', or some mechanism for telling if a symbol exists already? I see no analog to this, only the `ID2SYM' macro in the extensions API, and similar calls like String#to_sym.

Perhaps there is some way to clean up symbols after they are created. This to me would seem like the ideal route. It's good they've got a stop-gap fix by changing defaults, but it feels to me like they're punting here. Perhaps users who do [ab]use this feature also would not like DOS attacks?

I hope others who know more about Ruby extension development, and symbol management capabilities, can chime in on these questions.

Re:Denial of Service and Unsafe Object Creation Vulnerabilit... by benmmurphy on Monday February 11, 2013 @04:00PM (#5203184)
there are methods in the ruby reflection api that take strings and silently convert them to symbols so it is really easy to accidentally leak memory.

however, on ruby trunk they added a method: rb_check_id which can be used to check if a string has been already symbolized (https://github.com/ruby/ruby/blob/trunk/parse.y#L10465). this means when these reflection methods get passed a string and it hasn't been symbolized they can bail out and not symbolize the string. (https://github.com/ruby/ruby/blob/trunk/object.c#L2073)

Re:Denial of Service and Unsafe Object Creation Vulnerabilit... by oinksoft on Monday February 11, 2013 @04:04PM (#5203212)
This is an excellent development.

Indeed, when researching just now, I saw examples of people throwing strings at Module#const_defined?, which no doubt get converted to symbols straightaway.

Re:Denial of Service and Unsafe Object Creation Vulnerabilit... by sdevlin on Monday February 11, 2013 @04:01PM (#5203193)
Symbols in Ruby are basically interned strings.

So if you reference the symbol :foo, it will transparently get pinned in memory somewhere. Referencing :foo again will not allocate an additional object - the interpreter will just give you the existing symbol.

This is usually not an issue, because an application typically operates on a small, fixed set of known symbols. But if an attacker can generate arbitrary symbols (e.g. if you call .to_sym on user input), he can exhaust memory.

Re:Denial of Service and Unsafe Object Creation Vulnerabilit... by Confusion on Monday February 11, 2013 @03:47PM (#5203101)
A long running app will normally reach a steady state in which no new symbols are created anymore. If you for any reason create new symbols (which are basically interned strings) every n seconds or requests, you will eventually run out of memory. However, that is almost never a concern in practice, because you rarely need to do that.