Fedora has issued an advisory on May 18: http://lists.fedoraproject.org/pipermail/package-announce/2012-May/081428.html Mageia 2/Cauldron are also affected. The solution is to upgrade to 2.3.15 or apply the patch attached here: https://bugzilla.redhat.com/show_bug.cgi?id=790940
Updated package uploaded for Mageia 1, Mageia 2, and Cauldron. Advisory: ======================== Updated xinetd packages fix security vulnerability: 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 (CVE-2012-0862). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0862 http://lists.fedoraproject.org/pipermail/package-announce/2012-May/081428.html ======================== Updated packages in core/updates_testing: ======================== xinetd-2.3.15-1.mga1 xinetd-simple-services-2.3.15-1.mga1 xinetd-2.3.15-1.mga2 xinetd-simple-services-2.3.15-1.mga2 from SRPMS: xinetd-2.3.15-1.mga1.src.rpm xinetd-2.3.15-1.mga2.src.rpm
Version: 1 => 2Assignee: bugsquad => qa-bugsWhiteboard: (none) => MGA1TOO
PoC here https://bugzilla.redhat.com/show_bug.cgi?id=790940
I don't see how to enable tcpmux in Mageia to use the PoC. Testing x86_64 Mga1 complete. Testing using proftpd. Changed ServerType to inetd in /etc/proftpd.conf and disabled to no in /etc/xinetd.d/proftpd-xinetd Logged in via ftp from another computer with normal user login and browsed the users home.
Hardware: i586 => AllWhiteboard: MGA1TOO => MGA1TOO, mga1-64-OK
Testing complete x86_64 Mga2 Same procedure.
Whiteboard: MGA1TOO, mga1-64-OK => MGA1TOO, mga1-64-OK, mga2-64-OK
Testing complete i586 Mga2
Whiteboard: MGA1TOO, mga1-64-OK, mga2-64-OK => MGA1TOO, mga1-64-OK, mga2-64-OK, mga2-32-OK
Testing on i586 Mga1 This link was useful for setting up tcpmux for PoC test: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324678 Before update: $ telnet localhost 1 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. cvspserver no repository configured in /etc/cvs/cvs.conf Connection closed by foreign host. After update: $ telnet localhost 1 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. cvspserver -Service name not found Connection closed by foreign host. Testing complete i586 Mga1
CC: (none) => fcsWhiteboard: MGA1TOO, mga1-64-OK, mga2-64-OK, mga2-32-OK => MGA1TOO, mga1-64-OK, mga2-64-OK, mga2-32-OK, mga1-32-OK
Testing on i586 Mga1 More testing revealed a problem. The tcpmux server doesn't seem to reveal any service, even those set up to use it. Adding: type = TCPMUX or type = TCPMUXPLUS to any service, even the test_server example, all result in: $ telnet localhost 1 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. <some service> -Service name not found Connection closed by foreign host. They were accessible before, but so was everything else enabled.
Confirmed after enabling tcpmux, good catch William. Assigning David for now, please reassign it QA when you've had another chance to look. Thanks!
CC: (none) => qa-bugsAssignee: qa-bugs => luigiwalser
mga1 & 2 affected btw
(In reply to comment #7) > Testing on i586 Mga1 > > More testing revealed a problem. > > The tcpmux server doesn't seem to reveal any service, even those set up to use > it. > > Adding: > type = TCPMUX > or > type = TCPMUXPLUS > > to any service, even the test_server example, all result in: > > $ telnet localhost 1 > Trying 127.0.0.1... > Connected to localhost (127.0.0.1). > Escape character is '^]'. > <some service> > -Service name not found > Connection closed by foreign host. > > They were accessible before, but so was everything else enabled. Could you try getting the debugging messages from xinetd and see what it says when you are trying this? There is a variable in /etc/sysconfig/xinetd you can use to pass xinetd extra command-line options, which you can see in the man page. There are a few different ways to capture the debug output.
I just tried this and I can't reproduce your problem. I put: EXTRAOPTIONS="-filelog /var/log/xinetd.log" in /etc/sysconfig/xinetd, which helped me catch configuration errors along the way. Our xinetd package doesn't ship with a tcpmux-server service definition file like Fedora's does, so I had to write one (/etc/xinetd.d/tcpmux-server): service tcpmux { disable = no id = tcpmux-server type = INTERNAL wait = no socket_type = stream } Then I made my test_server definition (/etc/xinetd.d/test_server): service test_server { disable = no type = TCPMUXPLUS UNLISTED user = student port = 30 socket_type = stream protocol = tcp wait = no server = /bin/id } I restart the xinetd service. I also made disable = no in /etc/xinetd.d/krb5-telnet (installed from the krb5-appl-servers package). With xinetd 2.3.14, both my test_server and telnet services work through tcpmux. With xinetd 2.3.15, telnet gives the error message and test_server still works. I did note that it runs id as root, as the Debian bug you linked shows :o) So it looks like correct behavior for me. Tested Mageia 2 i586.
Assignee: luigiwalser => qa-bugs
You're right. Thanks for the help. Log files are your friend. The logs pointed out that tcpmux services must have 'UNLISTED' in the type. The 'id' parameter worked with both 'tcpmux' and 'tcpmux-server'. Restarted xinetd after changes and everything worked as it should. Tested Mageia 1 i586 OK.
Re-tested x86_64 Mageia 2 OK Thanks David. Needs to be rechecked mga1-64 and mga2-32 We should also add this info to QA procedures on the wiki.
Whiteboard: MGA1TOO, mga1-64-OK, mga2-64-OK, mga2-32-OK, mga1-32-OK => MGA1TOO, mga2-64-OK, mga1-32-OK
testing mga1 64
Testing complete mga1-64
Whiteboard: MGA1TOO, mga2-64-OK, mga1-32-OK => MGA1TOO, mga2-64-OK, mga1-32-OK, mga1-64-OK
testing mga2-32
Testing complete mga2-32 Validating Please note there are updates for mga1 and mga2 See comment 1 for Advisory and SRPMs Could sysadmin please push from core/updates_testing to core/updates Thanks!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsWhiteboard: MGA1TOO, mga2-64-OK, mga1-32-OK, mga1-64-OK => MGA1TOO, mga2-32-OK, mga2-64-OK, mga1-32-OK, mga1-64-OK
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0123
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED