A heap-based buffer overflow flaw was found in the way libyaml parsed YAML tags. A remote attacker could provide a specially-crafted YAML document that, when parsed by an application using libyaml, would cause the application to crash or, potentially, execute arbitrary code with the privileges of the user running the application. Acknowledgements: This issue was discovered by Florian Weimer of the Red Hat Product Security Team.
Created attachment 847926 [details] String overflow patch This is a proposed patch from Florian Weimer <fweimer> for the string overflow issue. It has been ack'd by upstream.
Created attachment 847934 [details] libyaml-node-id-hardening.patch This is a hardening patch also from Florian Weimer <fweimer>. It is not required to fix this CVE however it improves the robustness of the code against future issues by avoiding large node ID's in a central place.
Created attachment 856317 [details] libyaml-indent-column-overflow-v2.patch This expands upon the original indent column overflow patch from comment #12. The default parser indention is represented as an indention of -1. The original patch only modified the type of the column parameter to the roll/unroll functions, changing it from int to size_t to guard against integer overflow. However, there are code paths that call yaml_parser_unroll_indent with a column of -1 in order to reset the parser back to the initial indention. Since the column is now of type size_t and thus unsigned, passing a column value of -1 caused the column to underflow in this case. This new patch modifies the roll/unroll functions to handle the -1 indent as a special case. In addition, it adds a new function, yaml_parser_reset_indent. It is nearly an exact copy of yaml_parser_unroll_indent, except it does not take a column parameter. Instead it unrolls to a literal -1 indention, which does not suffer from the underflow. Code paths that previously called yaml_parser_unroll_indent with a column of -1 are updated to call the new yaml_parser_reset_indent function instead. With this patch instead of the original: - `make check` still passes - The reproducer script completes successfully with exit code 0 - The issue raised by John Haxby has been corrected and exits with SUCCESS
Created libyaml tracking bugs for this issue: Affects: fedora-all [bug 1059009] Affects: epel-all [bug 1059010]
Statement: The Red Hat security response team has rated this issue as having low security impact in Red Hat Enterpise MRG 1 and 2, CloudForms 3, and Red Hat Network Satellite 5. This issue is not currently planned to be addressed in future updates. The Red Hat security response team has rated this issue as having low security impact in Red Hat Update Infrastructure. A future update may address this issue. The Red Hat security response team has rated this issue as having moderate security impact in Subscription Asset Manager 1. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/
libyaml 0.1.5 has now been released (https://bitbucket.org/xi/libyaml/get/0.1.5.tar.gz) which now includes the patches (https://bitbucket.org/xi/libyaml/commits/all).
libyaml-0.1.4-6.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
libyaml-0.1.4-6.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
The upstream patch used previously caused some regressions in functionality. These were reported individually: * bug 1063866 Patch for CVE-2013-6393 introduces regression (Fedora) * bug 1063867 Patch for CVE-2013-6393 introduces regression (EPEL6) Which notes that upstream has addressed it slightly differently with the two following commits: https://bitbucket.org/xi/libyaml/commits/f859ed1eb757a3562b98a28a8ce69274bfd4b3f2 https://bitbucket.org/xi/libyaml/commits/af3599437a87162554787c52d8b16eab553f537b I don't believe this would require a new CVE for the regression, although it might if the regression results in libyaml still being vulnerable to this flaw (I'm not sure, can someone confirm?).
(In reply to Vincent Danen from comment #30) > The upstream patch used previously caused some regressions in functionality. > These were reported individually: > > * bug 1063866 Patch for CVE-2013-6393 introduces regression (Fedora) > * bug 1063867 Patch for CVE-2013-6393 introduces regression (EPEL6) > > Which notes that upstream has addressed it slightly differently with the two > following commits: > > > https://bitbucket.org/xi/libyaml/commits/ > f859ed1eb757a3562b98a28a8ce69274bfd4b3f2 > https://bitbucket.org/xi/libyaml/commits/ > af3599437a87162554787c52d8b16eab553f537b > > I don't believe this would require a new CVE for the regression, although it > might if the regression results in libyaml still being vulnerable to this > flaw (I'm not sure, can someone confirm?). The regressed version is not vulnerable to the flaw, it just fails to parse a subset of valid yaml documents that none of the tests caught.
Perfect, thank you for that confirmation John.
libyaml-0.1.2-6.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
libyaml-0.1.5-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
as per https://bugzilla.redhat.com/show_bug.cgi?id=1078083#c20 it looks like perl-YAML-LibYAML has an embedded copy of libyaml and may be affected. I will file tracking bugs.
Created perl-YAML-LibYAML tracking bugs for this issue: Affects: fedora-all [bug 1081385] Affects: epel-6 [bug 1081386]
This issue has been addressed in following products: Red Hat Software Collections for RHEL-6 Via RHSA-2014:0355 https://rhn.redhat.com/errata/RHSA-2014-0355.html
This issue has been addressed in following products: OpenStack 4 for RHEL 6 Via RHSA-2014:0354 https://rhn.redhat.com/errata/RHSA-2014-0354.html
This issue has been addressed in following products: OpenStack 3 for RHEL 6 Via RHSA-2014:0353 https://rhn.redhat.com/errata/RHSA-2014-0353.html
This issue has been addressed in following products: OpenStack 3 for RHEL 6 Via RHSA-2014:0364 https://rhn.redhat.com/errata/RHSA-2014-0364.html
perl-YAML-LibYAML-0.41-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
perl-YAML-LibYAML-0.41-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
perl-YAML-LibYAML-0.38-4.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Common for RHEL 6 Via RHSA-2014:0415 https://rhn.redhat.com/errata/RHSA-2014-0415.html
Red Hat Update Infrastructure 2.1.3 is now in Production 2 Phase of the support and maintenance life cycle. This has been rated as having Moderate security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Update Infrastructure Life Cycle: https://access.redhat.com/support/policy/updates/rhui.