| Summary: | <x11-apps/xrdb-1.0.9 hostname command injection (CVE-2011-0465) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Tomáš Chvátal (RETIRED) <scarabeus> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | x11 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | A1 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
(In reply to comment #0) > > @security: not sure what else you need to do with the bug so please pick > yourself. Thank you; got it. amd64 ok Arch teams, please test and mark stable: =x11-apps/xrdb-1.0.9 Target KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86" (Adding a bit of boilerplate.) Stable for HPPA. x86 stable, thanks. arm stable alpha/ia64/s390/sh/sparc stable amd64 stable ppc/ppc64 stable, last arch done Thanks, everyone. GLSA request filed. CVE-2011-0465 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-0465): xrdb.c in xrdb before 1.0.9 in X.Org X11R7.6 and earlier allows remote attackers to execute arbitrary commands via shell metacharacters in a hostname obtained from a (1) DHCP or (2) XDMCP message. This issue was resolved and addressed in GLSA 201412-09 at http://security.gentoo.org/glsa/glsa-201412-09.xml by GLSA coordinator Sean Amoss (ackle). |
Xrdb <1.0.9 contains possible root hole via rouge hostname. Filled as CVE-2011-0465. More onto the issue (copied from announce mail): Overview -------- By crafting hostnames with shell escape characters, arbitrary commands can be executed in a root environment when a display manager reads in the resource database via xrdb. These specially crafted hostnames can occur in two environments: * Hosts that set their hostname via DHCP * Hosts that allow remote logins via xdmcp Impact ------ Arbitrary (short) commands can be executed as root on affected hosts. With some display managers a working login is required (resource database is read upon login), with others no working login is required (resource database is read upon display manager start as well). Only systems are affected that 1) set their hostname via DHCP, and the used DHCP client allows setting of hostnames with illegal characters or 2) allow remote logins via xdmcp 1) requires either physical access to the network, or administrative access to the running DHCP server. 2) does not require physical access, if a regular account on a machine accepted by xdmcp is available, but describes a case that is considered insecure nowadays. @archies: please proceed with stabilisation. @security: not sure what else you need to do with the bug so please pick yourself.