Date: Sat, 29 Nov 2014 12:44:38 +1100 From: Jonathan Gray <jsg@....id.au> To: oss-security@...ts.openwall.com Subject: Re: Re: libyaml / YAML-LibYAML DoS On Fri, Nov 28, 2014 at 03:04:11PM -0500, cve-assign@...re.org wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > a crash/denial of service with untrusted yaml input. > > > https://bitbucket.org/xi/libyaml/issue/10/wrapped-strings-cause-assert-failure > > > https://github.com/yaml/libyaml/commit/e6aa721cc0e5a48f408c52355559fd36780ba32a > > Use CVE-2014-9130 for this Reachable Assertion issue in the libyaml > scanner.c file. > > Our understanding is that YAML-XS is a Perl wrapper module for the > libyaml C library, and that there isn't separate Perl code in > question. The rest of this message is a discussion of Python that > does not affect the Jonathan Gray CVE request. YAML-XS is not a direct wrapper it includes a version of the scanner.c code in question along with other parts of the libyaml code. That is why YAML-XS had to be patched seperately for CVE-2014-2525 and CVE-2013-6393. It should be noted that the libyaml author has made a commit to remove the assertion but has not yet made a new release: https://bitbucket.org/xi/libyaml/commits/2b9156756423e967cfd09a61d125d883fca6f4f2 > > > > Date: Fri, 28 Nov 2014 10:20:39 +0000 > > From: John Haxby <john.haxby@...cle.com> > > For what it's worth PyYAML 3.10 and 3.11 have exactly the same assertion: > > For PyYAML, however, it appears that the report is about the > scanner.py file, e.g., > > def save_possible_simple_key(self): > ... > # A simple key is required only if it is the first token in the current > # line. Therefore it is always allowed. > assert self.allow_simple_key or not required > > This Python code is apparently intended to correspond directly to the > yaml_parser_save_simple_key C code. However, because it's in a > different programming language, we would typically consider it a > separate codebase, eligible for its own CVE IDs. Here, "assert > self.allow_simple_key or not required" is not within the scope of > CVE-2014-9130. > > One question is whether identifying a security-relevant DoS caused by > an assert in C code means that there is also a security-relevant DoS > caused by an assert in corresponding Python code. In other words, > should the threat model be considered the same: the assert within > scanner.c might cause an outage of a C application that was intended > to remain available for processing YAML from other clients, and the > assert within scanner.py might cause an outage of a Python application > that was intended to remain available for processing YAML from other > clients? Or should the latter be considered much less plausible? If > the threat model is largely the same, we will assign a second CVE ID > for the scanner.py issue. > > A second question is whether a Reachable Assertion in Python should be > considered substantially different from a Reachable Assertion in C, > because Python is a scripting language that potentially makes it much > easier to ignore assert statements. (This question might not affect > the current CVE assignments.) > > In other words, for a product written in C, the author could argue (or > even document) that an assert line is supposed to be there, and the > end user is not supposed to be compiling the program with NDEBUG. > Similarly, the product can be shipped with specific build scripts that > do not use NDEBUG. However, for a Python script, is the end user > typically considered free to use -O if desired? The -O documentation > at https://docs.python.org/3/using/cmdline.html says "-O Turn on basic > optimizations" but the assert documentation at > https://docs.python.org/3/reference/simple_stmts.html says "(command > line option -O). The current code generator emits no code for an > assert statement when optimization is requested at compile time." It's > perhaps unclear whether ignoring assert statements is something that > would obviously be part of "basic optimizations." (This issue doesn't > apply to cases where there's a specific build process for .pyc files > or the end user is supposed to install shipped .pyc files.) > > To give two specific examples: > > 1. A C program's author uses assert to prevent reaching code that, > in cases where the assert expression is false, has a remote code > execution vulnerability. The author documents that aborting the > program is the intended behavior, and the author provides a > specific build/installation process without NDEBUG. > > 2. A Python script's author uses assert to prevent reaching code > that, in cases where the assert expression is false, has a remote > code execution vulnerability. Because Python is a scripting > language, the end user doesn't separately need to build anything. > The end user looks at the cmdline.html documentation, chooses to > enable optimization with -O, and therefore the assert statement > is ignored. > > Is it fair to conclude that example 2 has a vulnerability but example > 1 does not? > > - -- > CVE assignment team, MITRE CVE Numbering Authority > M/S M300 > 202 Burlington Road, Bedford, MA 01730 USA > [ PGP key available through http://cve.mitre.org/cve/request_id.html ] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (SunOS) > > iQEcBAEBAgAGBQJUeNRWAAoJEKllVAevmvms1g4IALrWfsOh7UkxQHxP28RBQgu0 > Jb7PdteW7250OH3DXb+WPkE90co+IOMoql3HrQoEy3+izwqaUBrDuR0yZVxlej6Q > 6EmcJ6Da1qjL2kXjJOYRrGsz9VJvQTRVrXhgQ3xvCWYw6mLxoTmztQ2UNNJ3DR12 > NVbMUFTmVtqyufvFl1ilOkxtt8cb8pqufYM5491M4Jp1EgLiqi7ztj91SUwUe0+w > rE2H/wXJKP0JSAuQUOl7sGC7R6LD7s7dp8eoa+0RPdUuvvtCq8/L+1xbzEkWo8LW > pxLCqHonpo0XnEMGMQRkSfkkyoFperqLpeBLR+ZNlSNYNzZlkhBuvTpGA5NyNIc= > =hUlY > -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ