I think this message (from the linux-security list regarding attacks on
INETD) might be relevant to exim...
The exploit was
send a TCP SYN to an inetd internal service port (ie daytime)
send a TCP RST (clearing the connection)
on the next connection to an inetd service, inetd dies!
Nigel.
------- Forwarded Message
Date: 15 Jan 1997 23:23:47 +0000
From: Bryan Reece <reece@???>
To: Magnus Bergman <trident@???>
cc: linux-security@???
Subject: [linux-security] dos-attack on inetd.
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.
------- End of Forwarded Message
--
[ Nigel.Metheringham@??? - Unix Applications Engineer ]
[ *Views expressed here are personal and not supported by PLAnet* ]
[ PLAnet Online : The White House Tel : +44 113 251 6012 ]
[ Melbourne Street, Leeds LS2 7PS UK. Fax : +44 113 2345656 ]
[Q: You know when you run sendmail.... A: No, you DELETE sendmail]
