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

USN-6344-1: Linux kernel (Azure) vulnerabilities

Read Time:1 Minute, 48 Second

Zi Fan Tan discovered that the binder IPC implementation in the Linux
kernel contained 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-21255)

It was discovered that a race condition existed in the f2fs file system in
the Linux kernel, leading to a null pointer dereference vulnerability. An
attacker could use this to construct a malicious f2fs image that, when
mounted and operated on, could cause a denial of service (system crash).
(CVE-2023-2898)

It was discovered that the DVB Core driver in the Linux kernel did not
properly handle locking events in certain situations. A local attacker
could use this to cause a denial of service (kernel deadlock).
(CVE-2023-31084)

Quentin Minster discovered that the KSMBD implementation in the Linux
kernel did not properly handle session setup requests. A remote attacker
could possibly use this to cause a denial of service (memory exhaustion).
(CVE-2023-32247)

Quentin Minster discovered that a race condition existed in the KSMBD
implementation in the Linux kernel when handling sessions operations. A
remote attacker could use this to cause a denial of service (system crash)
or possibly execute arbitrary code. (CVE-2023-32250, CVE-2023-32252,
CVE-2023-32257)

It was discovered that a race condition existed in the KSMBD implementation
in the Linux kernel when handling session connections, leading to a use-
after-free vulnerability. A remote attacker could use this to cause a
denial of service (system crash) or possibly execute arbitrary code.
(CVE-2023-32258)

It was discovered that the KSMBD implementation in the Linux kernel did not
properly validate buffer sizes in certain operations, leading to an out-of-
bounds read vulnerability. A remote attacker could use this to cause a
denial of service (system crash) or possibly expose sensitive information.
(CVE-2023-38426, CVE-2023-38428)

It was discovered that the KSMBD implementation in the Linux kernel did not
properly calculate the size of certain buffers. A remote attacker could use
this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2023-38429)

Read More

USN-6343-1: Linux kernel (OEM) vulnerabilities

Read Time:1 Minute, 39 Second

It was discovered that the IPv6 implementation in the Linux kernel
contained a high rate of hash collisions in connection lookup table. A
remote attacker could use this to cause a denial of service (excessive CPU
consumption). (CVE-2023-1206)

Ross Lagerwall discovered that the Xen netback backend driver in the Linux
kernel did not properly handle certain unusual packets from a
paravirtualized network frontend, leading to a buffer overflow. An attacker
in a guest VM could use this to cause a denial of service (host system
crash) or possibly execute arbitrary code. (CVE-2023-34319)

It was discovered that the bluetooth subsystem in the Linux kernel did not
properly handle L2CAP socket release, 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-40283)

It was discovered that some network classifier implementations in the Linux
kernel contained use-after-free vulnerabilities. A local attacker could use
this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2023-4128)

Andy Nguyen discovered that the KVM implementation for AMD processors in
the Linux kernel with Secure Encrypted Virtualization (SEV) contained a
race condition when accessing the GHCB page. A local attacker in a SEV
guest VM could possibly use this to cause a denial of service (host system
crash). (CVE-2023-4155)

It was discovered that the TUN/TAP driver in the Linux kernel did not
properly initialize socket data. A local attacker could use this to cause a
denial of service (system crash). (CVE-2023-4194)

Maxim Suhanov discovered that the exFAT file system implementation in the
Linux kernel did not properly check a file name length, leading to an out-
of-bounds write vulnerability. An attacker could use this to construct a
malicious exFAT image that, when mounted and operated on, could cause a
denial of service (system crash) or possibly execute arbitrary code.
(CVE-2023-4273)

Read More