linux port lockup
A bug in Linux 2.0.x kernels allows a user to send a listening port
into a weird state where it can never be used again until the machine is
rebooted. 2.1 and 2.2 kernels are immune to the bug, and allegedly
2.0.36 was supposed to have a fix, but it must've gotten overlooked.
security holes in security tools
Several of these, which are vaguely amusing to me because I'm a sadist:
One person posted "sscan", a tool for checking local exploits, and then
mere minutes later, posted that he knew about all the buffer overflows
(security enemy #1) in the code and that he was in the process of fixing
them. Lopht reported on a security tool (made by a competitor) that
transmits all the passwords it cracks in plaintext to a distant web site,
which has gotta make your tummy warm.
netbsd race condition
This is an old race condition, and is not present on Linux or Solaris,
but many of the old BSD-based OS's apparently still have it. If a
listening socket is opened and left non-blocking, a race condition can
occur for quickly-dropped connections. The server will enter select()
and wait for activity on the listening socket. When a new connection
comes in, the select() will trigger. If the connection is then dropped
before the server can enter accept(), the accept() will block, waiting
for another connection (since there are now none pending). This will
happen more often on very busy machines, or servers that do a significant
amount of work between select() and accept(). W. Richard Stevens
even mentions this problem in his networking books, and suggests marking
the listening socket as non-blocking. (Quick guide: a "blocking"
system call will wait indefinitely before returning, waiting for the requested
event to happen. A "non-blocking" system call return immediately
with an error if nothing is ready. "select()" is the system call
to poll for events, and "accept()" is the call to accept a new incoming
connection over a listening port.)
iis issues
IIS is the NT web server. The version of perl that comes
with it will display your web root path if invoked with a filename that
doesn't exist (ie "nosuch.pl"). Another person posted a small file
that makes requests of an IIS server that don't get logged -- apparently
if the request method is over about 10k characters, IIS sidesteps buffer
issues by just refusing to log it at all. (Remember that most cgi's
and asp's treat all unknown methods as GET.) It's possible that this
bug only shows up on IIS 4 if it was upgraded from IIS 3 as part of an
NT patch upgrade (don't ask me how that would happen).
web ramp not too secure
A little box called WebRamp can be used to route a small network (using
NAT, if you like) through some PPP dialup modems. It will dialup
and hangup the modems as traffic increases/decreases, which sounds pretty
neet. Sadly there's no way to turn off the login, so anyone can telnet
to the WebRamp device and "login" to it. It also ships with a backdoor
user/password "for tech support" which, of course, these passwords are
well known.
irix 6.2/6.3 and cds
If you export a CD under Irix (via NFS or such), whenever a remote
client mounts that CD and tries to read from it, the Irix box will probably
crash. This is allegedly fixed in post-6.3 releases of Irix.
microsoft questionable behavior
When using the Microsoft "Critical Update" for NT -- which apparently
downloads patches for the OS and asks which ones you want to install --
something is being downloaded and installed prior to any questions being
asked. Some people are trying to investigate what this is.
Scary stuff.
sshd not checking account expirations
sshd (both versions 1 and 2) appears to let users login after their
logins have expired (expiring logins is a feature of the shadow password
suite). It also lets users login to disabled accounts (password of
"*" or etc) if they use the public-key system to login. A patch is
being done.
buffer overflows