6 ms·

You're exactly right to bring up the issues with code distribution (e.g. for CPAN, PyPI), but the YAML usage is a more general/different problem. As far as I un

by mpyne 14y ago

You're exactly right to bring up the issues with code distribution (e.g. for CPAN, PyPI), but the YAML usage is a more general/different problem. As far as I understand it Ruby on Rails would have been vulnerable even if you installed it from cryptographically-signed tarballs without any additional code from Rubygems. But pointing out that other languages don't have super-secure code distribution systems doesn't change that they at least understand the danger of deserializers that can run arbitrary code or create arbitrary objects, especially when Ruby is also weak in this area. At least for Python I would hope that had learned their lesson in 2011 when some popular third-party Django plugins used YAML.load instead of YAML.safe_load, instead of waiting for this. Of course, RoR devs might have noticed the same issue at that time, but there's nothing we can do about it now.

Xylakant 14y ago
See, there's a lot more to ruby than rails - I love and use padrino, since it doesn't include as much magic. It doesn't suffer from the rails vulnerabilities caused by the yaml usage. There's also a problem, that in ruby yaml is the to-go marshalling and config format, thats what allowed the attack against rubygems. But now, suddenly all ruby applications were in danger - even my apps, even though I don't use yaml. Shell-scripts, daemons, everything that uses ruby - whether it uses yaml.load or safe_yaml.load. Chef and Puppet were at risk - and those provide root access to hundreds of servers, machines that don't even run ruby apps. And that is because gems are not signed. If gems were signed, all of this would be a major nuisance, but with limited fallout. Signatures would get checked, approved, done - no matter which attack was used to get to the gem repo. There will be more attacks, using other vectors - a kernel exploit, a webserver exploit, a mail account hacked into. And containing that fallout is way more important. And that's the lesson that needs to be learned by all language communities: Code distribution needs to be secured since otherwise a single attack puts the whole community at risk. So feel free to point at the python docs and pretend that that's the lack of insight about yaml is what caused the problem. It's the spark that blasted the powder keg, but we were sitting on it long before.

by mpyne 14y ago

Xylakant 14y ago

See, there's a lot more to ruby than rails - I love and use padrino, since it doesn't include as much magic. It doesn't suffer from the rails vulnerabilities caused by the yaml usage. There's also a problem, that in ruby yaml is the to-go marshalling and config format, thats what allowed the attack against rubygems. But now, suddenly all ruby applications were in danger - even my apps, even though I don't use yaml. Shell-scripts, daemons, everything that uses ruby - whether it uses yaml.load or safe_yaml.load. Chef and Puppet were at risk - and those provide root access to hundreds of servers, machines that don't even run ruby apps. And that is because gems are not signed. If gems were signed, all of this would be a major nuisance, but with limited fallout. Signatures would get checked, approved, done - no matter which attack was used to get to the gem repo. There will be more attacks, using other vectors - a kernel exploit, a webserver exploit, a mail account hacked into. And containing that fallout is way more important. And that's the lesson that needs to be learned by all language communities: Code distribution needs to be secured since otherwise a single attack puts the whole community at risk. So feel free to point at the python docs and pretend that that's the lack of insight about yaml is what caused the problem. It's the spark that blasted the powder keg, but we were sitting on it long before.