Debian Linux Security Advisory 5689-1 - A security issue was discovered in Chromium, which could result in the execution of arbitrary code, denial of service or information disclosure. Google is aware that an exploit for CVE-2024-4761 exists in the wild.

Debian Security Advisory 5689-1

Debian Linux Security Advisory 5690-1 - Amel Bouziane-Leblond discovered that LibreOffice's support for binding scripts to click events on graphics could result in unchecked script execution.

Debian Security Advisory 5690-1

Ubuntu Security Notice 6766-2 - It was discovered that the Open vSwitch implementation in the Linux kernel could overflow its stack during recursive action operations under certain conditions. A local attacker could use this to cause a denial of service. Sander Wiebing, Alvise de Faveri Tron, Herbert Bos, and Cristiano Giuffrida discovered that the Linux kernel mitigations for the initial Branch History Injection vulnerability were insufficient for Intel processors. A local attacker could potentially use this to expose sensitive information.

Ubuntu Security Notice USN-6766-2

Red Hat Security Advisory 2024-2853-03 - An update for the nodejs:20 module is now available for Red Hat Enterprise Linux 9. Issues addressed include HTTP request smuggling, denial of service, and out of bounds read vulnerabilities.

Red Hat Security Advisory 2024-2853-03

Compared to fuzzing for software vulnerabilities on Linux, where most of the code is open-source, targeting anything on macOS presents a few difficulties.

Talos releases new macOS open-source fuzzer

Automation can help increase efficiency, save time and improve consistency, which is why Red Hat Enterprise Linux (RHEL) includes features that help automate many tasks. RHEL system roles are a collection of Ansible content that helps provide more consistent workflows and streamline the execution of many manual tasks.Fapolicyd is a security-focused feature that can control which applications may be executed in a RHEL environment, as well as verify the integrity of applications prior to execution. This functionality helps prevent untrusted applications from being executed on a RHEL system. For

Automation can help increase efficiency, save time and improve consistency, which is why Red Hat Enterprise Linux (RHEL) includes features that help automate many tasks. RHEL system roles are a collection of Ansible content that helps provide more consistent workflows and streamline the execution of many manual tasks.

**Fapolicyd** is a security-focused feature that can control which applications may be executed in a RHEL environment, as well as verify the integrity of applications prior to execution. This functionality helps prevent untrusted applications from being executed on a RHEL system. For more information on fapolicyd, refer to the Blocking and allowing applications by using fapolicyd documentation. 

The recently introduced fapolicyd system role can help automate the process of installing and configuring fapolicyd, as well as manage the list of files that fapolicyd trusts. 

****Environment overview****

In my lab environment, I have a control node system named **rhel9-controlnode.example.com** and two managed nodes: **rhel9-server1.example.com** and **rhel9-server2.example.com**.

The **rhel9-controlenode.example.com** system, as my control node, has the **ansible-core** and **rhel-system-roles** packages installed, and has SSH key authentication setup with the **rhel9-server1.example.com** and **rhel9-server2.example.com** managed nodes. For more information on getting started with RHEL system roles, refer to the Introduction to RHEL system roles article. 

I’d like to use the fapolicyd system role to install and start fapolicyd on the two managed nodes. In addition, I’d like to have fapolicyd configured with the **sha256** integrity option, which will perform an integrity check prior to allowing applications to execute. 

****Create the inventory file****

I’ll create an inventory file named **inventory.yml** on the **rhel9-controlnode.example.com** host. This file lists the two managed nodes, and sets the **fapolicyd\_setup\_integrity** variable to **sha256** to instruct the fapolicyd role to configure the SHA-256 integrity option.

 all:
  hosts:
    rhel9-server1.example.com:
    rhel9-server2.example.com:
  vars:
    fapolicyd\_setup\_integrity: sha256

If you're using Ansible automation controller as your control node, this Inventory can be imported into Red Hat Ansible Automation Platform using an SCM project or using the awx-manage Utility, as specified in the documentation.

****Create the playbook****

Next, I’ll create a simple Ansible Playbook on the **rhel9-controlnode.example.com** host, named **fapolicyd.yml**, to call the fapolicyd system role:

 - name: Run the fapolicyd system role
  hosts: all
  roles:
    - redhat.rhel\_system\_roles.fapolicyd

If you're using Ansible automation controller as your control node, you can import this Ansible playbook into Red Hat Ansible Automation Platform. It's common to use Git repos to store Ansible Playbooks. Ansible Automation Platform stores automation in units called job templates, which contain the playbook, credentials and inventory.

****Run the playbook****

At this point, everything is in place. I’ll use the **ansible-playbook** command to run the **fapolicyd.yml** playbook from the **rhel9-controlnode.example.com** host (which already has **rhel-system-roles** and **ansible-core** packages installed). The **\-b** flag prompts Ansible to escalate privileges, and the -i option provides **inventory.yml** as the Ansible inventory.

    $ ansible-playbook -i inventory.yml -b fapolicyd.yml

If you're using Ansible automation controller as your control node, you can launch the job from the automation controller web interface.

I validated that the playbook completed successfully:

****Validating the configuration****

Next, I’ll validate that fapolicyd is working.  I’ll login to each of the managed nodes, both of which have a Python script located at **/usr/local/bin/python\_script.py.**  When I attempt to run this script, fapolicyd prevents it from being executed, as it has not been marked as a trusted file:

\[brian@rhel9-server1 ~\]$ /usr/local/bin/python\_script.py
-bash: /usr/local/bin/python\_script.py: Operation not permitted

If I would like fapolicyd to allow this script to be run, I can update the **inventory.yml** on the control node, and specify that this a trusted file by listing it under the **fapolciyd\_add\_trusted\_file** variable:

all:
  hosts:
    rhel9-server1.example.com:
    rhel9-server2.example.com:
  vars:
    fapolicyd\_setup\_integrity: sha256
    fapolicyd\_add\_trusted\_file:
      - /usr/local/bin/python\_script.py 

After running the **fapolicyd.yml** playbook again with the updated **inventory.yml**, I’ll again try to execute the script from one of the managed nodes, and fapolicyd now allows the script to be executed: 

\[brian@rhel9-server1 ~\]$ /usr/local/bin/python\_script.py
Hello world

However, if the script is modified, the fapolicyd SHA-256 integrity checking will cause fapolicyd to detect that the file was modified and prevent it from being executed. 

\[brian@rhel9-server1 ~\]$ sudo sed -i 's/Hello world/Hello World!/' 
     /usr/local/bin/python\_script.py
    \[brian@rhel9-server1 ~\]$ /usr/local/bin/python\_script.py
    -bash: /usr/local/bin/python\_script.py: Operation not permitted

In this example, I modified the script to output slightly different text.  When attempting to run the script, fapolicyd detects that the SHA-256 checksum of the file doesn’t match the file that was previously trusted, which results in fapolicyd preventing the Python script from being run.  If I’d like to allow this updated script to run, I could run the system role again, which would add the updated scripts SHA-256 checksum to the list of trusted files, allowing the updated script to be executed. 

****Wrap up****

The fapolicyd system role helps you automate the configuration of fapolicyd across your RHEL environment, more consistently and at scale. To explore additional system roles, review the list of available RHEL system roles and start managing your RHEL servers in a more efficient, consistent and automated manner today.

Want to learn more about the Red Hat Ansible Automation Platform? Check out our e-book the automation architect's handbook.

Automating fapolicyd with RHEL system roles

SAP Cloud Connector versions 2.15.0 through 2.16.1 were found to happily accept self-signed TLS certificates between SCC and SAP BTP.

SEC Consult Vulnerability Lab Security Advisory < 20240513-0 >  
=======================================================================  
               title: Tolerating Self-Signed Certificates  
             product: SAP® Cloud Connector  
  vulnerable version: 2.15.0 - 2.16.1 (Portable and Installer)  
       fixed version: 2.16.2 (Portable and Installer)  
          CVE number: CVE-2024-25642  
              impact: high  
            homepage: https://www.sap.com/about.html  
               found: 2023-11-13  
                  by: Mingshuo Li (Office Munich)  
                      Fabian Hagg  
                      SEC Consult Vulnerability Lab

                      An integrated part of SEC Consult, an Eviden business  
                      Europe | Asia

                      https://www.sec-consult.com

=======================================================================

Vendor description:  
-------------------  
"The Cloud Connector is an optional on-premise component that is needed to  
integrate on-demand applications with customer backend services and is the  
counterpart of SAP Connectivity service."

Source: https://tools.hana.ondemand.com/#cloud

Business recommendation:  
------------------------  
SEC Consult recommends to implement the security note 3424610, where the  
documented issue is fixed in version 2.16.2 according to the vendor. We  
advise installing the correction as a matter of priority to keep  
business-critical data secured.

Source: https://support.sap.com/en/my-support/knowledge-base/security-notes-news/february-2024.html

Vulnerability overview/description:  
-----------------------------------  
1) Tolerating Self-Signed Certificates (CVE-2024-25642)  
As per vendor documentation, the authentication between SCC and SAP BTP is guaranteed  
mutually:

"The tunnel itself is using TLS with strong encryption of the communication,  
and mutual authentication of both communication sides, the client side  
(Cloud Connector) and the server side (SAP BTP)."

Source: https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/inbound-connectivity#tls-tunnel

It was however discovered that the SCC trusts self-signed X.509 server certificates  
for transport security to establish outbound connections with cloud-related  
endpoints. Thus, an attacker can impersonate the genuine servers to interact  
with the SCC, hence breaking the mutual authentication promise. Our analysis shows  
furthermore that the product does not implement Certificate Pinning for the  
trusted endpoints.

The security impact of this vulnerability is rated high due to the trust put  
into self-signed certificates, SCC is unable to distinguish between genuine and  
malicious SAP BTP endpoints, rendering trivial adversary-in-the-middle attacks  
possible.

Proof of concept:  
-----------------  
1) Tolerating Self-Signed Certificates (CVE-2024-25642)  
A "tunnel" established between a subaccount of SAP BTP and SCC represents a  
long-lived bi-directional WebSocket over TLS customized by the vendor.  
Such a tunnel is initiated by the SCC, known as reverse invoke approach,  
to give the administrator full control of the tunnel.

Two tunnels established by SCC are protected by TLS with respect to encrypted  
communication. However, SCC does not verify the authenticity of the  
certification authority, hence allowing an attacker to impersonate the target  
server, using self-signed certificates.

In particular, the attack is targeted at the following two endpoints, but not  
limited to the region host us10.

- connectivitynotification.cf.us10.hana.ondemand.com  
- connectivity.us10.trial.applicationstudio.cloud.sap

Note that the following endpoint, which is used for the initial certificate  
signing request by SCC and to receive the BTP subaccount credentials, is  
not susceptible to this issue.

- connectivitycertsigning.cf.us10.hana.ondemand.com

Nonetheless, it suffices to silently eavesdrop and manipulate network traffic  
between SCC and SAP BTP by impersonating the two vulnerable endpoints above.

Without loss of generality, the first endpoint is taken as example to  
demonstrate the issue by the following steps:

1. Add an entry in /etc/hosts of the SCC host as below to resolve the host name  
    to an attacker-controlled IP address:

    192.168.1.100       connectivitynotification.cf.us10.hana.ondemand.com

2. Generate a self-signed certificate with the spoofed hostname as common name

```  
$ openssl req -x509 -newkey rsa:4096 -keyout conn-noti-key.pem -out conn-noti-cert.pem -sha256 -days 3650 -nodes -subj "/C=DE/ST=Baden-Wuerttemberg/L=Walldorf/O=SAP   
SE/OU=ITSecurity/CN=connectivitynotification.cf.us10.hana.ondemand.com"  
```

3. Start an HTTPS server on the attacker machine to receive the connection from  
    SCC, using the self-signed certificate created in step 2

The following Python script can be used to start the HTTPS server:  
```  
$ cat https-dummy-server.py  
import http.server  
import ssl

server_address = ("192.168.1.100", 443)  
httpd = http.server.HTTPServer(server_address, http.server.SimpleHTTPRequestHandler)  
httpd.socket = ssl.wrap_socket(httpd.socket,  
     server_side=True,  
     certfile="self-signed-cert/conn-noti-cert.pem",  
     keyfile="self-signed-cert/conn-noti-key.pem",  
     ssl_version=ssl.PROTOCOL_TLS)  
httpd.serve_forever()  
```

4. Connect to a subaccount of BTP, for example US East AWS, in the SCC  
    Administration UI

As soon as the connection is launched, the dummy web server will receive the  
request as shown below:

```  
$ python3 https-dummy-server.py  
192.168.1.200 - - [10/Nov/2023 12:00:00] "GET /connectivity HTTP/1.1" 200 -  
```

This observation confirms that the TLS connection between SCC and the spoofed  
BTP endpoint operated on the attacker's machine has been successfully established  
although the server presented a self-signed certificate. No security warning  
message is being displayed in the Administration UI, making the attack  
surreptitious.

Vulnerable / tested versions:  
-----------------------------  
The following versions have been tested which were the latest versions available  
at the time of the test:

* SAP Cloud Connector Linux x86_64 Version 2.16.0  
* SAP Cloud Connector Linux (Portable) x86_64 Version 2.16.0

According to the vendor, the vulnerability is a regression and affects the  
versions 2.15.0 - 2.16.1.

Vendor contact timeline:  
------------------------  
2023-11-14: Contacting vendor through vulnerability submission web form  
2023-11-17: Vendor confirms receipt and assign SAP security incident numbers to  
             the four submitted findings: 2370150975, 2370150977, 2370150994, 2370151022  
2023-11-20: Vendor informs the reported issues be assigned the appropriate  
             development teams for analysis  
2023-12-05: Requesting status update  
2023-12-05: Vendor informs that 2370151022 be rejected  
2023-12-05: Issuing rebuttal for 2370151022  
2023-12-06: Vendor contemplates further analysis  
2023-12-14: Vendor decides not to take any action on 2370151022 and rejects  
             2370150977 and 2370150975 as well.  
2023-12-15: Vendor accepts 2370150994  
2024-01-05: Asked vendor to comment on the three rejected issues  
2024-01-10: Vendor gives detailed rationale for the rejection of 2370150975  
2024-01-12: Issuing rebuttal for 2370150975  
2024-01-15: Vendor insists on rejection of 2370150975 and closes the ticket.  
             Removing three rejected potential security issues from advisory.  
2024-02-13: Release of SAP Security Patch Day, security note #3424610  
2024-02-26: Asking for the disclosure guideline to publish finding 2370150994  
2024-02-26: Vendor confirms the three-month embargo  
2024-05-13: Coordinated release of SEC Consult advisory.

Solution:  
---------  
The vendor provides a patched version 2.16.2 which can be downloaded from their  
website:  
https://tools.hana.ondemand.com/#cloud

Also see the vendor's security note #3424610 for further details:  
https://me.sap.com/notes/3424610

Workaround:  
-----------  
None

Advisory URL:  
-------------  
https://sec-consult.com/vulnerability-lab/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SEC Consult Vulnerability Lab  
An integrated part of SEC Consult, an Eviden business  
Europe | Asia

About SEC Consult Vulnerability Lab  
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an  
Eviden business. It ensures the continued knowledge gain of SEC Consult in the  
field of network and application security to stay ahead of the attacker. The  
SEC Consult Vulnerability Lab supports high-quality penetration testing and  
the evaluation of new offensive and defensive technologies for our customers.  
Hence our customers obtain the most current information about vulnerabilities  
and valid recommendation about the risk profile of new technologies.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Interested to work with the experts of SEC Consult?  
Send us your application https://sec-consult.com/career/

Interested in improving your cyber security with the experts of SEC Consult?  
Contact our local offices https://sec-consult.com/contact/  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mail: security-research at sec-consult dot com  
Web: https://www.sec-consult.com  
Blog: https://blog.sec-consult.com  
Twitter: https://twitter.com/sec_consult

EOF M. Li, F. Hagg / @2024

SAP Cloud Connector 2.16.1 Missing Validation

Red Hat Security Advisory 2024-2846-03 - An update for kernel-rt is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2846.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Moderate: kernel-rt security and bug fix update  
Advisory ID:        RHSA-2024:2846-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:2846  
Issue date:         2024-05-15  
Revision:           03  
CVE Names:          CVE-2023-52628  
====================================================================

Summary: 

An update for kernel-rt is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The kernel-rt packages provide the Real Time Linux Kernel, which enables fine-tuning for systems with extremely high determinism requirements.

Security Fix(es):

* kernel: untrusted VMM can trigger int80 syscall handling (CVE-2024-25744)

* kernel: netfilter: nftables: exthdr: fix 4-byte stack OOB write (CVE-2023-52628)

Bug Fix(es):

* kernel-rt: kernel: untrusted VMM can trigger int80 syscall handling (JIRA:RHEL-30421)

* kernel-rt: kernel: netfilter: nftables: exthdr: fix 4-byte stack OOB write (JIRA:RHEL-31093)

* kernel-rt: update RT source tree to the latest RHEL-9.2 ad hoc schedule build (JIRA:RHEL-34746)

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2023-52628

References:

https://access.redhat.com/security/updates/classification/#moderate  
https://bugzilla.redhat.com/show_bug.cgi?id=2263875  
https://bugzilla.redhat.com/show_bug.cgi?id=2272041

Red Hat Security Advisory 2024-2846-03

Red Hat Security Advisory 2024-2845-03 - An update for kernel is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2845.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Moderate: kernel security and bug fix update  
Advisory ID:        RHSA-2024:2845-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:2845  
Issue date:         2024-05-15  
Revision:           03  
CVE Names:          CVE-2023-52628  
====================================================================

Summary: 

An update for kernel is now available for Red Hat Enterprise Linux 9.2 Extended Update Support.

Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: untrusted VMM can trigger int80 syscall handling (CVE-2024-25744)

* kernel: netfilter: nftables: exthdr: fix 4-byte stack OOB write (CVE-2023-52628)

Bug Fix(es):

* kernel: untrusted VMM can trigger int80 syscall handling (JIRA:RHEL-30266)

* kernel: netfilter: nftables: exthdr: fix 4-byte stack OOB write (JIRA:RHEL-31090)

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2023-52628

References:

https://access.redhat.com/security/updates/classification/#moderate  
https://bugzilla.redhat.com/show_bug.cgi?id=2263875  
https://bugzilla.redhat.com/show_bug.cgi?id=2272041

Red Hat Security Advisory 2024-2845-03

Red Hat Security Advisory 2024-2843-03 - An update for.NET 7.0 is now available for Red Hat Enterprise Linux 9. Issues addressed include a denial of service vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_2843.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: .NET 7.0 security updateAdvisory ID:        RHSA-2024:2843-03Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2024:2843Issue date:         2024-05-15Revision:           03CVE Names:          CVE-2024-30045====================================================================Summary: An update for .NET 7.0 is now available for Red Hat Enterprise Linux 9.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:.NET is a managed-software framework. It implements a subset of the .NET framework APIs and several new APIs, and it includes a CLR implementation.New versions of .NET that address a security vulnerability are now available. The updated versions are .NET SDK 7.0.119 and .NET Runtime 7.0.19.Security Fix(es):* dotnet: stack buffer overrun in Double Parse (CVE-2024-30045)* dotnet: denial of service in ASP.NET Core due to deadlock in Http2OutputProducer.Stop() (CVE-2024-30046)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-30045References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2279695https://bugzilla.redhat.com/show_bug.cgi?id=2279697

Tag

#linux