A remote code execution (RCE) vulnerability in Beekeeper Studio v3.2.0 allows attackers to execute arbitrary code via a crafted payload injected into the display fields.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2022-26174: RCE Vulnerability in Beekeeper Studio · Issue #1051 · beekeeper-studio/beekeeper-studio

Specially crafted string in OTRS system configuration can allow the execution of any system command.

**Please read carefully and check if the version of your OTRS system is affected by this vulnerability.**

**Please send information regarding vulnerabilities in OTRS to: security@otrs.org**

**PGP Key**

*   pub 2048R/9C227C6B 2011-03-21
*   uid OTRS Security Team <security@otrs.org\>
*   GPG Fingerprint E330 4608 DA6E 34B7 1551 C244 7F9E 44E9 9C22 7C6B

**Security Advisory Details**

*   ID: OSA-2022-03
*   Date: 2022-03-21
*   Title: Authenticated remote code execution
*   Severity: 6.4 MEDIUM
*   Product: OTRS 8.0.x, OTRS 7.0.x, OTRSSTORM 8.0.x, OTRSSTORM 7.0.x, OTRSSTORM 6.0.x, SystemMonitoring 8.0.x, SystemMonitoring 7.0.x, SystemMonitoring 6.0.x, ((OTRS)) Community Edition 6.0.x.
*   Fixed in: OTRS 8.0.20, OTRS 7.0.33, OTRSSTORM 8.0.12, OTRSSTORM 7.0.28, SystemMonitoring 8.0.9, SystemMonitoring 7.0.19
*   FULL CVSS v3.1 VECTOR: CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H
*   References: CVE-2021-36100

**OSA-2022-03 Authenticated remote code execution (CVE-2021-36100)**

**PRODUCT AFFECTED:**

This issue affects

OTRS 8.0.x  
OTRS 7.0.x  
OTRSSTORM 8.0.x  
OTRSSTORM 7.0.x  
OTRSSTORM 6.0.x  
SystemMonitoring 8.0.x  
SystemMonitoring 7.0.x  
SystemMonitoring 6.0.x  
((OTRS)) Community Edition 6.0.x.

**PROBLEM:**

Specially crafted string in OTRS system configuration can allow the execution of any system command.

This issue was seen during production usage.

This issue has been assigned CVE-2021-36100.

**SOLUTION:**

Update to

OTRS 8.0.20  
OTRS 7.0.33  
OTRS 7.0.28  
OTRSSTORM 8.0.12  
OTRS 7.0.28  
Update to  
SystemMonitoring 8.0.9, OTRS 7.0.19.

**MODIFICATION HISTORY:**

*   022-01-19: Initial Publication.

*   *   CVE-2021-36100 at cve.mitre.org

**CVSS SCORE:**

6.4 (CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H)

**RISK LEVEL:**

MEDIUM

**ACKNOWLEDGEMENTS:**

Special thanks to Rayhan Ahmed and Maxime Brigaudeau for reporting these vulnerability.

CVE-2021-36100: OTRS Security Advisory 2022-03 | OTRS

Open Web Analytics (OWA) before 1.7.4 allows an unauthenticated remote attacker to obtain sensitive user information, which can be used to gain admin privileges by leveraging cache hashes. This occurs because files generated with '<?php (instead of the intended "<?php sequence) aren't handled by the PHP interpreter.

Open Web Analytics (OWA) is an open-source alternative to Google Analytics. OWA is written in PHP and can be hosted on an own server. Version 1.7.3 suffers from two vulnerabilities, which can be exploited by an unauthenticated attacker to gain RCE, when chained together.

The cause of the first vulnerability (CVE-2022-24637) is a single quote / double quote confusion, which leads to an information disclosure. The header of an automatically generated PHP cache file containing sensitive information is defined as '<?php\\n…' instead of "<?php\\n…". This leads to a literal backslash and n character being written instead of a newline character resulting in a broken PHP tag. Because of this the file is not interpreted as PHP code, but delivered in plain leaking sensitive cache information. This information can be leveraged to set a new password for the admin user.

The second vulnerability is a PHP file write, which requires admin privileges. The internal settings for the logfile path as well as the log level can be changed by manually crafting a POST request. This way the logfile can be set to a PHP file. By also increasing the log level and generating an event with attacker controlled data, PHP code can be injected into this logfile. This results in the possibility to execute arbitrary PHP code.

I would like to thank Peter Adams, the creator and maintainer of OWA who released a patch for the issue only one day after my initial notification. I was really amazed by the quick and professional reaction. There are security issues in each and every software, but the difference is how these are dealt with.

– Introduction  
– Single / Double Quote Confusion  
– PHP file write  
– Demonstration  
– Patch and Mitigations  
– Conclusion

**Introduction**

Open Web Analytics (OWA) is an open-source web analytics software written in PHP and using a MySQL database. The source code is freely available on GitHub. OWA offers profound tracking capabilities as well as a wide variety of detailed reports. In contrast to Google Analytics, OWA can be hosted on an own server.

In this article we will take a look at two vulnerabilities in OWA, which enable an unauthenticated attacker to gain RCE on the underlying webserver when combined. After determining the root cause of these vulnerabilities, we will point out how these can be mitigated and highlight a few general aspects regarding secure coding.

A basic entity in OWA is represented by the owa\_entity class. Examples for such entities inheriting from owa\_entity are documents (owa\_document), sites (owa\_site) or users (owa\_user). These entities are persisted in the MySQL database. In order to increase performance, OWA version 1.7.3 and prior uses a file based caching mechanism by default. When an entity is loaded from the database the first time, it is cached by writing its serialized data to a cache file.

The creation of these cache files is implemented in the putItemToCacheStore method within the owa\_fileCache class (modules/base/classes/fileCache.php):

...

    function putItemToCacheStore($collection, $id) {
    
            ...
        
            $data = $this->cache\_file\_header.base64\_encode(serialize($this->cache\[$collection\]\[$id\])).$this->cache\_file\_footer;

            ...
            
            $tcf\_handle = @fopen($temp\_cache\_file, 'w');

            ...
            
                fputs($tcf\_handle, $data);
                
                ...

As we can see, the serialized entity is base64 encoded and written to a temporary cache file. The name of this temporary file is later changed to consist of a unique id with a .php extension:

            ...
            
            $cache\_file = $collection\_dir.$id.'.php';
    
            ...
            
                if (!@ rename($temp\_cache\_file, $cache\_file)) {
                
                    ...

In the first code snippet we can also see that the base64 encoded data is prefixed by cache\_file\_header and suffixed by cache\_file\_footer. Let’s see how these are defined:

...

class owa\_fileCache extends owa\_cache {

    ...
    
    var $cache\_file\_header = '<?php\\n/\*';
    var $cache\_file\_footer = '\*/\\n?>';
    
    ...

Accordingly a cache file is supposed to look like this:

<?php
/\*BASE64-ENCODED DATA\*/
?>

When directly accessing such a PHP file, the response is supposed to be empty, because the file only contains a comment. Though the above strings are surrounded by single quotes instead of double quotes, which makes a severe difference when it comes to escape sequences:

php > echo '<?php\\n/\*'; // <-- single quotes
<?php\\n/\*

php > echo "<?php\\n/\*"; // <-- double quotes
<?php
/\*

As the above example shows, when using single quotes, escape sequences such as \\n are not evaluated.

What does this mean for the generated PHP file? The PHP tag <?php is supposed to be followed by a line feed (0x0a) like this:

user@b0x:~$ cat sample1.php 
<?php
echo 1;
?>

user@b0x:~$ php -f sample1.php
1

Valid alternatives for the line feed are tab (0x09), carriage return (0x0d) or space (0x20). Though, when the PHP tag is directly followed by a backslash character, it is no a valid PHP tag anymore and the PHP code is not interpreted, but rather displayed in plain:

user@b0x:/tmp$ cat sample2.php
<?php\\necho 1;\\n?>

user@b0x:/tmp$ php -f sample2.php
<?php\\necho 1;\\n?>

Since the PHP cache files are publicly accessible (owa-data/caches/), we can retrieve the base64 encoded serialized data. In order to do this, we need to know the name of the cache file. Though it turned out, that the filename is predictable. If the admin user at least logged in once, the cache file exists. But even if the user never logged in, we can trigger the creation by trying to login with this user. The failed login attempt does also create the cache file.

After calculating the filename, we can easily retrieve the cache file:

user@b0x:~$ curl http://localhost/owa\_web/owa-data/caches/1/owa\_user/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.php

<?php\\n/\*Tzo4OiJvd2FfdXNlciI6NTp7czo0OiJ ... YWNoZSI7Tjt9\*/\\n?>

The base64 encoded data contains all properties of the user within the MySQL database including the username, hashed password, temp\_passkey and API key:

user@b0x:~$ echo Tzo4OiJvd2FfdXNlciI6NTp7czo0OiJ ... YWNoZSI7Tjt9 | base64 -d
O:8:"owa\_user":5:{s:4:"name";s:9:"base.user";s:10:"properties"; ...
...
... s:4:"name";N;s:5:"value";s:5:"admin"; ...
... s:8:"password";O:12:"owa\_dbColumn":11:{s:4:"name";N;s:5:"value";s:60:"$2y$10$vT89Rpbp/kz92SdR2j03luLVFOy7ldaqdyOIpTmFtmp2WGGOmFIwS"; ...
... s:12:"temp\_passkey";O:12:"owa\_dbColumn":11:{s:4:"name";N;s:5:"value";s:32:"d7d8c0d6c8da08adea071fa80220b121"; ...
... s:7:"api\_key";s:5:"value";s:32:"2f37b9889afb326b2ae21a5eb45933bd"; ...
...
}s:12:"wasPersisted";b:1;s:5:"cache";N;}

The password is hashed and thus needs to be cracked before being valuable. Though the temp\_passkey can directly be used to set a new password for the user via the base.usersChangePassword action. After changing the password, an attacker can successfully login and now has full admin privileges.

**PHP file write**

The second vulnerability is a PHP file write, which requires admin privileges.

By browsing to the Settings tab in the admin interface, different options can be set:

When updating the settings (action base.optionsUpdate) the controller owa\_optionsUpdateController is triggered, which is responsible for persisting the new settings:

class owa\_optionsUpdateController extends owa\_adminController {

    ...

    function action() {

        $c = owa\_coreAPI::configSingleton();

        $config\_values = $this->get('config');

        if (!empty($config\_values)) {

            foreach ($config\_values as $k => $v) {

                list($module, $name) = explode('.', $k);

                if ( $module && $name ) {
                    $c->persistSetting($module, $name, $v);
                }
            }

            $c->save();
            owa\_coreAPI::notice("Configuration changes saved to database.");
            $this->setStatusCode(2500);
        }

        $this->setRedirectAction('base.optionsGeneral');
    }

    ...

The selected settings are sent via the config parameter ($config\_values). As we can see there is no restriction on the settings we can define. Although only a few settings are displayed in the GUI on the Settings tab, we can change all other settings by crafting a corresponding POST request.

Two of these settings are used within the owa\_error class, which is responsible for logging. When the application is running in production mode, the method createProductionHandler is called to initialize the logfile by calling make\_file\_logger:

...
class owa\_error {

    ...

    function createProductionHandler() {

        ...
        
        $this->make\_file\_logger();

        ...
    }
    
    ...
    
    function make\_file\_logger() {

        $path = owa\_coreAPI::getSetting('base', 'error\_log\_file');
        //instantiate a a log file
        $conf = array('name' => 'debug\_log', 'file\_path' => $path);
        $this->loggers\['file'\] = owa\_coreAPI::supportClassFactory( 'base', 'logFile', $conf );
    }

As we can see the file path of the logfile is determined by calling the owa\_coreAPI::getSetting method. The setting being used is base.error\_log\_file. We can control this value and thus control the file path, where the log is being written. This means that we can also set the file path to be a PHP file. In order to execute arbitrary PHP code, we only need to control some data, which is written to the logfile.

By default the application is only logging events with the log level OWA\_LOG\_NOTICE. These messages are mainly static and do not contain any data, which can be controlled by an attacker. Thus let’s have a look at the logging mechanism.

When a message is supposed to be logged, the method logMsg is called with the corresponding priority (log level):

    function logMsg( $msg, $priority ) {

        ...
        
        // check error priority before logging.
        if ( owa\_coreAPI::getSetting('base', 'error\_log\_level') <= $priority ) {

            $dt = date("H:i:s Y-m-d");
            $pid = getmypid();
            foreach ( $this->loggers as $logger ) {

                $message = sprintf("%s %s \[%s\] %s \\n", $dt, $pid, $logger->name, $msg);
                $logger->append( $message );
                ...

The code snippet above shows that before the message is actually logged, the value of base.error\_log\_level is checked. If the $priority value is greater or equal than the current base.error\_log\_level, the message is logged. We can also control the value of base.error\_log\_level. By setting this value to OWA\_LOG\_DEBUG = 2, the messages being logged are very verbose and even include each POST parameter send to the application. This way an attacker can easily inject arbitrary PHP code into the logfile. By accessing this logfile, which was set to a PHP file, the injected code is executed resulting in RCE.

**Demonstration**

The combination of both vulnerabilities can be leveraged by an unauthenticated attacker to gain RCE as the following demonstration shows:

**Patch and Mitigations**

Within this section we want to determine how both of these vulnerabilities can be mitigated and point out a few general aspects regarding secure coding.

Only shortly after my notification Peter provided a patch for the file cache vulnerability (CVE-2022-24637). This patch tackles the vulnerability on multiple layers. At first single quotes for the cache\_file\_header and cache\_file\_footer are replaced by double quotes preventing the leak, which was the actual cause of the vulnerability. Though the patch contains further hardening. The secret OWA\_AUTH\_KEY value is included into the cache filename calculation. Without knowing this value, it is far harder to determine the name of the cache file. Also the owa\_user entity was removed from the cache at all. Thus there is no cache file for user entities. Not part of the above commit, but also a crucial mitigation is to prevent files from being accessed via the webserver, which are not supposed to be accessed directly. One way to achieve this is to move all files out of the webroot, which are not supposed to be accessed via the webserver. The problem with this solution is that the website administrator needs file system access beyond the webroot. Depending on the hosting or security model this might not be intended. Another way is to use a webserver specific restriction mechanism like an .htaccess file, when an apache webserver is in place.

The second vulnerability is quite common for PHP. File writes should really be handled carefully. If an attacker can control what is being written to a file, RCE is not far away. Even if the file does not reside within the webroot or does not have a .php extension, an additional local file inclusion (LFI) vulnerability, which might be useless on its own, turns this into easy RCE. In this case a restriction should enforce that the logfile can only be a .txt file. Also this file should not reside within the webroot, if viable. This restriction must be enforced, if there is the necessity of making the file path configurable. Generally the settings, which are configurable via the webinterface, should be very limited. A more adequate way to make sensitive settings configurable is by defining constant values in a config file. These can only be changed by actually altering the config file (which in the best case should only be possible to the legitimate website administrator).

Summing up, the key takeaways are:

*   Mind the difference between single and double quotes in PHP
*   When hashing values, add a secret pepper / salt value
*   Do not store any files in the webroot, which are not supposed to be accessed via the webserver, or employ restrictions to prevent direct access to these files
*   Carefully restrict file writes (content, file path and extension)
*   Restrict which settings are configurable via the webinterface

**Conclusion**

The article described the chaining of two vulnerabilities in OWA, which can be exploited by an unauthenticated attacker to gain RCE on the underlying webserver. Also we took a look at how these vulnerabilities can be mitigated and pointed out a few general aspects regarding secure coding.

Thanks again to Peter for professionally handling these issues and quickly providing a patch.

**Timeline**  
01 February 2022 – Vendor Notification  
01 February 2022 – Vendor Acknowledgement  
02 February 2022 – Vendor Patch  
18 March 2022 – Public Disclosure

Post Views: 14,875

CVE-2022-24637: From Single / Double Quote Confusion To RCE (CVE-2022-24637) – devel0pment.de

Product: AndroidVersions: Android kernelAndroid ID: A-173788806References: Upstream kernel

_Published March 7, 2022_

The Pixel Update Bulletin contains details of security vulnerabilities and functional improvements affecting supported Pixel devices (Google devices). For Google devices, security patch levels of 2022-03-05 or later address all issues in this bulletin and all issues in the March 2022 Android Security Bulletin. To learn how to check a device's security patch level, see Check and update your Android version.

All supported Google devices will receive an update to the 2022-03-05 patch level. We encourage all customers to accept these updates to their devices.

**Announcements**

*   In addition to the security vulnerabilities described in the March 2022 Android Security Bulletin, Google devices also contain patches for the security vulnerabilities described below.

**Security patches**

Vulnerabilities are grouped under the component that they affect. There is a description of the issue and a table with the CVE, associated references, type of vulnerability, severity, and updated Android Open Source Project (AOSP) versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.

**Kernel components**

    

CVE

References

Type

Severity

Component

CVE-2021-43267

A-205243414  
Upstream kernel

RCE

Moderate

Kernel

CVE-2021-22600

A-213464034  
Upstream kernel

EoP

Moderate

Kernel

CVE-2021-37159

A-195082947  
Upstream kernel \[2\]

EoP

Moderate

Kernel

CVE-2021-39712

A-176918884\*

EoP

Moderate

Kernel

CVE-2021-39713

A-173788806  
Upstream kernel \[2\] \[3\] \[4\] \[5\]

EoP

Moderate

Kernel

CVE-2021-39714

A-205573273  
Upstream kernel

EoP

Moderate

Kernel

CVE-2021-41864

A-202511260  
Upstream kernel

EoP

Moderate

Kernel

CVE-2021-21781

A-197850306  
Upstream kernel

ID

Moderate

Kernel

CVE-2021-33624

A-192972537  
Upstream kernel

ID

Moderate

Kernel

CVE-2021-39711

A-154175781  
Upstream kernel

ID

Moderate

Kernel

CVE-2021-39715

A-178379135  
Upstream kernel

ID

Moderate

Kernel

CVE-2021-39792

A-161010552  
Upstream kernel

ID

Moderate

Kernel

CVE-2021-43975

A-207093880  
Upstream kernel

ID

Moderate

Kernel

**Pixel**

    

CVE

References

Type

Severity

Component

CVE-2021-39720

A-207433926\*

RCE

Critical

Modem

CVE-2021-39723

A-209014813\*

RCE

Critical

Modem

CVE-2021-39737

A-208229524\*

RCE

Critical

Modem

CVE-2021-25279

A-214310168\*

EoP

Critical

Modem

CVE-2021-25478

A-214309660\*

EoP

Critical

Modem

CVE-2021-25479

A-214309790\*

EoP

Critical

Modem

CVE-2021-39710

A-202160245\*

EoP

High

Telephony

CVE-2021-39734

A-208650395\*

EoP

High

Telephony

CVE-2021-39793

A-210470189\*

EoP

High

Display/Graphics

CVE-2021-39726

A-181782896\*

ID

High

Modem

CVE-2021-39727

A-196388042\*

ID

High

Titan M2

CVE-2021-39718

A-205035540\*

EoP

Moderate

Telephony

CVE-2021-39719

A-205995178\*

EoP

Moderate

Camera

CVE-2021-39721

A-195726151\*

EoP

Moderate

Camera

CVE-2021-39725

A-151454974\*

EoP

Moderate

Kernel

CVE-2021-39729

A-202006191\*

EoP

Moderate

TitanM

CVE-2021-39731

A-205036834\*

EoP

Moderate

Telephony

CVE-2021-39732

A-205992503\*

EoP

Moderate

Camera

CVE-2021-39733

A-206128522\*

EoP

Moderate

Audio

CVE-2021-39735

A-151455484\*

EoP

Moderate

Kernel

CVE-2021-39736

A-205995773\*

EoP

Moderate

Camera

CVE-2021-39716

A-206977562\*

ID

Moderate

Modem

CVE-2021-39717

A-198653629\*

ID

Moderate

Audio

CVE-2021-39722

A-204585345\*

ID

Moderate

Telephony

CVE-2021-39724

A-205753190\*

ID

Moderate

Camera

CVE-2021-39730

A-206472503\*

ID

Moderate

Bootloader

**Qualcomm components**

   

CVE

References

Severity

Component

CVE-2021-30299  

A-190406215  
QC-CR#2882860

Moderate

Audio

**Qualcomm closed-source components**

   

CVE

References

Severity

Component

CVE-2021-30331  

A-199194342\*

Moderate

Closed-source component

**Functional patches**

For details on the new bug fixes and functional patches included in this release, refer to the Pixel Community forum.

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

Security patch levels of 2022-03-05 or later address all issues associated with the 2022-03-05 security patch level and all previous patch levels. To learn how to check a device's security patch level, read the instructions on the Google device update schedule.

**2\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**3\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**4\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the Android bug ID in the _References_ column. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**5\. Why are security vulnerabilities split between this bulletin and the Android Security Bulletins?**

Security vulnerabilities that are documented in the Android Security Bulletins are required to declare the latest security patch level on Android devices. Additional security vulnerabilities, such as those documented in this bulletin are not required for declaring a security patch level.

**Versions**

  

Version

Date

Notes

1.0

March 7, 2022

Bulletin Released

1.1

March 9, 2022

Update a CVE ID

CVE-2021-39713: Pixel Update Bulletin—March 2022  |  Android Open Source Project

In NotificationStackScrollLayout of NotificationStackScrollLayout.java, there is a possible way to bypass Factory Reset Protections. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12Android ID: A-193149550

_Published March 7, 2022 | Updated April 5, 2022_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2022-03-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version.

Android partners are notified of all issues at least a month before publication. Source code patches for these issues have been released to the Android Open Source Project (AOSP) repository and linked from this bulletin. This bulletin also includes links to patches outside of AOSP.

The most severe of these issues is a critical security vulnerability in the System component that could lead to remote escalation of privilege with no additional execution privileges needed. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.

**Android and Google service mitigations**

This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android.

*   Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible.
*   The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play.

**2022-03-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-03-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates.

**Android runtime**

The vulnerability in this section could lead to local escalation of privilege with System execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39689

A-206090748

EoP

Moderate

12

**Framework**

The most severe vulnerability in this section could lead to local escalation of privilege with User execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39692

A-209611539

EoP

High

10, 11, 12

CVE-2021-39693

A-208662370

EoP

High

12

CVE-2021-39695

A-209607944

EoP

High

11

CVE-2021-39697

A-200813547 \[2\]

EoP

High

11, 12

CVE-2021-39690

A-204316511

DoS

High

12

**Media Framework**

The vulnerability in this section could lead to remote information disclosure with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39667

A-205702093

ID

High

10, 11, 12

**System**

The most severe vulnerability in this section could lead to remote escalation of privilege with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39708

A-206128341

EoP

Critical

12

CVE-2021-0957

A-193149550

EoP

High

10, 11, 12

CVE-2021-39701

A-212286849

EoP

High

11, 12

CVE-2021-39702

A-205150380

EoP

High

12

CVE-2021-39703

A-207057578

EoP

High

12

CVE-2021-39704

A-209965481

EoP

High

10, 11, 12

CVE-2021-39706

A-200164168 \[2\]

EoP

High

10, 11, 12

CVE-2021-39707

A-200688991

EoP

High

10, 11, 12

CVE-2021-39709

A-208817618

EoP

High

12

**Google Play system updates**

The following issues are included in Project Mainline components.

 

Component

CVE

Media Codecs

CVE-2021-39667

**2022-03-05 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-03-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.

**Framework**

The vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39694

A-202312327

EoP

High

12

**Kernel components**

The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.

    

CVE

References

Type

Severity

Component

CVE-2020-29368

A-174738029  
Upstream kernel

EoP

High

Kernel Memory Management

CVE-2021-39685

A-210292376  
Upstream kernel \[2\] \[3\]

EoP

High

Linux

CVE-2021-39686

A-200688826  
Upstream kernel \[2\] \[3\] \[4\]

EoP

High

Binder

CVE-2021-39698

A-185125206  
Upstream kernel \[2\] \[3\] \[4\] \[5\]

EoP

High

Kernel

CVE-2021-3655

A-197154735  
Upstream kernel \[2\] \[3\] \[4\]

ID

High

SCTP

**MediaTek components**

These vulnerabilities affect MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek.

   

CVE

References

Severity

Component

CVE-2022-20047

A-213120685  
M-ALPS05917489\*

High

video decoder

CVE-2022-20048  

A-213116796  
M-ALPS05917502\*

High

video decoder

CVE-2022-20053

A-213120689  
M-ALPS06219097\*

High

ims service

**Qualcomm components**

These vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

   

CVE

References

Severity

Component

CVE-2021-35088

A-204905738  
QC-CR#3007473

High

WLAN

CVE-2021-35103  

A-209481110  
QC-CR#3033509

High

WLAN

CVE-2021-35105  

A-209469958  
QC-CR#3034743 \[2\]

High

Display

CVE-2021-35106  

A-209481028  
QC-CR#3035196 \[2\]

High

WLAN

CVE-2021-35117  

A-209481202  
QC-CR#3028360

High

WLAN

**Qualcomm closed-source components**

These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

   

CVE

References

Severity

Component

CVE-2021-1942  

A-199191104\*

Critical

Closed-source component

CVE-2021-35110

A-209469768\*

Critical

Closed-source component

CVE-2021-1950  

A-199191539\*

High

Closed-source component

CVE-2021-30328

A-199191341\*

High

Closed-source component

CVE-2021-30329  

A-199191831\*

High

Closed-source component

CVE-2021-30332  

A-199190643\*

High

Closed-source component

CVE-2021-30333

A-199191889\*

High

Closed-source component

**Google Play system updates**

The following issues are included in Project Mainline components.

 

Component

CVE

Permission Controller

CVE-2021-39694

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

To learn how to check a device's security patch level, see Check and update your Android version.

*   Security patch levels of 2022-03-01 or later address all issues associated with the 2022-03-01 security patch level.
*   Security patch levels of 2022-03-05 or later address all issues associated with the 2022-03-05 security patch level and all previous patch levels.

Device manufacturers that include these updates should set the patch string level to:

*   \[ro.build.version.security\_patch\]:\[2022-03-01\]
*   \[ro.build.version.security\_patch\]:\[2022-03-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2022-03-01 security patch level. Please see this article for more details on how to install security updates.

**2\. Why does this bulletin have two security patch levels?**

This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.

*   Devices that use the 2022-03-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.
*   Devices that use the security patch level of 2022-03-05 or newer must include all applicable patches in this (and previous) security bulletins.

Partners are encouraged to bundle the fixes for all issues they are addressing in a single update.

**3\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**4\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**5\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**6\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**

Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

**Versions**

  

Version

Date

Notes

1.0

March 7, 2022

Bulletin Released

1.1

March 8, 2022

Bulletin revised to include AOSP links

1.2

April 5, 2022

Revised CVE table

CVE-2021-0957: Android Security Bulletin—March 2022

In the SCEP Server of RouterOS in certain Mikrotik products, an attacker can trigger a heap-based buffer overflow that leads to remote code execution. The attacker must know the scep_server_name value. This affects RouterOS 6.46.8, 6.47.9, and 6.47.10.

**Sign up for the newsletter**

Please sign up to get notified about new RouterOS version releases and other useful information!

CVE-2021-41987: MikroTik

Heap buffer overflow in Clickhouse's LZ4 compression codec when parsing a malicious query. There is no verification that the copy operations in the LZ4::decompressImpl loop and especially the arbitrary copy operation wildCopy<copy_amount>(op, ip, copy_end), don’t exceed the destination buffer’s limits. This issue is very similar to CVE-2021-43304, but the vulnerable copy operation is in a different wildCopy call.

The JFrog Security research team constantly monitors open-source projects to find new vulnerabilities or malicious packages and share them with the wider community to help improve their overall security posture. As part of this effort, the team recently discovered seven new security vulnerabilities in ClickHouse, a widely used open-source Database Management System (DBMS) dedicated to online analytical processing (OLAP). ClickHouse was developed by Yandex for the Yandex.Metrica, a web analytics tool often used to get visual reports and video recordings of user actions, as well as track traffic sources to help evaluate the effectiveness of online and offline advertising. The JFrog Security team responsibly disclosed these vulnerabilities and worked with ClickHouse’s maintainers on verifying the fixes.

The vulnerabilities require authentication, but can be triggered by any user with read permissions. This means the attacker must perform reconnaissance on the specific ClickHouse server target to obtain valid credentials. Any set of credentials would do, since even a user with the lowest privileges can trigger all of the vulnerabilities. By triggering the vulnerabilities, an attacker can crash the ClickHouse server, leak memory contents or even cause remote code execution (RCE).

Following are the seven vulnerabilities the JFrog Security team discovered:

*   **CVE-2021-43304** and **CVE-2021-43305** – heap buffer overflow vulnerabilities in LZ4 compression codec
*   **CVE-2021-42387** and **CVE-2021-42388** – heap out-of-bounds read vulnerabilities in LZ4 compression codec
*   **CVE-2021-42389** – divide by zero in Delta compression codec
*   **CVE-2021-42390** – divide by zero in Delta-Double compression codec
*   **CVE-2021-42391** – divide by zero in Gorilla compression codec

**CVE ID**

**Description**

**Potential Impact**

**CVSSv3.1 Score**

CVE-2021-43304

Heap buffer overflow in LZ4 compression codec when parsing a malicious query

RCE

8.8

CVE-2021-43305

Heap buffer overflow in LZ4 compression codec when parsing a malicious query

RCE

8.8

CVE-2021-42387

Heap out-of-bounds read in LZ4 compression codec when parsing a malicious query

Denial of Service or Information Leakage

7.1

CVE-2021-42388

Heap out-of-bounds read in LZ4 compression codec when parsing a malicious query

Denial of Service or Information Leakage

7.1

CVE-2021-42389

Divide-by-zero in Delta compression codec when parsing a malicious query

Denial of Service

6.5

CVE-2021-42390

Divide-by-zero in DeltaDouble compression codec when parsing a malicious query

Denial of Service

6.5

CVE-2021-42391

Divide-by-zero in Gorilla compression codec when parsing a malicious query

Denial of Service

6.5

**Technical Background**

The ClickHouse server allows a user to compress its queries. A user can pass a compressed query by supplying the **decompress=1** URL query string parameter to its web interface, like so:

    cat query.bin | curl -sS --data-binary @- 'http://serverIP:8123/?user=guest1&password=1234&decompress=1'

Where serverIP is the IP address of the ClickHouse server that has a user “guest1” with password “1234” set up. This user can also be configured with a “readonly” policy.

The query’s content (query.bin) should be in the following format:

    struct {
        uint128_t hash; // Google’s CityHash128
        uint8_t compress_method;
        uint32_t size_compressed_without_checksum; // the length (in bytes) of the entire struct (including compressed_data contents) minus the first 16bytes hash field. 
        uint32_t decompressed_size; // the expected decompressed output size 
        char compressed_data[0]; // the compressed data bytes (variable length)
    };

The client supplies the entire struct to the server and thus controls all of its contents.

The compressed data is consumed by constructing a CompressedReadBuffer instance with the struct as its input.

CompressedReadBuffer’s code calls readCompressedData which reads the struct and extracts its length values, calculates the CityHash128 over the struct contents (excluding the hash field), and verifies it against the struct’s hash field. It then resizes (basically realloc()’s) the initially allocated memory buffer used to hold the decompressed data. Then, through ICompressionCodec::decompress, the selected codec’s doDecompressData is called.

In **CVE-2021-42387**, **CVE-2021-43304**, **CVE-2021-42388** and **CVE-2021-43305** the LZ4 codec calls LZ4::decompress(source, dest, source\_size, dest\_size, ..) with the ‘compressed\_data’ as source, its length as source\_size, the resized memory buffer as dest, and the struct’s ‘decompressed\_size’ value as dest\_size. LZ4::decompress eventually calls LZ4::decompressImpl(source, dest, dest\_size) that does the actual LZ4 decompression in a loop –copying different parts of the compressed input in user-controlled lengths and offsets (supplied as part of the compressed\_data bytes) to the decompressed output memory buffer. It defines pointer variables for tracking the current location in the source (ip) and the dest (op).

**CVE-2021-43304  – a heap buffer overflow vulnerability**

Here is the code of LZ4::decompressImpl() that is relevant for CVE-2021-43304:

    template 
    void NO_INLINE decompressImpl(
         const char * const source,
         char * const dest,
         size_t dest_size)
    {
        ...
        while (true)
        {
            ... 
            wildCopy(op, ip, copy_end);    /// Here we can write up to copy_amount - 1 bytes after buffer.
     
            ip += length;
            op = copy_end;
     
            if (copy_end >= output_end)
                return;
            ...
        }
    }

**ip** is a pointer that points to the compressed buffer and **op** is a pointer that points to the allocated destination buffer, which is allocated with a size of the given decompressed\_size that is passed in the header. **copy\_end** is a pointer that points to the end of the copy area.

**copy\_amount** is the parameter of the template, which can be 8, 16 or 32. The copy area is being copied in chunks that each one of them is in size of **copy\_amount**. For example, this is the implementation of wildCopy16:

    inline void wildCopy16(UInt8 * dst, const UInt8 * src, const UInt8 * dst_end)
    {
        /// Unrolling with clang is doing >10% performance degrade.
    #if defined(__clang__)
        #pragma nounroll
    #endif
        do
        {
            copy16(dst, src);
            dst += 16;
            src += 16;
        } while (dst < dst_end);
    }
    

Since the user controls **decompressed\_size** and the compressed buffer, an attacker can take advantage of this situation by preparing compressed data with a header that contains a decompressed\_size which is smaller than the actual size of the compressed data. Note that the lengths of the overflow, as well as source’s allocation size and the overflowing byte contents are fully controlled by the user, which greatly facilitates exploitation.

Also note that the existing size check of “if (copy\_end >= output\_end)” does not prevent this vulnerability as it appears after the copy operation. CVE-2021-43305 is similar to CVE-2021-43304, but involves a different copy operation (whose source is a controlled offset of the destination buffer).

**Exploiting CVE-2021-43304**

In order to prove the exploitability of CVE-2021-43304, we created a specially crafted compressed file and sent it as previously explained. The query.bin file is comprised of the following header:

*   hash = the matching calculated Cityhash
*   compress\_method = 0x82 (LZ4 method)
*   size\_compressed\_without\_checksum = 0xc80a
*   decompressed\_size = 0x1

And for the compressed data we’ve used ‘\\xff’ (repeating 200 times) ‘A’ (repeating 5100 times). These are arbitrary values. The resulting malformed compressed file:  
00000000  26 fc 61 db c0 83 bb 0a  db 58 5a f0 34 e1 30 f6  |&.a......XZ.4.0.|  
00000010  82 0a c8 00 00 01 00 00  00 f0 ff ff ff ff ff ff  |................|  
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|  
*  
000000e0  ff ff 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |..AAAAAAAAAAAAAA|  
000000f0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|  
*  
0000c81a  
The 200 0xff’s are being used in the loop inside LZ4::decompressImpl():

    template 
    void NO_INLINE decompressImpl(
         const char * const source,
         char * const dest,
         size_t dest_size)
    {
        ...
        while (true)
        {
            ...
            size_t length;
     
            auto continue_read_length = [&]
            {
                unsigned s;
                do
                {
                    s = *ip++;
                    length += s;
                } while (unlikely(s == 255));
            };
     
            /// Get literal length.
     
            const unsigned token = *ip++;
            length = token >> 4;
            if (length == 0x0F)
                continue_read_length();
            
            /// Copy literals.
     
            UInt8 * copy_end = op + length;
     
            ...
     
            wildCopy(op, ip, copy_end);    /// Here we can write up to copy_amount - 1 bytes after buffer.
            ...
        }
    }

That will increase **length** by 0xff \* 200 = 51000, which is exactly the size of the rest of the data.

So although the decompressed size is 1, a much larger size will be copied to the destination.

By sending the query to a vulnerable ClickHouse server, while debugging the server’s process, we managed to periodically get the following crash, proving control of the instruction pointer register, since the code branches to an address taken from the RAX register, which has been overwritten with our “A” values:

Although this specific crash is statistical, we believe that with proper heap shaping techniques, a stable exploit can be developed.

**CVE-2021-42388 and CVE-2021-42387 – heap OOB read vulnerabilities**

In LZ4::decompressImpl():

    template 
    void NO_INLINE decompressImpl(
         const char * const source,
         char * const dest,
         size_t dest_size)
    {
        ...
        while (true)
        {
            ...
            const UInt8 * match = op - offset;
            ...
            if (length > copy_amount * 2)
                wildCopy(op + copy_amount, match + copy_amount, copy_end);
            ...
        }
    }

As part of the LZ4::decompressImpl() loop, a 16-bit unsigned user-supplied value (‘offset’) is read from the compressed\_data. it is subtracted from the current op and stored in **match** pointer (**op** is a pointer that starts as **dest** and moves forward). There is no verification that the **match** pointer is not smaller than **dest**. Later, there’s a copy operation from match to output pointer – possibly **copying out of bounds memory from before the ‘dest’ memory buffer**. Accessing memory outside of the buffer’s bounds can expose sensitive information or lead in certain cases to a crash of the application due to segmentation fault.

CVE-2021-42387 is a similar vulnerability to CVE-2021-42388, which exceeds the upper bounds of the compressed buffer (source) as part of the copy operation.

**CVE-2021-42389, CVE-2021-42390 and CVE-2021-42391 – Divide by zero vulnerabilities**

These are divide-by-zero vulnerabilities in various codecs supported by ClickHouse. They are based on setting the first byte of the compressed buffer (described in the “Technical Background” section above) to zero. The decompression code reads the first byte of the compressed buffer and performs a modulo operation with it to get the remainder:

    UInt8 bytes_size = source[0];
    UInt8 bytes_to_skip = uncompressed_size % bytes_size;

In most of the cases the modulo operation in Intel x86-64 is performed by a DIV instruction, which, apart from dividing the numbers, also keeps the remainder in a register. So in case bytes\_size is 0, it will end up dividing by zero.

These vulnerabilities were found by “smart fuzzing” the decompression mechanism. Smart fuzzing leverages the knowledge of the input format for generating input data which (relatively) adheres to the expected protocol schema, instead of completely random data.

**Fixes and Workarounds**

In order to fix the issues, update ClickHouse to the v21.10.2.15-stable version or later.

If upgrading is not possible, add firewall rules in the server that will restrict the access to the web port (8123) and the TCP server’s port (9000) to specific clients only.

**Are JFrog products vulnerable?**

JFrog products are not vulnerable to this issue, since they do not use the ClickHouse DBMS

**Acknowledgement**

We would like to thank the ClickHouse Inc. team for promptly and professionally handling this issue.

**Learn More**

In addition to exposing new security vulnerabilities and threats, JFrog provides developers and security teams easy access to the latest relevant information for their software with automated security scanning. Explore how JFrog Xray can be of help to you.

_Questions? Thoughts?_ Contact us at **research@jfrog.com** for any inquiries.

CVE-2021-43305: 7 RCE and DoS vulnerabilities Found in ClickHouse DBMS

The WPCargo Track & Trace WordPress plugin before 6.9.0 contains a file which could allow unauthenticated attackers to write a PHP file anywhere on the web server, leading to RCE

CVE-2021-25003

Zenario CMS 9.0.54156 is vulnerable to File Upload. The web server can be compromised by uploading and executing a web-shell which can run commands, browse system files, browse local resources, attack other servers, and exploit the local vulnerabilities, and so forth.

**Summary**  
hi team,  
I found high Upload file to RCE.

**Info**  
Zenario CMS 9.0.54156 last version  
FireFox 92.0.1 (64-bit)  

**Steps**

1.  Login to account http://xxx.xxx.x.x/admin.php?cID=1&cType=html  
    
2.  Choose Documents >> Upload documents  
    
3.  Use burpsuite and capture request file a.html  
    
4.  Click Edit document metadata >> use burpsuite to capture >> save  
    
5.  In value **current\_value**, edit value **html** to **php**  
    
6.  Click Actions >> view public link  
    

7.Copy link to URL >> **BOOM**  

Inpact :  
An attacker could upload a dangerous executable file like a virus, malware, etc..  
The web server can be compromised by uploading and executing a web-shell which can run commands, browse system files, browse local resources, attack other servers, and exploit the local vulnerabilities, and so forth.

CVE-2021-42171: Upload file to RCE in Zenario CMS 9.0.54156 · Issue #2 · hieuminhnv/Zenario-CMS-9.0-last-version

If LimitXMLRequestBody is set to allow request bodies larger than 350MB (defaults to 1M) on 32 bit systems an integer overflow happens which later causes out of bounds writes. This issue affects Apache HTTP Server 2.4.52 and earlier.

Tag

#rce