[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 03 Apr 2015 10:17:30 +0200
From: Jan Rusnacko <jrusnack@...hat.com>
To: cve-assign@...re.org
CC: oss-security@...ts.openwall.com
Subject: Re: Re: libyaml / YAML-LibYAML DoS
On 11/28/2014 09:04 PM, cve-assign@...re.org wrote:
> 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.
Belated ping on this one - since I don`t see a separate CVE assigned
for scanner.py, shall it be tracked under CVE-2014-9130, despite the
above statement that it is not within it`s scope ? Statement on how to
track this would be appreciated.
--
Jan Rusnacko, Red Hat Product Security
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.
