svn commit: r477811 - head/security/vuxml
Niclas Zeising
zeising at FreeBSD.org
Wed Aug 22 19:28:02 UTC 2018
Author: zeising
Date: Wed Aug 22 19:28:01 2018
New Revision: 477811
URL: https://svnweb.freebsd.org/changeset/ports/477811
Log:
Document libX11 vulnerabilities.
CVE-2018-14598
CVE-2018-14599
CVE-2018-14600
https://lists.x.org/archives/xorg-announce/2018-August/002915.html
Modified:
head/security/vuxml/vuln.xml
Modified: head/security/vuxml/vuln.xml
==============================================================================
--- head/security/vuxml/vuln.xml Wed Aug 22 18:57:49 2018 (r477810)
+++ head/security/vuxml/vuln.xml Wed Aug 22 19:28:01 2018 (r477811)
@@ -58,6 +58,57 @@ Notes:
* Do not forget port variants (linux-f10-libxml2, libxml2, etc.)
-->
<vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">
+ <vuln vid="fe99d3ca-a63a-11e8-a7c6-54e1ad3d6335">
+ <topic>libX11 -- Multiple vulnerabilities</topic>
+ <affects>
+ <package>
+ <name>libX11</name>
+ <range><lt>1.6.6,1</lt></range>
+ </package>
+ </affects>
+ <description>
+ <body xmlns="http://www.w3.org/1999/xhtml">
+ <p>The freedesktop.org project reports:</p>
+ <blockquote cite="https://lists.x.org/archives/xorg-announce/2018-August/002915.html">
+ <p>The functions XGetFontPath, XListExtensions, and XListFonts are
+ vulnerable to an off-by-one override on malicious server responses.
+ The server replies consist of chunks consisting of a length byte
+ followed by actual string, which is not NUL-terminated.
+ While parsing the response, the length byte is overridden with '\0',
+ thus the memory area can be used as storage of C strings later on.
+ To be able to NUL-terminate the last string, the buffer is reserved
+ with an additional byte of space. For a boundary check, the variable
+ chend (end of ch) was introduced, pointing at the end of the buffer
+ which ch initially points to. Unfortunately there is a difference
+ in handling "the end of ch". While chend points at the first byte
+ that must not be written to, the for-loop uses chend as the last
+ byte that can be written to. Therefore, an off-by-one can occur.</p>
+ <p>The length value is interpreted as signed char on many systems
+ (depending on default signedness of char), which can lead to an out
+ of boundary write up to 128 bytes in front of the allocated storage,
+ but limited to NUL byte(s).</p>
+ <p>If the server sends a reply in which even the first string would
+ overflow the transmitted bytes, list[0] (or flist[0]) will be set to
+ NULL and a count of 0 is returned. If the resulting list is freed
+ with XFreeExtensionList or XFreeFontPath later on, the first Xfree
+ call is turned into Xfree (NULL-1) which will most likely trigger a
+ segmentation fault. Casting the length value to unsigned char fixes
+ the problem and allows string values with up to 255 characters.</p>
+ </blockquote>
+ </body>
+ </description>
+ <references>
+ <url>https://lists.x.org/archives/xorg-announce/2018-August/002915.html</url>
+ <cvename>CVE-2018-14598</cvename>
+ <cvename>CVE-2018-14599</cvename>
+ <cvename>CVE-2018-14600</cvename>
+ </references>
+ <dates>
+ <discovery>2018-08-21</discovery>
+ <entry>2018-08-22</entry>
+ </dates>
+ </vuln>
+
<vuln vid="9b19b6df-a4be-11e8-9366-0028f8d09152">
<topic>couchdb -- administrator privilege escalation</topic>
<affects>
More information about the svn-ports-all
mailing list