Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

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