psych

Nice generalization! Safe_yaml is a first drop-in work-around that can be dumped into existing apps: a fix to quickly reduce the risk of exposure. If you have a proper set of tests in your app, it's fast to verify if something is broken here after starting using it. But then, the underlying issue is being discussed actively [1], with talks about how to incorporate the safe default into coming versions of Ruby. So I don't really see the parallel with what you describe... [1] https://github.com/tenderlove/psych/issues/119

So far, people I've seen using it are "security-aware" developers who know there is always a remaining risk and who are just trying to reduce the surface attack a bit. For the others, well, we'll have to educate them, or push a safe yaml default quickly into Ruby [1]. This is no holy grail for sure, and there are plenty of other topics to be addressed (eg: secret tokens stored in SCM, pushed to third-party CI services and shared with freelancers and remote employees using non-encrypted disk, shared as well between production and non-regularly updated staging servers etc!) [1] https://github.com/tenderlove/psych/issues/119

This is currently being discussed on https://github.com/tenderlove/psych/issues/119 There is also https://github.com/dtao/safe_yaml (hat tip @patio11, who also points out that this has not been audited for completeness/correctness)

> Any sufficiently advanced serialization standard ... it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. Yes, this is always a bad idea. It's actually in a similar problem space as the constant stream of vulnerabilities in the Java security sandbox (eg, applets); all it takes is one mistake and you lose. And thus, people have been saying to turn off Java in the browser for 4+ years, and this is also why Spring shouldn't have implemented such code. > It's hard stuff, by nature. Which is why deserializing into executable code is a bad idea, by nature. I'd thought this was well established by now, but apparently it is not. > Do you have a citation for this? What particular bug in the parser are you referring to? http://github.com/tenderlove/psych/issues/119

> Is that seriously what happened? Surprisingly, yes: https://github.com/tenderlove/psych/issues/119 And the RubyGems folks are trying to handle this with whitelisting specific classes that the YAML parsing will still be allowed to instantiate: https://github.com/rubygems/rubygems.org/pull/516/files

This is exactly what I'm wondering. Are there adults in the Ruby community? The vulnerability itself is simply ridiculous: https://github.com/tenderlove/psych/issues/119 The response from the Gem folks has betrayed a serious lack of experience. Has Rails been such an insular and young community for so long that there are truly no qualified engineers around with experience in this level of professional software development?

Short timeline: - 1 week ago: blambeau reported the issue to the rubygems people: https://github.com/tenderlove/psych/issues/119#issuecomment-... - Postmodern wrote a PoC - https://gist.github.com/4674219 - Postmodern: "I posted it in a private chat room. Guess someone took it for a ride." - https://twitter.com/postmodern_mod3/status/29665192240284057... - A gem called `exploit-36.44.16` was pushed to RubyGems. This contains a payload that only sends `uname -r` to pastie. - A gem called `exploit-22.31.31` was pushed to RubyGems. This contains a payload that posted the config/database.yml to pastie. This gem was removed by the rubygems admins when they discovered it - http://news.ycombinator.com/item?id=5140109 & https://gist.github.com/d891e876c53e55bf0920 (that's the payload) Other exploit-gems that was pushed (but we don't know what did