From: Sam F. <sf...@re...> - 2019-10-22 08:24:20
|
On 18/10/19 5:06 am, Felix Krause wrote: > I'll reiterate my point made on the related StackOverflow answer [1]: > > The YAML spec describes anchors & aliases as a way to (de-)serialize > graph structures in which a node is referenced by multiple other nodes > (also enabling cycles in the graph to be properly handled). > > The billion laughs attack that triggers the problematic behavior in > gopkg.in/yaml.v2 is caused by the implementation expanding aliases (i.e. > making copies of a node for each alias referencing it) instead of > linking to the node from multiple places as the specification suggests. > > The specification does not explicitly forbid this behavior. Rightfully > so (in my opinion), because not all programming languages do support > multiple references to a node; for example, a Python str is immutable > and therefore helper structures would be needed to represent a > modifyable !!str scalar node that is linked from multiple places in a > native Python structure. I assume this is the reason why PyYAML suffers > from the same behavior as described in the CVE. > > My conclusion is that on one hand, the issue emerges because of an > implementation choice that is in no way endorsed by the spec, so it does > not concern the spec. On the other hand, we see that there is at least > one other implementation (PyYAML) that suffers from this problem and > chances are that others do too since most YAML implementations are > rewrites of PyYAML. An implementation suggestion in the spec about this > problem might be a good idea. +1 for an implementation suggestion in the spec. My feeling is then that CVEs would be best assigned to individual implementations, in this instance gopkg.in/yaml.v2, perhaps with a disclaimer in the MITRE description text along the lines of: "The YAML version 1.2 spec does not prescribe whether or not node aliases should be expanded during deserialization." This would provide the benefits of CVE assignment (i.e. alerting users and projects to update to a non-vulnerable version), while also highlighting a gap in the specification. -- Sam Fowler, Red Hat Product Security |