chromium-127.0.6533.72-1.fc39

Read Time:46 Second

FEDORA-2024-f2e57b108e

Packages in this update:

chromium-127.0.6533.72-1.fc39

Update description:

update to 127.0.6533.72

* CVE-2024-6988: Use after free in Downloads
* CVE-2024-6989: Use after free in Loader
* CVE-2024-6991: Use after free in Dawn
* CVE-2024-6992: Out of bounds memory access in ANGLE
* CVE-2024-6993: Inappropriate implementation in Canvas
* CVE-2024-6994: Heap buffer overflow in Layout
* CVE-2024-6995: Inappropriate implementation in Fullscreen
* CVE-2024-6996: Race in Frames
* CVE-2024-6997: Use after free in Tabs
* CVE-2024-6998: Use after free in User Education
* CVE-2024-6999: Inappropriate implementation in FedCM
* CVE-2024-7000: Use after free in CSS. Reported by Anonymous
* CVE-2024-7001: Inappropriate implementation in HTML
* CVE-2024-7003: Inappropriate implementation in FedCM
* CVE-2024-7004: Insufficient validation of untrusted input in Safe Browsing
* CVE-2024-7005: Insufficient validation of untrusted input in Safe

Read More

chromium-127.0.6533.72-1.el8

Read Time:47 Second

FEDORA-EPEL-2024-08de4453df

Packages in this update:

chromium-127.0.6533.72-1.el8

Update description:

update to 127.0.6533.72

* CVE-2024-6988: Use after free in Downloads
* CVE-2024-6989: Use after free in Loader
* CVE-2024-6991: Use after free in Dawn
* CVE-2024-6992: Out of bounds memory access in ANGLE
* CVE-2024-6993: Inappropriate implementation in Canvas
* CVE-2024-6994: Heap buffer overflow in Layout
* CVE-2024-6995: Inappropriate implementation in Fullscreen
* CVE-2024-6996: Race in Frames
* CVE-2024-6997: Use after free in Tabs
* CVE-2024-6998: Use after free in User Education
* CVE-2024-6999: Inappropriate implementation in FedCM
* CVE-2024-7000: Use after free in CSS. Reported by Anonymous
* CVE-2024-7001: Inappropriate implementation in HTML
* CVE-2024-7003: Inappropriate implementation in FedCM
* CVE-2024-7004: Insufficient validation of untrusted input in Safe Browsing
* CVE-2024-7005: Insufficient validation of untrusted input in Safe

Read More

chromium-127.0.6533.72-1.fc40

Read Time:46 Second

FEDORA-2024-1b52220975

Packages in this update:

chromium-127.0.6533.72-1.fc40

Update description:

update to 127.0.6533.72

* CVE-2024-6988: Use after free in Downloads
* CVE-2024-6989: Use after free in Loader
* CVE-2024-6991: Use after free in Dawn
* CVE-2024-6992: Out of bounds memory access in ANGLE
* CVE-2024-6993: Inappropriate implementation in Canvas
* CVE-2024-6994: Heap buffer overflow in Layout
* CVE-2024-6995: Inappropriate implementation in Fullscreen
* CVE-2024-6996: Race in Frames
* CVE-2024-6997: Use after free in Tabs
* CVE-2024-6998: Use after free in User Education
* CVE-2024-6999: Inappropriate implementation in FedCM
* CVE-2024-7000: Use after free in CSS. Reported by Anonymous
* CVE-2024-7001: Inappropriate implementation in HTML
* CVE-2024-7003: Inappropriate implementation in FedCM
* CVE-2024-7004: Insufficient validation of untrusted input in Safe Browsing
* CVE-2024-7005: Insufficient validation of untrusted input in Safe

Read More

Providing Security Updates to Automobile Software

Read Time:2 Minute, 6 Second

Auto manufacturers are just starting to realize the problems of supporting the software in older models:

Today’s phones are able to receive updates six to eight years after their purchase date. Samsung and Google provide Android OS updates and security updates for seven years. Apple halts servicing products seven years after they stop selling them.

That might not cut it in the auto world, where the average age of cars on US roads is only going up. A recent report found that cars and trucks just reached a new record average age of 12.6 years, up two months from 2023. That means the car software hitting the road today needs to work­—and maybe even improve—­beyond 2036. The average length of smartphone ownership is just 2.8 years.

I wrote about this in 2018, in Click Here to Kill Everything, talking about patching as a security mechanism:

This won’t work with more durable goods. We might buy a new DVR every 5 or 10 years, and a refrigerator every 25 years. We drive a car we buy today for a decade, sell it to someone else who drives it for another decade, and that person sells it to someone who ships it to a Third World country, where it’s resold yet again and driven for yet another decade or two. Go try to boot up a 1978 Commodore PET computer, or try to run that year’s VisiCalc, and see what happens; we simply don’t know how to maintain 40-year-old [consumer] software.

Consider a car company. It might sell a dozen different types of cars with a dozen different software builds each year. Even assuming that the software gets updated only every two years and the company supports the cars for only two decades, the company needs to maintain the capability to update 20 to 30 different software versions. (For a company like Bosch that supplies automotive parts for many different manufacturers, the number would be more like 200.) The expense and warehouse size for the test vehicles and associated equipment would be enormous. Alternatively, imagine if car companies announced that they would no longer support vehicles older than five, or ten, years. There would be serious environmental consequences.

We really don’t have a good solution here. Agile updates is how we maintain security in a world where new vulnerabilities arise all the time, and we don’t have the economic incentive to secure things properly from the start.

Read More

USN-6923-2: Linux kernel vulnerabilities

Read Time:34 Second

Benedict Schlüter, Supraja Sridhara, Andrin Bertschi, and Shweta Shinde
discovered that an untrusted hypervisor could inject malicious #VC
interrupts and compromise the security guarantees of AMD SEV-SNP. This flaw
is known as WeSee. A local attacker in control of the hypervisor could use
this to expose sensitive information or possibly execute arbitrary code in
the trusted execution environment. (CVE-2024-25742)

Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
– TTY drivers;
– SMB network file system;
– Netfilter;
– Bluetooth subsystem;
(CVE-2024-26886, CVE-2023-52752, CVE-2024-36016, CVE-2024-26952,
CVE-2024-27017)

Read More

USN-6921-2: Linux kernel vulnerabilities

Read Time:36 Second

Benedict Schlüter, Supraja Sridhara, Andrin Bertschi, and Shweta Shinde
discovered that an untrusted hypervisor could inject malicious #VC
interrupts and compromise the security guarantees of AMD SEV-SNP. This flaw
is known as WeSee. A local attacker in control of the hypervisor could use
this to expose sensitive information or possibly execute arbitrary code in
the trusted execution environment. (CVE-2024-25742)

Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
– DMA engine subsystem;
– HID subsystem;
– I2C subsystem;
– PHY drivers;
– TTY drivers;
– IPv4 networking;
(CVE-2024-35997, CVE-2024-36016, CVE-2024-35990, CVE-2024-35984,
CVE-2024-35992, CVE-2024-36008)

Read More

How to setup PGP Keys for Encrypted Email

Read Time:3 Minute, 35 Second

The content of this post is solely the responsibility of the author.  LevelBlue does not adopt or endorse any of the views, positions, or information provided by the author in this article. 

In today’s world, electronic mails (e-mails) serve as a medium of both official and personal correspondence. With sensitive information being shared online, it’s essential to secure your emails. Pretty Good Privacy (PGP), a robust encryption program, offers a reliable solution for securing the contents of your emails. Developed by Phil Zimmermann in 1991, PGP utilizes public-key cryptography to ensure both confidentiality and authenticity in email exchanges.

PGP uses a pair of keys consisting of a public key and a private key. The public key is like your digital address that you share with other users. Anyone with your public key can send you encrypted messages. However, they cannot read messages encrypted with your private key. The private key is like the key to your mailbox and should be kept secure. You use it to decrypt messages sent to you with your public key. To use PGP, you need a pair of keys: a public key and a private key. Here’s how to generate them:

1. Install GnuPG: First, install GnuPG, a free implementation of the OpenPGP standard. You can download it from GnuPG’s official website.

2. Generate Key Pair: Open your terminal and type the following command: gpg –full-generate-key Follow the prompts to create your key pair. Choose your preferred encryption method, key size (at least 2048 bits), and validity period.

3. Backup Your Keys: Once generated, back up your keys. Use the following commands to export them:

gpg –export -a “Your Name” > public.key

gpg –export-secret-key -a “Your Name” > private.key

Distributing Your Public Key

To receive encrypted emails, share your public key:

1. Upload to a Key Server:

gpg –send-keys your-key-id

Replace your-key-id with your actual key ID. This makes your key publicly accessible.

2. Direct sharing: Alternatively, you can send your public key file (public.key) to your contacts directly.

Encrypting and Decrypting Emails

With your key pair ready and public key shared, you can start sending and receiving encrypted emails:

Encrypting an Email:

Import the Recipient’s Public Key: First, get the recipient’s public key. Import it with this command:

gpg –import recipient-public.key

Encrypt the Message: Use the recipient’s public key to encrypt your message:

gpg –encrypt –armor –recipient recipient-email@example.com message.txt –

Replace “recipient-email@example.com” with the email address of the receiving person/entity and “message.txt” with your message file. This creates an encrypted file (usually with a .asc extension) to attach to your email.

Decrypting an Email:

Now as you have shared your public key with your target users, they will be able to send you an encrypted email using PGP(for this to work they also need to have PGP insalled). When you receive an encrypted email (typically a .asc file), decrypt it with your private key:

gpg –decrypt encrypted-message.asc

Replace “encrypted-message.asc” with the file name of the encrypted attachment. You will need to enter your private key passphrase.

Using PGP with Email Clients

While the command-line method works, it can be complicated. Thankfully, many email clients have PGP plugins to make this easier. Here are two most preferred or known:

Thunderbird with Enigmail:

Installation: Download and install Mozilla Thunderbird, a free email client. Then, install the Enigmail add-on

Configuration: Open Thunderbird, go to Enigmail settings, and import or create your PGP key pair. Enigmail integrates PGP into Thunderbird, making encryption simple.

Outlook with Gpg4win:

Installation: Download and install Gpg4win, which includes GnuPG and plugins for Outlook.

Configuration: Set up your PGP key pair in Gpg4win, then use the Outlook plugin to encrypt your emails. In addition to OpenPGP Gpg4win also supports S/MIME (X.509)

Benefits of Email Client Integrations

Ease of Use: These integrations make encryption and decryption easy within your email client.

Automatic Key Management: They handle key tasks like importing keys and managing validity of the keys.

User-Friendly Interface: The visual interface simplifies the process. For webmail services like Gmail or Yahoo Mail, browser extensions like mailvelope allows using OpenPGP for encrypting emails and ease of use.

Read More

News, Advisories and much more

Exit mobile version