Created attachment 795808 [details] preliminary patch to set credentials before execve

Description of problem:

If a tcpmux service is enabled, the user and group directives are ignored and the service always runs as root. Verified in the xinetd codebase and affects all active versions of RHEL and Fedora. Without the fix for CVE-2012-0862, previously exposed non-tcpmux services could run as root bypassing their respective user and group restrictions.

Version-Release number of selected component (if applicable): 2.3.15-6

How reproducible: Always

Steps to Reproduce: 1. Enabled tcpmux-server 2. Create a sample tcpmux service

service testcred { id = tcpmux-testcred disable = no user = nobody group = nobody sockettype = stream type = TCPMUXPLUS UNLISTED flags = NAMEINARGS server = /usr/bin/id serverargs = id wait = no }

3. telnet localhost 1 4. type testcred

Actual results: Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. testcred +Go uid=0(root) gid=0(root) groups=0(root)

Expected results: Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. testcred +Go uid=99(nobody) gid=99(nobody) groups=99(nobody)

Additional info:

builtins.c in Xinetd before 2.3.15 does not check the service type when the tcpmux-server service is enabled, which exposes all enabled services and allows remote attackers to bypass intended access restrictions via a request to tcpmux port 1.

Memory leak in xinetd 2.3.10 allows remote attackers to cause a denial of service (memory consumption) via a large number of rejected connections.

xinetd 2.3.4 leaks file descriptors for the signal pipe to services that are launched by xinetd, which could allow those services to cause a denial of service via the pipe.

Buffer overflow in internal string handling routines of xinetd before 2.1.8.8 allows remote attackers to execute arbitrary commands via a length argument of zero or less, which disables the length check.

Multiple vulnerabilities in xinetd 2.3.0 and earlier, and additional variants until 2.3.3, may allow remote attackers to cause a denial of service or execute arbitrary code, primarily via buffer overflows or improper NULL termination.

xinetd 2.1.8 and earlier runs with a default umask of 0, which could allow local users to read or modify files that are created by an application that runs under xinetd but does not set its own safe umask.

xinetd 2.1.8.x does not properly restrict connections if hostnames are used for access control and the connecting host does not have a reverse DNS entry.