-- MARKDOWN --
- [KDE Discover](#kde-discover)
- [Wormable XSS affecting multiple marketplaces](#wormable-xss-affecting-multiple-marketplaces)
- [PlingStore RCE](#plingstore-rce)
- [RCE by design](#rce-by-design)
- [Exploitation from any browser](#exploitation-from-any-browser)
- [Disclosure](#disclosure)
- [Gnome Shell Extensions XSS](#gnome-shell-extensions-xss)
- [Conclusion](#conclusion)
# KDE Discover
In the beginning of this year, we analyzed how popular desktop applications handle user supplied URIs [and found code execution vulnerabilities in several of them](https://positive.security/blog/url-open-rce). One of the applications I checked was the *KDE Discover* App Store, which did turn out to handle untrusted URIs in an insecure manner (CVE-2021-28117, [KDE Security Advisory](https://kde.org/info/security/advisory-20210310-1.txt)).
Along the way I quickly found several more severe vulnerabilities in other FOSS marketplaces.
A wormable XSS with potential for supply chain attacks on *Pling*-based marketplaces, and a drive-by RCE affecting users of the *PlingStore* application are still exploitable as of 2021-06-22.
# Wormable XSS affecting multiple marketplaces
*KDE Discover* retrieves and displays data from [https://store.kde.org](https://store.kde.org). While creating my own listing to test *Discover*'s URI handling, I stumbled upon a field that looked like XSS by design:
While a simple XSS payload did not work, it was sufficient to first add an iframe and then the malicious JavaScript payload in a separate line:
This stored XSS could be used to modify active listings, or post new listings on the *Pling* store in the context of other users, resulting in a [wormable XSS](https://en.wikipedia.org/wiki/Samy_(computer_worm)). Besides the typical XSS implications, this would allow for a supply-chain attack XSS worm using a JavaScript payload that performs the following two steps:
Interestingly, the KDE Store is only one of many stores based on the *Pling* platform, sharing not only this vulnerability, but also user accounts and session data.
The following is a **list of interconnected and vulnerable Pling-based FOSS App Stores**:
# PlingStore RCE
All *Pling*-based App Stores advertise the use of the native *PlingStore* app, an Electron application that can display the different websites and allows for easy 1-click app installation.
The XSS can also be triggered inside this Electron application and from there, can likely be escalated to RCE when combined with an Electron sandbox bypass.
However, as the application can install other applications, it has another built in mechanism to execute code on the OS level. As it turns out, that mechanism can be exploited by any website to run arbitrary native code while the *PlingStore* app is open in the background.
## RCE by design
When the *PlingStore* app is started, it also launches [*ocs-manager*](https://git.opendesktop.org/akiraohgaki/ocs-manager/), a local WebSocket server that listens to messages from the Electron app. *ocs-manager* [implements various functions](https://git.opendesktop.org/akiraohgaki/ocs-manager/blob/master/app/src/websockets/websocketserver.cpp), that can be called by the Electron app to retrieve information or trigger actions.
By combining three function calls, it's possible to execute arbitrary code:
1. Call `ItemHandler::getItem` to download an AppImage from any URL as type `bin`
2. Call `ConfigHandler::getAppConfigInstallTypes` to leak the full bin directory path (by default in the home directory, thus dependent on the username)
3. Call `SystemHandler::openUrl` with the AppImage path as argument ([implements](https://git.opendesktop.org/akiraohgaki/ocs-manager/blob/master/app/src/handlers/systemhandler.cpp#L37-42) special handling for AppImage files to execute them instead of starting them with the default application)
When the XSS is triggered inside the Electron app, the payload can establish a connection to the local WebSocket server and send messages to execute arbitrary native code (by downloading and executing a `.AppImage` file).
## Exploitation from any browser
Browsers do not implement the [Same-origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) for WebSocket connections. Therefore, it's important to validate the origin server-side or implement additional authentication over the WebSocket connection. With *ocs-manager*, this is not the case, which means that any website in any browser can initiate a connection to the WebSocket server, and *ocs-manager* will happily accept any commands sent.
**Demo video** of the exploit:
Exploitation is triggered by visiting a malicious website in any browser, while *PlingStore* is running in the background. The PoC payload downloads an AppImage file that launches *xmessage* with a custom string as argument to demonstrate arbitrary code execution.
## Disclosure
Unfortunately, I could not to reach anyone at *Pling/OpenDesktop/hive01 GmbH* via any of the contact addresses and communication methods (e.g. via phone or a forum post) that I have tried. As I could neither get any acknowledgement of the vulnerabilities nor a commitment to fix them, I'll now publicly disclose this information to warn users of those vulnerabilities specifically and the maintenance state of the platform in general (I'm leaving out another vulnerability in this post that I've reported but does not directly affect users).
**Timeline:**
2021-02-24: Initial disclosure via mail to [contact@opendesktop.org](mailto:contact@opendesktop.org)
2021-02-26: Created a [forum post](https://forum.opendesktop.org/t/where-to-report-vulnerabilities-in-the-pling-opendesktop-platform/19555) (now locked), tried calling the owning company/their CEO and sent a mail to @goerke-partner.com
2021-03-03: Follow-up mail
2021-03-03: Disclosure of the issues to [security@kde.org](mailto:security@kde.org) and received an immediate response
2021-03-08: Patch for *KDE Discover* issue created, forwarded other issue information to a contact at the Pling team
2021-03-10: *KDE Discover* patch and [advisory published](https://kde.org/info/security/advisory-20210310-1.txt)
2021-03-16: *Pling* follow-up mail
2021-04-12: *Pling* follow-up mail and contact attempt via [their chat](https://chat.opendesktop.org/#/room/#opendesktop:chat.opendesktop.org)
2021-04-28: Received a *Pling* team member contact by the KDE Discover team
2021-04-28: Mail to new contact, mentioning disclosure in case we can't reach anyone from the team
2021-05-27: Follow-up to new contact
2021-06-18: Announced upcoming public disclosure to all previous contacts
2021-06-22: Public disclosure
# Gnome Shell Extensions XSS
As a Gnome user, I was aware of another marketplace not connected to the Plingiverse, [https://extensions.gnome.org](https://extensions.gnome.org). This extension store also offers native integration, via browser extensions ([Chrome](https://chrome.google.com/webstore/detail/gnome-shell-integration/gphhapmejobijbbhgpjhcjognlahblep?hl=de) and [Firefox](https://addons.mozilla.org/en-US/firefox/addon/gnome-shell-integration/)) and a native "connector" application. This time, the origin is validated to prevent other websites from communicating with the native connector.
-- /MARKDOWN --
-- CODE language-js --
chrome.runtime.onMessageExternal.addListener(function (request, sender, sendResponse) {
if (sender.url.startsWith(EXTENSIONS_WEBSITE)) // EXTENSIONS_WEBSITE = "https://extensions.gnome.org/"
}
-- MARKDOWN --
With an XSS on [*https://extensions.gnome.org*](https://extensions.gnome.org/) however, this check could be passed to e.g. gather information, enable extensions or trigger the installation of new extensions.
It didn't take long to find a basic XSS by specifying a *javascript:* URI as the "Extension Homepage" (requiring a click):
In contrast to the *Pling*-based AppStores, Gnome Extension submissions are reviewed. While this may lead to an increase in quality and might catch malicious extensions, it also means that a logged-in reviewer (probably with high privileges) will definitely take a look at the review page with the malicious payload. In addition to that, the review page itself is public immediately after submission and the link can be sent to other potential victims.
Similar to the the *Pling* XSS, this could be used to hijack user/reviewer accounts for a supply chain attack (backdooring published extensions), or to directly attack the victim's computer by issuing commands to the *Gnome Shell Integration* browser extension.
The issue was reported via the [Gnome Security Page](https://security.gnome.org/) on 2021-02-24 and fixed within 24h.
# Conclusion
App Marketplaces are at the intersection of two worlds:
1. user-provided content, mostly presented to the user with web technology
2. managing and installing native applications
While #1 is usually considered highly untrusted and heavily sandboxed, App Store integrations create a bridge to #2, an area that requires a high level of trust.
In this blog post, we've shown multiple vulnerabilities that demonstrate the additional risk associated with such marketplaces. In this environment, even relatively small vulnerabilities (e.g. a missing origin check) can lead to severe consequences (drive-by RCE from any browser with the vulnerable application running in background). Developers of such applications must put in a high level of scrutiny to ensure their security.
**For users of any of the mentioned Pling-based marketplaces, we recommend the following:**
- Do not run the *PlingStore* Electron application (best, remove the AppImage) until the RCE is fixed
- Be aware that any listing on *appimagehub.com/store.kde.org/gnome-look.org/xfce-look.org/pling.com* could hijack your account on the platform via XSS and any of the downloadable assets might be compromised (best, log out of your account and do not use the websites until the issues have been fixed)
