Author

Markus Vervier

Risk

[

Security Risk Medium

]

0day-ID

0day-ID-31141

Category

local exploits

Date add

21-09-2018

CVE

CVE-2018-17141

Platform

windows

Multiple Vulnerabilities in HylaFAX
===================================


Overview
--------
Confirmed Affected Versions: HylaFAX 6.0.6, HylaFAX+ 5.6.0
Confirmed Patched Versions: HylaFAX 6.0.7, HylaFAX+ 5.6.1
Vendor: Hylafax, Hylafax+
Vendor URL: https://www.hylafax.org/, http://hylafax.sourceforge.net/
Credit: X41 D-SEC GmbH, Luis Merino, Eric Sesterhenn, Markus Vervier
Status: Public
Advisory-URL: https://www.x41-dsec.de/lab/advisories/x41-2018-008-Hylafax/


Summary and Impact
------------------
Severity Rating: Critical
Vector: Incoming fax call
CVE: CVE-2018-17141
CWE: 122, 457
CVSS Score: 9.0
CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
Multiple bugs were found in the code handling fax page reception in JPEG
format that allow arbitrary writes to an uninitialized pointer by remote
parties dialing in. When processing an specially crafted input, the issue
could lead to remote code execution.
Although JPEG reception is not announced as an available capability
by HylaFAX and is explicitly disabled during capabilities announcement,
there is code for JPEG support in HylaFAX that can be reached by a remote
party when setting certain flags during session negotiation.
X41 did not perform a full test or audit on the software.


Product Description
-------------------
HylaFAX is an open-source system for sending and receiving faxes using
one or multiple fax modems.

Analysis
========
X41 discovered several vulnerabilities in HylaFAX that are exploitable
by local or remote attackers.


Uninitialized pointer write in FaxModem::writeECMData()
-------------------------------------------------------
In CopyQuality.c++:990 recvRow is initialized only when params.jp is
exactly JP_GREY or JP_COLOR and also params.df is exactly zero.

{% highlight c %}
uint dataform = params.df + (params.jp ? params.jp + 4 : 0);
//...
switch (dataform) {
//...
case JPGREY+4:
case JPCOLOR+4:
    recvEOLCount = 0;
    recvRow = (uchar) malloc(10241000); // 1M should do it?
{% endhighlight %}
However, later in the same function recvRow is used as a target for
memcpy() when params.jp is JP_GREY or JP_COLOR, irrespective of
params.df.  Consequently, if a sender crafts a DCS signal that leads to
params.df being non-zero while params.jp is JP_GREY or JP_COLOR, then
recvRow will be uninitialized when it is used as a target for memcpy().
{% highlight c %}
if (params.jp != JPGREY && params.jp != JPCOLOR) {
    flushRawData(tif, 0, (const u_char) buf, cc);
} else {
    memcpy(recvRow, (const char) buf, cc);
    recvRow += cc;
}
{% endhighlight %}


Out of bounds write in FaxModem::writeECMData()
-----------------------------------------------
The same piece of code for memcpy at CopyQuality.c++:1045 can be
abused to perform an out of bounds write to recvRow, as there is no
bounds check before writing to and incrementing recvRow. This can
lead to remote code execution when an attacker sends an specially
crafted input.


Out of bounds write in FaxModem::recvPageDLEData()
--------------------------------------------------
CopyQuality:c++:446 presents another unbounded memcpy that can be
abused to perform an out of bounds write to recvRow.

{% highlight c %}
if (n >= RCVBUFSIZ)
    flushRawData(tif, 0, (const u_char) raw, n);
else {
    memcpy(recvRow, (const char) raw, n);
    recvRow += n;
}
{% endhighlight %}

The code doesn't seem to be reachable, as JPEG flag forces ECM
reception.


Workaround
----------
None.

Timeline
========
2018-06-07 Issues found
2018-08-24 Issue reported to vendor
2018-09-02 Vendor sends patches
2018-09-17 CVE ID assigned
2018-09-18 Patches released
2018-09-19 Advisory released

#  0day.today [2024-12-26]  #