BugTraq summary, week of 14 dec 1998.

network mapping tool crashes remote machines
Someone posted a tool called "nmap" that was supposed to scan machines on a network and determine what OS and TCP stack each machine is running, as well as what services it's providing, and so forth.  Unfortunately one of the scans it does (the "connect" scan) will crash HPUX 10.10 boxes and knocking out the inetd (service daemon) on Irix 6.5 and Digital Unix.  Apparently it does a rapid-fire connect/disconnect to one of inetd's built-in services.  Inetd tries to send something to the connection after it's closed, and gets SIGPIPE which causes it to terminate.  Cisco routers running IOS 12.0 were also possibly vulnerable (though maybe not to the same attack).

sun patches
Sun is being obstinately tight-lipped about it, but there's some bug in the 'passwd' command that affects security, and a patch has been released.  They also finally fixed an old BIND bug and cleaned up a hole in their use of temporary files, and fixed some buffer overflows in dtmail (CDE's mail reader) with regard to email attachments.

valueclick provides dubious value
The ValueClick Online Advertising agency web interface embeds your username and password in the URL after you login, so that when you enter subsequent sites, this "enhanced" URL will appear as the referrer in the log.  Some evil person could then login to ValueClick and redirect your payment checks.

clever new port scan technique
Salvatore Sanfilippo of Italy posted a way to do a port scan using spoofed packets.  (A port scan is a scan of a machine's TCP ports to see which ones are answering connection requests.)  In his scenario, the scanner (S) uses a patsy (P) to port scan the victim (V).  The only requirement is that P be a quiet machine (no network traffic) at the time of the port scan.  This can be a fairly simple requirement at certain times of the day.

S sends SYN packets to V, spoofed to look like they're coming from P.  If V is listening at that port, it will respond with SYN/ACK to P.  But P didn't ask for a connection, so it will return RST to V.  If V is not listening at that port, it will respond with a RST packet to P, which P will ignore.  The trick is that P only sends packets to V if the port was open on V.  When P sends packets, it increments its IP ID header field.  S just needs to send a stream of pings to P, and see if the IP ID field increments by 1 or 2.  Whenever it increments by 2, S knows P has sent another packet between the two ping replies, and that the packet was most likely a RST to V.  (This is why P needs to be free of other network traffic.)

A later post proposed fixing the Linux kernel to increment the IP ID by a random amount, to prevent Linux boxes from being the unwitting patsy box.  However, as far as I know, almost every other OS uses a direct increment there.  (The IP ID is unrelated to the TCP sequence number, which is generally as close to random as the OS can make it.)

irix tape drives
Irix may set the permissions on the raw tape-drive devices incorrectly.  This has all the same problems as were listed when Solaris had this problem (see BTT #4).

usr totalswitch is totally open
In the great tradition of routers and switches, you can password protect the configuration on the USR (now 3Com?) TotalSwitch, and that password can be read by anyone with the secret overriding "tech support" password.  And just to make it easier, the switch doesn't require you to be coming in over the console port when using the "tech support" password -- coming in over the network is fine.

nt proxy will forward packets
If you're running NT Proxy Server 2 on a machine with multiple ethernet cards (one for the inside, one for the outside), you may want to reconsider.  Apparently you can connect to the proxy server (which is listening on the inside interface card) from the outside interface card, because NT will pass packets between the two cards.  Once you've done that, you can ask for web pages from machines on the inside network and it will happily fetch them for you.  (I really hope this isn't true.  Nobody verified it but nobody contradicted it either.  Maybe just very few people are actually running their proxy server on an NT box?  One can hope...)

buffer overflows

/tmp race conditions