I hate to say this, but it looks like crack was never actually using SafeYAML (despite having it as a dependency)?
It was actually pretty tricky to even find a scenario where this mattered! For one, crack automatically adds a space after the ":" character; so injecting symbols wasn't possible.
It also does this magical replacement of "/" with "!ruby/regexp /"; so arbitrary object serialization using, e.g., "!ruby/object:Foo" would get all mangled.
I did find this, though: a malicious attacker could bypass both of these by making crack think it's in the middle of a quoted string. The trick is to put an opening quote in a YAML comment: crack then ignores subsequent "/" and ":" characters; meanwhile, YAML ignores the first line.
You can see that without the change to require 'safe_yaml', the test I added actually deserializes a Foo object.
I hate to say this, but it looks like crack was never actually using SafeYAML (despite having it as a dependency)?
It was actually pretty tricky to even find a scenario where this mattered! For one, crack automatically adds a space after the ":" character; so injecting symbols wasn't possible.
It also does this magical replacement of "/" with "!ruby/regexp /"; so arbitrary object serialization using, e.g., "!ruby/object:Foo" would get all mangled.
I did find this, though: a malicious attacker could bypass both of these by making crack think it's in the middle of a quoted string. The trick is to put an opening quote in a YAML comment: crack then ignores subsequent "/" and ":" characters; meanwhile, YAML ignores the first line.
You can see that without the change to
require 'safe_yaml', the test I added actually deserializes aFooobject.