Gene Lee wrote:
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.


  
horio shoichi


Gene Lee wrote:
> 
> Your attack is a variation of a similar attack seen last year which attached
> a root shell to the ingreslock port 1524.
> 
> The statd vulnerability is documented in the CERT advisory CA-97.26.statd
> (http://www.cert.org/advisories/CA-97.26.statd.html). In this document, find
> your system listed in the Vendor Information Appendix and patch your OS to
> the required level. If you are not running NFS, I  would recommend you even
> disable the whole NFS subsystem (including statd) at startup.
> 
> --
> Gene Lee
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to