Multiple integer overflows leading to heap-based buffer overflows were found in the libdmx, an The X.Org X11 DMX (Distributed Multihead X) runtime library.. When a X client is connected to a malicious X server, (modified to return invalid values), it can cause arbirary code execution with the privileges of the user running the X client. Affected functions: DMXGetScreenAttributes(), DMXGetWindowAttributes(), DMXGetInputAttributes()
Created attachment 743959 [details] 0043-integer-overflow-in-DMXGetInputAttributes.patch
Public via: http://www.openwall.com/lists/oss-security/2013/05/23/3
Created libdmx tracking bugs for this issue Affects: fedora-all [bug 966819]
libdmx-1.1.2-4.20130524git5074d9d64.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
libdmx-1.1.2-4.20130524git5074d9d64.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
This issue affects the version of libdmx as shipped with Red Hat Enterprise Linux 5 and 6.
External References: http://www.x.org/wiki/Development/Security/Advisory-2013-05-23
When will a Red Hat Enterprise Linux 5 update be available in the YUM repository Beta or otherwise? I've searched all repos in RHEL's Customer Portal. This shows as a Retina security scanner vulnerability. Further investigation shows updated patches were released for RHEL 6, Fedora 20, Fedora 19 and Fedora 18 but NOTHING in Beta nor any other updates beyond the version shipped with RHEL 5. A reference source for Linux Packages for O/S: http://pkgs.org/download/libdmx
Statement: Red Hat Enterprise Linux 5 is now in Production 3 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 Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/. This flaw only affects X clients that connect to malicious X servers. Generally speaking, these will be untrusted/unknown X servers only, as trusted remote X servers should be connected to via SSH (which provides end-point verification and authentication), or the local X server. Because this flaw requires that the X server be changed (recompiled to deviate from a standard X server) in order to impact the X client, it requires root privileges on the X server to effect the change. If this is a system where the X client and server are on the same (local) host, and an attacker is able to replace the X server binary, then they already have root privileges and no trust boundary is crossed. With remote X servers, using SSH with strict host-key checking will prevent the X client from connecting to the X server without intervention, as the user will be alerted to host-key changes.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2014:1436 https://rhn.redhat.com/errata/RHSA-2014-1436.html