5 ms·

http://www.insinuator.net/2013/01/rails-yaml/ http://www.insinuator.net/2013/01/rails-yaml/ Some explanation why YAML user input is evil. It works like this

• charliesome 14y ago
  Posting the gory details this early on is not a nice thing to do. It's probably best to hold off for a while until everyone has had a reasonable chance to upgrade.
  • merlincorey 14y ago
    Do you think not selling guns on an open market stops criminals from obtaining them as well?
    • charliesome 14y ago
      If you want to get into silly analogies, compare the US to Australia. Tight firearms restrictions in AU makes it significantly harder for criminals to obtain guns.
    • tptacek 14y ago
      If anybody thinks we're solving vulnerability full disclosure once and for all on an HN thread about a Rails vulnerability, that person is pretty naive. We've now officially captured both sides of the argument and can safely move on.
  • elliotanderson 14y ago
    At this stage with the vulnerability publicly and widely reported - demonstrating an attack vector that involves seemingly harmless code is perfectly acceptable. Not everyone understands the magic involved and it would be able to spot exploitable code.
    • charliesome 14y ago
      A harmless payload can be absolutely trivially turned into a malicious payload. I intend to share some details about this later on, but not so soon after the vulnerability is announced. There has to be a reasonable amount of time allowed for people to patch their servers.
• makomk 14y ago
  For all its reputation as overly strict and pedantic, one of the good things Java did was make sure that if something looked like a string it was going to be a string...
  • teyc 14y ago
    I just read this today and it is clever and horrific at the same time: http://websec.wordpress.com/2012/01/04/multiple-vulnerabilities-in-apache-struts2-and-property-oriented-programming-with-java/ http://websec.wordpress.com/2012/01/04/multiple-vulnerabilit...
• mattbee 14y ago
  Hmm, looking around I am thinking that if you don't want random object instantiation, this monkey-patch: module YAML; @@tagged_classes.delete('tag:ruby.yaml.org,2002:object'); end makes user-supplied YAML a lot less dangerous. I am going to poke this into a production application and see if anything breaks - it really really shouldn't <g>
  • tptacek 14y ago
    It breaks YAML deserialization in other places. You could enable and disable it on demand in the XML parser, but a more sensible solution is just to get YAML the hell out of the XML processor. Trying to make YAML safer is probably not the right approach.
    • mattbee 14y ago
      It's meant to partially break YAML deserialization :) My apps do care about YAML, so I've an interest in cleaning this up. Is there some unintended consequence? You can still instantiate some Ruby classes (Regexp, Symbol etc.) in the YAML loader, or you can go through @@tagged_classes and pick out any other types you don't want. But by taking out Object, YAML is only left with a whitelist of types that are safe, anything else will get turned into a YAML::DomainType.
      • tptacek 14y ago
        What I mean by that is, this workaround breaks application code that depends on other portions of Rails that use XmlMini. In exchange, it allows you to potentially expose YAML to HTTP requests, which is still an extremely bad idea.
        • mattbee 14y ago
          I don't see why YAML is a dangerous serialization format - the other type deserializations in the code seem sane and limited enough. (I wouldn't use YAML over e.g. JSON these days but I'm fixing up quite old projects)
  • 14y ago
• homakov 14y ago
  sql injection is possible, but how to work around to get remote code execution