VARIoT IoT vulnerabilities database
| VAR-202103-0583 | CVE-2020-6785 | Bosch BVMS and BVMS Viewer Vulnerability in Uncontrolled Search Path Elements |
CVSS V2: 6.9 CVSS V3: 7.8 Severity: HIGH |
Loading a DLL through an Uncontrolled Search Path Element in Bosch BVMS and BVMS Viewer in versions 10.1.0, 10.0.1, 10.0.0 and 9.0.0 and older potentially allows an attacker to execute arbitrary code on a victim's system. This affects both the installer as well as the installed application. This also affects Bosch DIVAR IP 7000 R2, Bosch DIVAR IP all-in-one 5000 and Bosch DIVAR IP all-in-one 7000 with installers and installed BVMS versions prior to BVMS 10.1.1. Bosch BVMS and BVMS Viewer There is a vulnerability in an element of an uncontrolled search path.Information is obtained, information is tampered with, and service is disrupted (DoS) It may be put into a state
| VAR-202103-0588 | CVE-2020-6790 | Bosch Video Streaming Gateway Vulnerability in Uncontrolled Search Path Elements |
CVSS V2: 6.9 CVSS V3: 7.8 Severity: HIGH |
Calling an executable through an Uncontrolled Search Path Element in the Bosch Video Streaming Gateway installer up to and including version 6.45.10 potentially allows an attacker to execute arbitrary code on a victim's system. A prerequisite is that the victim is tricked into placing a malicious exe in the same directory where the installer is started from. Bosch BVMS is an application system of Bosch Company in Germany. For video management. A security vulnerability exists in Bosch BVMS that could allow an attacker to execute arbitrary code on a victim's system
| VAR-202103-1327 | CVE-2021-25367 | Samsung Notes Traversal Vulnerability in Japan |
CVSS V2: 5.5 CVSS V3: 5.4 Severity: Medium |
Path Traversal vulnerability in Samsung Notes prior to version 4.2.00.22 allows attackers to access local files without permission
| VAR-202103-1464 | CVE-2021-3449 | OpenSSL In NULL Pointer dereference vulnerability |
CVSS V2: 4.3 CVSS V3: 5.9 Severity: MEDIUM |
An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j). The product supports a variety of encryption algorithms, including symmetric ciphers, hash algorithms, secure hash algorithms, etc. On March 25, 2021, the OpenSSL Project released a security advisory, OpenSSL Security Advisory [25 March 2021], that disclosed two vulnerabilities.
Exploitation of these vulnerabilities could allow an malicious user to use a valid non-certificate authority (CA) certificate to act as a CA and sign a certificate for an arbitrary organization, user or device, or to cause a denial of service (DoS) condition. OpenSSL Security Advisory [25 March 2021]
=========================================
CA certificate check bypass with X509_V_FLAG_X509_STRICT (CVE-2021-3450)
========================================================================
Severity: High
The X509_V_FLAG_X509_STRICT flag enables additional security checks of the
certificates present in a certificate chain. It is not set by default.
Starting from OpenSSL version 1.1.1h a check to disallow certificates in
the chain that have explicitly encoded elliptic curve parameters was added
as an additional strict check.
An error in the implementation of this check meant that the result of a
previous check to confirm that certificates in the chain are valid CA
certificates was overwritten. This effectively bypasses the check
that non-CA certificates must not be able to issue other certificates.
If a "purpose" has been configured then there is a subsequent opportunity
for checks that the certificate is a valid CA. All of the named "purpose"
values implemented in libcrypto perform this check. Therefore, where
a purpose is set the certificate chain will still be rejected even when the
strict flag has been used. A purpose is set by default in libssl client and
server certificate verification routines, but it can be overridden or
removed by an application.
In order to be affected, an application must explicitly set the
X509_V_FLAG_X509_STRICT verification flag and either not set a purpose
for the certificate verification or, in the case of TLS client or server
applications, override the default purpose.
This issue was reported to OpenSSL on 18th March 2021 by Benjamin Kaduk
from Akamai and was discovered by Xiang Ding and others at Akamai. The fix was
developed by Tomáš Mráz.
This issue was reported to OpenSSL on 17th March 2021 by Nokia. The fix was
developed by Peter Kästle and Samuel Sapalski from Nokia.
Note
====
OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended
support is available for premium support customers:
https://www.openssl.org/support/contracts.html
OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind.
References
==========
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20210325.txt
Note: the online version of the advisory may be updated with additional details
over time.
For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
. Summary:
Openshift Serverless 1.10.2 is now available. This version of the OpenShift Serverless
Operator is supported on Red Hat OpenShift Container Platform version 4.5. Solution:
See the documentation at:
https://access.redhat.com/documentation/en-us/openshift_container_platform/
4.5/html/serverless_applications/index
4. Description:
Windows Container Support for Red Hat OpenShift allows you to deploy
Windows container workloads running on Windows Server containers.
Bug Fix(es):
* WMCO patch pub-key-hash annotation to Linux node (BZ#1945248)
* LoadBalancer Service type with invalid external loadbalancer IP breaks
the datapath (BZ#1952917)
* Telemetry info not completely available to identify windows nodes
(BZ#1955319)
* WMCO incorrectly shows node as ready after a failed configuration
(BZ#1956412)
* kube-proxy service terminated unexpectedly after recreated LB service
(BZ#1963263)
3. Solution:
For Windows Machine Config Operator upgrades, see the following
documentation:
https://docs.openshift.com/container-platform/4.7/windows_containers/window
s-node-upgrades.html
4. Bugs fixed (https://bugzilla.redhat.com/):
1945248 - WMCO patch pub-key-hash annotation to Linux node
1946538 - CVE-2021-25736 kubernetes: LoadBalancer Service type don't create a HNS policy for empty or invalid external loadbalancer IP, what could lead to MITM
1952917 - LoadBalancer Service type with invalid external loadbalancer IP breaks the datapath
1955319 - Telemetry info not completely available to identify windows nodes
1956412 - WMCO incorrectly shows node as ready after a failed configuration
1963263 - kube-proxy service terminated unexpectedly after recreated LB service
5.
Bug fix:
* RHACM 2.0.10 images (BZ #1940452)
3. Bugs fixed (https://bugzilla.redhat.com/):
1940452 - RHACM 2.0.10 images
1944286 - CVE-2021-23358 nodejs-underscore: Arbitrary code execution via the template function
5. Relevant releases/architectures:
Red Hat Enterprise Linux BaseOS EUS (v. 8.2) - aarch64, ppc64le, s390x, x86_64
3. Description:
OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL) and
Transport Layer Security (TLS) protocols, as well as a full-strength
general-purpose cryptography library. 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
For the update to take effect, all services linked to the OpenSSL library
must be restarted, or the system rebooted. Package List:
Red Hat Enterprise Linux BaseOS EUS (v. Our key and
details on how to verify the signature are available from
https://access.redhat.com/security/team/key/
7. Summary:
Red Hat Advanced Cluster Management for Kubernetes 2.1.6 General
Availability release images, which fix several bugs and security issues. Description:
Red Hat Advanced Cluster Management for Kubernetes 2.1.6 images
Red Hat Advanced Cluster Management for Kubernetes provides the
capabilities to address common challenges that administrators and site
reliability engineers face as they work across a range of public and
private cloud environments. Clusters and applications are all visible and
managed from a single console—with security policy built in.
Bug fixes:
* RHACM 2.1.6 images (BZ#1940581)
* When generating the import cluster string, it can include unescaped
characters (BZ#1934184)
3. Solution:
Before applying this update, make sure all previously released errata
relevant to your system have been applied. Bugs fixed (https://bugzilla.redhat.com/):
1853652 - CVE-2020-14040 golang.org/x/text: possibility to trigger an infinite loop in encoding/unicode could lead to crash
1929338 - CVE-2020-35149 mquery: Code injection via merge or clone operation
1934184 - When generating the import cluster string, it can include unescaped characters
1940581 - RHACM 2.1.6 images
5. -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
====================================================================
Red Hat Security Advisory
Synopsis: Important: Red Hat JBoss Core Services Apache HTTP Server 2.4.37 SP7 security update
Advisory ID: RHSA-2021:1200-01
Product: Red Hat JBoss Core Services
Advisory URL: https://access.redhat.com/errata/RHSA-2021:1200
Issue date: 2021-04-14
CVE Names: CVE-2021-3449 CVE-2021-3450
====================================================================
1. Summary:
Red Hat JBoss Core Services Pack Apache Server 2.4.37 Service Pack 7 zip
release for RHEL 7, RHEL 8 and Microsoft Windows is available.
Red Hat Product Security has rated this update as having a security impact
of Important. A Common Vulnerability Scoring System (CVSS) base score,
which gives a detailed severity rating, is available for each vulnerability
from the CVE link(s) in the References section.
2. Description:
Red Hat JBoss Core Services is a set of supplementary software for Red Hat
JBoss middleware products. This software, such as Apache HTTP Server, is
common to multiple JBoss middleware products, and is packaged under Red Hat
JBoss Core Services to allow for faster distribution of updates, and for a
more consistent update experience.
This release adds the new Apache HTTP Server 2.4.37 Service Pack 7 packages
that are part of the JBoss Core Services offering.
This release serves as a replacement for Red Hat JBoss Core Services Pack
Apache Server 2.4.37 Service Pack 6 and includes bug fixes and
enhancements. Refer to the Release Notes for information on the most
significant bug fixes and enhancements included in this release.
3. Solution:
Before applying the update, back up your existing installation, including
all applications, configuration files, databases and database settings, and
so on.
The References section of this erratum contains a download link for the
update. You must be logged in to download the update.
4. Bugs fixed (https://bugzilla.redhat.com/):
1941547 - CVE-2021-3450 openssl: CA certificate check bypass with X509_V_FLAG_X509_STRICT
1941554 - CVE-2021-3449 openssl: NULL pointer dereference in signature_algorithms processing
5. References:
https://access.redhat.com/security/cve/CVE-2021-3449
https://access.redhat.com/security/cve/CVE-2021-3450
https://access.redhat.com/security/updates/classification/#important
https://access.redhat.com/jbossnetwork/restricted/listSoftware.html?product=core.service.apachehttp&downloadType=securityPatches&version=2.4.37
6. Contact:
The Red Hat security contact is <secalert@redhat.com>. More contact
details at https://access.redhat.com/security/team/contact/
Copyright 2021 Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUBYHcRztzjgjWX9erEAQi2UA//ZnBZbF6yu43LNZh8SpIsZt25+kmRXpPO
24bitxkguIp8Mbf6aysizioKh10TgUzJAZL/xwzVGaf1YTtGXEiiQZvl+qetQhal
CYcQUX9iRTbN3LL5sT0es8qIc9pXnVSh9YCRaa2i3l9KWlPWA2U0R4OfrAmGIjUe
VG3tJ92HhtdeEx0VOHC+X6e7bDMoGQboT7cDJsP/xn8abWrBn9pQYfh7Ej/4qwMK
8sm6M7KcMcl2Sxjv0PB5obmZWBILWiTwHrJu6M3D6HBMJ4IdA0+DrDjf5U3NW6xp
uYmmkKkw18juBkRyLBFG0Xnm8JUh9t50zRL5XbI5rcv8w+puqcuLuNWD83L+fIFE
Z7eDdVaf0TYljefjbiZP/An2vjiOJ6Tm7nO79lrCI/g7Oax+/oK0/ClDpLuwVKtB
hz7f5VrK2+q+qDRvXk65Ala9kMHvhkr7s2/64/UMcvqpnTSkzypFORSdj+UBevUb
a+2ClrFEeokOXZxvZGQQxvu6do8roy2vrpLgNmxaDf65JZk5R4NlC3J4SbEjwBTT
Wg4bnZRXHi+T8OL3fmPTnNsEMOAdH3kwUfgzIbj9o6wFzoZiKYRUk9qQv8jb1G9K
x0qnCqtrwqzBBUs+ntXfTguTOba7JYx7aWH6ieBOIb5tapLJw7xOlVWbE1d29BCy
CkeZnyNSON8=u60F
-----END PGP SIGNATURE-----
--
RHSA-announce mailing list
RHSA-announce@redhat.com
https://listman.redhat.com/mailman/listinfo/rhsa-announce
| VAR-202103-1463 | CVE-2021-3450 | OpenSSL In CA Vulnerability to bypass the check that other certificates cannot issue other certificates |
CVSS V2: 5.8 CVSS V3: 7.4 Severity: HIGH |
The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1h-1.1.1j). The product supports a variety of encryption algorithms, including symmetric ciphers, hash algorithms, secure hash algorithms, etc. On March 25, 2021, the OpenSSL Project released a security advisory, OpenSSL Security Advisory [25 March 2021], that disclosed two vulnerabilities.
Exploitation of these vulnerabilities could allow an malicious user to use a valid non-certificate authority (CA) certificate to act as a CA and sign a certificate for an arbitrary organization, user or device, or to cause a denial of service (DoS) condition.
This advisory is available at the following link:tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-openssl-2021-GHY28dJd.
Bug Fix(es):
This update includes various bug fixes and enhancements. Space precludes
documenting all of these changes in this advisory. Bugs fixed (https://bugzilla.redhat.com/):
1803849 - [RFE] Include per volume encryption with Vault integration in RHCS 4.1
1814681 - [RFE] use topologySpreadConstraints to evenly spread OSDs across hosts
1840004 - CVE-2020-7608 nodejs-yargs-parser: prototype pollution vulnerability
1850089 - OBC CRD is outdated and leads to missing columns in get queries
1860594 - Toolbox pod should have toleration for OCS tainted nodes
1861104 - OCS podDisruptionBudget prevents successful OCP upgrades
1861878 - [RFE] use appropriate PDB values for OSD
1866301 - [RHOCS Usability Study][Installation] “Create storage cluster” should be a part of the installation flow or need to be emphasized as a crucial step.
1869406 - must-gather should include historical pod logs
1872730 - [RFE][External mode] Re-configure noobaa to use the updated RGW endpoint from the RHCS cluster
1874367 - "Create Backing Store" page doesn't allow to select already defined k8s secret as target bucket credentials when Google Cloud Storage is selected as a provider
1883371 - CVE-2020-26160 jwt-go: access restriction bypass vulnerability
1886112 - log message flood with Reconciling StorageCluster","Request.Namespace":"openshift-storage","Request.Name":"ocs-storagecluster"
1886416 - Uninstall 4.6: ocs-operator logging regarding noobaa-core PVC needs change
1886638 - CVE-2020-8565 kubernetes: Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9
1888839 - Create public route for ceph-rgw service
1892622 - [GSS] Noobaa management dashboard reporting High number of issues when the cluster is in healthy state
1893611 - Skip ceph commands collection attempt if must-gather helper pod is not created
1893613 - must-gather tries to collect ceph commands in external mode when storagecluster already deleted
1893619 - OCS must-gather: Inspect errors for cephobjectoreUser and few ceph commandd when storage cluster does not exist
1894412 - [RFE][External] RGW metrics should be made available even if anything else except 9283 is provided as the monitoring-endpoint-port
1896338 - OCS upgrade from 4.6 to 4.7 build failed
1897246 - OCS - ceph historical logs collection
1897635 - CVE-2020-28362 golang: math/big: panic during recursive division of very large numbers
1898509 - [Tracker][RHV #1899565] Deployment on RHV/oVirt storage class ovirt-csi-sc failing
1898680 - CVE-2020-7774 nodejs-y18n: prototype pollution vulnerability
1898808 - Rook-Ceph crash collector pod should not run on non-ocs node
1900711 - [RFE] Alerting for Namespace buckets and resources
1900722 - Failed to init upgrade process on noobaa-core-0
1900749 - Namespace Resource reported as Healthy when target bucket deleted
1900760 - RPC call for Namespace resource creation allows invalid target bucket names
1901134 - OCS - ceph historical logs collection
1902192 - [RFE][External] RGW metrics should be made available even if anything else except 9283 is provided as the monitoring-endpoint-port
1902685 - Too strict Content-Length header check refuses valid upload requests
1902711 - Tracker for Bug #1903078 Deleting VolumeSnapshotClass makes VolumeSnapshot not Ready
1903973 - [Azure][ROKS] Set SSD tuning (tuneFastDeviceClass) as default for OSD devices in Azure/ROKS platform
1903975 - Add "ceph df detail" for ocs must-gather to enable support to debug compression
1904302 - [GSS] ceph_daemon label includes references to a replaced OSD that cause a prometheus ruleset to fail
1904929 - [GSS][RFE]Reduce debug level for logs of Nooba Endpoint pod
1907318 - Unable to deploy & upgrade to ocs 4.7 - missing postgres image reference
1908414 - [GSS][VMWare][ROKS] rgw pods are not showing up in OCS 4.5 - due to pg_limit issue
1908678 - ocs-osd-removal job failed with "Invalid value" error when using multiple ids
1909268 - OCS 4.7 UI install -All OCS operator pods respin after storagecluster creation
1909488 - [NooBaa CLI] CLI status command looks for wrong DB PV name
1909745 - pv-pool backing store name restriction should be at 43 characters
1910705 - OBCs are stuck in a Pending state
1911131 - Bucket stats in the NB dashboard are incorrect
1911266 - Backingstore phase is ready, modecode is INITIALIZING
1911627 - CVE-2020-26289 nodejs-date-and-time: ReDoS in parsing via date.compile
1911789 - Data deduplication does not work properly
1912421 - [RFE] noobaa cli allow the creation of BackingStores with already existing secrets
1912894 - OCS storagecluster is Progressing state and some noobaa pods missing with latest 4.7 build -4.7.0-223.ci and storagecluster reflected as 4.8.0 instead of 4.7.0
1913149 - make must-gather backward compatibility for version <4.6
1913357 - ocs-operator should show error when flexible scaling and arbiter are both enabled at the same time
1914132 - No metrics available in the Object Service Dashboard in OCS 4.7, logs show "failed to retrieve metrics exporter servicemonitor"
1914159 - When OCS was deployed using arbiter mode mon's are going into CLBO state, ceph version = 14.2.11-95
1914215 - must-gather fails to delete the completed state compute-xx-debug pods after successful completion
1915111 - OCS OSD selection algorithm is making some strange choices.
1915261 - Deleted MCG CRs are stuck in a 'Deleting' state
1915445 - Uninstall 4.7: Storagecluster deletion stuck on a partially created KMS enabled OCS cluster + support TLS configuration for KMS
1915644 - update noobaa db label in must-gather to collect db pod in noobaa dir
1915698 - There is missing noobaa-core-0 pod after upgrade from OCS 4.6 to OCS 4.7
1915706 - [Azure][RBD] PV taking longer time ~ 9 minutes to get deleted
1915730 - [ocs-operator] Create public route for ceph-rgw service
1915737 - Improve ocs-operator logging during uninstall to be more verbose, to understand reasons for failures - e.g. for Bug 1915445
1915758 - improve noobaa logging in case of uninstall - logs do not specify clearly the resource on which deletion is stuck
1915807 - Arbiter: OCS Install failed when used label = topology.kubernetes.io/zone instead of deprecated failureDomain label
1915851 - OCS PodDisruptionBudget redesign for OSDs to allow multiple nodes to drain in the same failure domain
1915953 - Must-gather takes hours to complete if the OCS cluster is not fully deployed, delay seen in ceph command collection step
1916850 - Uninstall 4.7- rook: Storagecluster deletion stuck on a partially created KMS enabled OCS cluster(OSD creation failed)
1917253 - Restore-pvc creation fails with error "csi-vol-* has unsupported quota"
1917815 - [IBM Z and Power] OSD pods restarting due to OOM during upgrade test using ocs-ci
1918360 - collect timestamp for must-gather commands and also the total time taken for must-gather to complete
1918750 - CVE-2021-3114 golang: crypto/elliptic: incorrect operations on the P-224 curve
1918925 - noobaa operator pod logs messages for other components - like rook-ceph-mon, csi-pods, new Storageclass, etc
1918938 - ocs-operator has Error logs with "unable to deploy Prometheus rules"
1919967 - MCG RPC calls time out and the system is unresponsive
1920202 - RGW pod did not get created when OCS was deployed using arbiter mode
1920498 - [IBM Z] OSDs are OOM killed and storage cluster goes into error state during ocs-ci tier1 pvc expansion tests
1920507 - Creation of cephblockpool with compression failed on timeout
1921521 - Add support for VAULT_SKIP_VERIFY option in Ceph-CSI
1921540 - RBD PVC creation fails with error "invalid encryption kms configuration: "POD_NAMESPACE" is not set"
1921609 - MongoNetworkError messages in noobaa-core logs
1921625 - 'Not Found: Secret "noobaa-root-master-key" message' in noobaa logs and cli output when kms is configured
1922064 - uninstall on VMware LSO+ arbiter with 4 OSDs in Pending state: Storagecluster deletion stuck, waiting for cephcluster to be deleted
1922108 - OCS 4.7 4.7.0-242.ci and beyond: osd pods are not created
1922113 - noobaa-db pod init container is crashing after OCS upgrade from OCS 4.6 to OCS 4.7
1922119 - PVC snapshot creation failing on OCP4.6-OCS 4.7 cluster
1922421 - [ROKS] OCS deployment stuck at mon pod in pending state
1922954 - [IBM Z] OCS: Failed tests because of osd deviceset restarts
1924185 - Object Service Dashboard shows alerts related to "system-internal-storage-pool" in OCS 4.7
1924211 - 4.7.0-249.ci: RGW pod not deployed, rook logs show - failed to create object store "must be no more than 63 characters"
1924634 - MG terminal logs show `pods "compute-x-debug" not found` even though pods are in Running state
1924784 - RBD PVC creation fails with error "invalid encryption kms configuration: failed to parse kms configuration"
1924792 - RBD PVC creation fails with error "invalid encryption kms configuration: failed to parse kms configuration"
1925055 - OSD pod stuck in Init:CrashLoopBackOff following Node maintenance in OCP upgrade from OCP 4.7 to 4.7 nightly
1925179 - MG fix [continuation from bug 1893619]: Do not attempt creating helper pod if storagecluster/cephcluster already deleted
1925249 - KMS resources should be garbage collected when StorageCluster is deleted
1925533 - [GSS] Unable to install Noobaa in AWS govcloud
1926182 - [RFE] Support disabling reconciliation of monitoring related resources using a dedicated reconcile strategy flag
1926617 - osds are in Init:CrashLoopBackOff with rgw in CrashLoopBackOff on KMS enabled cluster
1926717 - Only one NOOBAA_ROOT_SECRET_PATH key created in vault when the same backend path is used for multiple OCS clusters
1926831 - [IBM][ROKS] Deploy RGW pods only if IBM COS is not available on platform
1927128 - [Tracker for BZ #1937088] When Performed add capacity over arbiter mode cluster ceph health reports PG_AVAILABILITY Reduced data availability: 25 pgs inactive, 25 pgs incomplete
1927138 - must-gather skip collection of ceph in every run
1927186 - Configure pv-pool as backing store if cos creds secret not found in IBM Cloud
1927317 - [Arbiter] Storage Cluster installation did not started because ocs-operator was Expecting 8 node found 4
1927330 - Namespacestore-backed OBCs are stuck on Pending
1927338 - Uninstall OCS: Include events for major CRs to know the cause of deletion getting stuck
1927885 - OCS 4.7: ocs operator pod in 1/1 state even when Storagecluster is in Progressing state
1928063 - For FD: rack: actual osd pod distribution and OSD placement in rack under ceph osd tree output do not match
1928451 - MCG CLI command of diagnose doesn't work on windows
1928471 - [Deployment blocker] Ceph OSDs do not register properly in the CRUSH map
1928487 - MCG CLI - noobaa ui command shows wss instead of https
1928642 - [IBM Z] rook-ceph-rgw pods restarts continously with ocs version 4.6.3 due to liveness probe failure
1931191 - Backing/namespacestores are stuck on Creating with credentials errors
1931810 - LSO deployment(flexibleScaling:true): 100% PGS unknown even though ceph osd tree placement is correct(root cause diff from bug 1928471)
1931839 - OSD in state init:CrashLoopBackOff with KMS signed certificates
1932400 - Namespacestore deletion takes 15 minutes
1933607 - Prevent reconcile of labels on all monitoring resources deployed by ocs-operator
1933609 - Prevent reconcile of labels on all monitoring resources deployed by rook
1933736 - Allow shrinking the cluster by removing OSDs
1934000 - Improve error logging for kv-v2 while using encryption with KMS
1934990 - Ceph health ERR post node drain on KMS encryption enabled cluster
1935342 - [RFE] Add OSD flapping alert
1936545 - [Tracker for BZ #1938669] setuid and setgid file bits are not retained after a OCS CephFS CSI restore
1936877 - Include at OCS Multi-Cloud Object Gateway core container image the fixes on CVEs from RHEL8 on "nodejs"
1937070 - Storage cluster cannot be uninstalled when cluster not fully configured
1937100 - [RGW][notification][kafka]: notification fails with error: pubsub endpoint configuration error: unknown schema in: kafka
1937245 - csi-cephfsplugin pods CrashLoopBackoff in fresh 4.6 cluster due to conflict with kube-rbac-proxy
1937768 - OBC with Cache BucketPolicy stuck on pending
1939026 - ServiceUnavailable when calling the CreateBucket operation (reached max retries: 4): Reduce your request rate
1939472 - Failure domain set incorrectly to zone if flexible scaling is enabled but there are >= 3 zones
1939617 - [Arbiter] Mons cannot be failed over in stretch mode
1940440 - noobaa migration pod is deleted on failure and logs are not available for inspection
1940476 - Backingstore deletion hangs
1940957 - Deletion of Rejected NamespaceStore is stuck even when target bucket and bucketclass are deleted
1941647 - OCS deployment fails when no backend path is specified for cluster wide encryption using KMS
1941977 - rook-ceph-osd-X gets stuck in initcontainer expand-encrypted-bluefs
1942344 - No permissions in /etc/passwd leads to fail noobaa-operaor
1942350 - No permissions in /etc/passwd leads to fail noobaa-operaor
1942519 - MCG should not use KMS to store encryption keys if cluster wide encryption is not enabled using KMS
1943275 - OSD pods re-spun after "add capacity" on cluster with KMS
1943596 - [Tracker for BZ #1944611][Arbiter] When Performed zone(zone=a) Power off and Power On, 3 mon pod(zone=b,c) goes in CLBO after node Power off and 2 Osd(zone=a) goes in CLBO after node Power on
1944980 - Noobaa deployment fails when no KMS backend path is provided during storagecluster creation
1946592 - [Arbiter] When both the rgw pod hosting nodes are down, the rgw service is unavailable
1946837 - OCS 4.7 Arbiter Mode Cluster becomes stuck when entire zone is shutdown
1955328 - Upgrade of noobaa DB failed when upgrading OCS 4.6 to 4.7
1955601 - CVE-2021-3528 NooBaa: noobaa-operator leaking RPC AuthToken into log files
1957187 - Update to RHCS 4.2z1 Ceph container image at OCS 4.7.0
1957639 - Noobaa migrate job is failing when upgrading OCS 4.6.4 to 4.7 on FIPS environment
5. -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
====================================================================
Red Hat Security Advisory
Synopsis: Moderate: Red Hat OpenShift Container Storage 4.6.5 security and bug fix update
Advisory ID: RHSA-2021:2479-01
Product: Red Hat OpenShift Container Storage
Advisory URL: https://access.redhat.com/errata/RHSA-2021:2479
Issue date: 2021-06-17
CVE Names: CVE-2016-10228 CVE-2017-14502 CVE-2019-2708
CVE-2019-3842 CVE-2019-9169 CVE-2019-13012
CVE-2019-14866 CVE-2019-25013 CVE-2020-8231
CVE-2020-8284 CVE-2020-8285 CVE-2020-8286
CVE-2020-8927 CVE-2020-9948 CVE-2020-9951
CVE-2020-9983 CVE-2020-13434 CVE-2020-13543
CVE-2020-13584 CVE-2020-13776 CVE-2020-15358
CVE-2020-24977 CVE-2020-25659 CVE-2020-25678
CVE-2020-26116 CVE-2020-26137 CVE-2020-27618
CVE-2020-27619 CVE-2020-27783 CVE-2020-28196
CVE-2020-29361 CVE-2020-29362 CVE-2020-29363
CVE-2020-36242 CVE-2021-3139 CVE-2021-3177
CVE-2021-3326 CVE-2021-3449 CVE-2021-3450
CVE-2021-3528 CVE-2021-20305 CVE-2021-23239
CVE-2021-23240 CVE-2021-23336
====================================================================
1. Summary:
Updated images that fix one security issue and several bugs are now
available for Red Hat OpenShift Container Storage 4.6.5 on Red Hat
Enterprise Linux 8 from Red Hat Container Registry.
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. Description:
Red Hat OpenShift Container Storage is software-defined storage integrated
with and optimized for the Red Hat OpenShift Container Platform. Red Hat
OpenShift Container Storage is a highly scalable, production-grade
persistent storage for stateful applications running in the Red Hat
OpenShift Container Platform. In addition to persistent storage, Red Hat
OpenShift Container Storage provisions a multicloud data management service
with an S3 compatible API.
Security Fix(es):
* NooBaa: noobaa-operator leaking RPC AuthToken into log files
(CVE-2021-3528)
For more details about the security issue(s), including the impact, a CVSS
score, and other related information, refer to the CVE page(s) listed in
the References section.
Bug Fix(es):
* Currently, a newly restored PVC cannot be mounted if some of the
OpenShift Container Platform nodes are running on a version of Red Hat
Enterprise Linux which is less than 8.2, and the snapshot from which the
PVC was restored is deleted.
Workaround: Do not delete the snapshot from which the PVC was restored
until the restored PVC is deleted. (BZ#1962483)
* Previously, the default backingstore was not created on AWS S3 when
OpenShift Container Storage was deployed, due to incorrect identification
of AWS S3. With this update, the default backingstore gets created when
OpenShift Container Storage is deployed on AWS S3. (BZ#1927307)
* Previously, log messages were printed to the endpoint pod log even if the
debug option was not set. With this update, the log messages are printed to
the endpoint pod log only when the debug option is set. (BZ#1938106)
* Previously, the PVCs could not be provisioned as the `rook-ceph-mds` did
not register the pod IP on the monitor servers, and hence every mount on
the filesystem timed out, resulting in CephFS volume provisioning failure.
With this update, an argument `--public-addr=podIP` is added to the MDS pod
when the host network is not enabled, and hence the CephFS volume
provisioning does not fail. (BZ#1949558)
* Previously, OpenShift Container Storage 4.2 clusters were not updated
with the correct cache value, and hence MDSs in standby-replay might report
an oversized cache, as rook did not apply the `mds_cache_memory_limit`
argument during upgrades. With this update, the `mds_cache_memory_limit`
argument is applied during upgrades and the mds daemon operates normally.
(BZ#1951348)
* Previously, the coredumps were not generated in the correct location as
rook was setting the config option `log_file` to an empty string since
logging happened on stdout and not on the files, and hence Ceph read the
value of the `log_file` to build the dump path. With this update, rook does
not set the `log_file` and keeps Ceph's internal default, and hence the
coredumps are generated in the correct location and are accessible under
`/var/log/ceph/`. (BZ#1938049)
* Previously, Ceph became inaccessible, as the mons lose quorum if a mon
pod was drained while another mon was failing over. With this update,
voluntary mon drains are prevented while a mon is failing over, and hence
Ceph does not become inaccessible. (BZ#1946573)
* Previously, the mon quorum was at risk, as the operator could erroneously
remove the new mon if the operator was restarted during a mon failover.
With this update, the operator completes the same mon failover after the
operator is restarted, and hence the mon quorum is more reliable in the
node drains and mon failover scenarios. (BZ#1959983)
All users of Red Hat OpenShift Container Storage are advised to pull these
new images from the Red Hat Container Registry.
3. Solution:
Before applying this update, make sure all previously released errata
relevant to your system have been applied.
For details on how to apply this update, refer to:
https://access.redhat.com/articles/11258
4. Bugs fixed (https://bugzilla.redhat.com/):
1938106 - [GSS][RFE]Reduce debug level for logs of Nooba Endpoint pod
1950915 - XSS Vulnerability with Noobaa version 5.5.0-3bacc6b
1951348 - [GSS][CephFS] health warning "MDS cache is too large (3GB/1GB); 0 inodes in use by clients, 0 stray files" for the standby-replay
1951600 - [4.6.z][Clone of BZ #1936545] setuid and setgid file bits are not retained after a OCS CephFS CSI restore
1955601 - CVE-2021-3528 NooBaa: noobaa-operator leaking RPC AuthToken into log files
1957189 - [Rebase] Use RHCS4.2z1 container image with OCS 4..6.5[may require doc update for external mode min supported RHCS version]
1959980 - When a node is being drained, increase the mon failover timeout to prevent unnecessary mon failover
1959983 - [GSS][mon] rook-operator scales mons to 4 after healthCheck timeout
1962483 - [RHEL7][RBD][4.6.z clone] FailedMount error when using restored PVC on app pod
5. References:
https://access.redhat.com/security/cve/CVE-2016-10228
https://access.redhat.com/security/cve/CVE-2017-14502
https://access.redhat.com/security/cve/CVE-2019-2708
https://access.redhat.com/security/cve/CVE-2019-3842
https://access.redhat.com/security/cve/CVE-2019-9169
https://access.redhat.com/security/cve/CVE-2019-13012
https://access.redhat.com/security/cve/CVE-2019-14866
https://access.redhat.com/security/cve/CVE-2019-25013
https://access.redhat.com/security/cve/CVE-2020-8231
https://access.redhat.com/security/cve/CVE-2020-8284
https://access.redhat.com/security/cve/CVE-2020-8285
https://access.redhat.com/security/cve/CVE-2020-8286
https://access.redhat.com/security/cve/CVE-2020-8927
https://access.redhat.com/security/cve/CVE-2020-9948
https://access.redhat.com/security/cve/CVE-2020-9951
https://access.redhat.com/security/cve/CVE-2020-9983
https://access.redhat.com/security/cve/CVE-2020-13434
https://access.redhat.com/security/cve/CVE-2020-13543
https://access.redhat.com/security/cve/CVE-2020-13584
https://access.redhat.com/security/cve/CVE-2020-13776
https://access.redhat.com/security/cve/CVE-2020-15358
https://access.redhat.com/security/cve/CVE-2020-24977
https://access.redhat.com/security/cve/CVE-2020-25659
https://access.redhat.com/security/cve/CVE-2020-25678
https://access.redhat.com/security/cve/CVE-2020-26116
https://access.redhat.com/security/cve/CVE-2020-26137
https://access.redhat.com/security/cve/CVE-2020-27618
https://access.redhat.com/security/cve/CVE-2020-27619
https://access.redhat.com/security/cve/CVE-2020-27783
https://access.redhat.com/security/cve/CVE-2020-28196
https://access.redhat.com/security/cve/CVE-2020-29361
https://access.redhat.com/security/cve/CVE-2020-29362
https://access.redhat.com/security/cve/CVE-2020-29363
https://access.redhat.com/security/cve/CVE-2020-36242
https://access.redhat.com/security/cve/CVE-2021-3139
https://access.redhat.com/security/cve/CVE-2021-3177
https://access.redhat.com/security/cve/CVE-2021-3326
https://access.redhat.com/security/cve/CVE-2021-3449
https://access.redhat.com/security/cve/CVE-2021-3450
https://access.redhat.com/security/cve/CVE-2021-3528
https://access.redhat.com/security/cve/CVE-2021-20305
https://access.redhat.com/security/cve/CVE-2021-23239
https://access.redhat.com/security/cve/CVE-2021-23240
https://access.redhat.com/security/cve/CVE-2021-23336
https://access.redhat.com/security/updates/classification/#moderate
6. Contact:
The Red Hat security contact is <secalert@redhat.com>. More contact
details at https://access.redhat.com/security/team/contact/
Copyright 2021 Red Hat, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUBYMtu/9zjgjWX9erEAQh6fhAAm9UPxF0e8ubzCEae+bkQAduwCkzpQ0ND
Q1/UcDAAc4ueEhBrwXPhOLrgfBj+VG+QA19YZcNPzbW7I48RGjCm5WccnUyEbFAo
FKTspCZW7FkXKBU15u58c/sFCGa4/Yuu+IpqCMuZ6lR2g9WHIBKdVtaB4y59AyfS
v59cAorqZ3AoTX4lVys6HfDGySQWlg5P8t6ST72cUJjESi6U0HV00P7ECU2SFxCF
HXA4gbXbZ1EPb/1+UkRRnXemJuT8SaRFRTrzj9woTrVAGQFvn+yjxLbZxVZb0WDd
6QeNpiJNICfL+/ExvEmGQucf7NcekYPWud11pnRUfQ+Uqsj+I7YoaepXAAolLzvN
kAVVpFNsWADOVz7BrfSKoo4b38UCFOEUSd2d1ijCNE96Q9XyNUpn+kZqz0/wpBQC
L+E5N9kEuaLyDBoI0wJAfoqU1NY4Cvl6lIMDgHUv2CE10zxhFwHCDulAfcQgxNQG
sIbpSgSegq9HfZSDxa6Rtrox1I7oGhnBy10sIwUUH1+fxAusUk+Xrxf8hUv8KgDz
V144yrGwN/6KVxh74A60bJX3ai12l6fC8bkmsxg5K1r/Dk4tUkQeXNdBbaK/rEKO
AQs7YDab/0VA2qKtXDRkbnzqBRSbamDNOO/jd28nGMoclaIRHCzQgJRFv6Qb6dwT
RCrstqAM5QQ=DHD0
-----END PGP SIGNATURE-----
--
RHSA-announce mailing list
RHSA-announce@redhat.com
https://listman.redhat.com/mailman/listinfo/rhsa-announce
.
Bug Fix(es):
* WMCO patch pub-key-hash annotation to Linux node (BZ#1945248)
* LoadBalancer Service type with invalid external loadbalancer IP breaks
the datapath (BZ#1952917)
* Telemetry info not completely available to identify windows nodes
(BZ#1955319)
* WMCO incorrectly shows node as ready after a failed configuration
(BZ#1956412)
* kube-proxy service terminated unexpectedly after recreated LB service
(BZ#1963263)
3. Solution:
For Windows Machine Config Operator upgrades, see the following
documentation:
https://docs.openshift.com/container-platform/4.7/windows_containers/window
s-node-upgrades.html
4. Bugs fixed (https://bugzilla.redhat.com/):
1945248 - WMCO patch pub-key-hash annotation to Linux node
1946538 - CVE-2021-25736 kubernetes: LoadBalancer Service type don't create a HNS policy for empty or invalid external loadbalancer IP, what could lead to MITM
1952917 - LoadBalancer Service type with invalid external loadbalancer IP breaks the datapath
1955319 - Telemetry info not completely available to identify windows nodes
1956412 - WMCO incorrectly shows node as ready after a failed configuration
1963263 - kube-proxy service terminated unexpectedly after recreated LB service
5. It is comprised of the Apache
Tomcat Servlet container, JBoss HTTP Connector (mod_cluster), the
PicketLink Vault extension for Apache Tomcat, and the Tomcat Native
library. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 202103-03
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
https://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: Normal
Title: OpenSSL: Multiple vulnerabilities
Date: March 31, 2021
Bugs: #769785, #777681
ID: 202103-03
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Synopsis
========
Multiple vulnerabilities have been found in OpenSSL, the worst of which
could allow remote attackers to cause a Denial of Service condition.
Background
==========
OpenSSL is an Open Source toolkit implementing the Secure Sockets Layer
(SSL v2/v3) and Transport Layer Security (TLS v1/v1.1/v1.2/v1.3) as
well as a general purpose cryptography library.
Affected packages
=================
-------------------------------------------------------------------
Package / Vulnerable / Unaffected
-------------------------------------------------------------------
1 dev-libs/openssl < 1.1.1k >= 1.1.1k
Description
===========
Multiple vulnerabilities have been discovered in OpenSSL. Please review
the CVE identifiers referenced below for details.
Impact
======
Please review the referenced CVE identifiers for details.
Workaround
==========
There is no known workaround at this time.
Resolution
==========
All OpenSSL users should upgrade to the latest version:
# emerge --sync
# emerge --ask --oneshot --verbose ">=dev-libs/openssl-1.1.1k"
References
==========
[ 1 ] CVE-2021-23840
https://nvd.nist.gov/vuln/detail/CVE-2021-23840
[ 2 ] CVE-2021-23841
https://nvd.nist.gov/vuln/detail/CVE-2021-23841
[ 3 ] CVE-2021-3449
https://nvd.nist.gov/vuln/detail/CVE-2021-3449
[ 4 ] CVE-2021-3450
https://nvd.nist.gov/vuln/detail/CVE-2021-3450
Availability
============
This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:
https://security.gentoo.org/glsa/202103-03
Concerns?
=========
Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users' machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.
License
=======
Copyright 2021 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).
The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.
https://creativecommons.org/licenses/by-sa/2.5
. Description:
Red Hat Advanced Cluster Management for Kubernetes 2.1.6 images
Red Hat Advanced Cluster Management for Kubernetes provides the
capabilities to address common challenges that administrators and site
reliability engineers face as they work across a range of public and
private cloud environments. Clusters and applications are all visible and
managed from a single console—with security policy built in.
Bug fixes:
* RHACM 2.1.6 images (BZ#1940581)
* When generating the import cluster string, it can include unescaped
characters (BZ#1934184)
3. Bugs fixed (https://bugzilla.redhat.com/):
1853652 - CVE-2020-14040 golang.org/x/text: possibility to trigger an infinite loop in encoding/unicode could lead to crash
1929338 - CVE-2020-35149 mquery: Code injection via merge or clone operation
1934184 - When generating the import cluster string, it can include unescaped characters
1940581 - RHACM 2.1.6 images
5. Summary:
Red Hat JBoss Core Services Pack Apache Server 2.4.37 Service Pack 7 zip
release for RHEL 7, RHEL 8 and Microsoft Windows is available. This software, such as Apache HTTP Server, is
common to multiple JBoss middleware products, and is packaged under Red Hat
JBoss Core Services to allow for faster distribution of updates, and for a
more consistent update experience.
This release adds the new Apache HTTP Server 2.4.37 Service Pack 7 packages
that are part of the JBoss Core Services offering. Solution:
Before applying the update, back up your existing installation, including
all applications, configuration files, databases and database settings, and
so on.
The References section of this erratum contains a download link for the
update. You must be logged in to download the update
| VAR-202103-0765 | CVE-2021-1460 | plural Cisco Resource depletion vulnerability in the product |
CVSS V2: 5.0 CVSS V3: 7.5 Severity: HIGH |
A vulnerability in the Cisco IOx Application Framework of Cisco 809 Industrial Integrated Services Routers (Industrial ISRs), Cisco 829 Industrial ISRs, Cisco CGR 1000 Compute Module, and Cisco IC3000 Industrial Compute Gateway could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due to insufficient error handling during packet processing. An attacker could exploit this vulnerability by sending a high and sustained rate of crafted TCP traffic to the IOx web server on an affected device. A successful exploit could allow the attacker to cause the IOx web server to stop processing requests, resulting in a DoS condition. plural Cisco The product contains a resource depletion vulnerability.Denial of service (DoS) It may be put into a state. Cisco Iox is a secure development environment of the US Cisco (Cisco) that combines Cisco IOS and Linux OS for secure network connection and development of IOT applications
| VAR-202103-0777 | CVE-2021-1441 | Cisco IOS XE In OS Command injection vulnerability |
CVSS V2: 7.2 CVSS V3: 6.7 Severity: MEDIUM |
A vulnerability in the hardware initialization routines of Cisco IOS XE Software for Cisco 1100 Series Industrial Integrated Services Routers and Cisco ESR6300 Embedded Series Routers could allow an authenticated, local attacker to execute unsigned code at system boot time. This vulnerability is due to incorrect validations of parameters passed to a diagnostic script that is executed when the device boots up. An attacker could exploit this vulnerability by tampering with an executable file stored on a device. A successful exploit could allow the attacker to execute unsigned code at boot time and bypass the software image verification check part of the secure boot process of an affected device. To exploit this vulnerability, the attacker would need administrative level credentials (level 15) on the device. Cisco IOS XE Has OS A command injection vulnerability exists.Information is obtained, information is tampered with, and service is disrupted (DoS) It may be put into a state. Cisco IOS XE is a set of modular operating system based on Linux kernel developed by American Cisco company for its network equipment. Attackers can use this vulnerability to execute unsigned code when the system is started
| VAR-202103-0776 | CVE-2021-1439 | Cisco Aironet Series Access Points Classic buffer overflow vulnerability in software |
CVSS V2: 3.3 CVSS V3: 7.4 Severity: HIGH |
A vulnerability in the multicast DNS (mDNS) gateway feature of Cisco Aironet Series Access Points Software could allow an unauthenticated, adjacent attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due to insufficient input validation of incoming mDNS traffic. An attacker could exploit this vulnerability by sending a crafted mDNS packet to an affected device through a wireless network that is configured in FlexConnect local switching mode or through a wired network on a configured mDNS VLAN. A successful exploit could allow the attacker to cause the access point (AP) to reboot, resulting in a DoS condition. Remote attackers can use this vulnerability to submit special requests, which can crash applications and cause denial of service attacks
| VAR-202103-0467 | CVE-2021-1373 | Cisco Catalyst 9000 For family wireless controller Cisco IOS XE Buffer over-read vulnerability in wireless controller software |
CVSS V2: 7.8 CVSS V3: 8.6 Severity: HIGH |
A vulnerability in the Control and Provisioning of Wireless Access Points (CAPWAP) protocol processing of Cisco IOS XE Wireless Controller Software for the Cisco Catalyst 9000 Family Wireless Controllers could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition of an affected device. The vulnerability is due to insufficient validation of CAPWAP packets. An attacker could exploit this vulnerability by sending a malformed CAPWAP packet to an affected device. A successful exploit could allow the attacker to cause the affected device to crash and reload, resulting in a DoS condition. Cisco Catalyst 9000 is a switch made by Cisco in the United States
| VAR-202103-0530 | CVE-2021-1423 | Cisco Aironet Access Points Vulnerability in Resource Leakage to Wrong Domain |
CVSS V2: 2.1 CVSS V3: 4.4 Severity: MEDIUM |
A vulnerability in the implementation of a CLI command in Cisco Aironet Access Points (AP) could allow an authenticated, local attacker to overwrite files in the flash memory of the device. This vulnerability is due to insufficient input validation for a specific command. An attacker could exploit this vulnerability by issuing a command with crafted arguments. A successful exploit could allow the attacker to overwrite or create files with data that is already present in other files that are hosted on the affected device. Cisco Aironet Access Points (AP) Is vulnerable to a resource leak to the wrong area.Information may be tampered with
| VAR-202103-0545 | CVE-2021-1385 | Cisco IOx Path Traversal Vulnerability in Applications |
CVSS V2: 6.0 CVSS V3: 6.5 Severity: MEDIUM |
A vulnerability in the Cisco IOx application hosting environment of multiple Cisco platforms could allow an authenticated, remote attacker to conduct directory traversal attacks and read and write files on the underlying operating system or host system. This vulnerability occurs because the device does not properly validate URIs in IOx API requests. An attacker could exploit this vulnerability by sending a crafted API request that contains directory traversal character sequences to an affected device. A successful exploit could allow the attacker to read or write arbitrary files on the underlying operating system. Cisco IOx The application contains a path traversal vulnerability.Information may be obtained and information may be tampered with. Cisco Iox is a secure development environment of the US Cisco (Cisco) that combines Cisco IOS and Linux OS for secure network connection and development of IOT applications.
A security vulnerability exists in the Cisco IOx application
| VAR-202103-0550 | CVE-2021-1391 | Cisco IOS XE Active debug code vulnerability in |
CVSS V2: 7.2 CVSS V3: 6.7 Severity: MEDIUM |
A vulnerability in the dragonite debugger of Cisco IOS XE Software could allow an authenticated, local attacker to escalate from privilege level 15 to root privilege. The vulnerability is due to the presence of development testing and verification scripts that remained on the device. An attacker could exploit this vulnerability by bypassing the consent token mechanism with the residual scripts on the affected device. A successful exploit could allow the attacker to escalate from privilege level 15 to root privilege. Cisco IOS XE Exists in an active debug code vulnerability.Information is obtained, information is tampered with, and service is disrupted (DoS) It may be put into a state. Cisco IOS XE Software is an operating system of Cisco (Cisco). A single operating system for enterprise wired and wireless access, aggregation, core, and WAN, Cisco IOS XE reduces business and network complexity
| VAR-202103-0540 | CVE-2021-1377 | Cisco IOS and IOS XE Resource management vulnerabilities in |
CVSS V2: 5.0 CVSS V3: 5.8 Severity: MEDIUM |
A vulnerability in Address Resolution Protocol (ARP) management of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to prevent an affected device from resolving ARP entries for legitimate hosts on the connected subnets. This vulnerability exists because ARP entries are mismanaged. An attacker could exploit this vulnerability by continuously sending traffic that results in incomplete ARP entries. A successful exploit could allow the attacker to cause ARP requests on the device to be unsuccessful for legitimate hosts, resulting in a denial of service (DoS) condition. Cisco IOS and IOS XE There is a resource management vulnerability in.Denial of service (DoS) It may be put into a state
| VAR-202103-0537 | CVE-2021-1392 | Cisco IOS and IOS XE Vulnerability regarding inadequate protection of credentials in |
CVSS V2: 2.1 CVSS V3: 7.8 Severity: HIGH |
A vulnerability in the CLI command permissions of Cisco IOS and Cisco IOS XE Software could allow an authenticated, local attacker to retrieve the password for Common Industrial Protocol (CIP) and then remotely configure the device as an administrative user. This vulnerability exists because incorrect permissions are associated with the show cip security CLI command. An attacker could exploit this vulnerability by issuing the command to retrieve the password for CIP on an affected device. A successful exploit could allow the attacker to reconfigure the device. Cisco IOS and IOS XE Exists in an inadequate protection of credentials.Information is obtained, information is tampered with, and service is disrupted (DoS) It may be put into a state. Pillow is a Python-based image processing library.
There is currently no information about this vulnerability, please feel free to follow CNNVD or manufacturer announcements. Both Cisco IOS and IOS XE are a set of operating systems developed by Cisco for its network equipment
| VAR-202103-1568 | CVE-2021-21783 | Genivia gSOAP Integer overflow vulnerability in |
CVSS V2: 7.5 CVSS V3: 9.8 Severity: CRITICAL |
A code execution vulnerability exists in the WS-Addressing plugin functionality of Genivia gSOAP 2.8.107. A specially crafted SOAP request can lead to remote code execution. An attacker can send an HTTP request to trigger this vulnerability. Genivia gSOAP Exists in an integer overflow vulnerability.Information is obtained, information is tampered with, and service operation is interrupted. (DoS) It may be put into a state. Genivia gSOAP is a C/C++ software development toolkit with automatic coding function of Genivia Company in the United States
| VAR-202103-0543 | CVE-2021-1383 | Cisco IOS XE SD-WAN Input confirmation vulnerability |
CVSS V2: 7.2 CVSS V3: 6.7 Severity: MEDIUM |
Multiple vulnerabilities in the CLI of Cisco IOS XE SD-WAN Software could allow an authenticated, local attacker to access the underlying operating system with root privileges. These vulnerabilities are due to insufficient input validation of certain CLI commands. An attacker could exploit these vulnerabilities by authenticating to the device and submitting crafted input to the CLI. The attacker must be authenticated as an administrative user to execute the affected commands. A successful exploit could allow the attacker to access the underlying operating system with root privileges. Cisco IOS XE SD-WAN Is vulnerable to input validation.Information is obtained, information is tampered with, and service is disrupted (DoS) It may be put into a state. Cisco IOS XE SD-WAN Software is a software for network management (software-defined networking) applied to the Cisco IOS XE network operating system from Cisco
| VAR-202103-0779 | CVE-2021-1443 | Cisco IOS XE Command injection vulnerability |
CVSS V2: 8.5 CVSS V3: 7.2 Severity: HIGH |
A vulnerability in the web UI of Cisco IOS XE Software could allow an authenticated, remote attacker to execute arbitrary code with root privileges on the underlying operating system of an affected device. The vulnerability exists because the affected software improperly sanitizes values that are parsed from a specific configuration file. An attacker could exploit this vulnerability by tampering with a specific configuration file and then sending an API call. A successful exploit could allow the attacker to inject arbitrary code that would be executed on the underlying operating system of the affected device. To exploit this vulnerability, the attacker would need to have a privileged set of credentials to the device. Cisco IOS XE Contains a command injection vulnerability.Information is obtained, information is tampered with, and service is disrupted (DoS) It may be put into a state. Pillow is a Python-based image processing library.
There is currently no information about this vulnerability, please feel free to follow CNNVD or manufacturer announcements. Cisco IOS XE Software is an operating system of Cisco (Cisco). A single operating system for enterprise wired and wireless access, aggregation, core, and WAN, Cisco IOS XE reduces business and network complexity
| VAR-202103-0778 | CVE-2021-1442 | Cisco IOS XE Vulnerability related to information disclosure from log files |
CVSS V2: 6.9 CVSS V3: 7.8 Severity: HIGH |
A vulnerability in a diagnostic command for the Plug-and-Play (PnP) subsystem of Cisco IOS XE Software could allow an authenticated, local attacker to elevate privileges to the level of an Administrator user (level 15) on an affected device. The vulnerability is due to insufficient protection of sensitive information. An attacker with low privileges could exploit this vulnerability by issuing the diagnostic CLI show pnp profile when a specific PnP listener is enabled on the device. A successful exploit could allow the attacker to obtain a privileged authentication token. This token can be used to send crafted PnP messages and execute privileged commands on the targeted system. Cisco IOS XE Exists in a vulnerability related to information leakage from log files.Information is obtained, information is tampered with, and service is disrupted (DoS) It may be put into a state. Pillow is a Python-based image processing library.
There is currently no information about this vulnerability, please feel free to follow CNNVD or manufacturer announcements. Cisco IOS XE Software is an operating system of Cisco (Cisco). A single operating system for enterprise wired and wireless access, aggregation, core, and WAN, Cisco IOS XE reduces business and network complexity
| VAR-202103-0775 | CVE-2021-1437 | Cisco Aironet Series Access Points Software permission vulnerabilities |
CVSS V2: 5.0 CVSS V3: 7.5 Severity: HIGH |
A vulnerability in the FlexConnect Upgrade feature of Cisco Aironet Series Access Points Software could allow an unauthenticated, remote attacker to obtain confidential information from an affected device. This vulnerability is due to an unrestricted Trivial File Transfer Protocol (TFTP) configuration. An attacker could exploit this vulnerability by sending a specific TFTP request to an affected device. A successful exploit could allow the attacker to download any file from the filesystem of the affected access point (AP)
| VAR-202103-0774 | CVE-2021-1436 | Cisco IOS XE SD-WAN Traversal Vulnerability in Japan |
CVSS V2: 4.7 CVSS V3: 4.4 Severity: MEDIUM |
A vulnerability in the CLI of Cisco IOS XE SD-WAN Software could allow an authenticated, local attacker to conduct path traversal attacks and obtain read access to sensitive files on an affected system. This vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vulnerability by sending a crafted request to an affected system. A successful exploit could allow the attacker to view arbitrary files on the affected system. Cisco IOS XE SD-WAN Contains a path traversal vulnerability.Information may be obtained