[PATCH] xinet 2.1.8.8p3 umask and tcpd looping problems
Hi, I recently sent a problem report to SuSE feedback and reported the second problem to the xinetd mailing list (I presume Mandrake have already reported #1), but haven't got a response from SuSE yet. I'm resending the information so no-one is trapped. In xinetd-2.1.8.8p3, at least as of SuSE Linux 7.0 (didn't check older or newer versions), there are two major problems with xinetd. 1. SECURITY: Mandrake issued a security advisory about the umask being initialized to 0, so some network daemons create world + group writable files. See http://www.securityfocus.com/advisories/3351 NOTE that daemons which don't set a proper umask need to be fixed in the first place, fixing xinetd is only a band-aid. (void)umask(022); or (void)umask(022 | umask(077)); Should be a standard initialization procedure in daemons or their startup scripts. NOTE also that the standard inetd doesn't touch umask at all, but inherits it from its sysvinit script. In contrast, xinetd kills the umask and sets it to 0, so this cannot be fixed in an init script. WORKAROUND: write a wrapper script around the actual network server that looks like this: #! /bin/sh umask 022 exec /path/to/real_server "$@" exit 127 2. RELIABILITY: A service "flags = NAMEINARGS" configuration is killed by the defaults {} section key word "enabled = <service>". Cause is a bug in sconf.h. This does not strike when using disabled or omitting these keywords. Resulting problem: when you're using server = /usr/sbin/tcpd and configure enabled keywords in the defaults section, tcpd will have its own path as argv[0] rather than the first component of server_args, thus it will go into a unterminated loop, exec'ing itself all over again, eating up kernel resources and pids and flooding away log files. WORKAROUND: 1. don't use enabled = keyword 2. to catch looping services, add this to the TOP of your /etc/hosts.allow: tcpd : ALL : twist echo "421 service is looping on tcpd, aborting." This is harmless as long as you have one tcpd start another one in a different path which should be pretty uncommon. Note both bugs also affect 2.1.8.9pre15. I have been told pre16 is due out soon. A patch which remedies these problems, please incorporate these into the xinetd RPMs and provide the updated packages through the standard mechanisms follows: --- xinetd-2.1.8.8p3/xinetd/sconf.h.fix Sat Dec 11 01:07:18 1999 +++ xinetd-2.1.8.8p3/xinetd/sconf.h Sun Jun 17 14:34:02 2001 @@ -185,9 +185,9 @@ #define SC_IS_SPECIAL( scp ) ( M_IS_SET( (scp)->sc_type, ST_SPECIAL ) ) #define SC_IS_UNLISTED( scp ) ( M_IS_SET( (scp)->sc_type, ST_UNLISTED ) ) #define SC_IS_INTERCEPTED( scp ) ( M_IS_SET( (scp)->sc_xflags, SF_INTERCEPT ) ) -#define SC_IS_DISABLED( scp ) ( M_IS_SET( (scp)->sc_xflags, ST_DISABLED ) ) -#define SC_DISABLE(scp) ( M_SET( (scp)->sc_xflags, ST_DISABLED ) ) -#define SC_ENABLE(scp) ( M_CLEAR( (scp)->sc_xflags, ST_DISABLED ) ) +#define SC_IS_DISABLED( scp ) ( M_IS_SET( (scp)->sc_type, ST_DISABLED ) ) +#define SC_DISABLE(scp) ( M_SET( (scp)->sc_type, ST_DISABLED ) ) +#define SC_ENABLE(scp) ( M_CLEAR( (scp)->sc_type, ST_DISABLED ) ) #define LOGS_USERID( scp, flags ) \ ( M_IS_SET( (scp)->flags, LO_USERID ) && SC_ACCEPTS_CONNECTIONS( scp ) ) --- xinetd-2.1.8.8p3/xinetd/init.c.fix Sun Jun 17 14:34:43 2001 +++ xinetd-2.1.8.8p3/xinetd/init.c Sun Jun 17 14:34:53 2001 @@ -210,7 +210,7 @@ "Initialization of %s facility failed. Exiting...", mp->name ) ; exit( 1 ) ; } - (void) umask( 0 ) ; + (void) umask( 022 ) ; } -- Matthias Andree
Hi,
I recently sent a problem report to SuSE feedback and reported the second problem to the xinetd mailing list (I presume Mandrake have already reported #1), but haven't got a response from SuSE yet.
You've sent the mail on Tuesday, and I've seen it last night. The subject
was
Subject: [SuSE 7.0] Schwerer Bug (DOS) in xinetd-2.1.8.8p3-18.i386.rpm
and it was about the "enabled"-directive in /etc/xinetd.conf. I do not
consider this a DoS bug, and it is also not a "Schwerer Bug" (heavy bug),
so I decided to skip it for the weekend (Thursday was a holiday in Bavaria
and many other parts of Germany, and the following Friday is a good day to
be taken off). It's a bug, and nothing else. Nobody will keep you from
shooting yourself in the foot in a UN*X system, regardless if it is a
software bug or a problem between keyboard and chair.
The thing with the umask: I wonder why so many people start screaming at
this right now. xinetd has been doing this for ages now, and all of a
sudden everybody gets load about it. To me it seems that nobody has seen a
negative impact of this since basically all started daemons set their
umask on their own (which is the right thing to do), or a shell as a final
result from starting a service sets its umask in /etc/profile. And as
usual, if everybody starts publishing update packages, SuSE are expected
to do the same, without asking for a reason.
Linus has changed the default umask in the vfs layer of 2.4.4 because he's
right saying "no default policy in the kernel". I guess people were
alerted by this, and now they're looking into umask settings of other
parts of the system. In the meanwhile, he has accepted a patch that
reverts this change when /sbin/init is started at the end of the kernel
boot. In addition to a umask setting of 022 in /sbin/init, the default
kernel in SuSE-7.2 has the vfs change reverted to prevent any accidents
that can result from a umask of 0 (such as world-writeable files).
I guess with the two instead of one problem fixed, an update package is
justified. We will mention it in a section 2) of one of the next security
announcements, but, honestly, it's not really worth an own announcement.
And it is not marked "urgent", ok?
Thanks for the patch.
Thanks,
Roman.
--
- -
| Roman Drahtmüller
Roman Drahtmueller writes:
and it was about the "enabled"-directive in /etc/xinetd.conf. I do not consider this a DoS bug, and it is also not a "Schwerer Bug" (heavy bug), so I decided to skip it for the weekend (Thursday was a holiday in Bavaria and many other parts of Germany, and the following Friday is a good day to be taken off). It's a bug, and nothing else.
Yes, it jumps in your face the very moment you start thinking, "hey, why use default open when I can have default close, and let's use tcpd now."
The thing with the umask: I wonder why so many people start screaming at this right now. xinetd has been doing this for ages now, and all of a sudden everybody gets load about it. To me it seems that nobody has seen a negative impact of this since basically all started daemons set their umask on their own (which is the right thing to do), or a shell as a final result from starting a service sets its umask in /etc/profile.
Well, there are two reasons, and a patch. :-) The actual problem is that xinetd documentation doesn't mention that xinetd kills the umask. I'll report that separately to the xinetd mailing list again so they can fix their man page or their init.c or both. The Mandrake patch (it's the umask part of the patch I sent) changes the umask to 022, but removing the umask call from xinetd/init.c might also be a fix in the SuSE Linux environment, but I did not test that. You choose the one that fits. Either enforce 022 in xinetd or just have it inherit the umask.
I guess with the two instead of one problem fixed, an update package is justified. We will mention it in a section 2) of one of the next security announcements, but, honestly, it's not really worth an own announcement. And it is not marked "urgent", ok?
Of course. Thanks a lot. Please credit Mandrake as well. Also, since my subscription to xinetd was lost, I'm not sure if I was the first one to fix the "tcpd loops" bug. -- Matthias Andree
participants (2)
-
Matthias Andree
-
Roman Drahtmueller