Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Nov 2014 15:04:11 -0500 (EST)
Subject: Re: libyaml / YAML-LibYAML DoS

Hash: SHA1

> a crash/denial of service with untrusted yaml input.



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 <>
> 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 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

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 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 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 says "-O Turn on basic
optimizations" but the assert documentation at 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 ]
Version: GnuPG v1.4.14 (SunOS)


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.