Bug 1006100 - (CVE-2013-4342) CVE-2013-4342 xinetd: ignores user and group directives for tcpmux services
CVE-2013-4342 xinetd: ignores user and group directives for tcpmux services
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All All
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20050823,repor...
: Security
Depends On: 1006477 1007293 1007294 1007297 1007299 1014897
Blocks: 1006478
  Show dependency treegraph
 
Reported: 2013-09-09 22:48 EDT by thomas.swan
Modified: 2015-10-15 13:59 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
preliminary patch to set credentials before execve (7.70 KB, patch)
2013-09-09 22:48 EDT, thomas.swan
no flags Details | Diff
updated, simpler patch (351 bytes, patch)
2013-09-19 01:15 EDT, thomas.swan
no flags Details | Diff

  None (edit)
Description thomas.swan 2013-09-09 22:48:06 EDT
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:
Comment 1 Vincent Danen 2013-09-10 12:42:42 EDT
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
Comment 3 thomas.swan 2013-09-11 20:39:40 EDT
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.
Comment 4 thomas.swan 2013-09-11 21:48:04 EDT
The github request has been redacted.  When you are ready, and if you want, I can issue a new pull request.
Comment 6 Huzaifa S. Sidhpurwala 2013-09-12 02:13:00 EDT
This issue has been assigned CVE-2013-4342
Comment 11 thomas.swan 2013-09-19 01:15:29 EDT
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.
Comment 12 thomas.swan 2013-09-23 13:00:10 EDT
The later patch should be the correct fix.
Comment 15 Huzaifa S. Sidhpurwala 2013-10-02 02:39:53 EDT
(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.
Comment 16 thomas.swan 2013-10-03 00:32:59 EDT
Please, go ahead.  The pull request has been created.
Comment 17 Huzaifa S. Sidhpurwala 2013-10-03 00:44:15 EDT
Created xinetd tracking bugs for this issue:

Affects: fedora-all [bug 1014897]
Comment 18 Vincent Danen 2013-10-07 12:08:34 EDT
Acknowledgements:

Red Hat would like to thank Thomas Swan of FedEx for reporting this issue.
Comment 19 errata-xmlrpc 2013-10-07 13:19:24 EDT
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
Comment 22 Fedora Update System 2013-10-11 19:56:21 EDT
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.
Comment 23 Fedora Update System 2013-10-12 00:27:56 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.