Date: Tue, 11 Jan 2005 07:59:49 -0800
From: Lee Howard <faxguy@...ardsilvan.com>
To: bugtraq@...urityfocus.com, hylafax-announce@...afax.org
Subject: HylaFAX hfaxd unauthorized login vulnerability


HylaFAX security advisory
11 Jan 2005

Subject:  HylaFAX hfaxd unauthorized login vulnerability

Introduction:

HylaFAX is a mature (est. 1991) enterprise-class open-source software
package for sending and receiving facsimiles as well as for sending
alpha-numeric pages.  It runs on a wide variety of UNIX-like platforms
including Linux, BSD (including Mac OS X), SunOS and Solaris, SCO, IRIX,
AIX, and HP-UX.  See http://www.hylafax.org


Problem Description and Impact:

HylaFAX hfaxd authenticates users against the hosts.hfaxd database.  
The first field of a hosts.hfaxd database entry (the "client") has a 
syntax of "^username@...tname$" where "username" is supplied during the 
hfaxd protocol exchange, and "hostname" is the official host name or 
the dotted IP address.  Regular expressions are used to match 
usernames, hostnames, and addresses.  By tradition, if the entry does 
not have the "@" in it, then the entry field is understood to be the 
full hostname or full dotted IP address - authenticating any user from 
the specified host.

The problem is that hfaxd always authenticates against the hosts.hfaxd 
entry by comparing the string "username@...tname" with the client 
field, irrespective of the formatting of the hosts.hfaxd client field.  
If there is a match (regex) between the string and the client field and 
no password is required (a subsequent entry field), then the login 
succeeds.  Thus, if an attacker can guess hosts.hfaxd entries that do 
not contain passwords (and most HylaFAX installations will likely 
contain "localhost" and "127.0.0.1"), then hfaxd will authenticate the 
attacker's login attempts if the attacker merely uses a username or 
configures their hostname to match the hosts.hfaxd entry.  Because 
hfaxd did not verify that hostnames outside of the local domain matched 
their resolved addresses before trusting them, "localhost" entries are 
therefore particularly vulnerable to "DNS spoofing".

All HylaFAX versions as far back as 4.0pl0 (1996) are vulnerable to 
unauthorized remote access of HylaFAX services when there are 
hosts.hfaxd entries without passwords.  HylaFAX installations are 
likely to have hosts.hfaxd entries without passwords, as it is the 
default.

This vulnerability has been assigned CAN-2004-1182.


Status:

HylaFAX.org has released HylaFAX version 4.2.1 which includes changes 
to hfaxd to keep it from erroniously matching usernames against 
hostname entries and verifying that hostnames match their resolved 
addresses before trusting them.  All HylaFAX users are strongly 
encouraged to upgrade.  The HylaFAX 4.2.1 source code is available at

   ftp://ftp.hylafax.org/source/hylafax-4.2.1.tar.gz

In the event that upgrading to 4.2.1 is not appropriate, the patch to 
fix HylaFAX hfaxd is available at

   http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=610

In the event that both patching and upgrading are not possible then 
firewalling techniques restricting access to port 4559 are strongly 
encouraged.  Administrators may also consider adding passwords to all 
entries in the hosts.hfaxd database that do not contain them.

Although no abuse of this vulnerability is known to HylaFAX 
development, recent postings to the public HylaFAX.org mailing lists 
have indicated problems with hosts.hfaxd entries that are associated 
with this vulnerability.  As any serious investigation into the nature 
of those problems would expose the vulnerability, this prompt response 
has been made.


Effect:

Some HylaFAX installations may actually utilize the weak hostname and 
username validation for authorized uses, although contrary to 
hosts.hfaxd documentation.  For example, hosts.hfaxd entries that may 
be common are

   192.168.0
   username:uid:pass:adminpass
   user@...t

After updating, these entries will need to be changed in order to 
continue to function.  Respectively, the correct entries should be

   192.168.0.[0-9]+
   username@:uid:pass:adminpass
   user@...t

Unless such maching of "username" with "otherusername" and "host" with 
"hostname" is desired, the proper form of these entries should include 
the delimiter and markers like this

   @192.168.0.[0-9]+$
   ^username@:uid:pass:adminpass
   ^user@...t$


Thanks, Timeline:

Many thanks go to Patrice Fournier of iFAX Solutions for discovery of 
the vulnerability (24 December) and the controlled reporting of it.  
Thanks also go to Aidan Van Dyk of iFAX Solutions, whom I assisted, for 
developing the final fix (28 December).

The vendor-sec mailing list was notified on 28 December, and HylaFAX 
CVS-HEAD was updated on 9 and 10 January.

Lee Howard
HylaFAX developer

Powered by blists - more mailing lists