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 socket_type = stream type = TCPMUXPLUS UNLISTED flags = NAMEINARGS server = /usr/bin/id server_args = 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:
Thanks for this report, Thomas. It seems it was reported to Debian 8 years ago and was never fixed or even reported upstream: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324678
I have a github pull request for upstream addressing this as well. If you think that it should be retracted for now, please let me know.
The github request has been redacted. When you are ready, and if you want, I can issue a new pull request.
This issue has been assigned CVE-2013-4342
Created attachment 799732 [details] updated, simpler patch I believe the child_process, not exec_server should be called on a tcpmux service. This preserves the existing behavior of exec_server and also keeps the tcpmux services within the same code path as other services when being executed.
The later patch should be the correct fix.
(In reply to thomas.swan from comment #9) > With regards to responsible disclosure, please let me know when would be the > correct time to create a pull request for the proposed fix to the upstream > repository on github. On github, the current home, pull requests are > public, and I would not want to place the pull request in the open until it > has been properly communicated. > > I would also like to provide the patch to the freebsd ports maintainer. > Please advise. Thomas, Hi, it seems i did not see comment #1 above, this issue is already public, do you mind if i open up this bug now? You can do a public pull request.
Please, go ahead. The pull request has been created.
Created xinetd tracking bugs for this issue: Affects: fedora-all [bug 1014897]
Acknowledgements: Red Hat would like to thank Thomas Swan of FedEx for reporting this issue.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 6 Via RHSA-2013:1409 https://rhn.redhat.com/errata/RHSA-2013-1409.html
xinetd-2.3.15-8.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
xinetd-2.3.15-8.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.