USN-5705-1: LibTIFF vulnerabilities

Read Time:25 Second

Chintan Shah discovered that LibTIFF incorrectly handled memory in
certain conditions. An attacker could trick a user into processing a specially
crafted image file and potentially use this issue to allow for information
disclosure or to cause the application to crash. (CVE-2022-3570)

It was discovered that LibTIFF incorrectly handled memory in certain
conditions. An attacker could trick a user into processing a specially
crafted tiff file and potentially use this issue to cause a denial of service.
(CVE-2022-3598)

Read More

USN-5706-1: Linux kernel (Azure CVM) vulnerabilities

Read Time:2 Minute, 9 Second

It was discovered that the BPF verifier in the Linux kernel did not
properly handle internal data structures. A local attacker could use this
to expose sensitive information (kernel memory). (CVE-2021-4159)

It was discovered that an out-of-bounds write vulnerability existed in the
Video for Linux 2 (V4L2) implementation in the Linux kernel. A local
attacker could use this to cause a denial of service (system crash) or
possibly execute arbitrary code. (CVE-2022-20369)

Duoming Zhou discovered that race conditions existed in the timer handling
implementation of the Linux kernel’s Rose X.25 protocol layer, resulting in
use-after-free vulnerabilities. A local attacker could use this to cause a
denial of service (system crash). (CVE-2022-2318)

Roger Pau Monné discovered that the Xen virtual block driver in the Linux
kernel did not properly initialize memory pages to be used for shared
communication with the backend. A local attacker could use this to expose
sensitive information (guest kernel memory). (CVE-2022-26365)

Pawan Kumar Gupta, Alyssa Milburn, Amit Peled, Shani Rehana, Nir Shildan
and Ariel Sabba discovered that some Intel processors with Enhanced
Indirect Branch Restricted Speculation (eIBRS) did not properly handle RET
instructions after a VM exits. A local attacker could potentially use this
to expose sensitive information. (CVE-2022-26373)

Eric Biggers discovered that a use-after-free vulnerability existed in the
io_uring subsystem in the Linux kernel. A local attacker could possibly use
this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2022-3176)

Roger Pau Monné discovered that the Xen paravirtualization frontend in the
Linux kernel did not properly initialize memory pages to be used for shared
communication with the backend. A local attacker could use this to expose
sensitive information (guest kernel memory). (CVE-2022-33740)

It was discovered that the Xen paravirtualization frontend in the Linux
kernel incorrectly shared unrelated data when communicating with certain
backends. A local attacker could use this to cause a denial of service
(guest crash) or expose sensitive information (guest kernel memory).
(CVE-2022-33741, CVE-2022-33742)

Oleksandr Tyshchenko discovered that the Xen paravirtualization platform in
the Linux kernel on ARM platforms contained a race condition in certain
situations. An attacker in a guest VM could use this to cause a denial of
service in the host OS. (CVE-2022-33744)

It was discovered that the Netlink Transformation (XFRM) subsystem in the
Linux kernel contained a reference counting error. A local attacker could
use this to cause a denial of service (system crash). (CVE-2022-36879)

Read More

BrandPost: 10 Best Practices for a Zero Trust Data Center

Read Time:48 Second

Today, there is no such thing as an enterprise network perimeter — the location of applications, users, and their devices are no longer static; BYOD is common; and data is everywhere. With ever-evolving cybersecurity threats and no fixed perimeter, traditional security strategies fail to protect highly distributed networks, users, and applications. Organizations need an innovative approach that is not only simple and promising, but also proven and sustainable. That is why Zero Trust is getting so much attention.

What is Zero Trust and why do we need it?

Zero Trust is an enterprise security framework based on the principle “never trust; always verify.” In other words, this approach does not trust any user, application, or device unless explicitly allowed by a security policy. By adopting the concepts and architectural components of Zero Trust, organizations can improve visibility and better secure their hybrid environments while meeting compliance requirements and reducing costs over time.

To read this article in full, please click here

Read More

BrandPost: Top 5 Regulatory Reasons for Implementing Zero Trust

Read Time:36 Second

We are beyond the point of viewing Zero Trust as a simple marketing feature for information technology or cybersecurity companies. It is a floor for any technology vendor who wants to provide high-value solutions to government or commercial customers.

Before getting into the details, let’s first settle on what we mean by Zero Trust. In 2017, Forrester’s Stephanie Balaouras provided what has become a common definition within the industry:

“A conceptual and architectural model for how security teams should redesign networks into secure microperimeters, increase data security through obfuscation techniques, limit the risks associated with excessive user privileges, and dramatically improve security detection and response through analytics and automation.”

To read this article in full, please click here

Read More

How Cisco’s Cloud Control Framework helps it comply with multiple security standards

Read Time:45 Second

An XKCD comic strip shows two tech workers frustrated that there are 14 competing standards for a variety of use cases. “We need to develop one unified standard that covers everyone’s use cases,” they say. The next frame shows that there are now 15 standards instead of one.

Brad Arkin, the chief security and trust officer at Cisco, will tell you that this illustration of how standards proliferate hits uncomfortably close to the truth. “Everybody is trying to come up with their own set of security controls that they would like to see SaaS applications adhere to,” Arkin says. Such commendable goals notwithstanding, enthusiasm for being the defining standard for SaaS security compliance instead creates a confusing jungle of competing ones: ISO 27001, SOC, CS in Germany, IRAP in Australia, and ISMAP in Japan, to name just a few.

To read this article in full, please click here

Read More