Some older apps use hostnames for authentication purposes and don't do this double-check. Notably, ancient versions of 'rshd' and 'rlogind' will believe the reverse lookup and let you in if your fake hostname matches something in the '.rhosts' file. tcpd tried to stop this (with the -DPARANOID option) by doing the DNS double-check first, and immediately dropping the connection if the two DNS lookups didn't match. It's been proven that this is ineffective (though it requires a serious amount of control over your DNS server).
You can create a true (accurate) reverse DNS record for your machine with a lifetime of N minutes, and connect to the (for example) rshd service. tcpd will ask for the IP->host mapping, and your DNS server responds. tcpd will then ask for the host->IP mapping to make sure it gets the same IP back. However, this time you keep your DNS server from responding, and you disconnect. Wait N minutes, minus about 15-30 seconds, then reconnect. This time, the tcpd will do the IP->host mapping and will be answered from its own DNS cache (which is about 15 seconds from expiring). Once again it will ask your DNS server for the host->IP mapping, and this time your DNS server will wait 15-30 seconds, then answer. tcpd, confident that your hostname is correct (and it is), will let you through to rshd. Now rshd will do its own IP->host mapping, but the cache has expired. It makes a request to your DNS server, which now lies and gives "hr.corp.sun.com" as the answer. The problem is that tcpd has no way to tell the rshd service what hostname it verified (and of course that rshd's hostname authentication sucks).
The bottom line is that ancient rshd/rlogind should be upgraded, and that tcpd with -DPARANOID will not protect those services at all, contrary to popular belief.
nt has old dns cache bug
A problem with older versions of BIND (the reference DNS server) allowed
people to insert fake data into the server's cache. When responding
to a DNS query, your DNS server could append an "unrelated additional information"
field that gave answers for DNS queries that it wasn't authoritative for.
BIND was fixed to drop this extra info, but apparently the NT DNS server
still has this bug. It's also possible to fool DNS servers (both
NT and BIND) by guessing the ID sequence used in queries.
rpc portmap contains possibly fatal flaws
Some interesting posts passed back and forth around the way portmap
(a unix RPC tool) works. Portmap is used by services like NFS and
NIS. Instead of grabbing a well-known port (http = 80, etc), these
RPC services consult portmap and request an unused port. Remote
clients then first contact your portmapper, ask which port NIS (for
example) is on, and then connect to the NIS port. Two of the portmap
RPC calls are for requesting and then discarding a local port -- unfortunately,
these RPC calls can be made from remote machines. With IP spoofing,
a remote machine can send a request to discard the NIS/NFS/etc port.
OpenBSD handles this by requiring certain RPC calls to be sent through
the loopback IP (127.0.0.1), which can't be spoofed. Unfortunately
that requires changes to the code in the RPC clients (which OpenBSD did
by changing libc), so many OS may be vulnerable to this. Another
flaw is that the XID (transaction ID) used in RPC exchanges can be
fairly easily determined, because it's the XOR of a few numbers that are
relatively easy to guess.
pirch (irc client) dcc flaw
Pirch has an old bug that mIRC (both are Windows IRC clients) used
to have. DCC file transfers (sending a file from one user to another
across the IRC chat network) are saved by default into the same directory
that your Pirch executable and script files are stored. So someone
could send you a file that replaces one of your scripts (including the
startup script). Pirch has released a new version that changes the
default download directory. I reiterate here that automatically receiving
any file someone sends you is a really stupid thing to do.
xinetd has the /tmp hole
If you kill xinetd with the HUP signal, it'll write /tmp/xinetd.dump.
Unfortunately it doesn't do much checking about that file, so you can link
an existing file to /tmp/xinetd.dump and xinetd will happily overwrite
it.
icq sends your real ip
ICQ (a Windows-only replacement for IRC), plagued by security holes,
has the additional problem that it sends your local IP in the ICQ packet
under NT. That is, if you are behind a firewall or are connected
to a local ethernet, that IP will be included in the ICQ packet for others
to see.
wwwboard: don't use it
More bug reports floating in about a piece of software called "WWWboard"
that seems to be some kind of web-based note-board system. All of
the exploits so far have been uninteresting and indicative of just plain
badly written code. Avoiding using this software is probably the
best route for now.
foolproof for windows isn't
A piece of software for Windows (there's a Mac version too) called
Foolproof attempts to make a machine safe for public use (like in a library).
It's disabled if you boot into "safe" mode (which you can do with a well-timed
reboot). Also you can get rid of it by redirecting the output of
"echo" to its various executable files (apparently it protects itself against
modification, but forgot to protect against echo). The administration
password is stored in plaintext in the swapfile (look for "FOOLPROO"),
etc. There are a bunch more. This just proves how difficult
"foolproofing" a machine against console access can be.
browser bugs