USN-6348-1: Linux kernel vulnerabilities

Read Time:2 Minute, 28 Second

Daniel Moghimi discovered that some Intel(R) Processors did not properly
clear microarchitectural state after speculative execution of various
instructions. A local unprivileged user could use this to obtain to
sensitive information. (CVE-2022-40982)

Tavis Ormandy discovered that some AMD processors did not properly handle
speculative execution of certain vector register instructions. A local
attacker could use this to expose sensitive information. (CVE-2023-20593)

Ye Zhang and Nicolas Wu discovered that the io_uring subsystem in the Linux
kernel did not properly handle locking for rings with IOPOLL, leading to a
double-free vulnerability. A local attacker could use this to cause a
denial of service (system crash) or possibly execute arbitrary code.
(CVE-2023-21400)

It was discovered that the universal 32bit network packet classifier
implementation in the Linux kernel did not properly perform reference
counting in some situations, leading to a use-after-free vulnerability. A
local attacker could use this to cause a denial of service (system crash)
or possibly execute arbitrary code. (CVE-2023-3609)

It was discovered that the netfilter subsystem in the Linux kernel did not
properly handle certain error conditions, leading to a use-after-free
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-3610)

It was discovered that the Quick Fair Queueing network scheduler
implementation in the Linux kernel contained an out-of-bounds write
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-3611)

It was discovered that the network packet classifier with
netfilter/firewall marks implementation in the Linux kernel did not
properly handle reference counting, leading to a use-after-free
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-3776)

Kevin Rich discovered that the netfilter subsystem in the Linux kernel did
not properly handle table rules flush in certain circumstances. A local
attacker could possibly use this to cause a denial of service (system
crash) or execute arbitrary code. (CVE-2023-3777)

Kevin Rich discovered that the netfilter subsystem in the Linux kernel did
not properly handle rule additions to bound chains in certain
circumstances. A local attacker could possibly use this to cause a denial
of service (system crash) or execute arbitrary code. (CVE-2023-3995)

It was discovered that the netfilter subsystem in the Linux kernel did not
properly handle PIPAPO element removal, leading to a use-after-free
vulnerability. A local attacker could possibly use this to cause a denial
of service (system crash) or execute arbitrary code. (CVE-2023-4004)

Kevin Rich discovered that the netfilter subsystem in the Linux kernel did
not properly handle bound chain deactivation in certain circumstances. A
local attacker could possibly use this to cause a denial of service (system
crash) or execute arbitrary code. (CVE-2023-4015)

Read More

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

Read Time:5 Minute, 38 Second

William Zhao discovered that the Traffic Control (TC) subsystem in the
Linux kernel did not properly handle network packet retransmission in
certain situations. A local attacker could use this to cause a denial of
service (kernel deadlock). (CVE-2022-4269)

It was discovered that the NTFS file system implementation in the Linux
kernel did not properly check buffer indexes in certain situations, leading
to an out-of-bounds read vulnerability. A local attacker could possibly use
this to expose sensitive information (kernel memory). (CVE-2022-48502)

Seth Jenkins discovered that the Linux kernel did not properly perform
address randomization for a per-cpu memory management structure. A local
attacker could use this to expose sensitive information (kernel memory) or
in conjunction with another kernel vulnerability. (CVE-2023-0597)

It was discovered that a race condition existed in the btrfs file system
implementation in the Linux kernel, leading to a use-after-free
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly expose sensitive information. (CVE-2023-1611)

It was discovered that the APM X-Gene SoC hardware monitoring driver in the
Linux kernel contained a race condition, leading to a use-after-free
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or expose sensitive information (kernel memory).
(CVE-2023-1855)

It was discovered that the ST NCI NFC driver did not properly handle device
removal events. A physically proximate attacker could use this to cause a
denial of service (system crash). (CVE-2023-1990)

Ruihan Li discovered that the bluetooth subsystem in the Linux kernel did
not properly perform permissions checks when handling HCI sockets. A
physically proximate attacker could use this to cause a denial of service
(bluetooth communication). (CVE-2023-2002)

It was discovered that the XFS file system implementation in the Linux
kernel did not properly perform metadata validation when mounting certain
images. An attacker could use this to specially craft a file system image
that, when mounted, could cause a denial of service (system crash).
(CVE-2023-2124)

Juan Jose Lopez Jaimez, Meador Inge, Simon Scannell, and Nenad Stojanovski
discovered that the BPF verifier in the Linux kernel did not properly mark
registers for precision tracking in certain situations, leading to an out-
of-bounds access vulnerability. A local attacker could use this to cause a
denial of service (system crash) or possibly execute arbitrary code.
(CVE-2023-2163)

It was discovered that the SLIMpro I2C device driver in the Linux kernel
did not properly validate user-supplied data in some situations, leading to
an out-of-bounds write vulnerability. A privileged attacker could use this
to cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2023-2194)

It was discovered that the perf subsystem in the Linux kernel contained a
use-after-free vulnerability. A privileged local attacker could possibly
use this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2023-2235)

Zheng Zhang discovered that the device-mapper implementation in the Linux
kernel did not properly handle locking during table_clear() operations. A
local attacker could use this to cause a denial of service (kernel
deadlock). (CVE-2023-2269)

It was discovered that the ARM Mali Display Processor driver implementation
in the Linux kernel did not properly handle certain error conditions. A
local attacker could possibly use this to cause a denial of service (system
crash). (CVE-2023-23004)

It was discovered that a race condition existed in the TLS subsystem in the
Linux kernel, leading to a use-after-free or a null pointer dereference
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-28466)

It was discovered that the DA9150 charger driver in the Linux kernel did
not properly handle device removal, leading to a user-after free
vulnerability. A physically proximate attacker could use this to cause a
denial of service (system crash) or possibly execute arbitrary code.
(CVE-2023-30772)

It was discovered that the Ricoh R5C592 MemoryStick card reader driver in
the Linux kernel contained a race condition during module unload, leading
to a use-after-free vulnerability. A local attacker could use this to cause
a denial of service (system crash) or possibly execute arbitrary code.
(CVE-2023-3141)

Quentin Minster discovered that the KSMBD implementation in the Linux
kernel did not properly validate pointers in some situations, leading to a
null pointer dereference vulnerability. A remote attacker could use this to
cause a denial of service (system crash). (CVE-2023-32248)

It was discovered that the kernel->user space relay implementation in the
Linux kernel did not properly perform certain buffer calculations, leading
to an out-of-bounds read vulnerability. A local attacker could use this to
cause a denial of service (system crash) or expose sensitive information
(kernel memory). (CVE-2023-3268)

It was discovered that the Qualcomm EMAC ethernet driver in the Linux
kernel did not properly handle device removal, leading to a user-after free
vulnerability. A physically proximate attacker could use this to cause a
denial of service (system crash) or possibly execute arbitrary code.
(CVE-2023-33203)

It was discovered that the BQ24190 charger driver in the Linux kernel did
not properly handle device removal, leading to a user-after free
vulnerability. A physically proximate attacker could use this to cause a
denial of service (system crash) or possibly execute arbitrary code.
(CVE-2023-33288)

It was discovered that the video4linux driver for Philips based TV cards in
the Linux kernel contained a race condition during device removal, leading
to a use-after-free vulnerability. A physically proximate attacker could
use this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2023-35823)

It was discovered that the SDMC DM1105 PCI device driver in the Linux
kernel contained a race condition during device removal, leading to a use-
after-free vulnerability. A physically proximate attacker could use this to
cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2023-35824)

It was discovered that the Renesas USB controller driver in the Linux
kernel contained a race condition during device removal, leading to a use-
after-free vulnerability. A privileged attacker could use this to cause a
denial of service (system crash) or possibly execute arbitrary code.
(CVE-2023-35828)

It was discovered that the Rockchip Video Decoder IP driver in the Linux
kernel contained a race condition during device removal, leading to a use-
after-free vulnerability. A privileged attacker could use this to cause a
denial of service (system crash) or possibly execute arbitrary code.
(CVE-2023-35829)

Read More

CVE-2021-35980

Read Time:19 Second

Acrobat Reader DC versions 2021.005.20054 (and earlier), 2020.004.30005 (and earlier) and 2017.011.30197 (and earlier) are affected by a Path traversal vulnerability. An unauthenticated attacker could leverage this vulnerability to achieve arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Read More

CVE-2021-28644

Read Time:19 Second

Acrobat Reader DC versions 2021.005.20054 (and earlier), 2020.004.30005 (and earlier) and 2017.011.30197 (and earlier) are affected by a Path traversal vulnerability. An unauthenticated attacker could leverage this vulnerability to achieve arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Read More

CVE-2021-21088

Read Time:19 Second

Acrobat Reader DC versions versions 2020.013.20074 (and earlier), 2020.001.30018 (and earlier) and 2017.011.30188 (and earlier) are affected by a Use After Free vulnerability. An unauthenticated attacker could leverage this vulnerability to achieve arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Read More

USN-6346-1: Linux kernel (Raspberry Pi) vulnerabilities

Read Time:1 Minute, 5 Second

Daniel Moghimi discovered that some Intel(R) Processors did not properly
clear microarchitectural state after speculative execution of various
instructions. A local unprivileged user could use this to obtain to
sensitive information. (CVE-2022-40982)

Tavis Ormandy discovered that some AMD processors did not properly handle
speculative execution of certain vector register instructions. A local
attacker could use this to expose sensitive information. (CVE-2023-20593)

It was discovered that the universal 32bit network packet classifier
implementation in the Linux kernel did not properly perform reference
counting in some situations, leading to a use-after-free vulnerability. A
local attacker could use this to cause a denial of service (system crash)
or possibly execute arbitrary code. (CVE-2023-3609)

It was discovered that the Quick Fair Queueing network scheduler
implementation in the Linux kernel contained an out-of-bounds write
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-3611)

It was discovered that the network packet classifier with
netfilter/firewall marks implementation in the Linux kernel did not
properly handle reference counting, leading to a use-after-free
vulnerability. A local attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2023-3776)

Read More

The Future of Work: How Technology & the WFH Landscape Are Making an Impact

Read Time:4 Minute, 47 Second

As of the writing of this article, the height of the pandemic seems like a distant but still vivid dream. Sanitizing packages, sparse grocery shelves, and video conferencing happy hours are things of the past for the majority of the population. Thank goodness.

A “new normal” society is adapting to today’s working culture. The work landscape changed significantly since 2020, and it might never return to what it once was. In 2022, workers spent an average 3.5 days in the office per week, which is 30% below the prepandemic in-office average.1

The work-from-home movement is likely here to stay, to the joy of employees seeking a better work-life balance and flexibility; however, some responsibility does fall upon people like you to secure home offices to protect sensitive company information.

To make sure you’re not the weak cyber link in your company’s security, make sure to follow these three tips for a secure home office.

1. Lock Your Screen, Stow Your Device

When you’re not physically in front of your work computer, best practices dictate that you lock the screen or put your device to sleep. No matter how much you trust your family, roommates, or the trustworthy-looking person seated next to you at a café, your company device houses all kinds of corporate secrets. A stray glance from the wrong person could put that information’s secrecy in jeopardy. Plus, imagine your cat walking across your keyboard or a toddler mashing your mouse, deleting hours’ worth of work. Disastrous.

Then, when you’re done with work for the day, stow your device in a secure location, preferably a drawer with a lock. Even if your work computer is 10 times faster and sleeker than your personal laptop, keep each device in its designated sphere in your life: work devices only for work, personal devices only for personal activities.

2. Secure Your Home Wi-Fi

Wi-Fi networks that are not password protected invite anyone off the street to surf on your network and eavesdrop on your online activities. A stranger sneaking on to your home Wi-Fi could be dangerous to your workplace. There would be very little stopping a stranger from spying on your connected work devices and spreading confidential information onto the dark web or leaking company secrets to the media.

There are a few steps you can take to secure your home office’s internet connection. First, make sure to change the default name and password of your router. Follow password best practices to create a strong first defense. For your router name, choose an obscure inside joke or a random pairing of nouns and adjectives. It’s best to omit your address and your real name as the name of your router, because that could alert a cybercriminal that that network belongs to you. Better yet, you can hide your router completely from strangers and only make it searchable to people who know the exact name of your network.

For an additional layer of protection, connect to a virtual private network (VPN). Your company may offer a corporate VPN. If not, signing up for your own VPN is easy. A VPN encrypts the traffic coming in and going out of your devices making it nearly impossible for a cybercriminal to burst into your online session and see what’s on your screen.

3. Take Your Security Training Seriously

The scenarios outlined in your company’s security training may seem far-fetched, but the concepts of those boring corporate videos actually happen! For example, the huge Colonial Pipeline breach in 2021 originated from one employee who didn’t secure the company’s VPN with multifactor authentication (MFA).2 Cutting small corners like disabling MFA – which is such a basic and easy-to-use security measure – can have dire consequences.

Pay attention to your security training and make sure to follow all company cybersecurity rules and use security tools as your IT team intends. For example, if your company requires that everyone use a password manager, a corporate VPN, and multi-factor authentication, do so! And use them correctly every workday!

Secure Home Office, Secure Home

These tips are essential to a secure home office, but they’re also applicable to when you’re off the clock. Password- or passcode-protecting your personal laptop, smartphone, and tablet keeps prying eyes out of your devices, which actually hold more personally identifiable information (PII) than you may think. Password managers, a secure router, VPNs, and safe browsing habits will go a long way toward maintaining your online privacy.

To fill in the cracks to better protect your home devices and your PII, partner with McAfee+. McAfee+ includes a VPN, safe browsing tool, identity monitoring and remediation services, a password manager, and more for a more secure digital life.

In one global survey, 68% of people prefer hybrid work models, and nearly three-quarters of companies allow employees to work from home some of the time.3,4 The flexibility afforded by hybrid work and 100% work-from-home policies is amazing. Cutting out the time and cost of commuting five days a week is another bonus. Let’s make at-home work a lasting and secure way of professional life!

1McKinsey Global Institute, “How hybrid work has changed the way people work, live, and shop

2The Hacker News, “Hackers Breached Colonial Pipeline Using Compromised VPN Password

3World Economic Forum, “Hybrid working: Why there’s a widening gap between leaders and employees

4International Foundation of Employee Benefit Plans, “Employee Benefits Survey: 2022 Results

 

The post The Future of Work: How Technology & the WFH Landscape Are Making an Impact appeared first on McAfee Blog.

Read More