Security holes found in HylaFAX programSep 28, 1998, 04:22 (0 Talkback[s])
There is a thread on the security-related mailing list, bugtraq, about security problems with the HylaFAX fax program.
"This is about the HylaFAX Facsimile Software copyrighted by Sam Leffler and Silicon Graphics, Inc but available for free.
faxcron, xferstats and recvstats as they are installed with hylafax-v4.0pl2 can be used to execute arbitary awk programs as the invoking user. All three programs are usually run by cron on behalf of the fax user (aka uucp).
faxcron, xferstats and recvstats which are all Bourne Shell scripts create temporary files in /tmp which are later executed by awk. The names of these temp files can easily be guessed. Any awk code that is found in a correctly guessed file will be run verbatim (if the attacker was clever enough to protect his file from being overwritten).
There are several other files created but not executed in /tmp with such a weak naming sheme and without and checks for tampering.
Disableing those scripts completely should not break hylafax serivces. You'll only miss those nice reports."
"While setting up the HylaFAX package of S.u.S.E. Linux 5.1 I found some nice security holes in the fax-filter.
1. the spool-file (fax_$USER.ps) is created w/ mode 666 and has U/GID 'lp' - this bug allows modification of the spool-file... which doesn't seem very dangerous but think about a fax which contains the company's logo, the name of a top-manager and some malicious information solution: set umask in filter-script
2. another scary fact is, that the filter- script doesn't check for an already existing "spool"-file or link now, an attacker is able to overwrite files w/ the perm. of 'lp' and to modify the file (mode: 666) the attacker is also able to exploit possible holes in 'lpd' by creating malicious spool-files and s/he could execute commands w/ the UID of 'lp' by creating and rewriting filter-scripts, that are in /etc/printcap but aren't created if the attacker could access the faxspool direc. und user 'lp' owns the filter-script, s/he has the ability to overwrite the script, which leads to an DoS attack (hm, what would happen if the attacker links the spool-file to /dev/null or /dev/zero?) solution: use the builtin-shell-command 'test' or better recodeing of the filter- script in C/++ or Perl using open(O_EXCL|O_CREAT) and using another spool-direc, otherwise an local (maybe remote) DoS attack still exists
3. if the attacker is able to remotely set a username of his/her own choice, i.e. `echo "+ +" > ~lp/.rhosts, by faking the network-protocol of the HylaFAX system s/he could gain remote access to the HylaFAX server... ... it's a bad idea to set a shell in /etc/passwd for the user 'lp'
I notified the auditing-team of suse.de about that bugs... I hope they will release a patch as soon as possible."
0 Talkback[s] (click to add your comment)