>From: horio shoichi <[EMAIL PROTECTED]>
>I had a port 2222 scan last January. The port was, according to discussions
on
>[EMAIL PROTECTED], used by amd buffer overflow on Linux machines
>utilizing inetd. What is unique is that the technique completely bypasses
>attack/defence surrounding /etc/passwd to gain root shell.
>
>Seeing that these practices are becoming so common, I think following
points
>are now vitally important.
>
>o As often pointed out, packet filter rules must be default block. Any port
> could be used for such attacks. If default block is chosen, then even if
> a port is open, telnetting to the host via the port is still disabled.
> You drop your sword, but you still retain your shield.
>
> The old rule is just not only for paranoia.
>
>o Unfortunately there are inetd implementations that allow arbitrary port.
> Port 2222 on Linux is such one. Although most of these ports can be
blocked by
> the default rule, there are hard to protect ports. Passive mode ftpd has
> typically such ports. Some of OS have the feature to narrow the range of
> ports, but the range is still too wide (actually, one port is wide
enough).
>
> If ftpd is run with such inetd, then the bet is no other than "pray" that
> all services, including ftpd, are not vulnerable. We have no defence
beyond
> there.
>
>We should have noticed the potential of the technique more earlier.
I think the potential of the buffer overruns have already been noted, thus
the advocation of bastion-host application gateways to prevent direct access
and sanitize connections to running services as well as the system
operator's vigilance required to keep up to date with OS and application
patches.
The problem with this exploit's modus operandi - the use of buffer
overruns - is that, from the standpoint of packet filtering, the attacker
really has his/her choice of port to attach the root shell to, and that the
system is already compromised before the inetd command is run (the attacker
could have done an "rm -rf /" just as easily). The root (pardon the pun) of
the problem again is trying to prevent or sanitize access to the unpatched
service in the first place.
--
Gene Lee
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
