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 usersor 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 logincapabilities 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 gaininghigher 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 loginto 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 ifyour 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 authenticateactions.
- 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:
Current thread:
- [PkC] Advisory #005: Default Slackware 7.1 installation /etc/shells perms bug recidjvo (Jun 11)
- Re: [PkC] Advisory #005: Default Slackware 7.1 installation /etc/shells perms bug Brian J. Kifiak (Jun 11)
- Re: [PkC] Advisory #005: Default Slackware 7.1 installation /etc/shells perms bug Jeffrey W. Baker (Jun 11)
- <Possible follow-ups>
- Re: [PkC] Advisory #005: Default Slackware 7.1 installation /etc/shells perms bug recidjvo (Jun 12)