Percona XtraBackup 2.4.20 unintentionally writes the command line to any resulting backup file output. This may include sensitive arguments passed at run time. In addition, when --history is passed at run time, this command line is also written to the PERCONA_SCHEMA.xtrabackup_history table. NOTE: this issue exists because of an incomplete fix for CVE-2020-10997.

Date

April 26, 2022

Percona XtraBackup for MySQL Databases enables MySQL backups without blocking user queries. Percona XtraBackup is ideal for companies with large data sets and mission-critical applications that cannot tolerate long periods of downtime. Offered free as an open source solution, Percona XtraBackup drives down backup costs while providing unique features for MySQL backups.

Percona XtraBackup 2.4 does not support making backups of databases created in _MySQL 8.0_, _Percona Server for MySQL 8.0_, or _Percona XtraDB Cluster 8.0_. Use Percona XtraBackup 8.0 to make backups for these versions.

*   Release Highlights
    
*   New Features
    
*   Bugs Fixed
    
*   Useful Links
    

**Release Highlights¶**

The xbcloud binary adds support for the Microsoft Azure Cloud Storage using the REST API.

**New Features¶**

*   PXB-1883: Implements support for Microsoft Azure Cloud Storage in the xbcloud binary. (Thanks to Ivan Groenewold for reporting this issue)
    

**Bugs Fixed¶**

*   PXB-2608: Upgraded the Vault API to V2 (Thanks to Benedito Marques Magalhaes for reporting this issue)
    
*   PXB-2649: Fix for compilation issues on GCC-10.
    
*   PXB-2648: CURL prior to 7.38.0 version doesn’t use CURLE\_HTTP2 and throws an error 'CURLE_HTTP2' is not a member of 'CURLcode'. Added CURLE\_OBSOLETE16 as a connectivity error code. In CURL versions after 7.38.0, CURLE\_OBSOLETE16 is translated to CURLE\_HTTP2.
    
*   PXB-2711: Fix for libgcrypt initialization warnings in xtrabackup.
    
*   PXB-2722: Fix for when via command line, a password, passed using the -p option, was written into the backup tool\_command in xtrabackup\_info.
    

**Useful Links¶**

*   The Percona XtraBackup installation instructions
    
*   The Percona XtraBackup downloads
    
*   The Percona XtraBackup GitHub location
    
*   To contribute to the documentation, review the Documentation Contribution Guide

CVE-2022-26944: Percona XtraBackup 2.4.25 — Percona XtraBackup 2.4 Documentation

libdwarf 0.4.0 has a heap-based buffer over-read in _dwarf_check_string_valid in dwarf_util.c.

CVE-2022-32200: DA's Libdwarf Vulnerabilities

Onlyoffice Document Server v6.0.0 and below and Core 6.1.0.26 and below were discovered to contain a stack overflow via the component DesktopEditor/common/File.cpp.

@@ -159,60 +159,90 @@ namespace NSFile else if (0x00 == (byteMain & 0x20)) { // 2 byte int val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); int val = 0; if ((lIndex + 1) < lCount) { val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 2; } else if (0x00 == (byteMain & 0x10)) { // 3 byte int val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); int val = 0; if ((lIndex + 2) < lCount) { val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 3; } else if (0x00 == (byteMain & 0x0F)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 4; } else if (0x00 == (byteMain & 0x08)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 4; } else if (0x00 == (byteMain & 0x04)) { // 5 byte int val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); int val = 0; if ((lIndex + 4) < lCount) { val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 5; } else { // 6 byte int val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); int val = 0; if ((lIndex + 5) < lCount) { val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); }  
pUnicodeString\[lIndexUnicode++\] = (WCHAR)(val); lIndex += 5; } @@ -242,64 +272,89 @@ namespace NSFile else if (0x00 == (byteMain & 0x20)) { // 2 byte int val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); int val = 0; if ((lIndex + 1) < lCount) { val = (int)(((byteMain & 0x1F) << 6) | (pBuffer\[lIndex + 1\] & 0x3F)); }  
\*pUnicodeString++ = (WCHAR)(val); lIndex += 2; } else if (0x00 == (byteMain & 0x10)) { // 3 byte int val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); int val = 0; if ((lIndex + 2) < lCount) { val = (int)(((byteMain & 0x0F) << 12) | ((pBuffer\[lIndex + 1\] & 0x3F) << 6) | (pBuffer\[lIndex + 2\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 3; } else if (0x00 == (byteMain & 0x0F)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 4; } else if (0x00 == (byteMain & 0x08)) { // 4 byte int val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); int val = 0; if ((lIndex + 3) < lCount) { val = (int)(((byteMain & 0x07) << 18) | ((pBuffer\[lIndex + 1\] & 0x3F) << 12) | ((pBuffer\[lIndex + 2\] & 0x3F) << 6) | (pBuffer\[lIndex + 3\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 4; } else if (0x00 == (byteMain & 0x04)) { // 5 byte int val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); int val = 0; if ((lIndex + 4) < lCount) { val = (int)(((byteMain & 0x03) << 24) | ((pBuffer\[lIndex + 1\] & 0x3F) << 18) | ((pBuffer\[lIndex + 2\] & 0x3F) << 12) | ((pBuffer\[lIndex + 3\] & 0x3F) << 6) | (pBuffer\[lIndex + 4\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 5; } else { // 6 byte int val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); int val = 0; if ((lIndex + 5) < lCount) { val = (int)(((byteMain & 0x01) << 30) | ((pBuffer\[lIndex + 1\] & 0x3F) << 24) | ((pBuffer\[lIndex + 2\] & 0x3F) << 18) | ((pBuffer\[lIndex + 3\] & 0x3F) << 12) | ((pBuffer\[lIndex + 4\] & 0x3F) << 6) | (pBuffer\[lIndex + 5\] & 0x3F)); }  
WriteUtf16\_WCHAR(val, pUnicodeString); lIndex += 5;

CVE-2022-29776: Fix 25 errors · ONLYOFFICE/core@88cf60a

USR IOT 4G LTE Industrial Cellular VPN Router v1.0.36 was discovered to contain hard-coded credentials for its highest privileged account. The credentials cannot be altered through normal operation of the device.

Title: USR IOT 4G LTE Industrial Cellular VPN Router 1.0.36 Remote Root Backdoor  
Advisory ID: ZSL-2022-5705  
Type: Local/Remote  
Impact: Exposure of Sensitive Information, Security Bypass, System Access, DoS  
Risk: (5/5)  
Release Date: 20.04.2022

**Summary**

USR-G806 is a industrial 4G wireless LTE router which provides a solution for users to connect own device to 4G network via WiFi interface or Ethernet interface. USR-G806 adopts high performance embedded CPU which can support 580MHz working frequency and can be widely used in Smart Grid, Smart Home, public bus and Vending machine for data transmission at high speed. USR-G806 supports various functions such as APN card, VPN, WIFIDOG, flow control and has many advantages including high reliability, simple operation, reasonable price. USR-G806 supports WAN interface, LAN interface, WLAN interface, 4G interface. USR-G806 provides various networking mode to help user establish own network.

**Description**

The USR IOT industrial router is vulnerable to hard-coded credentials within its Linux distribution image. These sets of credentials are never exposed to the end-user and cannot be changed through any normal operation of the device. The 'usr' account with password 'www.usr.cn' has the highest privileges on the device. The password is also the default WLAN password.

**Vendor**

Jinan USR IOT Technology Limited - https://www.pusr.com

**Affected Version**

1.0.36 (USR-G800V2, USR-G806, USR-G807, USR-G808)  
1.2.7 (USR-LG220-L)

**Tested On**

GNU/Linux 3.10.14 (mips)  
OpenWrt/Linaro GCC 4.8-2014.04  
Ralink SoC MT7628 PCIe RC mode  
BusyBox v1.22.1  
uhttpd  
Lua

**Vendor Status**

\[10.04.2022\] Vulnerability discovered.  
\[14.04.2022\] Vendor contacted.  
\[19.04.2022\] No response from the vendor.  
\[20.04.2022\] Public security advisory released.

**PoC**

usriot\_root.py

**Credits**

Vulnerability discovered by Gjoko Krstic - <gjoko@zeroscience.mk\>

**References**

\[1\] https://packetstormsecurity.com/files/166813/  
\[2\] https://cxsecurity.com/issue/WLB-2022040086  
\[3\] https://exchange.xforce.ibmcloud.com/vulnerabilities/224930  
\[4\] https://www.exploit-db.com/exploits/50894  
\[5\] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29730  
\[6\] https://nvd.nist.gov/vuln/detail/CVE-2022-29730

**Changelog**

\[20.04.2022\] - Initial release  
\[03.05.2022\] - Added reference \[1\], \[2\] and \[3\]  
\[13.05.2022\] - Added reference \[4\]  
\[29.05.2022\] - Added reference \[5\] and \[6\]

**Contact**

Zero Science Lab

Web: https://www.zeroscience.mk  
e-mail: lab@zeroscience.mk

CVE-2022-29730: Zero Science Lab » USR IOT 4G LTE Industrial Cellular VPN Router 1.0.36 Remote Root Backdoor

** UNSUPPORTED WHEN ASSIGNED ** An issue was discovered in WinAPRS 2.9.0. A buffer overflow in DIGI address processing for VHF KISS packets allows a remote attacker to cause a denial of service (daemon crash) via a malicious AX.25 packet over the air. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Hackers have been breaching computer system defenses for more than half a century, and the networks they use to exploit those weaknesses have been around for far longer than that. With the internet replacing most wirelines and wavelengths, and with the rise of cybercrime sophistication from petty thieves to organized nation-states, the threat landscape has exploded over the last 20 years. Yet one of the oldest network protocols – amateur or “ham” radio – is still used to this day in emergency communications during times of war and disaster, and to this day can still be used in binary exploitation.

Ham radio evokes an image of old guys turning knobs on vintage, tube radios and talking to other hobbyists about their configurations. Nowadays, radios are getting much more complicated, and with the built-in ability to perform digital communications, the possibilities are almost limitless. You can hook them up to computers to do anything from text messaging and email to sharing images and tracking weather balloons. There’s still something magical about connecting to a device or contacting someone across the planet without being hooked up to the internet or a phone line.

I recently passed the Offensive Security Exploit Developer (OSED) exam and wanted to apply what I’d learned to real-world security problems. I’m always looking for ways to improve my threat modeling, attack simulation, and penetration testing skills, and thought that ham radio would be a fun environment to explore. Amateur radio equipment and frequency spectrums are accessible all over the world and are instructive for a blog series that shows how the vulnerabilities of older technologies can be leveraged with today’s hacking fundamentals. With ham radio as our testing and proving ground, we’ll look at reverse engineering, the creation of custom exploits, and developing skills to bypass security mitigations. We’ll also take a look at writing handmade Windows shellcode and adopting older techniques to more modern versions of Windows.

**Packet Radio**

I've been messing around with packet radio and various digital modes on and off for years and have wondered if any vulnerabilities exist that could allow an attacker to obtain remote code execution through the airwaves. I always thought it was a fun idea to be able to hack a computer that isn't even hooked up to the internet. Many ham programs are written by enthusiasts and are quite old, so it seemed likely that there would be exploitable vulnerabilities. In my research I decided to focus mainly on vulnerabilities that could lead to remote code or command execution, though if I found other vulnerabilities, I didn't ignore them. I also decided to start by focusing on Windows software, since the OSED exam focused on Windows user-mode exploitation and it's where I have the most experience. I started this project with a specific goal in mind: get a remote shell over ham radio.

As a hacker, I am most interested in the various digital modes that ham radio has to offer. There are many, and for my research I decided to focus on software that uses the AX.25 protocol.

"Packet radio" generally refers to a very specific digital mode of operation that uses the AX.25 protocol. AX.25 is a data-link layer protocol (layer 2 of the OSI model). In this mode, data is split into packets and transmitted over the air. AX.25 has support for different packet types and includes modes that are similar to Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) on Ethernet. In some cases, the protocol can do some error correcting, like TCP. Another mode will just send packets out into the air without waiting for any kind of acknowledgement, like UDP. Windows does not have any built-in way to handle AX.25 traffic, so end-user software would have to do this on its own or it must be abstracted away. The Linux kernel has built-in support for AX.25, so you can potentially set up AX.25 network interfaces that have callsigns for addresses instead of IP addresses.

AX.25 is commonly used today for Automatic Packet Reporting System (APRS), Winlink email over ham radio, Bulletin Board Systems (BBS) operations, and more. It seems it is more generally used for a ham to make a contact with a computer, as opposed to making live contacts with other hams. More information about the AX.25 protocol can be found here: http://www.ax25.net/AX25.2.2-Jul%2098-2.pdf

**Automatic Packet Reporting System (APRS)**

The most common use of AX.25 is with the Automatic Packet Reporting System (APRS). Therefore, I decided to focus first on APRS software for this research project. APRS allows hams to transmit telemetry data such as GPS coordinates, weather data, small generic messages, and more. An APRS station can send out a broadcast message, or it can send a message addressed to another specific station. Since the range on the 2m band isn’t that great, APRS stations can “digipeat” the packets out again. This means that if one station receives a packet, it will retransmit it to send it further away. There are also “IGate” systems which are bridged to the internet via the APRS Internet Service (APRS-IS) backbone (http://www.aprs-is.net). This adds extra usability to the APRS system and means you can transmit data globally using the internet if desired. In fact, you can view APRS traffic anywhere in the world at https://aprs.fi and you don’t even need a license to check it out.

How do APRS stations find each other? How does one station find an IGate to bridge to the internet? You can transmit APRS on basically any amateur frequency for which you are licensed, but around the globe each region generally has an allotted frequency where this traffic is used. In the US, that frequency is 144.390 MHz. Just about anywhere in the country you can tune a radio to this frequency and hear data being transmitted at least every minute or so.

APRS is a protocol that runs on top of AX.25, like how HTTP runs on top of TCP. APRS packets make use of the AX.25 unnumbered information (UI) frames. Since I was going to be reverse engineering APRS software, it made sense to examine APRS data frames to understand their structure. AX.25 UI frames look like this:

  
**Image from** **http://www.aprs.org/doc/APRS101.PDF**

In an AX.25 UI frame, all addresses will be ham radio callsigns with an optional SSID appended to them. If your callsign was K7HAX, your address could be something like K7HAX-14. The digipeater addresses field can contain up to eight digipeater addresses to specify the path the packet should take. A digipeater is a radio station that listens for packets and then retransmits those packets to extend the range. The information field contains user-specified data. APRS makes heavy use of this field and it’s likely to be the most interesting field to play with.

The APRS specification allows for various data types, formats, and encodings. Most of this information is stored in the information field of the AX.25 packet. A generic APRS information field structure looks like this:

  
**Image from** **http://www.aprs.org/doc/APRS101.PDF**

The data type specifies what kind of APRS data follows. Options include GPS position, direction finding, weather information, messages, and more. Here’s a real APRS message I pulled from https://aprs.fi:

:Are you working tonight?

The colon denotes that the APRS data contains a message. The rest of the data is just the plaintext message. In this case the APRS data extension and comment fields are unused. Here’s another example:

\=3319.44S/06012.46W# 144.930MHz. SNDigi

The equal sign denotes that the data contains position data without a timestamp. Immediately following that is the actual position data. Between the two coordinates is a forward slash and immediately following the data is a hash symbol. Combined, these symbols would make “/#”. This data tells the receiving station what type of station sent the message and what symbol or icon to use to display the station on a map.

APRS has two tables full of different symbols (car, truck, bicycle, balloon, etc.). The forward slash specifies which table to use. The hash tells which symbol to use in that table. After the hash symbol is some additional message data which appears to list the transmitting frequency and probably the software or device used to transmit (SNDigi). There’s so much more to APRS than just this but it gives a rough idea of how the packets look and what we can expect APRS software to be doing when decoding messages. More information about the APRS protocol can be found here: http://www.aprs.org/doc/APRS101.PDF

Since APRS is probably the most common packet protocol in use today, and there is no shortage of APRS software to choose from, I decided to start my research here. I focused on Windows-based APRS software that was written in C or C++ so I could continue honing my IDA and WinDbg reversing skills.

**Hardware for Packet Radio**

There is a huge number of combinations of hardware to get on the air with packet, but in general you’ll need three main components: a transceiver, a terminal node controller (TNC), and a computer. You use the computer to interact with the various packet radio software you want to use. The transceiver sends and receives the communications over the radio. The TNC is basically a packet radio modem that sits between the two, converting the data into sound. It works similarly to a dial-up modem, but for radio instead of telephone lines. A TNC is typically a little box that’s hooked up to the computer and the radio. A TNC will often have a built-in microcomputer with its own operating system so you can open a terminal and send and receive messages right from the TNC. My TNC has a built-in mailbox where other hams can leave messages. It can decode APRS messages with its own software and display them in a human-readable format via serial console. Here’s a photo of the hardware I’m using for my receiving station:

****

**Keep It Simple, Stupid! (KISS)**

Each TNC make and model has its own set of commands you must use to send packets, and they may display packets differently to the user. The computer software must therefore understand how to interface with each make and model, which is cumbersome. To remedy this, most TNCs support a mode called KISS (Keep It Simple, Stupid). This mode disables all the “smart” features of the TNC and turns it into a dumb modem. The TNC will simply demodulate the signals from the radio and transmit the raw data back to your PC and vice versa. To simplify things, I’ll be placing my TNC into KISS mode for testing and using it wherever possible.

The important bit to know about the KISS protocol is that the TNC will add a 0xC0 control character to the beginning and end of each packet, and it will expect those characters to be there for any outgoing transmissions. There are also a few other special control characters the TNC will watch for, which is important to be aware of when writing shellcode later. These characters would be considered “bad characters” when writing shellcode and must be avoided. A full description of the KISS protocol can be found here: http://www.ax25.net/kiss.aspx

**Choosing an APRS Program**

The aprs-is.net website has a list of some known APRS client software.

Looking over the list, I figured an older client would be the most likely to contain exploitable memory corruption vulnerabilities. Looking at the various options, I found that the WinAPRS download page said it hadn't been updated since January 14, 2013. I figured that was a good sign that the software was likely not maintained and would therefore contain vulnerabilities. I downloaded the latest version (2.9.0) and got to work.

**Next Steps**

The next post in this series will discuss the reverse engineering process using WinDbg. We’ll dive into the nitty gritty technical details of an exploitable memory corruption vulnerability in WinAPRS including how it was found and why it’s exploitable.

CVE-2022-24700: Hacking Ham Radio: WinAPRS – Part 1

RSA Archer 6.8.00500.1003 P5 allows Unrestricted Upload of a File with a Dangerous Type.

master

Switch branches/tags

**1** branch **0** tags

Code

**Latest commit**

**Git stats**

*   **107** commits

**Files**Permalink

Failed to load latest commit information.

Type

Name

Latest commit message

Commit time

2022

FEYE-2019-0001

FEYE-2019-0002

FEYE-2019-0003

FEYE-2019-0004

FEYE-2019-0005

FEYE-2019-0006

FEYE-2019-0007

FEYE-2019-0008

FEYE-2019-0009

FEYE-2019-0010

FEYE-2019-0011

FEYE-2019-0012

FEYE-2019-0013

FEYE-2019-0014

FEYE-2019-0015

FEYE-2020-0001

FEYE-2020-0002

FEYE-2020-0003

FEYE-2020-0004

FEYE-2020-0005

FEYE-2020-0006

FEYE-2020-0007

FEYE-2020-0008

FEYE-2020-0009

FEYE-2020-0010

FEYE-2020-0011

FEYE-2020-0012

FEYE-2020-0013

FEYE-2020-0014

FEYE-2020-0015

FEYE-2020-0016

FEYE-2020-0017

FEYE-2020-0018

FEYE-2020-0019

FEYE-2020-0020

FEYE-2021-0001

FEYE-2021-0002

FEYE-2021-0003

FEYE-2021-0004

FEYE-2021-0005

FEYE-2021-0006

FEYE-2021-0007

FEYE-2021-0008

FEYE-2021-0009

FEYE-2021-0010

FEYE-2021-0011

FEYE-2021-0012

FEYE-2021-0013

FEYE-2021-0014

FEYE-2021-0015

FEYE-2021-0016

FEYE-2021-0017

FEYE-2021-0018

FEYE-2021-0019

FEYE-2021-0020

FEYE-2021-0021

FEYE-2021-0022

FEYE-2021-0023

FEYE-2021-0024

FEYE-2021-0025

MNDT-2021-0001

MNDT-2021-0002

MNDT-2021-0003

MNDT-2021-0004

MNDT-2021-0005

MNDT-2021-0006

MNDT-2021-0007

MNDT-2021-0008

MNDT-2021-0009

MNDT-2021-0010

MNDT-2021-0011

MNDT-2021-0012

README.md

**README.md**

**Mandiant Vulnerability Disclosures**

This repository details vulnerabilities disclosed by Mandiant. These vulnerabilities were discovered by internal research, through Red Team assessments, or in use in the wild. Proof of concepts (PoCs) may or may not be provided.

**About**

No description, website, or topics provided.

**Resources**

Readme

**Stars**

**117** stars

**Watchers**

**23** watching

**Forks**

**41** forks

**Releases**

No releases published

**Packages**

No packages published  

**Contributors 3**

**Languages**

*   C++ 100.0%

CVE-2021-33615: GitHub - mandiant/Vulnerability-Disclosures

An issue was discovered in swftools through 20201222. A NULL pointer dereference exists in the function traits_parse() located in abc.c. It allows an attacker to cause Denial of Service.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==47344==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000030 (pc 0x000000488d17 bp 0x000000000000 sp 0x7fffffffdd20 T0)  
#0 0x488d16 in traits\_parse as3/abc.c:482  
#1 0x495d41 in swf\_ReadABC as3/abc.c:946  
#2 0x409045 in main /test/swftools-asan/src/swfdump.c:1577  
#3 0x7ffff68a683f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#4 0x40c168 in \_start (/test/swftools-asan/src/swfdump+0x40c168)

AddressSanitizer can not provide additional info.  
SUMMARY: AddressSanitizer: SEGV as3/abc.c:482 traits\_parse  
\==47344==ABORTING

POC  
traits\_parse\_poc

CVE-2021-42196: A NULL pointer dereference exists in the function traits_parse  in abc.c · Issue #172 · matthiaskramm/swftools

An issue was discovered in swftools through 20201222 through a memory leak in the swftools when swfdump is used. It allows an attacker to cause code execution.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==43305==ERROR: LeakSanitizer: detected memory leaks

Indirect leak of 63245 byte(s) in 2 object(s) allocated from:  
#0 0x7ffff6f02602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)  
#1 0x532fa7 in rfx\_alloc /test/swftools-asan/lib/mem.c:30  
#2 0x7fffffffe2bf ()

Indirect leak of 144 byte(s) in 3 object(s) allocated from:  
#0 0x7ffff6f0279a in \_\_interceptor\_calloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x9879a)  
#1 0x53318c in rfx\_calloc /test/swftools-asan/lib/mem.c:69  
#2 0x7fffffffe2bf ()

SUMMARY: AddressSanitizer: 63389 byte(s) leaked in 5 allocation(s).

POC  
memory\_leaks\_poc

CVE-2021-42197: memory leaks in swftools when we use swfdump · Issue #177 · matthiaskramm/swftools

An issue was discovered in swftools through 20201222. A NULL pointer dereference exists in the function swf_GetBits() located in rfxswf.c. It allows an attacker to cause Denial of Service.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==41593==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000471fac bp 0x0ffffed896e0 sp 0x7fffffffdd30 T0)  
#0 0x471fab in swf\_GetBits /test/swftools-asan/lib/rfxswf.c:213  
#1 0x478bf8 in swf\_GetMatrix /test/swftools-asan/lib/rfxswf.c:867  
#2 0x414975 in handlePlaceObject /test/swftools-asan/src/swfdump.c:831  
#3 0x409acd in main /test/swftools-asan/src/swfdump.c:1604  
#4 0x7ffff68a683f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#5 0x40c168 in \_start (/test/swftools-asan/src/swfdump+0x40c168)

AddressSanitizer can not provide additional info.  
SUMMARY: AddressSanitizer: SEGV /test/swftools-asan/lib/rfxswf.c:213 swf\_GetBits  
\==41593==ABORTING

POC  
swf\_GetBits\_null\_poc

CVE-2021-42198: A NULL pointer dereference exists in the function swf_GetBits in rfxswf.c · Issue #168 · matthiaskramm/swftools

An issue was discovered in swftools through 20201222. A heap buffer overflow exists in the function swf_FontExtract_DefineTextCallback() located in swftext.c. It allows an attacker to cause code execution.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==29246==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61600000ffa0 at pc 0x00000044059d bp 0x7fffffffd270 sp 0x7fffffffd260  
WRITE of size 2 at 0x61600000ffa0 thread T0  
#0 0x44059c in swf\_FontExtract\_DefineTextCallback modules/swftext.c:508  
#1 0x449c46 in swf\_FontExtract\_DefineText modules/swftext.c:532  
#2 0x44a355 in swf\_FontExtract modules/swftext.c:617  
#3 0x40c2dc in fontcallback2 /test/swftools-asan/src/swfdump.c:941  
#4 0x4433c6 in swf\_FontEnumerate modules/swftext.c:133  
#5 0x409208 in main /test/swftools-asan/src/swfdump.c:1296  
#6 0x7ffff68a683f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#7 0x40c168 in \_start (/test/swftools-asan/src/swfdump+0x40c168)

AddressSanitizer can not describe address in more detail (wild memory access suspected).  
SUMMARY: AddressSanitizer: heap-buffer-overflow modules/swftext.c:508 swf\_FontExtract\_DefineTextCallback  
Shadow bytes around the buggy address:  
0x0c2c7fff9fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c2c7fff9fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c2c7fff9fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
0x0c2c7fff9fd0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa  
0x0c2c7fff9fe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
\=>0x0c2c7fff9ff0: fa fa fa fa\[fa\]fa fa fa fa fa fa fa fa fa fa fa  
0x0c2c7fffa000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c2c7fffa010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c2c7fffa020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c2c7fffa030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c2c7fffa040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
Shadow byte legend (one shadow byte represents 8 application bytes):  
Addressable: 00  
Partially addressable: 01 02 03 04 05 06 07  
Heap left redzone: fa  
Heap right redzone: fb  
Freed heap region: fd  
Stack left redzone: f1  
Stack mid redzone: f2  
Stack right redzone: f3  
Stack partial redzone: f4  
Stack after return: f5  
Stack use after scope: f8  
Global redzone: f9  
Global init order: f6  
Poisoned by user: f7  
Container overflow: fc  
Array cookie: ac  
Intra object redzone: bb  
ASan internal: fe  
\==29246==ABORTING  
POC  
swf\_FontExtract\_DefineTextCallback\_poc

Tag

#c++