An exploitable privilege escalation vulnerability exists in the Shimo VPN helper service due to improper validation of code signing. A user with local access can use this vulnerability to raise their privileges to root. An attacker would need local access to the machine to successfully exploit this bug.

**Summary**

An exploitable privilege escalation vulnerability exists in the Shimo VPN helper service due to improper validation of code signing. A user with local access can use this vulnerability to raise their privileges to root. An attacker would need local access to the machine to successfully exploit this bug.

**Tested Versions**

Shimo VPN 4.1.5.1

**Product URLs**

https://www.shimovpn.com/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-19: Improper Input Validation

**Details**

Shimo VPN is a VPN client for Mac OSX used to connect to multiple VPN accounts in one place. The application uses what is defined as a “Helper Tool” to do some of the privileged work on its behalf. The helper tool is installed as root when the application is first installed and is a LaunchD daemon, meaning it will be restarted if it is killed. The service listens using:

    v3 = objc_msgSend(&OBJC_CLASS___NSXPCListener, "alloc");
    v4 = objc_msgSend(v3, "initWithMachServiceName:", CFSTR("com.feingeist.shimo.helper"));
    

The second argument registers the string passed in as a service and tells it to begin listening. The service can then be connected to using Objective-C XPC calls.A similar section of code needs to be executed to connect a client to this service.

     v8 = objc_msgSend(v7, "initWithMachServiceName:options:", CFSTR("com.feingeist.shimo.helper"), 4096LL); [1]
      v11 = objc_msgSend(
              &OBJC_CLASS___NSXPCInterface,
              "interfaceWithProtocol:",
              &OBJC_PROTOCOL___ShimoHelperToolProtocol);                                                      [2]
    

At \[1\], the same call as the one above is used, except this time, the options variable is used to signify that the client is connecting rather than listening. At \[2\], a special protocol is passed in that defines all the functions available to the client. The server must have the same protocol defined in order for these calls to work. We can begin to see the vulnerabilities arise by looking at the protocol.

This vulnerability is present inside of the connection management code for all the different provided VPN services. We will be focusing on connectOpenVPNWithConfig:withManagementPort:withReply: for this report. When one first installs the Shimo application, it bundles multiple VPN clients to actually instantiate the connections. These include, among others, openconnect, openvpn and vpnc. All of these executables are vulnerable to this code-signing attack. Below is the relevant code for the connectOpenVPN command.

    v20 = objc_msgSend(self->shimoBundle, "pathForAuxiliaryExecutable:", CFSTR("openvpn"));         [3]
    openvpn_path = objc_retainAutoreleasedReturnValue(v20);
    ...
            (objc_msgSend)(
              self,
              "runServiceAtPath:withArguments:withComPort:waitUntilExit:withError:",                [4]
              openvpn_path,
              arguments,
              0LL,
              1LL,
              &v59);
    

The above code snippet simply takes the path for the openvpn executable path,\[3\] and passes it into a helper function designed to run the service passing in the required arguments, \[4\]. The vulnerability becomes apparent when looking at the runServiceAtPath function.

    if (  v13 = objc_msgSend(v11, "fileExistsAtPath:", v9),                                               [5]
          objc_release(v11),  
          v14 = v13 == 0,
          v9 = v12,
          v14) )
    
    }
    if ( -[ShimoHelperTool codeSignStateForExecutable:](self, "codeSignStateForExecutable:", v12) != 2 )  [6]
    ...
      objc_msgSend(v16, "setLaunchPath:", v12);
      objc_msgSend(v16, "setCurrentDirectoryPath:", self->tmpDirPath);
      if ( v22 )
        objc_msgSend(v16, "setArguments:", v22);
      v37 = v16;
      objc_msgSend(v16, "launch");                                                                         [7]
    

At location \[5\], the passed-in executable is verified to actually exist. Then, at location \[6\], the executable is checked to be properly signed, and at \[7\], the program is launched with the required arguments. The issue with the code comes at location \[6\]. If we look at the function codeSignStateForExecutable, it will give us a bit more information as to what is happening at this line.

     v7 = 0LL;
      v3 = objc_msgSend(&OBJC_CLASS___NSURL, "fileURLWithPath:", a3);
      v4 = objc_retainAutoreleasedReturnValue(v3);
      SecStaticCodeCreateWithPath(v4, 0LL, &v7);
      v5 = 6;
      if ( v7 )
      {
        switch ( SecStaticCodeCheckValidityWithErrors(v7, 6LL, 0LL, 0LL) + 67062 )            [8]
    

This function first verifies that the file exists at the path. Then, at location \[8\], it calls out to an Apple-provided security API to check the code-signing of an executable. The second argument passed in the expected level of code-signing verification performed by this function call. Looking at the API, we can see that 6 correlates to kSecCSBasicValidateOnly. What this means is that the check is only verifying that the code is properly signed. There are no checks or verifications on the signing authority and thus any properly signed binary can be executed here. It is trivial to create a self-signed certificate to pass this check. Then, any application can be put into the place of the provided executable and be executed under root context. This creates a privilege escalation vulnerability.

**Exploit Proof of Concept**

This vulnerability is demonstrated with a program we have created and signed ourselves included with this report called openvpn_dummy. When run through the Shimo app this program will create a file called root.txt in the root directory, which is not writeable to any other than the root user. The Shimo application needs to attempt to establish a connection using OpenVpn and the replacement executable needs to be put into the application directory replacing the provided OpenVpn binary. Example command is shown below.

    mv openvpn_dummy Shimo.app/Contents/MacOS/openvpn 
    

**Timeline**

2018-09-21 - Vendor Disclosure  
2018-09-22 - Vendor acknowledged and gave main developer contact  
2018-09-26 - Reports sent to main developer  
2018-10-08 - First follow up  
2018-11-09 - 2nd follow up  
2018-12-04 - 3rd follow up  
2019-03-14 - Final follow up for public disclosure  
2019-04-15 - Zero day/Public release

Discovered by Tyler Bohan of Cisco Talos.

CVE-2018-4009: TALOS-2018-0678 || Cisco Talos Intelligence Group

Sequelize version 5 before 5.3.0 does not properly ensure that standard conforming strings are used.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2019-11069: Release v5.3.0 · sequelize/sequelize

Users who cached their CLI authentication before Jenkins was updated to 2.150.2 and newer, or 2.160 and newer, would remain authenticated in Jenkins 2.171 and earlier and Jenkins LTS 2.164.1 and earlier, because the fix for CVE-2019-1003004 in these releases did not reject existing remoting-based CLI authentication caches.

This advisory announces vulnerabilities in the following Jenkins deliverables:

*   Jenkins (core)

**Descriptions****Jenkins accepted cached legacy CLI authentication**

**SECURITY-1289 / CVE-2019-1003049**

The fix for SECURITY-901 in Jenkins 2.150.2 and 2.160 did not reject existing remoting-based CLI authentication caches.

This means that users who cached their CLI authentication before Jenkins was updated to 2.150.2 and newer, or 2.160 and newer, would remain authenticated.

Support for the remoting-based CLI was dropped in Jenkins 2.165, so newer weekly releases are not affected. Jenkins 2.164.2 no longer supports legacy CLI authentication caches from before 2.150.2/2.160, and these users will be considered logged out.

**XSS vulnerability in form validation button**

**SECURITY-1327 / CVE-2019-1003050**

The f:validateButton form control for the Jenkins UI did not properly escape job URLs. This resulted in a cross-site scripting (XSS) vulnerability exploitable by users with the ability to control job names.

The affected form control has been rewritten to no longer need to escape job URLs.

**Severity**

*   SECURITY-1289: Medium
*   SECURITY-1327: Medium

**Affected Versions**

*   Jenkins weekly up to and including 2.171
*   Jenkins LTS up to and including 2.164.1

**Fix**

*   Jenkins weekly should be updated to version 2.172
*   Jenkins LTS should be updated to version 2.164.2

These versions include fixes to the vulnerabilities described above. All prior versions are considered to be affected by these vulnerabilities unless otherwise indicated.

**Credit**

The Jenkins project would like to thank the reporters for discovering and reporting these vulnerabilities:

*   **Daniel Beck, CloudBees, Inc.** for SECURITY-1289

CVE-2019-1003049: Jenkins Security Advisory 2019-04-10

An elevation of privilege vulnerability exists in Windows when the Win32k component fails to properly handle objects in memory, aka 'Win32k Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2019-0685, CVE-2019-0859.

CVE-2019-0803

An elevation of privilege vulnerability exists when Windows AppX Deployment Service (AppXSVC) improperly handles hard links, aka 'Windows Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2019-0730, CVE-2019-0731, CVE-2019-0796, CVE-2019-0805, CVE-2019-0836.

CVE-2019-0841

The HTTP Connector component of TIBCO Software Inc.'s TIBCO ActiveMatrix BusinessWorks contains a vulnerability that theoretically allows unauthenticated HTTP requests to be processed by the BusinessWorks engine even when authentication is required. This possibility is restricted to circumstances where HTTP "Basic Authentication" policy is used in conjunction with an XML Authentication resource. The BusinessWorks engine might instead use credentials from a prior HTTP request for authorization purposes. Affected releases are TIBCO Software Inc. TIBCO ActiveMatrix BusinessWorks: versions up to and including 6.4.2.

**TIBCO ActiveMatrix BusinessWorks Fails To Properly Enforce Authentication**

Original release date: April 9, 2019  
Last revised:  
CVE-2019-8990  
Source: TIBCO Software Inc.

The information on this page is being provided to you on an "AS IS" and "AS-AVAILABLE" basis. The issues described on this page may or may not impact your system(s). TIBCO makes no representations, warranties, or guarantees as to the information contained herein. ANY AND ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE ARE HEREBY DISCLAIMED. BY ACCESSING THIS DOCUMENT YOU ACKNOWLEDGE THAT TIBCO SHALL IN NO EVENT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES THAT ARISE OUT OF YOUR USE OR FAILURE TO USE THE INFORMATION CONTAINED HEREIN. The information on this page is being provided to you under the terms of your license and/or services agreement with TIBCO, and may be used only for the purposes contemplated by the agreement. If you do not have such an agreement with TIBCO, this information is provided under the TIBCO.com Terms of Use, and may be used only for the purposes contemplated by such Terms of Use.

CVE-2019-8990: TIBCO Security Advisory: April 9, 2019 - TIBCO ActiveMatrix BusinessWorks

In Wireshark 2.4.0 to 2.4.13, 2.6.0 to 2.6.7, and 3.0.0, the DOF dissector could crash. This was addressed in epan/dissectors/packet-dof.c by properly handling generated IID and OID bytes.

**Summary**

**Name:** DOF dissector crash

**Docid:** wnpa-sec-2019-15

**Date:** April 8, 2019

**Affected versions:** 3.0.0, 2.6.0 to 2.6.7, 2.4.0 to 2.4.13

**Fixed versions:** 3.0.1, 2.6.8, 2.4.14

**References:**

Wireshark issue 15617.  
CVE-2019-10896.

**Details****Description**

The DOF dissector could crash. Discovered by the OSS-Fuzz project.

**Impact**

It may be possible to make Wireshark crash by injecting a malformed packet onto the wire or by convincing someone to read a malformed packet trace file.

**Resolution**

Upgrade to Wireshark 3.0.1, 2.6.8, 2.4.14 or later.

CVE-2019-10896: Wireshark • wnpa-sec-2019-15 DOF dissector crash

In Wireshark 2.4.0 to 2.4.13, 2.6.0 to 2.6.7, and 3.0.0, the LDSS dissector could crash. This was addressed in epan/dissectors/packet-ldss.c by handling file digests properly.

**Summary**

**Name:** LDSS dissector crash

**Docid:** wnpa-sec-2019-17

**Date:** April 8, 2019

**Affected versions:** 3.0.0, 2.6.0 to 2.6.7, 2.4.0 to 2.4.13

**Fixed versions:** 3.0.1, 2.6.8, 2.4.14

**References:**

Wireshark issue 15620.  
CVE-2019-10901.

**Details****Description**

The LDSS dissector could crash. Discovered by Mateusz Jurczyk.

**Impact**

It may be possible to make Wireshark crash by injecting a malformed packet onto the wire or by convincing someone to read a malformed packet trace file.

**Resolution**

Upgrade to Wireshark 3.0.1, 2.6.8, 2.4.14 or later.

CVE-2019-10901: Wireshark • wnpa-sec-2019-17 LDSS dissector crash

In clearFilter() in utilities.php in Cacti before 1.2.3, no escaping occurs before printing out the value of the SNMP community string (SNMP Options) in the View poller cache, leading to XSS.

**Describe the bug**  
There's no escape being done before printing out the value of SNMP community string (SNMP Options) in the View poller cache.

**To Reproduce**  
Steps to reproduce the behavior:

1.  Login as normal user ( should have device creation explicitly enabled ).
    
2.  Select create a new device from the console menu.
    
3.  Enter the below shared payload into the "SNMP community string" field & save the device. Payload - <script> alert('XSS'); document.location.replace('//google.com');</script>\`
    
4.  Now login as an Admin user & go to Utilities > System utils > View poller cache, XSS would be trigerred & redirected to google.com as specified in the payload. .
    

**Expected behavior**  
Proper filtration & escaping needs to be done, before taking in the data from the user.

**Screenshots**  

**Desktop (please complete the following information):**

*   OS: Ubuntu 16.04
*   Browser: Firefox

**Smartphone (please complete the following information):**

**Additional context**  
Vulnerable snippet:

Line 1849 in utilities.php  
__('Community:') . ' ' . $item['snmp_community']

CVE-2019-11025: When viewing poller cache, Device SNMP community is not properly escaped · Issue #2581 · Cacti/cacti

In the wp-google-maps plugin before 7.11.18 for WordPress, includes/class.rest-api.php in the REST API does not sanitize field names before a SELECT statement.

Tag

#perl