[1379] in linux-security and linux-alert archive
[linux-security] dos-attack on inetd.
daemon@ATHENA.MIT.EDU (Bryan Reece)
Thu Jan 16 07:21:29 1997
Date: 15 Jan 1997 23:23:47 -0000
From: Bryan Reece <reece@taz.nceye.net>
To: Magnus Bergman <trident@unix.pp.se>
Cc: linux-security@redhat.com
In-Reply-To: <Pine.LNX.3.95.970112221956.17857B-100000@night.dataphone.se>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
Magnus Bergman writes:
> I discovered a bug in the inetd that comes with NetKit-B-0-08 and older.
>
> If a single SYN is sent to port 13
or 37
> of the server, inetd will die of Broken
> Pipe:
>
> write(3, "Sun Jan 12 21:50:35 1997\r\n", 26) = -1 EPIPE (Broken pipe)
> --- SIGPIPE (Broken pipe) ---
>
> I am no C-guru but I think this patch to inetd would fix it without adding
> any other problems:
>
> 1426c1426,1427
> < sprintf(buffer, "%.24s\r\n", ctime(&clocc));
> ---
> > (void) sprintf(buffer, "%.24s\r\n", ctime(&clocc));
> > signal(SIGPIPE, SIG_IGN);
> 1427a1429
> > signal(SIGPIPE, 13);
That last line shouldn't work. If you want to set SIGPIPE back to the
default behavior, use SIG_DFL instead of 13.
[mod: Yes, but actually whenever inetd recieves a sigpipe it should
NOT exit. I'd say moving the "signal(SIGPIPE, SIG_IGN);" over to the
initialization, and leaving out the "put it back code" would be best --REW]
Better fixes:
1) Disable the TCP time and daytime services (comment out their lines
in inetd.conf and restart inetd).
or
2) Make inetd fork before running the time and daytime servers. The
time and daytime processes should then _exit(0) (not return or exit)
when finished.
[mod: I have objections to both suggestions: 1) Inetd is a program
that simply shouldn't crash. Saying that YOU don't need the offending
service is not really fixing anything. 2) The internal services are
internal because the overhead of forking an external program was
considered too much for these simple services.... (ok now you're
forking an internal program...) -- REW]
> [mod: This looks like a quick hack to me. How can a USER process like
> inetd get a socket to play with when the 3-way handshake hasn't been
> completed? -- REW]
Good question, but some other systems seem to have this kernel
behavior too. It's probably better to fix inetd not to assume that
the write will always be successful than to change the kernel.
