[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Nov 2014 15:04:11 -0500 (EST)
From: cve-assign@...re.org
To: jsg@....id.au
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: libyaml / YAML-LibYAML DoS
-----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.
> 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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
