BugTraq summary, week of 05 oct 1998.

dumb windows trojan
Someone on EFnet is DCC'ing a trojan to windows users. The trojan puts them on a weird channel and uses mIRC script to attempt to download a file from a defunct web site on Geocities. Doh! Nobody would have noticed except that Geocities wondered why so many people were trying to access a web page that didn't exist, and thought it might be a denial of service attack. Turns out it's just hundreds of owned mIRC's attempting to download a newer version of their trojan. It's named something similar to:
    C:\windows\system\oce.exe
Erasing that file, cleaning your mIRC scripts, and rebooting seems to kill it.

token ring bug on NT
Nomad Mobile Research Centre reports that a token ring packet with bad data in the RIF field will cause any receiving NT box to bluescreen. This includes NT4.03 with hot fixes. Among the "bad data" that will cause NT to bluescreen: giving a hops count greater than 7, or including the same node twice in the hops list. The packet does not have to be addressed to the NT box; merely receiving the packet will crash it. Obviously this only works if you're on a token ring with the victim NT boxes. (Hubs and routers won't pass these bogus packets.)

irix 'at' can read any file
It looks like SGI found this by testing a netBSD exploit on irix and finding to their horror that it worked on them as well. Using 'at' to schedule a job will let that job read any file on the system. Nuff said.

windows(95/nt) reveals sequence numbers in reset
The description was kind of ambiguous, so I may be off the mark here a bit. If you send a PSH/ACK packet to any arbitrary port (even a port that isn't in use) on a Windows box, it will respond with a RST, but the ack field of the RST will be filled with the last valid sequence number the box received on any port. This means that if you know someone is connected to a known service (for example, an IRC server), you can bounce a PSH/ACK off a random port, retrieve the ack field, and immediately send a forged RST from the server, with the ack field as the sequence number. The chance is pretty good that you will knock down the connection after only a few tries.
http://deep.ee.siue.edu/br/brkill/brkill.html
 
hpux/irix/solaris ttdbserver has buffer overflow
Same old typical server buffer overflow problem.

comm 4.x has weird mime type
If Communicator receives a Content-type of "internal/parser" it will crash or lockup. You get one guess what's probably happening.

comm 4.x new variant on cache flaw
A link to about:<script> ... javascript code ... </script> executes the embedded code, which has access to your cache. Also there are now exploits to retreive cookies from an arbitrary site (some sites use cookies for authentication) and possibly to list files in your local directory. Tague says this is causing a 4.08 release to be spun, heh.

redhat man pages can be corrupted
There's a buffer overflow in Redhat's 'man' command that will let you execute things as group "man". This is really only useful for changing man pages.

better 'locate'
Kevin Lindsay wrote a better version of 'locate' that will respect user permissions and can handle extremely long filenames. Users won't be able to 'locate' files that they couldn't normally see using 'find'. (This has been a longstanding problem with 'locate'.)
ftp://ftp.mkintraweb.com/pub/linux/slocate/

ms proxy 2.0 can ftp forever
A client can ask the proxy server to GET ftp://somewhere:chargen and then drop the connection before getting the response. The proxy will happily go fetch this "file" and wait for it to "finish" (never) without noticing that the client has left the building. [As a previous coder for a proxy server, I think what's happening is that MS Proxy is attempting to download the entire file so it can cache it, in case the client tries again later. It's not realizing that there is no end to this particular "file".]

ie javascript can upload any file
IE's javascript command to upload a file to the web server is restricted so that the script can't enter the filename -- a user has to specifically select the file to upload, so that presumably the user knows what's going on and consents to it. However, IE doesn't restrict javascript from using copy & paste commands during this file selection, so a javascript can just copy a filename into the clipboard, start an upload, paste the filename in, and start it up, without user interaction.