Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 29 Nov 2014 12:44:38 +1100
From: Jonathan Gray <>
Subject: Re: Re: libyaml / YAML-LibYAML DoS

On Fri, Nov 28, 2014 at 03:04:11PM -0500, wrote:
> 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.

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:

> > 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
> 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 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)
> Jb7PdteW7250OH3DXb+WPkE90co+IOMoql3HrQoEy3+izwqaUBrDuR0yZVxlej6Q
> 6EmcJ6Da1qjL2kXjJOYRrGsz9VJvQTRVrXhgQ3xvCWYw6mLxoTmztQ2UNNJ3DR12
> NVbMUFTmVtqyufvFl1ilOkxtt8cb8pqufYM5491M4Jp1EgLiqi7ztj91SUwUe0+w
> rE2H/wXJKP0JSAuQUOl7sGC7R6LD7s7dp8eoa+0RPdUuvvtCq8/L+1xbzEkWo8LW
> pxLCqHonpo0XnEMGMQRkSfkkyoFperqLpeBLR+ZNlSNYNzZlkhBuvTpGA5NyNIc=
> =hUlY

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ