Bugzilla – Full Text Bug Listing
|Summary:||VUL-0: CVE-2013-5680: hylafax: HylaFAX+ heap overflow, unchecked network traffic.|
|Product:||[Novell Products] SUSE Security Incidents||Reporter:||Marcus Meissner <meissner>|
|Component:||Incidents||Assignee:||Security Team bot <security-team>|
|Status:||RESOLVED FIXED||QA Contact:||Security Team bot <security-team>|
|Priority:||P3 - Medium||CC:||drankinatty, pth, security-team, zaitor|
|Found By:||---||Services Priority:|
|Marketing QA Status:||---||IT Deployment:||---|
Description Marcus Meissner 2013-10-01 08:35:09 UTC
is public, via firstname.lastname@example.org 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 =========================================================== "HylaFAX231 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. 223hfaxd224 typically runs as the 223uucp224 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 223LDAPServerURI:224 directive in 223/usr/local/lib/fax/hfaxd.conf224 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, don222t connect to 223localhost224 / 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 223USER224 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 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx12345. (connection hangs until 221nc222 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".
Comment 1 Swamp Workflow Management 2013-10-01 22:00:15 UTC
bugbot adjusting priority
Comment 2 David Rankin 2013-12-08 18:47:14 UTC
Marcus, You will need to reassign the bug. I do not have a current test platform. I recommend reassignment to email@example.com for the time being. I have reassigned the bug to you for now.
Comment 3 Marcus Meissner 2013-12-16 16:30:02 UTC
anton, can you help?
Comment 4 David Rankin 2013-12-16 23:05:38 UTC
Anton, whoever, gets the bug, I am happy to help test. I have a current install (6.0.6) on an Arch box and an older install on 11.0: 17:03 nemesis:~> rpm -q hylafax hylafax-6.0.2-23.1 Keep me in the loop. Thanks.
Comment 5 Anton Aylward 2013-12-17 14:34:32 UTC
I don't know why this has been assigned to me. I don't know why David suggested it. I don't have a fax; I've never had a fax. I don't run hylafax. I've never run hylafax. I don't plan to. Please take me off the list for this bug. I can't help you with it. I don't even have an analogue phone line!
Comment 6 Marcus Meissner 2013-12-17 14:51:08 UTC
zaitor at opensuse.org was last updating it ... can he help?
Comment 7 Bjørn Lie 2013-12-23 09:26:07 UTC
Sorry, I was just doing a "drive-by update", I haven't had a landline since back in the last millenium either. Sidenote: Since I'm not familiar with the code: This seems to affect hylafax+, and since we have hylafax and not + , are we even exposed?
Comment 8 Sebastian Krahmer 2014-01-14 10:01:43 UTC
Good question. As its based on the same source theres at least the chance that it is. Someone who knows the hylafax sources has to dig into it :)
Comment 9 Marcus Meissner 2014-09-04 10:57:32 UTC
was probably updated , is at 6.0.6 in factory and 6.0.5 in 12.3/13.1