Re: [Yaml-core] CVE-2019-11253: Kubectl/API Server YAML parsing vulnerable to "Billion Laughs" Attack

[Sam F. <sf...@re...>]

Hi yaml-core list members,

I'm writing this to request input on the possibility of assigning a CVE 
to the YAML spec for the issue described in the below mail chain.

The TL;DR is:

* gopkg.in/yaml.v2 package was patched to address behaviour that allowed 
for excessive resource consumption (i.e. DoS) on crafted YAML input.

* This usage of gopkg.in/yaml.v2 in kubernetes was assigned CVE-2019-11253

* gopkg.in/yaml.v2 is used in many golang projects, so I proposed 
assigning a CVE directly to gopkg.in/yaml.v2

* gopkg.in/yaml.v2 follows the YAML spec, which does not make any 
security considerations, hence this mail exploring the possibility of 
assigning a CVE to the YAML spec instead


Any input or feedback is appreciated.

Thanks,
--
Sam Fowler, Red Hat Product Security

On 11/10/19 5:42 pm, Gustavo Niemeyer wrote:
> Sorry that this is painful, but option (a) is the only correct option. 
> If you go with (c) you'll force me to publicly explain why, which isn't 
> something I'm keen on focusing on right now.
> 
> 
> On Fri, Oct 11, 2019, 05:55 Sam Fowler <sf...@re... 
> <mailto:sf...@re...>> wrote:
> 
>     Thanks for the replies. There's certainly a fair case to be made that
>     since the yaml spec makes no security considerations, it is flawed and
>     more deserving of CVE assignment than specific implementations.
> 
>     I then see three options:
> 
>     a) Assign a CVE to the YAML spec
>     b) Assign individual CVEs to projects that use gopkg.in/yaml.v2
>     <http://gopkg.in/yaml.v2> in a
>     vulnerable way
>     c) Assign a CVE to gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2>
> 
>     The recent set of HTTP/2 vulnerabilities[0] took a similar route to
>     option a) and assigned generic CVEs across all implementations. As
>     someone who worked downstream on these CVEs, my opinion is that this
>     was
>     the wrong move and was particularly cumbersome for pieces of code that
>     were vulnerable in multiple ways (e.g. both dependent on net/http and
>     gRPC).
> 
>     Option b) is fair in principle, but does not scale well. I am aware of
>     at least 100 different repositories used in Red Hat OpenShift that are
>     dependent on gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> and I
>     imagine that there are many more in
>     the wild. Potential individual CVE assignments adds a lot of overhead
>     for little benefit, in my view.
> 
>     Thus, my opinion is that option c) is the most pragmatic choice. This
>     could potentially lead to similar CVEs in other implementations (e.g.
>     libyaml, yaml-cpp, pyyaml, js-yaml) though I think that outcome is
>     reasonable and warranted if they indeed exhibit the same behaviour.
> 
>     If this is acceptable, I can proceed with option a) and assign a CVE
>     for
>     gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2>.
> 
>     [I also added Doran Moppert from Red Hat to CC as an FYI]
> 
>     Thanks,
>     --
>     Sam Fowler, Red Hat Product Security
> 
>     [0] https://tools.ietf.org/html/rfc7540#section-10.5
> 
>     On 11/10/19 12:13 am, Jordan Liggitt wrote:
>      > Moving the list to bcc. This probably isn't that relevant for it
>     anyway
>      > since k8s already has a CVE covering the vulnerability.
>      >
>      > Vulnerability in the spec vs vulnerability in a library is
>     interesting.
>      >
>      > The JSON RFC explicitly permits parsers to limit nesting, precision,
>      > string size, etc - https://tools.ietf.org/html/rfc7159#section-9
>      > The http/2 RFC has a security considerations
>      > <https://tools.ietf.org/html/rfc7540#section-10.5> section that
>      > describes attacks and explicitly permits mitigations, but many
>      > implementations were still vulnerable, and
>     non-implementation-specific
>      > CVEs were opened (https://kb.cert.org/vuls/id/605641/)
>      > The yaml spec <https://yaml.org/spec/current.html> has no security
>      > considerations section or notes permitting implementers to bound
>      > expansion/depth that I could find, so I'm not sure what the best
>     course
>      > of action there is.
>      > The corresponding XML expansion vulnerability has a CWE
>      > (https://cwe.mitre.org/data/definitions/776.html) but not an
>     overarching
>      > CVE.
>      >
>      >
>      >
>      > On Thu, Oct 10, 2019 at 10:00 AM Gustavo Niemeyer
>     <gu...@ni... <mailto:gu...@ni...>
>      > <mailto:gu...@ni... <mailto:gu...@ni...>>> wrote:
>      >
>      >     For the record, I'm getting an error out of the
>      >     "kubernetes-security-discuss" mailing list, because I'm not
>     subscribed.
>      >
>      >     So nobody but you can see this reply.
>      >
>      >
>      >     On Thu, Oct 10, 2019 at 2:58 PM Gustavo Niemeyer
>      >     <gu...@ni... <mailto:gu...@ni...>
>     <mailto:gu...@ni... <mailto:gu...@ni...>>> wrote:
>      >
>      >
>      >         The fix for this is to not accept certain valid documents, so
>      >         this is a vulnerability in the specification more than it
>     is in
>      >         the code. We are using heuristics to attempt to draw a line
>      >         between what's something reasonable from something that
>     could be
>      >         abuse or someone being naive. Even with that in place, if
>     your
>      >         system accepts a large enough YAML document you may still
>     be in
>      >         trouble, because that's the nature of variable expansion: it
>      >         allows the document to grow non-linearly with its input size.
>      >
>      >         That's a class of problem that I haven't seen CVEs being
>      >         assigned to before, and it still feels somewhat wrong in this
>      >         case. We're addressing the issue, by violating the
>     specification
>      >         and preventing certain valid files from being parsed,
>     based on
>      >         heuristics. I'm pragmatic and happy to collaborate on
>     trying to
>      >         prevent abuse, as we did in this case, but if you want a
>     CVE for
>      >         libraries handling data files per the specification, I'm
>     not the
>      >         right person.
>      >
>      >
>      >
>      >
>      >
>      >         On Thu, Oct 10, 2019 at 2:35 PM Jordan Liggitt
>      >         <li...@go... <mailto:li...@go...>
>     <mailto:li...@go... <mailto:li...@go...>>> wrote:
>      >
>      >             A CVE specific to the yaml library makes sense to me.
>      >
>      >             On Thu, Oct 10, 2019 at 1:53 AM Sam Fowler
>      >             <sf...@re... <mailto:sf...@re...>
>     <mailto:sf...@re... <mailto:sf...@re...>>> wrote:
>      >
>      >                 Hi Kubernetes PSC + go-yaml maintainers,
>      >
>      >                 Re $subject[0], I posted a comment on the PR for the
>      > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> <http://gopkg.in/yaml.v2>
>      >                 patch here[1]:
>      >
>      >
>      >                 "This patch partly comprises the k8s fix for
>      >                 CVE-2019-11253, which
>      >                 updates gopkg.in/yaml.v2
>     <http://gopkg.in/yaml.v2> <http://gopkg.in/yaml.v2> to
>      >                 version 2.2.4. Presumably any repository
>      >                 that uses an earlier version of gopkg.in/yaml.v2
>     <http://gopkg.in/yaml.v2>
>      >                 <http://gopkg.in/yaml.v2> and accepts untrusted
>      >                 YAML is similarly vulnerable. Rather than assigning
>      >                 individual CVEs for
>      >                 every repo that uses gopkg.in/yaml.v2
>     <http://gopkg.in/yaml.v2>
>      >                 <http://gopkg.in/yaml.v2> in a vulnerable way, I am
>      >                 wondering if it makes more sense to assign a CVE
>      >                 directly to
>      > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> <http://gopkg.in/yaml.v2>.
>      >
>      >                 There is certainly an argument of "caveat
>     emptor": that
>      > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2> <http://gopkg.in/yaml.v2>
>      >                 should not bear the responsibility of other
>     projects to
>      >                 accept untrusted
>      >                 YAML. However, assigning a new CVE direct to
>      > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2>
>     <http://gopkg.in/yaml.v2> allows for
>      >                 those projects to be alerted of this patch and
>     potential
>      >                 vulnerability,
>      >                 which is essentially the same (i.e. allows for
>     excessive
>      >                 resource usage
>      >                 via crafted YAML).
>      >
>      >                 I can assist with CVE assignment for
>     gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2>
>      >                 <http://gopkg.in/yaml.v2>, if there are no
>      >                 objections."
>      >
>      >
>      >                 I believe timely CVE assignment is appropriate for
>      > gopkg.in/yaml.v2 <http://gopkg.in/yaml.v2>
>     <http://gopkg.in/yaml.v2> as
>      >                 I'm aware of many repos and projects that use it (at
>      >                 least within Red
>      >                 Hat), and would like to deliver updates. However, I
>      >                 don't wish to
>      >                 proceed without agreement that this is the right
>     approach.
>      >
>      >                 So, are there any objections from the Kubernetes
>     PSC or
>      >                 go-yaml team to
>      >                 assigning a CVE for this package?
>      >
>      >                 [0]
>     https://github.com/kubernetes/kubernetes/issues/83253
>      >                 [1]
>      > https://github.com/go-yaml/yaml/pull/515#issuecomment-540242856
>      >
>      >
>      >                 Thanks,
>      >                 --
>      >                 Sam Fowler, Red Hat Product Security
>      >
>      >                 --
>      >                 You received this message because you are
>     subscribed to
>      >                 the Google Groups "kubernetes-security-discuss"
>     group.
>      >                 To unsubscribe from this group and stop receiving
>     emails
>      >                 from it, send an email to
>      > kub...@go...
>     <mailto:kubernetes-security-discuss%2Bu...@go...>
>      >               
>       <mailto:kubernetes-security-discuss%2Bu...@go...
>     <mailto:kubernetes-security-discuss%252...@go...>>.
>      >                 To view this discussion on the web visit
>      >
>     https://groups.google.com/d/msgid/kubernetes-security-discuss/7d283c5b-f49e-96c2-7d56-1e08b3cfc8ac%40redhat.com.
>      >
>      >
>      >
>      >         --
>      >
>      >         gustavo @ http://niemeyer.net
>      >
>      >
>      >
>      >     --
>      >
>      >     gustavo @ http://niemeyer.net
>      >
>