The is a code injection vulnerability in versions of Rails prior to 5.0.1 that wouldallow an attacker who controlled the `locals` argument of a `render` call to perform a RCE.

CVE-2020-8163

PLCopen XML file parsing in Phoenix Contact PC Worx and PC Worx Express version 1.87 and earlier can lead to a stack-based overflow. Manipulated PC Worx projects could lead to a remote code execution due to insufficient input data validation.

2020-07-01 10:25 (CEST) VDE-2020-023  

**PHOENIX CONTACT: Two Vulnerabilities in Automation Worx Suite**  
Share: Email | Twitter  

**

Published

**

2020-07-01 10:25 (CEST)

**

Last update

**

2020-07-01 10:25 (CEST)

**Vendor(s)**

PHOENIX CONTACT GmbH & Co. KG  

**Product(s)**

Article No°

Product Name

Affected Version(s)

PC Worx

<= 1.87

PC Worx Express

<= 1.87

**

Summary

**

Manipulated PC Worx projects could lead to a remote code execution due to insufficient input  
data validation.

The attacker needs to get access to an original PC Worx project to be able to manipulate data  
inside the project folder. After manipulation the attacker needs to exchange the original files by  
the manipulated ones on the application programming workstation.

**

Vulnerabilities

**

**Last Update**

3\. Juli 2020 15:34

**Weakness**

Stack-based Buffer Overflow (CWE-121)

**Summary**

_PLCopen XML file parsing in Phoenix Contact PC Worx and PC Worx Express version 1.87 and earlier can lead to a stack-based overflow. Manipulated PC Worx projects could lead to a remote code execution due to insufficient input data validation._

**Last Update**

3\. Juli 2020 15:34

**Weakness**

Stack-based Buffer Overflow (CWE-121)

**Summary**

_mwe file parsing in Phoenix Contact PC Worx and PC Worx Express version 1.87 and earlier is vulnerable to out-of-bounds read remote code execution. Manipulated PC Worx projects could lead to a remote code execution due to insufficient input data validation._

**

Impact

**

Availability, integrity, or confidentiality of an application programming workstation might be compromised by attacks using these vulnerabilities.  
Automated systems in operation which were programmed with one of the above-mentioned products are not affected.

**

Solution

**

**Temporary Fix / Mitigation**

We strongly recommend customers to exchange project files only using secure file exchange services. Project files should not be exchanged via unencrypted email.  
In addition, we recommend exchanging or storing project files together with a checksum to ensure their integrity.

**Remediation**

With the next version of Automation Worx Software Suite a sharpened input data validation with respect to buffer size and description of size and number of objects referenced in a file will be implemented.

**

Reported by

**

ZDI-CAN-10147 was discovered by Natnael Samson working with Trend Micro Zero Day Initiative  
ZDI-CAN-10586 was discovered by mdm working with Trend Micro Zero Day Initiative

Phoenix Contact reported the vulnerabilities to CERT@VDE.

CVE-2020-12497: VDE-2020-023 | CERT@VDE

In BIG-IP versions 15.0.0-15.1.0.3, 14.1.0-14.1.2.5, 13.1.0-13.1.3.3, 12.1.0-12.1.5.1, and 11.6.1-11.6.5.1, the Traffic Management User Interface (TMUI), also referred to as the Configuration utility, has a Remote Code Execution (RCE) vulnerability in undisclosed pages.

CVE-2020-5902

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.

Tag

#rce