A user interface issue was addressed. This issue is fixed in watchOS 8.5, Safari 15.4. Visiting a malicious website may lead to address bar spoofing.

This document describes the security content of Safari 15.4.

**About Apple security updates**

For our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the Apple security updates page.

Apple security documents reference vulnerabilities by CVE-ID when possible.

For more information about security, see the Apple Product Security page.

![](https://support.apple.com/library/content/dam/edam/applecare/images/en_US/mac_apps/itunes/divider.png)

**Safari 15.4**

Released March 15, 2022

**Safari**

Available for: macOS Big Sur and macOS Catalina

Impact: Visiting a malicious website may lead to address bar spoofing

Description: A user interface issue was addressed.

CVE-2022-22654: Abdullah Md Shaleh of take0ver

**WebKit**

Available for: macOS Big Sur and macOS Catalina

Impact: Processing maliciously crafted web content may lead to code execution

Description: A memory corruption issue was addressed with improved state management.

WebKit Bugzilla: 232812  
CVE-2022-22610: Quan Yin of Bigo Technology Live Client Team

**WebKit**

Available for: macOS Big Sur and macOS Catalina

Impact: Processing maliciously crafted web content may lead to arbitrary code execution

Description: A use after free issue was addressed with improved memory management.

WebKit Bugzilla: 233172  
CVE-2022-22624: Kirin (@Pwnrin) of Tencent Security Xuanwu Lab

WebKit Bugzilla: 234147  
CVE-2022-22628: Kirin (@Pwnrin) of Tencent Security Xuanwu Lab

**WebKit**

Available for: macOS Big Sur and macOS Catalina

Impact: Processing maliciously crafted web content may lead to arbitrary code execution

Description: A buffer overflow issue was addressed with improved memory handling.

WebKit Bugzilla: 234966  
CVE-2022-22629: Jeonghoon Shin at Theori working with Trend Micro Zero Day Initiative

**WebKit**

Available for: macOS Big Sur and macOS Catalina

Impact: A malicious website may cause unexpected cross-origin behavior

Description: A logic issue was addressed with improved state management.

WebKit Bugzilla: 235294  
CVE-2022-22637: Tom McKee of Google

![](https://support.apple.com/library/content/dam/edam/applecare/images/en_US/mac_apps/itunes/divider.png) 

**Additional recognition**

**WebKit**

We would like to acknowledge Abdullah Md Shaleh for their assistance.

**WebKit Storage**

We would like to acknowledge Martin Bajanik of FingerprintJS for their assistance.

Information about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. Contact the vendor for additional information.

Published Date: March 15, 2022

CVE-2022-22654: About the security content of Safari 15.4

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

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:

![](https://devel0pment.de/wp-content/uploads/2022/02/screen01.png)

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:

![](https://devel0pment.de/wp-content/uploads/2022/03/owa_unauth_rce.gif)

**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: 157

Memory leak in icmp6 implementation in Linux Kernel 5.13+ allows a remote attacker to DoS a host by making it go out-of-memory via icmp6 packets of type 130 or 131. We recommend upgrading past commit 2d3916f3189172d5c69d33065c3c21119fe539fc.

While investigating on why a synchronize\_net() has been added recently in ipv6\_mc\_down(), I found that igmp6\_event\_query() and igmp6\_event\_report() might drop skbs in some cases. Discussion about removing synchronize\_net() from ipv6\_mc\_down() will happen in a different thread. Fixes: f185de28d9ae ("mld: add new workqueues for process mld events") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Taehee Yoo <ap420073@gmail.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20220303173728.937869-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>

@@ -475,9 +475,9 @@ int igmp6\_late\_init(void);

void igmp6\_cleanup(void);

void igmp6\_late\_cleanup(void);

\-int igmp6\_event\_query(struct sk\_buff \*skb);

+void igmp6\_event\_query(struct sk\_buff \*skb);

\-int igmp6\_event\_report(struct sk\_buff \*skb);

+void igmp6\_event\_report(struct sk\_buff \*skb);

#ifdef CONFIG\_SYSCTL

diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c  
index a8861db52c187..909f937befd71 100644  
\--- a/net/ipv6/mcast.c  
+++ b/net/ipv6/mcast.c

@@ -1371,27 +1371,23 @@ static void mld\_process\_v2(struct inet6\_dev \*idev, struct mld2\_query \*mld,

}

/\* called with rcu\_read\_lock() \*/

\-int igmp6\_event\_query(struct sk\_buff \*skb)

+void igmp6\_event\_query(struct sk\_buff \*skb)

{

struct inet6\_dev \*idev = \_\_in6\_dev\_get(skb->dev);

\- if (!idev)

\- return -EINVAL;

\-

\- if (idev->dead) {

\- kfree\_skb(skb);

\- return -ENODEV;

\- }

\+ if (!idev || idev->dead)

\+ goto out;

spin\_lock\_bh(&idev->mc\_query\_lock);

if (skb\_queue\_len(&idev->mc\_query\_queue) < MLD\_MAX\_SKBS) {

\_\_skb\_queue\_tail(&idev->mc\_query\_queue, skb);

if (!mod\_delayed\_work(mld\_wq, &idev->mc\_query\_work, 0))

in6\_dev\_hold(idev);

\+ skb = NULL;

}

spin\_unlock\_bh(&idev->mc\_query\_lock);

\-

\- return 0;

+out:

\+ kfree\_skb(skb);

}

static void \_\_mld\_query\_work(struct sk\_buff \*skb)

@@ -1542,27 +1538,23 @@ static void mld\_query\_work(struct work\_struct \*work)

}

/\* called with rcu\_read\_lock() \*/

\-int igmp6\_event\_report(struct sk\_buff \*skb)

+void igmp6\_event\_report(struct sk\_buff \*skb)

{

struct inet6\_dev \*idev = \_\_in6\_dev\_get(skb->dev);

\- if (!idev)

\- return -EINVAL;

\-

\- if (idev->dead) {

\- kfree\_skb(skb);

\- return -ENODEV;

\- }

\+ if (!idev || idev->dead)

\+ goto out;

spin\_lock\_bh(&idev->mc\_report\_lock);

if (skb\_queue\_len(&idev->mc\_report\_queue) < MLD\_MAX\_SKBS) {

\_\_skb\_queue\_tail(&idev->mc\_report\_queue, skb);

if (!mod\_delayed\_work(mld\_wq, &idev->mc\_report\_work, 0))

in6\_dev\_hold(idev);

\+ skb = NULL;

}

spin\_unlock\_bh(&idev->mc\_report\_lock);

\-

\- return 0;

+out:

\+ kfree\_skb(skb);

}

static void \_\_mld\_report\_work(struct sk\_buff \*skb)

CVE-2022-0742: git/torvalds/linux.git - Linux kernel source tree

A local attacker could read files from some other users' SA360 reports stored in the /tmp folder during staging process before the files are loaded in BigQuery. We recommend upgrading to version 1.0.3 or above.

New issue

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

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

**setting file permissions on datastore directory #15**

Conversation 6 Commits 1 Checks 1 Files changed

**Conversation**

![KatTraxler](https://avatars.githubusercontent.com/u/52041609?s=60&v=4)

You are using the File API to create a directory ('datastore') which ultimately stores OAuth2 credentials. Utilizing methods on the File API, I was able to set the read and write permission on that directory to restrict the permission to the owner of the directory. This change doesn't really fix the issue.

It _appears_ as though the creation of the file which stores the credentials ('StoredCredentials') is being handled by the `[com.google.auth.oauth2.UserCredentials](https://googleapis.dev/java/google-auth-library/0.23.0/index.html)` Class. I don't see any native capability to set file permissions in this library.

You might need to migrate to a different method of creating the 'StoredCredentials' file, one that allows more control of the StoredCredentials File or request an upgrade to the underlying library.

![@KatTraxler](https://avatars.githubusercontent.com/u/52041609?s=40&v=4)

![@google-cla](https://avatars.githubusercontent.com/in/42202?s=88&v=4)

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 **Please visit https://cla.developers.google.com/ to sign.**

Once you've signed (or fixed any issues), please reply here with `@googlebot I signed it!` and we'll verify it.

**What to do if you already signed the CLA****Individual signers**

*   It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

**Corporate signers**

*   Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
*   The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
*   The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ **Googlers: Go here for more info**.

![@anantdamle](https://avatars.githubusercontent.com/u/13331827?s=60&u=ef142b7a3131d1af8a94d41f8cb05144e76ab32a&v=4) anantdamle linked an issue that may be closed by this pull request

Feb 17, 2021

![@anantdamle](https://avatars.githubusercontent.com/u/13331827?s=88&u=ef142b7a3131d1af8a94d41f8cb05144e76ab32a&v=4)

@KatTraxler Thanks for this PR. Can you sign the CLA and update this conversation.  
I am curious to learn if this approach will allow running the JAR file through `cron`

![@KatTraxler](https://avatars.githubusercontent.com/u/52041609?s=88&u=2bf5859cc6cf6adb79f8e91669150e682b02cac5&v=4)

![@anantdamle](https://avatars.githubusercontent.com/u/13331827?s=88&u=ef142b7a3131d1af8a94d41f8cb05144e76ab32a&v=4)

Thanks @KatTraxler for the PR.  
This solution does not solve the issue completely.

Do you think one of the following may be a better solution:

1.  accepting datastore folder as an input parameter. Allows the user to setup protections outside of the code.
2.  Removing the stored credentials. Use service account credentials to access all services including SA360.

![@KatTraxler](https://avatars.githubusercontent.com/u/52041609?s=88&u=2bf5859cc6cf6adb79f8e91669150e682b02cac5&v=4)

Hi @anantdamle  
I don't imagine either of the options would address the underlying issue:

**Option 1:** accepting datastore folder as an input parameter. Allows the user to setup protections outside of the code.  
The users OAuth credentials are contained in the 'StoredCredentials' file, in the 'datastore' directory. If instead of creating the 'datastore' directory in code, the user was asked to provide a directory, the resultant file where the OAuth credentials are stored is still created by com.google.auth.oauth2.UserCredentials Class and is still the same 'StoredCredentials' file with insecure permissions.  
**Option 2:** Removing the stored credentials. Use service account credentials to access all services including SA360.  
I'm assuming proposal entails generating a private key for a service account? If that's the case, this solution would likely be worse than the current state. Today, the credentials that are stored insecurely are considered 'short-term'. They will always have an expiration.  
Changing this application to have the ability to run as a service account would result in durable credentials being stored on a local file system where if not explicitly set, the default and insecure set of file permissions are `-rw-r--r--`

Recommendation:  
Open an issue with the maintainers of the Java google-auth-library asking if there is a Method on the Class com.google.auth.oauth2.UserCredentials allowing you configure the permissions on the file which is created when OAuth2 credentials are generated.

![@anantdamle](https://avatars.githubusercontent.com/u/13331827?s=88&u=ef142b7a3131d1af8a94d41f8cb05144e76ab32a&v=4)

@KatTraxler Thanks for notifying of the bug and proposing a PR. This is a temporary solution. Long term solution is fixing Issue#8. Will work on building that solution.  
Directory level permissions would not fix the file permissions.

![@anantdamle](https://avatars.githubusercontent.com/u/13331827?s=60&u=ef142b7a3131d1af8a94d41f8cb05144e76ab32a&v=4) anantdamle linked an issue that may be closed by this pull request

Feb 23, 2021

2 participants

 ![@KatTraxler](https://avatars.githubusercontent.com/u/52041609?s=52&v=4)![@anantdamle](https://avatars.githubusercontent.com/u/13331827?s=52&v=4)

CVE-2021-22571: setting file permissions on datastore directory by KatTraxler · Pull Request #15 · google/sa360-webquery-bigquery

In Paramiko before 2.10.1, a race condition (between creation and chmod) in the write_private_key_file function could allow unauthorized information disclosure.

CVE-2022-24302: Changelog — Paramiko documentation

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

_Published March 7, 2022 | Updated March 8, 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. User interaction is not needed for exploitation. 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. User interaction is not needed for exploitation.

    

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. User interaction is needed for exploitation.

    

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-39624

A-67862680 \[2\]

DoS

High

10, 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. User interaction is needed for exploitation.

    

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. User interaction is not needed for exploitation.

    

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

CVE-2021-39705

A-186026746 \[2\] \[3\]

ID

High

10, 11, 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. User interaction is not needed for exploitation.

    

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. User interaction is not needed for exploitation.

    

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

Tag

#google