Bugtraq mailing list archives
Re: Futile rexecd holes
From: espel () clipper ens fr (Roger Espel Llima)
Date: Tue, 19 Nov 1996 10:52:50 +0100
Vulnerability: Rexecd allows redirection of stderr stream to an arbitrary port on the client machine. This stream is opened by rexecd before authentication of the user.
[ ... ]
Discussion: Because rexec uses unprivileged ports for the whole process, any user can send a request to a rexecd requesting connection of the stderr stream to an arbitrary port on the client machine. Since the client is unprivileged, there is no possibility for the legitimate stderr stream to be destined for a privileged port.
At least rexecd is sensible enough to make the connection to the provided port from an unprivileged port too. I'd say that this ``vulnerability'' doesn't let Joe Hacker do anything much that he couldn't do already; if somoene can use rexec on a remote host, they can also execute netcat on it, and directly open connections to whatever machine and port they want. Still, it does provide an easy way to do things like send mail from a machine w/o being logged on it. Concerning rexec, I'd be more worried about the fact that most versions of it allow anyone to check if an account exists (by having a different message for "login incorrect" and "password incorrect"), and to execute commands without much logging. Since there is no standard rexec client anyway (in the sense that rsh is one for the shell service, rlogin for the login service, etc), there isn't much reason to keep rexec anyway. And if we're going to worry about services that can be made to connect to an arbitrary port on a host and send data to it, then the worst offender is definitely ftp, with the infamous PORT command that lets you choose not only to which port but also to which IP address the daemon is going to send its data... and for the same price, the connection comes from a privileged port (ftp-data = 20) ! Good thing the r* commands are smart enough to not consider ports between 0 and 512 privileged, but I wouldn't be too surprised if some newer services out there that re-use the (weak) concept of privileged ports could be abused by this. -Roger -- e-mail: roger.espel.llima () ens fr WWW page & PGP key: http://www.eleves.ens.fr:8080/home/espel/index.html
Current thread:
- Serious hole in Solaris 2.5[.1] gethostbyname() (exploit included), (continued)
- Serious hole in Solaris 2.5[.1] gethostbyname() (exploit included) Jeremy Elson (Nov 18)
- Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit Craig Raskin (Nov 18)
- Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit Paul B. Henson (Nov 18)
- Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit Russell Street (Nov 18)
- ALERT: Solaris 2.5.1 locks up on TCP connections in Pine 3.9x Todd Vierling (Nov 18)
- Re: ALERT: Solaris 2.5.1 locks up on TCP connections in Pine 3.9x Brian Harvell (Nov 20)
- ssh w/ solaris 2.5.[1] Aleph One (Nov 18)
- Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit Mike Battersby (Nov 18)
- Re: Serious hole in Solaris 2.5[.1] gethostbyname() (exploit Casper Dik (Nov 19)
- Futile rexecd holes jaeger (Nov 18)
- Re: Futile rexecd holes Roger Espel Llima (Nov 19)
- Irix: new LicenseManager is safe? No way Yuri Volobuev (Nov 22)
- Re: Futile rexecd holes Jon Peatfield (Nov 22)
- Administratrivia Aleph One (Nov 22)
- Administratrivia Scriptors of DOOM (Nov 23)
- A Stupid script. Efrain Torres (Nov 22)
- A Stupid script. Aleph One (Nov 24)
- AIX lquerypv Aleph One (Nov 25)
- lquerypv fix Troy Bollinger (Nov 25)
- Security Problems in XMCD David J. Meltzer (Nov 25)
- FreeBSD Security Advisory: FreeBSD-SA-96:18.lpr FreeBSD Security Officer (Nov 25)