memory corruption bugs in libsane
GHSL-2020-075
, GHSL-2020-079
, GHSL-2020-080
, GHSL-2020-081
, GHSL-2020-082
, GHSL-2020-083
, GHSL-2020-084
GitHub Security Lab (GHSL) Vulnerability Report: The GitHub Security Lab team has identified potential security vulnerabilities in libsane.
We are committed to working with you to help resolve these issues. In this report you will find everything you need to effectively coordinate a resolution of these issues with the GHSL team.
If at any point you have concerns or questions about this process, please do not hesitate to reach out to us at securitylab@github.com
(please include the relevant GHSL IDs as a reference).
If you are NOT the correct point of contact for this report, please let us know!
Summary
libsane contains several memory corruption vulnerabilities which can be triggered by a malicious device or computer that is connected to the same network. The vulnerabilities are triggered when an application such as simple-scan searches the network for scanners. In the specific case of simple-scan, this happens immediately when simple-scan starts, so there isn't even any need to trick the user into thinking that the scanner is genuine so that they will click on it.
We have also identified some other vulnerabilities in libsane, which are less severe because they do require the user to click the "Scan" button after connecting to a malicious device. We have included these additional bugs in this report. Please note that we have not explored this "one click" attack surface as thoroughly as we have explored the "zero clicks" attack surface, so there may be other bugs in the code which we have not discovered. We also haven't explored the attack surface that would require the malicious device to be connected via USB, rather than the network.
Product
libsane
Tested Version
libsane 1.0.27-1~experimental3ubuntu2.2, tested on Ubuntu 18.04.4 LTS with simple-scan 3.28.0-0ubuntu1.
Details
GHSL-2020-075
): null pointer dereference in sanei_epson_net_read
Issue 1 (The function sanei_epson_net_read
has buggy code for handling the situation where it receives a response with an unexpected size:
/* receive net header */
size = sanei_epson_net_read_raw(s, header, 12, status);
if (size != 12) {
return 0;
}
if (header[0] != 'I' || header[1] != 'S') {
DBG(1, "header mismatch: %02X %02x\n", header[0], header[1]);
*status = SANE_STATUS_IO_ERROR;
return 0;
}
size = be32atoh(&header[6]); <===== size is controlled by attacker
DBG(23, "%s: wanted = %lu, available = %lu\n", __func__,
(u_long) wanted, (u_long) size);
*status = SANE_STATUS_GOOD;
if (size == wanted) {
DBG(15, "%s: full read\n", __func__);
read = sanei_epson_net_read_raw(s, buf, size, status);
if (s->netbuf) {
free(s->netbuf);
s->netbuf = NULL;
s->netlen = 0;
}
if (read < 0) {
return 0;
}
/* } else if (wanted < size && s->netlen == size) { */
} else {
DBG(23, "%s: partial read\n", __func__);
read = sanei_epson_net_read_raw(s, s->netbuf, size, status); <===== s->netbuf could be NULL
if (read != size) {
return 0;
}
s->netlen = size - wanted;
s->netptr += wanted;
read = wanted;
DBG(23, "0,4 %02x %02x\n", s->netbuf[0], s->netbuf[4]); <===== s->netbuf could be NULL
DBG(23, "storing %lu to buffer at %p, next read at %p, %lu bytes left\n",
(u_long) size, s->netbuf, s->netptr, (u_long) s->netlen);
memcpy(buf, s->netbuf, wanted);
}
return read;
Notice that the value of size
is read from an incoming message, so an attacker can set it to any value they like. In the else
branch, which handles the case where size != wanted
, there is no check that s->netbuf
is large enough for size
bytes. This could potentially lead to a buffer overflow. However, our proof-of-concept exploit for this bug triggers a case where s->netbuf
hasn't even been initialized so the program crashes due to a null pointer dereference, rather than a buffer overflow.
We have included a proof-of-concept exploit for this vulnerability. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
./fakescanner epson 0
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
simple-scan
You should see simple-scan
crash with a segmentation fault.
Impact
This issue may lead to remote denial of service, where "remote" means a device or computer connected to the same network as the victim. For example, in a typical office environment the malicious device would need to be somewhere inside the building. Because the vulnerability causes simple-scan
to crash as soon as it starts, it makes the application unusable.
Remediation
The else
branch of sanei_epson_net_read
, which handles the case where size != wanted
, should check that s->netbuf
has been initialized and that it is large enough for size
bytes.
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
GHSL-2020-079
): null pointer dereference in epsonds_net_read
Issue 2 (The function epsonds_net_read
has buggy code for handling the situation where it receives a response with an unexpected size:
/* receive net header */
size = epsonds_net_read_raw(s, header, 12, status);
if (size != 12) {
return 0;
}
if (header[0] != 'I' || header[1] != 'S') {
DBG(1, "header mismatch: %02X %02x\n", header[0], header[1]);
*status = SANE_STATUS_IO_ERROR;
return 0;
}
// incoming payload size
size = be32atoh(&header[6]);
DBG(23, "%s: wanted = %lu, available = %lu\n", __func__,
(u_long) wanted, (u_long) size);
*status = SANE_STATUS_GOOD;
if (size == wanted) {
DBG(15, "%s: full read\n", __func__);
if (size) {
read = epsonds_net_read_raw(s, buf, size, status);
}
if (s->netbuf) {
free(s->netbuf);
s->netbuf = NULL;
s->netlen = 0;
}
if (read < 0) {
return 0;
}
} else if (wanted < size) {
DBG(23, "%s: long tail\n", __func__);
read = epsonds_net_read_raw(s, s->netbuf, size, status); <===== no bounds check
if (read != size) {
return 0;
}
memcpy(buf, s->netbuf, wanted);
read = wanted;
free(s->netbuf);
s->netbuf = NULL;
s->netlen = 0;
} else {
DBG(23, "%s: partial read\n", __func__);
read = epsonds_net_read_raw(s, s->netbuf, size, status);
if (read != size) {
return 0;
}
s->netlen = size - wanted; <===== negative integer overflow (because size < wanted)
s->netptr += wanted;
read = wanted;
DBG(23, "0,4 %02x %02x\n", s->netbuf[0], s->netbuf[4]);
DBG(23, "storing %lu to buffer at %p, next read at %p, %lu bytes left\n",
(u_long) size, s->netbuf, s->netptr, (u_long) s->netlen);
memcpy(buf, s->netbuf, wanted); <===== no bounds check
}
return read;
This code is very similar to the code in epson2_net.c
(see issue 1) and has similar bugs. The first of these is a NULL pointer exception at epsonds-net.c, line 160.
We have included a proof-of-concept exploit for this vulnerability. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
./fakescanner epson 1
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
simple-scan
You should see simple-scan
crash with a segmentation fault.
Impact
This issue may lead to remote denial of service, where "remote" means a device or computer connected to the same network as the victim. For example, in a typical office environment the malicious device would need to be somewhere inside the building. Because the vulnerability causes simple-scan
to crash as soon as it starts, it makes the application unusable.
Remediation
The else
branch of epsonds_net_read
, which handles the case where wanted > size
, should check that s->netbuf
has been initialized and that it is large enough for wanted
bytes. There is also a negative integer overflow in the calculation of s->netlen
, which should be fixed.
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
GHSL-2020-080
): heap buffer overflow in epsonds_net_read
Issue 3 (This bug is in the same function as issue 2: epsonds_net_read
. There is a heap buffer overflow at epsonds-net.c, line 135. The value of size
is controlled by the attacker, so an arbitrary amount of attacker-controlled data is written to s->netbuf
.
We have included a proof-of-concept exploit for this vulnerability. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
./fakescanner epson 2
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
simple-scan
You should see simple-scan
crash with a segmentation fault.
Impact
This issue may lead to remote code execution, where "remote" means a device or computer connected to the same network as the victim. For example, in a typical office environment the malicious device would need to be somewhere inside the building.
Mitigations such as ASLR may make it difficult for an attacker to create a reliable RCE exploit for the vulnerability. The PoC that we have provided only causes libsane to crash.
Remediation
The else
branch of epsonds_net_read
, which handles the case where wanted < size
, should check that s->netbuf
has been initialized and that it is large enough for size
bytes.
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
GHSL-2020-081
): reading uninitialized data in epsonds_net_read
Issue 4 (This bug is in the same function as issue 2: epsonds_net_read
. The memcpy
at epsonds-net.c, line 164 can read uninitialized data. The value of size
is controlled by the attacker, so the attacker can specify that size == 0
. Since s->netbuf
is a newly allocated heap buffer, it contains uninitialized memory.
We have included a proof-of-concept exploit for this vulnerability. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
./fakescanner epson 3
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
$ gdb simple-scan
(gdb) break epsonds-net.c:164
(gdb) run
You need to run simple-scan
in a debugger (gdb) to see this bug, because it does not cause a crash.
Impact
By itself, the severity of this issue is very low. However, it may be very useful to an attacker who is attempting to exploit one of the buffer overflow vulnerabilities, such as issue 3, because it may enable the attacker to obtain the ASLR offsets of the program.
Remediation
The else
branch of epsonds_net_read
, which handles the case where wanted > size
, should copy at most size
bytes into buf
, because the remaining bytes are uninitialized.
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
GHSL-2020-082
): out-of-bounds read in decode_binary
Issue 5 (The function decode_binary
has an out-of-bounds read:
/* h000 */
static char *decode_binary(char *buf)
{
char tmp[6];
int hl;
memcpy(tmp, buf, 4);
tmp[4] = '\0';
if (buf[0] != 'h')
return NULL;
hl = strtol(tmp + 1, NULL, 16);
if (hl) {
char *v = malloc(hl + 1);
memcpy(v, buf + 4, hl);
v[hl] = '\0';
return v;
}
return NULL;
}
The value of hl
is controlled by the attacker and can be any value between 0 and 0xFFF (4095). buf
is a pointer to a 64 byte stack buffer (rbuf
in esci2_cmd
), so the memcpy at line 273 can copy up to 4095 bytes from the stack into the newly allocated buffer.
We have included a proof-of-concept exploit for this vulnerability. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
./fakescanner epson 4
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
$ gdb simple-scan
(gdb) break decode_binary
(gdb) run
You need to run simple-scan
in a debugger (gdb) to see this bug, because it does not cause a crash.
Impact
By itself, the severity of this issue is very low. However, it may be very useful to an attacker who is attempting to exploit one of the buffer overflow vulnerabilities, such as issue 3, because it may enable the attacker to obtain the ASLR offsets of the program.
Remediation
decode_binary
should check that hl
does not exceed the remaining number of bytes in the buffer.
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
sanei_tcp_write
Issue 6: SIGPIPE in This issue is not a security issue. It is just a minor coding issue which we noticed and which we thought we would mention since it is very easy to fix. sanei_tcp_write
calls send
, which can raise a SIGPIPE
signal if the socket connection has closed. It is not a serious issue because libsane has a signal handler for SIGPIPE
. We only noticed it because we were running libsane in gdb and saw the signal.
We have included a proof-of-concept for this issue. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
./fakescanner epson 5
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
$ gdb simple-scan
(gdb) run
You should see gdb pause the program because a SIGPIPE
was raised.
Impact
This issue does not have any security impact.
Remediation
We recommend passing MSG_NOSIGNAL
as the flags
argument of send
, so that it will return an error code rather than raising a SIGPIPE
. In other words, change the implementation of sanei_tcp_write
as follows:
ssize_t
sanei_tcp_write(int fd, const u_char * buf, int count)
{
return send(fd, buf, count, MSG_NOSIGNAL);
}
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
GHSL-2020-083
): out-of-bounds read in esci2_check_header
Issue 7 (esci2_check_header
uses sscanf
to read a number from the message:
/* INFOx0000100#.... */
/* read the answer len */
if (buf[4] != 'x') {
DBG(1, "unknown type in header: %c\n", buf[4]);
return 0;
}
err = sscanf(&buf[5], "%x#", more);
if (err != 1) {
DBG(1, "cannot decode length from header\n");
return 0;
}
buf
is a pointer to a 64 byte stack buffer (rbuf
in esci2_cmd
), the contents of which are entirely controlled by the attacker. If the attacker fills the buffer with the character '0', then sscanf
will read off the end of the buffer. If the characters beyond the buffer are valid hexadecimal digits, then they will be converted to a number and written to the variable named more
. The value of more
is included in the next message that is sent to the malicious device, so this issue is an information leak vulnerability.
We have included a proof-of-concept exploit for this vulnerability. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
./fakescanner epson 6
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
$ gdb simple-scan
(gdb) break epsonds-cmd.c:120
(gdb) run
You need to run simple-scan
in a debugger (gdb) to see this bug, because it does not cause a crash.
Impact
This issue may lead to remote information disclosure, where "remote" means a device or computer connected to the same network as the victim. In practice, though, this issue is very low severity, because the byte immediately following the buffer is usually not a valid hexadecimal digit, so no information disclosure occurs.
Remediation
Make sure that the string in the buffer is null-terminated, so that sscanf
cannot read beyond the end of the buffer.
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
sanei_tcp_read
Issue 8: integer overflow in the count parameter of The type of the count
argument of sanei_tcp_read
is int
, but it is sometimes called with an argument of type ssize_t
, which can cause an integer overflow.
We have included a proof-of-concept exploit for this vulnerability. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
./fakescanner epson 7
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
$ gdb simple-scan
(gdb) break epsonds_net_read_raw
(gdb) cond 1 (wanted > 10000)
(gdb) run
You need to run simple-scan
in a debugger (gdb) to see this bug, because it does not cause a crash. After gdb has stopped at the conditional breakpoint, you should be able to see that the value of wanted
is 4294967295. But when you step into sanei_tcp_read
the value of count
is -1 due to the integer overflow.
We think it is also worth mentioning that the error condition is ignored in esci2_cmd
(epsonds-cmd.c, line 195):
ssize_t read = eds_recv(s, pbuf, more, &status);
if (read != more) {
}
/* parse the received data block */
if (cb) {
status = esci2_parse_block(pbuf, more, userdata, cb);
if (status != SANE_STATUS_GOOD) {
DBG(1, "%s: %4s error while parsing received data block\n", __func__, cmd);
}
}
So the call to esci2_parse_block
on line 200 is reading uninitialized data.
Impact
The integer overflow appears to be harmless in practice.
Remediation
We recommend changing the type of the count
argument of sanei_tcp_read
to ssize_t
.
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
GHSL-2020-084
): buffer overflow in esci2_img
Issue 9 (This issue requires the user to click the "Scan" button, so it is a one-click vulnerability, rather than a zero-click vulnerability. The function esci2_img
has a heap buffer overflow:
SANE_Status
esci2_img(struct epsonds_scanner *s, SANE_Int *length)
{
SANE_Status status = SANE_STATUS_GOOD;
SANE_Status parse_status;
unsigned int more;
ssize_t read;
*length = 0;
if (s->canceling)
return SANE_STATUS_CANCELLED;
/* request image data */
eds_send(s, "IMG x0000000", 12, &status, 64);
if (status != SANE_STATUS_GOOD) {
return status;
}
/* receive DataHeaderBlock */
memset(s->buf, 0x00, 64);
eds_recv(s, s->buf, 64, &status);
if (status != SANE_STATUS_GOOD) {
return status;
}
/* check if we need to read any image data */
more = 0;
if (!esci2_check_header("IMG ", (char *)s->buf, &more)) { <===== attacker controls value of `more`
return SANE_STATUS_IO_ERROR;
}
/* this handles eof and errors */
parse_status = esci2_parse_block((char *)s->buf + 12, 64 - 12, s, &img_cb);
/* no more data? return using the status of the esci2_parse_block
* call, which might hold other error conditions.
*/
if (!more) {
return parse_status;
}
/* ALWAYS read image data */
if (s->hw->connection == SANE_EPSONDS_NET) {
epsonds_net_request_read(s, more);
}
read = eds_recv(s, s->buf, more, &status); <===== heap buffer overflow
if (status != SANE_STATUS_GOOD) {
return status;
}
if (read != more) {
return SANE_STATUS_IO_ERROR;
}
/* handle esci2_parse_block errors */
if (parse_status != SANE_STATUS_GOOD) {
return parse_status;
}
DBG(15, "%s: read %lu bytes, status: %d\n", __func__, (unsigned long) read, status);
*length = read;
if (s->canceling) {
return SANE_STATUS_CANCELLED;
}
return SANE_STATUS_GOOD;
}
We have included a proof-of-concept exploit for this vulnerability. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
./fakescanner epson 8
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
simple-scan
Now, if you click the "Scan" button then you should see simple-scan
crash with an error message like this:
corrupted size vs. prev_size
Aborted (core dumped)
Impact
This issue may lead to remote code execution, where "remote" means a device or computer connected to the same network as the victim. For example, in a typical office environment the malicious device would need to be somewhere inside the building.
Mitigations such as ASLR may make it difficult for an attacker to create a reliable RCE exploit for the vulnerability. The PoC that we have provided only causes libsane to crash.
Remediation
esci2_img
should check that the value of more
does not exceed the size of the buffer (s->buf
).
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
mc_setup_block_mode
Issue 10: SIGFPE in This issue requires the user to click the "Scan" button, so it is a one-click vulnerability, rather than a zero-click vulnerability. mc_setup_block_mode
does some arithmetic on attacker-controlled values, which can lead to a crash due to a divide-by-zero:
static SANE_Status
mc_setup_block_mode (Magicolor_Scanner *s)
{
/* block_len should always be a multiple of bytes_per_line, so
* we retrieve only whole lines at once */
s->block_len = (int)(0xff00/s->scan_bytes_per_line) * s->scan_bytes_per_line; <===== divide-by-zero
s->blocks = s->data_len / s->block_len;
s->last_len = s->data_len - (s->blocks * s->block_len);
if (s->last_len>0)
s->blocks++;
DBG(5, "%s: block_len=0x%x, last_len=0x%0x, blocks=%d\n", __func__, s->block_len, s->last_len, s->blocks);
s->counter = 0;
s->bytes_read_in_line = 0;
if (s->line_buffer)
free(s->line_buffer);
s->line_buffer = malloc(s->scan_bytes_per_line);
if (s->line_buffer == NULL) {
DBG(1, "out of memory (line %d)\n", __LINE__);
return SANE_STATUS_NO_MEM;
}
DBG (5, " %s: Setup block mode - scan_bytes_per_line=%d, pixels_per_line=%d, depth=%d, data_len=%x, block_len=%x, blocks=%d, last_len=%x\n",
__func__, s->scan_bytes_per_line, s->params.pixels_per_line, s->params.depth, s->data_len, s->block_len, s->blocks, s->last_len);
return SANE_STATUS_GOOD;
}
The value of s->scan_bytes_per_line
is attacker controlled. If it's zero, then the code crashes due to a divide-by-zero error.
We have included a proof-of-concept exploit for this vulnerability. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
sudo ./fakescanner magicolor
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
simple-scan
Now, if you click the "Scan" button then you should see simple-scan
crash with an error message like this:
Floating point exception (core dumped)
Impact
This issue does not have any security impact, because the user has to click the "Scan" button to trigger the bug and the only consequence is that libsane will crash.
Remediation
cmd_get_scanning_parameters
should do better validation of the parameters received from the device.
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
mc_get_device_from_identification
Issue 11: read of uninitialized data in The function mc_network_discovery_handle
calls mc_get_device_from_identification
on line 1915 with device
containing uninitialized data. Ironically, this does not cause anything to go wrong due to a bug in the implementation of mc_get_device_from_identification
:
static struct MagicolorCap *
mc_get_device_from_identification (const char*ident)
{
int n;
for (n = 0; n < NELEMS (magicolor_cap); n++) {
if (strcmp (magicolor_cap[n].model, ident) || strcmp (magicolor_cap[n].OID, ident))
return &magicolor_cap[n];
}
return NULL;
}
The bug is that strcmp
returns 0 when the strings are equal, so this function always succeeds immediately on the first iteration of the loop, even when ident
contains garbage (which it does because it's uninitialized).
We have included a proof-of-concept exploit for this vulnerability. Compile and run the PoC as follows:
g++ fakescanner.cpp -o fakescanner
sudo ./fakescanner magicolor
Now run simple-scan
on a different computer that is connected to the same network (ethernet or wifi):
$ gdb simple-scan
(gdb) break mc_get_device_from_identification
(gdb) run
You need to run simple-scan
in a debugger (gdb) to see this bug, because it does not cause a crash.
Impact
This issue does not have any security impact.
Remediation
Use memset
to initialize device
at the beginning of mc_network_discovery_handle
.
Check the return value of strcmp
correctly in mc_get_device_from_identification
:
static struct MagicolorCap *
mc_get_device_from_identification (const char*ident)
{
int n;
for (n = 0; n < NELEMS (magicolor_cap); n++) {
if (strcmp (magicolor_cap[n].model, ident) == 0 || strcmp (magicolor_cap[n].OID, ident) == 0)
return &magicolor_cap[n];
}
return NULL;
}
Resources
We have attached the source code for our PoC, fakescanner.cpp, to this report.
Credit
These issues were discovered and reported by GHSL team member @kevinbackhouse (Kevin Backhouse).
Contact
You can contact the GHSL team at securitylab@github.com
, please include the relevant GHSL IDs in any communication regarding these issues.
Disclosure Policy
This report is subject to our coordinated disclosure policy.