Home page logo
/

bugtraq logo Bugtraq mailing list archives

[PkC] Advisory #005: Default Slackware 7.1 installation /etc/shells perms bug
From: "recidjvo" <recidjvo () pkcrew org>
Date: Mon, 11 Jun 2001 10:15:27 GMT

/*                                  pkc005.txt                          */

-=[ SECURITY ADVISORY #005 ]=-
               _____________                         _______
              |              \  [www.pkcrew.org]   /         \
               \             |   ______          /     ___     \
                |            |  |_    _|  ___   |    /     \___|
                |            |    |  |   /  _|  |   |
                |    _______/     |  | /  /     |   |
                |   /             |   _ <       |   |       ___
                |   |    [PkC]    |  |  \ \     |    \_____/   |
               _|   |_           _|  |_   \ \_   \             |
|_______| |______| |____| \__________/ [ Packet Knights Crew ] -=[ SECURITY ADVISORY #005 ]=-


      - Vulnerable program: Linux Slackware 7.1 default installation
- Tested on: i386 from official iso image on ftp.slackware.com
      - Advisory author: tHE rECIdjVO <recidjvo () pkcrew org>
- Group: Packet Knights (http://www.pkcrew.org/) - Date of release: 06/11/2001 - Problems: /etc/shells installed with world-writable perms.
      - Impact: Non-privileged users can create DoS to other users
or increase their access. - Risk level: MEDIUM-HIGH - Exploit: Proof-of-concept script attached. - Dedicated to: My little kitty that was killed. She really loved me. - Credits: A bad sunday night and my sadness. - Greetings: (you know if you're here... - and now I can smile.)
      - Summary:
                There is an error during the default installation of Linux
        Slackware 7.1 (tested only for i386 version).
        When installing files in /etc, /etc/shells has world-writable
        attributes (-rw-rw-rw-), allowing a non privileged user with login
capabilities to misconfigurate the entire system.
      - Details:
                This can seem a little bug, but impacts can be very dangerous
        for the system integrity.
        The main problem is that changing data contained in /etc/shells
        modifies the behaviour of the glibc call getusershell(3), that is
        often used by programs to authenticate a valid account comparing
        the shell field in /etc/passwd with shells listed in /etc/shells.
        This can cause a denial of service against other users or gaining
higher privileges if attacker has restrictions due to his login shell.
        [recidjvo () pkcrew:~]$ ls -l /etc/shells | cut -f1 -d' '
-rw-rw-rw-
        Some examples:
        (in the following examples recidjvo has a valid shell in
/etc/shells, cyrax doesn't)
        1. ftpd
                One of the conditions that must be satisfied to successfully
        login in ftp mode is that the user must have a valid shell (anonymous
        ftp doesn't do this check).
        This would mean that we can prevent any user (except user ftp) to log
into the ftp server (or let me in if I couldn't).
        [recidjvo () pkcrew:~]$ ftp localhost
        Connected to localhost.
        220 FTP server (slackware.pkcrew.org) ready.
        Name (localhost:recidjvo): cyrax
        331 Password required for cyrax.
        Password:
        530 Login incorrect.
        Login failed.
[recidjvo () pkcrew:~]$
        (in syslogd output)
        pkcrew ftpd[158]: connect from 127.0.0.1
        pkcrew ftpd[158]: FTP LOGIN REFUSED (shell not in /etc/shells)
FROM localhost [127.0.0.1], cyrax
        2. chsh
                chsh(1) is an utility to change users default login shell.
        If you're root, you can do anything you want, as usual; but if you're
        a simple user, you can only change your login shell by chsh only if
your shell in the /etc/passwd matches a shell in /etc/shells.
        [cyrax () pkcrew:~]$ chsh
        You may not change the shell for cyrax.
[cyrax () pkcrew:~]$
        (in syslogd output)
pkcrew chsh[174]: can't change shell for `cyrax'
        3. sendmail
                This is not always a complete denial of services, but we can
        deny the executions of user-defined commands in the ~/.forward files,
        and read informations about user mail attitudes.
        If a user has a program in his .forward, he will receive mails no more.
        Sendmail checks if the destination user has a valid login shell in
        /etc/shells before allowing execution of commands in .forward,
as shown below.
        [recidjvo () pkcrew:~]$ mail cyrax () pkcrew org -s '/etc/shells bug'
        Have fun :)
        t.R.
        .
        Cc:
        /home/cyrax/.forward: line 1: | mailparser... User cyrax () pkcrew org
        doesn't have a valid shell for mailing to programs
        /home/recidjvo/dead.letter... Saved message in
        /home/recidjvo/dead.letter
[recidjvo () pkcrew:~]$
        4. Others
                I found other programs that can be altered changing
        /etc/shells (e.g.: rpc.yppasswdd, gdmlogin, su -from source tree-).
        Check out any program that uses getusershell(3) call to authenticate
actions.
      - Solution:
                If you're root, chmod 644 /etc/shells will resolve
        the problem.
        If you're a simple user and you're not in love with root, check
        your shell to be always in /etc/shells :)
This bug seems to be fixed in the slackware-current branch. /* pkc005.txt */

Attachment: ShellsTrunz.sh
Description:


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault