Mobile transactions could’ve been disabled, created and signed by attackers.

Mobile transactions could’ve been disabled, created and signed by attackers.

Smartphone maker Xiaomi, the world’s number three phone maker behind Apple and Samsung, reported it has patched a high-severity flaw in its “trusted environment” used to store payment data that opened some of its handsets to attack.

Researchers at Check Point Research revealed last week in a report released at DEF CON that the Xiaomi smartphone flaw could have allowed hackers to hijack the mobile payment system and disable it or create and sign their own forged transactions.

The potential pool of victims was massive, considering one in seven of the world’s smartphones are manufactured by Xiaomi, according to Q2/22 data from Canalys. The company is the third largest vendor globally, according to Canalys.  
“We discovered a set of vulnerabilities that could allow forging of payment packages or disabling the payment system directly, from an unprivileged Android application. We were able to hack into WeChat Pay and implemented a fully worked proof of concept,” wrote Slava Makkaveev, security researcher with Check Point.

He said, the Check Point study marks the first time Xiaomi’s trusted applications have been reviewed for security issues. WeChat Pay is a mobile payment and digital wallet service developed by a firm of the same name, which is based in China. The service is used by over 300 million customers and allows Android users to make mobile payments and online transactions.

**The Flaw**

It’s unclear how long the vulnerability existed or if it was exploited by attackers in the wild. The bug, tracked as CVE-2020-14125, was patched by Xiaomi in June and has a CVSS severity rating of high.

“A denial of service vulnerability exists in some Xiaomi models of phones. The vulnerability is caused by out-of-bound read/write and can be exploited by attackers to make denial of service,” according to the NIST common vulnerability and exposure description of the bug.

While details of the bug’s impact were limited at the time Xiaomi disclosed the vulnerability in June, researchers at Check Point have outlined in its postmortem of the patched bug and the full potential impact of the flaw.

The core issue with Xiaomi phone was the mobile phones payment method and the Trusted Execution Environment (TEE) component of the phone. The TEE is the Xiaomi’s virtual enclave of the phone, responsible for processing and storing ultra-sensitive security information such fingerprints and the cryptographic keys used in signing transactions.

“Left unpatched, an attacker could steal private keys used to sign WeChat Pay control and payment packages. Worst case, an unprivileged Android app could have created and signed a fake payment package,” researchers wrote.

Two types of attacks could have been performed against handsets with the flaw according to Check Point.

*   From an unprivileged Android app: The user installs a malicious application and launches it. The app extracts the keys and sends a fake payment packet to steal the money.
*   If the attacker has the target devices in their hands: The attacker rootes the device, then downgrades the trust environment, and then runs the code to create a fake payment package without an application.

**Two Ways to Skin a TEE**

Controlling the TEE, according to Check Point, is a MediaTek chip component that needed to be present to conduct the attack. To be clear, the flaw was not in the MediaTek chip – however the bug was only executable in phones configured with the MediaTek processor.

“The Asian market,” the researchers noted, is “mainly represented by smartphones based on MediaTek chips.” Xiaomi phones that run on MediaTek chips use a TEE architecture called “Kinibi,” within which Xiaomi can embed and sign their own trusted applications.

“Usually, trusted apps of the Kinibi OS have the MCLF format” – Mobicore Loadable Format – “but Xiaomi decided to come up with one of their own.” Within their own format, however, was a flaw: an absence of version control, without which “an attacker can transfer an old version of a trusted app to the device and use it to overwrite the new app file.” The signature between versions doesn’t change, so the TEE doesn’t know the difference, and it loads the old one.

In essence the attacker could’ve turned back time, bypassing any security fixes made by Xiaomi or MediaTek in the most sensitive area of the phone.

As a case-in-point, the researchers targeted “Tencent soter,” Xiaomi’s embedded framework providing an API to third-party apps that want to integrate mobile payments. Soter is what’s responsible for verifying payments between phones and backend servers, for hundreds of millions of Android devices worldwide. The researchers performed time travel to exploit an arbitrary read vulnerability in the soter app. This allowed them to steal the private keys used to sign transactions.

The arbitrary read vulnerability is already patched, while the version control vulnerability is “being fixed.”

In addition, the researchers came up with one other trick for exploiting soter.

Using a regular, unprivileged Android application, they were able to communicate with the trusted soter app via “SoterService,” an API for managing soter keys. “In practice, our goal is to steal one of the soter private keys,” the authors wrote. However, by performing a classic heap overflow attack, they were able to “completely compromise the Tencent soter platform,” allowing much greater power to, for example, sign fake payment packages.

**Phones Remain Un-scrutinized**

Mobile payments are already receiving more scrutiny from security researchers, as services like Apple Pay and Google Pay gain popularity in the West. But the issue is even more significant for the Far East, where the market for mobile payments is already way ahead. According to data from Statista, that hemisphere was responsible for a full two-thirds of mobile payments globally in 2021 – about four billion dollars in transactions in all.

And yet, the Asian market “has still not yet been widely explored,” the researchers noted. “No one is scrutinizing trusted applications written by device vendors, such as Xiaomi, instead of by chip manufacturers, even though security management and the core of mobile payments are implemented there.”

As previously noted, Check Point asserted this was the first time Xiaomi’s trusted applications have been reviewed for security issues.

Xiaomi Phone Bug Allowed Payment Forgery

** UNSUPPORTED WHEN ASSIGNED ** An issue in the UPnP protocol in 4thline cling 2.0.0 through 2.1.2 allows remote attackers to cause a denial of service via an unchecked CALLBACK parameter in the request header.

Universal Plug and Play (UPnP), a ubiquitous protocol used by “billions of devices,” may be vulnerable to data exfiltration and reflected amplified TCP distributed denial of service (DDoS) attacks.

**Background**

On June 8, researcher Yunus Çadirci published an advisory for CallStranger, a vulnerability in the Universal Plug and Play (UPnP) protocol. UPnP is currently managed by the Open Connectivity Foundation (OCF). As its name implies, UPnP is a protocol designed to allow a variety of networked devices to universally communicate with each other without any special setup or configuration.

Because of its ubiquitous nature, UPnP is used by a wide variety of devices, including personal computers, networking equipment, video game consoles and internet of things (IoT) devices such as smart televisions. As a result, Çadirci says this particular vulnerability potentially affects “billions of devices.”

**Analysis**

CVE-2020-12695 is a server-side request forgery (SSRF)-like vulnerability in devices that utilize UPnP. The vulnerability exists due to the ability to control the Callback header value in the UPnP SUBSCRIBE function.

Source: CallStranger Technical Report

The SUBSCRIBE function is part of the UPnP standard that allows devices to monitor changes in other devices and services. For example, the PoC published on GitHub shows port 2869 for Microsoft’s Xbox One — which is used to monitor device changes on the network for features like media sharing — as vulnerable.

In order to exploit the flaw, an attacker would need to send a specially crafted HTTP SUBSCRIBE request to a vulnerable device.

An attacker could utilize this vulnerability in the following scenarios:

*   Intranet device port scanning to gather additional data from trusted assets within an organization’s LAN, bypassing organizational Data Loss Prevention (DLP) standards.
*   Send large amounts of traffic to arbitrary destinations. Targets flooded by the affected devices could crash under the increased network load, resulting in a denial of service (DoS). This is a result of UPnP attempting to establish a TCP handshake with multiple SYN packets for all Callback values in the SUBSCRIBE request.
*   Exfiltrate sensitive device data by directing callback information to arbitrary targets.

With the exception of the DoS, these scenarios provide a stealthy method for an attacker to steal data from a compromised network. This sensitive information could potentially open up an organization to further attack.

**Proof of concept**

The original proof of concept (PoC) created by Çadirci has been added to his GitHub repository.

**Solution**

Since CallStranger is a protocol-level vulnerability, OCF has made changes to the UPnP protocol specification. Therefore, manufacturers of affected devices are in the process of determining its impact. As a result, we anticipate newly affected devices will be reported and patches will be released over time for devices still receiving product support. Tenable product coverage for this vulnerability can be found in the “identifying affected systems” section below.

At the time this blog post was published, the CallStranger website listed the following operating systems, networking equipment, printers, IoT devices and applications as reportedly vulnerable.

****Operating Systems****

**Vendor/Model**

**Version**

Windows 10

10.0.18362.719

Xbox One OS

10.0.19041.2494

****Networking Equipment****

**Vendor/Model**

**Version**

ASUS

RT-N11

Broadcom ADSL

\-

Cisco Wireless Access Point

WAP150 WAP131 WAP351

D-Link

DVG-N5412SP

Huawei

HG255s (HG255sC163B03) HG532e MyBox

NEC AccessTechnica

WR8165N

Netgear

WNHDE111

Ruckus ZoneDirector

\-

TP-Link

Archer C50

ZTE

ZXV10 W300 H108N

Zyxel

AMG1202-T10B

****Printers****

**Vendor/Model**

**Version**

Canon Selphy

CP1200

Dell

B1165NFW

EPSON EP, EW, XP Series Printers

\-

Hewlett Packard Deskjet, Photsmart and Officejet ENVY

\-

Samsung

X4300

****Internet of Things****

**Vendor/Model**

**Version**

Canal Digital ADB

TNR-5720 SX

Belkin Wemo

\-

Nokia HomeMusic Media Device

\-

Panasonic

BB-HCM735 VL-MWN350

Philips

2k14MTK TV (TPL161E\_012.003.039.001)

Samsung

UE55MU7000 (T-KTMDEUC-1280.5, BT - S) MU8000

Siemens

CNE1000

Trendnet

TV-IP551W

****Applications****

**Vendor/Model**

**Version**

ASUS Media Streamer

\-

LG Smartshare Media

\-

Sony Media Go Media

\-

Stream What You Hear

\-

Ubiquiti UniFi Controller

\-

**Identifying affected systems**

A list of Tenable plugins to identify this vulnerability will appear here as they’re released. Additionally, the table below lists several Tenable plugins to help identify devices within your network that may have UPnP enabled.

**Plugin ID**

**Description**

**Product**

10829

UPnP Client Detection

Nessus

35711

Universal Plug and Play (UPnP) Protocol Detection

Nessus

8061

UPNP Traffic Detection (Client)

Nessus Network Monitor (NMM)

1948

UPNP Traffic Detection

Nessus Network Monitor (NMM)

**Get more information**

*   CallStranger Disclosure Site
*   CERT/CC CallStranger Advisory (VU#339275)
*   Proof of Concept Code released on GitHub

**_Join Tenable's Security Response Team on the Tenable Community._**

**_Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface._**

Get a free 30-day trial of Tenable.io Vulnerability Management.

CVE-2020-23622: CVE-2020-12695: CallStranger Vulnerability in Universal Plug and Play (UPnP) Puts Billions of Devices At Risk

By Deeba Ahmed
Cisco has confirmed that its security was successfully breached by Yanluowang Ransomware Gang in May 2022. Networking giant…
This is a post from HackRead.com Read the original post: Cisco Confirms Network Breach After Employee’s Google Account was Hacked

****Cisco has confirmed that its security was successfully breached by Yanluowang Ransomware Gang in May 2022.****

Networking giant Cisco Systems is the latest victim of hacking. The company confirmed that attackers used a compromised Google account of one of its employees after the Yanluowang ransomware gang added a list of files obtained from the company on their data leak site.

**Hacking Details**

On Wednesday, August 10th, 2022, Cisco Systems confirmed experiencing a cyberattack that took place on 24 May 2022. Sharing their findings, the networking equipment provider stated that the attackers obtained details of an employee’s private Google account, which contained passwords synced with Cisco’s web browser.

The attackers obtained initial access to **its VPN** after successfully compromising the Google account. The credentials were synced through the Chrome browser, where the targeted employee had also stored their Cisco credentials.

Consequently, attackers could synchronize their Google accounts using this information. On August 10th, the Yanluowang ransomware gang indirectly took responsibility for the breach by publishing files stolen in the data leak.

Yanluowang ransomware gang’s website (Image: Hackread.com)

**Investigation of the “Potential Compromise”**

Cisco Talos launched an investigation into the May hack and referred to it as a “potential compromise” in its detailed **report** published Wednesday. Cisco Talos threat research team conducted the investigation.

Forensic details confirmed the involvement of the Yanluowang threat group, which has ties with **Lapsus$** and **UNC2447** cybercrime groups. For your information, Lapsus$ was behind some of the most high-profile data breaches in recent months including **Microsoft**, **Okta**, **T-Mobile**, **Samsung**, and **Ubisoft**.

As for the Cisco breach, the researchers concluded that the attackers couldn’t deploy ransomware successfully but were indeed successful in penetrating its network and planting an array of hacking tools. The attacks, according to researchers, also scanned the company’s internal network, a common practice adopted before deploying ransomware.

**How Attackers Bypassed MFA?**

Cisco said that hackers used various techniques to bypass the multifactor authentication feature linked to the VPN client. This includes voice phishing (aka **vishing**) and MFA fatigue. In MFA fatigue, attackers send push requests in high volume to their targeted device so the user has no choice but to accept to stop the incoming notifications.

Cisco Talos threat researchers identified that Multi-factor Authentication **(MFA) spoofing attacks** were launched against their employees, which were eventually successful, and they could run the VPN software. After obtaining initial access, they enrolled various new devices for MFA and authenticated them successfully to the company’s VPN.

> Given the actor’s demonstrated proficiency in using a wide array of techniques to obtain initial access, user education is also a key part of countering MFA bypass techniques. Equally important to implementing MFA is ensuring that employees are educated on what to do and how to respond if they get errant push requests on their respective phones. It is also essential to educate employees about who to contact if such incidents do arise to help determine if the event was a technical issue or malicious.
> 
> Cisco Talos threat researchers

The attacker then accelerated to administrative privileges. Afterward, they could log in to multiple systems. This raised suspicion, and Cisco Security Incident Response Team intervened to mitigate the threat.

Further digging revealed that the ransomware gang used remote access and offensive security tools in the attack. These tools included the following:

*   **TeamViewer**
*   **LogMein** (Now GoTo)

*   **Mimikatz**
*   **Impacket**
*   **PowerSploit**
*   **Cobalt Strike**

Cisco then implemented password reset across the company networks and disclosed their findings in the report. The company has created two Clam AntiVirus signatures to prevent additional compromise.

Cisco Confirms Network Breach After Employee’s Google Account was Hacked

Keep private photos, videos, and documents away from prying eyes.

The lock screen on your smartphone is an essential barrier to anyone looking to gain access to the device: It stops people from getting at your data, your social media accounts, your banking apps, and everything else.

However, you may well want to add a second barrier to entry for anyone who gets past your lock screen—whether it’s friends or relatives who have borrowed your phone, or someone more sinister who’s managed to work out how to bypass the lock screen.

In those situations, a secure folder can protect your most important files—such as photos or documents—from prying eyes, requiring another authentication method such as a PIN code or a recognized fingerprint before it will open up.

There are options built into Android and iOS, as well as third-party apps you can turn to if you want to set up a secure folder of some sort on your smartphone.

If You’re Using an Android Phone

The good news if you’re using a midrange or premium Samsung Galaxy handset is that there’s a Secure Folder feature built in. To enable it, go to Settings and choose **Biometrics and Security**, then **Secure Folder**: You’ll be prompted to create a Samsung account or sign into an existing one, and then you’ll be able to choose your lock method. You can protect the folder with a pattern, PIN, password, or fingerprint scan.

The Secure Folder appears on the home screen by default, though you can hide it through the same **Secure Folder** menu in Settings—no one else will be able to get into that folder without the login method you’ve specified. When you’re in the Secure Folder, you can add files by tapping the **+** (plus) button.

Samsung makes its own Secure Folder app.

Samsung via David Nield

Another way to get files into your Secure Folder is from the apps they're already in. In the Samsung Gallery app, for example, you can select one or more images, tap the **More** button in the lower right corner, then pick **Move to Secure Folder**. If you need to delete your Secure Folder, go back to the **Secure Folder** menu in Settings.

Other options on Android are available, but the best one depends on what you want to protect. If you want to lock away sensitive photos and videos in Google Photos, for example, the feature is built right in: From the app, pick **Library**, **Utilities**, then **Get Started** under **Locked Folder**. Follow the instructions, which will involve entering your screen lock code.

Images and videos in the Locked Folder won’t show up in searches or on other screens, and aren’t backed up to the cloud. You can send files straight there from the Google Camera app (gallery icon top right, then **Locked Folder**) or from the photo gallery in Google Photos (select your items, tap **More**, then **Move to Locked Folder**).

Google Photos comes with a Locked Folder feature.

Google via David Nield

If none of those options cover your needs, there are plenty of third-party options available, as you would expect. For example, OneDrive for Android has a Personal Vault space that needs an extra level of authentication to access, though you’ll need to pay Microsoft for some cloud storage space if you want to save more than three files in it.

There’s also the free Norton App Lock, which takes a slightly different approach. It lets you lock away entire apps behind a passcode—not only protecting your files from unwanted access but locking away entire apps. It’s also a handy app to have around if you’re regularly lending your phone to other people and want to control which parts of the device they have access to.

If You’re Using an iPhone

The iPhone doesn’t have any kind of secure-folder functionality integrated into its iOS software, but there is a Hidden folder inside the Photos app that you can move private photos and videos to. Select any item in one of the Photos app galleries, tap on the **Share** button (the arrow pointing out of a square), and choose **Hide** to do just that.

At the time of writing, this isn’t really all that effective a protection method, because anyone can just go to **Albums** and **Hidden** to see what you’ve put there. However, with the arrival of iOS 16 (which we’re expecting in September 2022 or thereabouts), this folder will need to be unlocked with a passcode, Touch ID, or Face ID.

The iOS Notes app works in a similar way to a secure folder.

Apple via David Nield

Another option is to use the Notes app, which lets you lock individual notes with text, images, and videos inside them. First, go to Settings on iOS, then choose **Notes** and **Password** to set a password specifically for the Notes app. Once that’s done, you can lock a note and put it behind the password you’ve configured by opening the note, tapping the three dots at the top, then choosing **Lock**.

Other than that, you’re relying on a third-party app to do the job for you—and you can try OneDrive, as we mentioned in the Android section. The Personal Vault section comes with another layer of security on top, so even if someone gets into the OneDrive app, they won’t be able to access that folder in particular without extra authentication.

Folder Lock is straightforward enough, giving you a sealed-off section of your iPhone that no one else can get inside without the right credentials—you can save notes, videos, images, documents, and audio files, though some of the more advanced features require a $4 upgrade fee.

MaxVault is one of the third-party apps on iOS you can try.

MaxVault via David Nield

Best Secret Folder is perhaps even simpler to use, and gives you a password-protected place to lock away photos and videos that you don’t want anyone else to see. You get a decent number of options for organizing said photos and videos, and you can even check on failed login attempts should you suspect that someone is trying to get at your files without your permission. It’s free to try, with various paid options for removing ads and unlocking additional features.

Lastly, MaxVault is also worth a look. You can keep a wealth of data in your PIN-protected MaxVault folder, including photos, videos, documents, and passwords—and getting items into your folder only takes a couple of taps. There’s even a privacy-focused web browser included that you can make use of, and it also alerts you if someone else tries to get at your data. Some of the features require a premium upgrade, which will cost you $4 a month.

How to Create a Secure Folder on Your Phone

The Raspberry Pi-powered device can scan for phones around you. If it keeps spotting the same one, it’ll send you an alert.

Matt Edmondson, a federal agent with the Department of Homeland Security for the last 21 years, got a call for help last year. A friend working in another part of government—he won’t say which one—was worried that someone might have been tailing them when they were meeting a confidential informant who had links to a terrorist organization. If they were being followed, their source’s cover may have been blown. “It was literally a matter of life and death,” Edmondson says.

“If you’re trying to tell whether you’re being followed, there are surveillance detection routes,” Edmondson says. If you’re driving, you can change lanes on a freeway, perform a U-turn, or change your route. Each can help determine whether a car is following you. But it didn’t feel like enough, Edmondson says. “He had those skills, but he was just looking for an electronic supplement,” Edmondson explains. “He was worried about the safety of the confidential informant.”

After not finding any existing tools that could help, Edmondson, a hacker and digital forensics expert, decided to build his own anti-tracking tool. The Raspberry Pi-powered system, which can be carried around or sit in a car, scans for nearby devices and alerts you if the same phone is detected multiple times within the past 20 minutes. In theory it can alert you if a car is tailing you. Edmondson built the system using parts that cost around $200 in total, and will present the research project at the Black Hat security conference in Las Vegas this week. He’s also open-sourced its underlying code.

The anti-tracking tool is made up of a Raspberry Pi, wireless signal detectors, and a battery pack.

Photograph: Matt Edmondson

In recent years there’s been an explosion in the number of ways people can be tracked by domestic abusers, stalkers, or those in the murky world of government-backed espionage. Tracking can either be software- or hardware-based. Stalkerware and spyware that can be installed directly on people’s phones can give attackers access to all your location data, messages, photos, videos, and more, while physical trackers—such as Apple’s AirTags—have been used to track where people are in real time. (In response to criticism, Apple has added some anti-tracking tools to AirTags.)

A quick search online reveals plenty of tracking tools, which are easy to buy. “There’s so much out there to spy on people, and so little to help people who are wondering whether they're being spied on,” Edmondson says.

The homemade system works by scanning for wireless devices around it and then checking its logs to see whether they also were present within the past 20 minutes. It was designed to be used while people are on the move rather than sitting in, say, a coffee shop, where it would pick up too many false readings.

The anti-tracking tool, which can sit inside a shoebox-sized case, is made up of a few components. A Raspberry Pi 3 runs its software, a Wi-Fi card looks for nearby devices, a small waterproof case protects it, and a portable charger powers the system. A touchscreen shows the alerts the device produces. Each alert may be a sign that you are being tailed.

The device runs Kismet, which is a wireless network detector, and is able to detect smartphones and tablets around it that are looking for Wi-Fi or Bluetooth connections. The phones we use are constantly looking for wireless networks around them, including networks they’ve connected to before as well as new networks.

Edmondson says Kismet makes a record of the first time it sees a device and then the most recent time it was detected. But to make the anti-tracking system work, he had to write code in Python to create lists of what Kismet detects over time. There are lists for devices spotted in the past five to 10 minutes, 10 to 15 minutes, and 15 to 20 minutes. If a device appears twice, an alert flashes up on the screen. The system can show a phone’s MAC address, although this is not much use if it’s been randomized. It can also record the names of Wi-Fi networks that devices around it are looking for—a phone that’s trying to connect to a Wi-Fi network called Langley may give some clues about its owner. “If you have a device on you, I should see it,” he says. In an example, he showed WIRED that a device was looking for a network called SAMSUNGSMART.

To stop the system from detecting your own phone or those of other people traveling with you, it has an “ignore” list. By tapping one of the device’s onscreen buttons, it’s possible to “ignore everything that it has already seen.” Edmondson says that in the future, the device could be modified to send a text alert instead of showing them on the screen. He is also interested in adding the capability to detect tire-pressure monitoring systems that could show recurring nearby vehicles. A GPS unit could also be added so you can see where you were when you were being tracked, he says.

“It’s purely designed to try to tell you that you’re seeing something now that you were also seeing a few minutes ago,” Edmondson says. “This isn’t designed to follow people in any way, shape, or form.” The hacker says he lives near the desert, so he tested the system in his car while driving around places where nobody else was, carrying multiple phones with him that could be detected by the tool. Edmondson says he believes the tool can be effective, since even spies working for a government still carry devices.“You still have your phone in your pocket,” he says. “You still have your phone on the seat sitting next to you, or in the center console.”

Edmondson has no plans to make the device into a commercial product, but he says the design could easily be copied and reused by anyone with some technical knowledge. Many of the parts involved are easy to obtain or may be lying around the homes of people in tech communities.

Ultimately, he says, the tech community needs to take tech-enabled tracking and surveillance more seriously. “It was really kind of disheartening and depressing to look at the ratio of tools to spy on people versus tools to help you not get spied on,” he says, adding that a person close to him has been the victim of a stalker in the past. In the case of his clandestine friend in another government department, the anti-tracking device was useful. “It was really designed to help someone who came to me asking for help,” he says. Fortunately for Edmondson’s friend (and his source), they used it in the real world, and the device didn’t find anyone following them.

This Anti-Tracking Tool Checks If You’re Being Followed

TEE_Malloc in Samsung mTower through 0.3.0 allows a trusted application to achieve Excessive Memory Allocation via a large len value, as demonstrated by a Numaker-PFM-M2351 TEE kernel crash.

// SPDX-License-Identifier: BSD-2-Clause /\* \* Copyright (c) 2014, STMicroelectronics International N.V. \* All rights reserved. \* \* Redistribution and use in source and binary forms, with or without \* modification, are permitted provided that the following conditions are met: \* \* 1. Redistributions of source code must retain the above copyright notice, \* this list of conditions and the following disclaimer. \* \* 2. Redistributions in binary form must reproduce the above copyright notice, \* this list of conditions and the following disclaimer in the documentation \* and/or other materials provided with the distribution. \* \* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" \* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE \* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE \* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE \* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR \* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF \* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS \* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN \* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) \* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE \* POSSIBILITY OF SUCH DAMAGE. \*/ #include <stdlib.h\> #include <string.h\> #include <tee\_api.h\> #include <utee\_syscalls.h\> #include <user\_ta\_header.h\> #include "tee\_user\_mem.h" //#include "tee\_api\_private.h" #include "utee\_types.h" static const void \*tee\_api\_instance\_data; /\* System API - Internal Client API \*/ void \_\_utee\_from\_param(struct utee\_params \*up, uint32\_t param\_types, const TEE\_Param params\[TEE\_NUM\_PARAMS\]) { size\_t n; up->types = param\_types; for (n = 0; n < TEE\_NUM\_PARAMS; n++) { switch (TEE\_PARAM\_TYPE\_GET(param\_types, n)) { case TEE\_PARAM\_TYPE\_VALUE\_INPUT: case TEE\_PARAM\_TYPE\_VALUE\_OUTPUT: case TEE\_PARAM\_TYPE\_VALUE\_INOUT: up->vals\[n \* 2\] = params\[n\].value.a; up->vals\[n \* 2 + 1\] = params\[n\].value.b; break; case TEE\_PARAM\_TYPE\_MEMREF\_INPUT: case TEE\_PARAM\_TYPE\_MEMREF\_OUTPUT: case TEE\_PARAM\_TYPE\_MEMREF\_INOUT: up->vals\[n \* 2\] = (uintptr\_t)params\[n\].memref.buffer; up->vals\[n \* 2 + 1\] = params\[n\].memref.size; break; default: up->vals\[n \* 2\] = 0; up->vals\[n \* 2 + 1\] = 0; break; } } } void \_\_utee\_to\_param(TEE\_Param params\[TEE\_NUM\_PARAMS\], uint32\_t \*param\_types, const struct utee\_params \*up) { size\_t n; uint32\_t types = up->types; for (n = 0; n < TEE\_NUM\_PARAMS; n++) { uintptr\_t a = up->vals\[n \* 2\]; uintptr\_t b = up->vals\[n \* 2 + 1\]; switch (TEE\_PARAM\_TYPE\_GET(types, n)) { case TEE\_PARAM\_TYPE\_VALUE\_INPUT: case TEE\_PARAM\_TYPE\_VALUE\_OUTPUT: case TEE\_PARAM\_TYPE\_VALUE\_INOUT: params\[n\].value.a = a; params\[n\].value.b = b; break; case TEE\_PARAM\_TYPE\_MEMREF\_INPUT: case TEE\_PARAM\_TYPE\_MEMREF\_OUTPUT: case TEE\_PARAM\_TYPE\_MEMREF\_INOUT: params\[n\].memref.buffer = (void \*)a; params\[n\].memref.size = b; break; default: break; } } if (param\_types) \*param\_types = types; } TEE\_Result TEE\_OpenTASession(const TEE\_UUID \*destination, uint32\_t cancellationRequestTimeout, uint32\_t paramTypes, TEE\_Param params\[TEE\_NUM\_PARAMS\], TEE\_TASessionHandle \*session, uint32\_t \*returnOrigin) { TEE\_Result res; struct utee\_params up; uint32\_t s; \_\_utee\_from\_param(&up, paramTypes, params); res = utee\_open\_ta\_session(destination, cancellationRequestTimeout, &up, &s, returnOrigin); \_\_utee\_to\_param(params, NULL, &up); /\* \* Specification says that \*session must hold TEE\_HANDLE\_NULL is \* TEE\_SUCCESS isn't returned. Set it here explicitly in case \* the syscall fails before out parameters has been updated. \*/ if (res != TEE\_SUCCESS) s = TEE\_HANDLE\_NULL; \*session = (TEE\_TASessionHandle)(uintptr\_t)s; return res; } void TEE\_CloseTASession(TEE\_TASessionHandle session) { if (session != TEE\_HANDLE\_NULL) { TEE\_Result res = utee\_close\_ta\_session((uintptr\_t)session); if (res != TEE\_SUCCESS) TEE\_Panic(res); } } TEE\_Result TEE\_InvokeTACommand(TEE\_TASessionHandle session, uint32\_t cancellationRequestTimeout, uint32\_t commandID, uint32\_t paramTypes, TEE\_Param params\[TEE\_NUM\_PARAMS\], uint32\_t \*returnOrigin) { TEE\_Result res; uint32\_t ret\_origin; struct utee\_params up; \_\_utee\_from\_param(&up, paramTypes, params); res = utee\_invoke\_ta\_command((uintptr\_t)session, cancellationRequestTimeout, commandID, &up, &ret\_origin); \_\_utee\_to\_param(params, NULL, &up); if (returnOrigin != NULL) \*returnOrigin = ret\_origin; if (ret\_origin == TEE\_ORIGIN\_TRUSTED\_APP) return res; if (res != TEE\_SUCCESS && res != TEE\_ERROR\_OUT\_OF\_MEMORY && res != TEE\_ERROR\_TARGET\_DEAD) TEE\_Panic(res); return res; } /\* System API - Cancellations \*/ bool TEE\_GetCancellationFlag(void) { uint32\_t c; TEE\_Result res = utee\_get\_cancellation\_flag(&c); if (res != TEE\_SUCCESS) c = 0; return !!c; } bool TEE\_UnmaskCancellation(void) { uint32\_t old\_mask; TEE\_Result res = utee\_unmask\_cancellation(&old\_mask); if (res != TEE\_SUCCESS) TEE\_Panic(res); return !!old\_mask; } bool TEE\_MaskCancellation(void) { uint32\_t old\_mask; TEE\_Result res = utee\_mask\_cancellation(&old\_mask); if (res != TEE\_SUCCESS) TEE\_Panic(res); return !!old\_mask; } /\* System API - Memory Management \*/ TEE\_Result TEE\_CheckMemoryAccessRights(uint32\_t accessFlags, void \*buffer, uint32\_t size) { TEE\_Result res; if (size == 0) return TEE\_SUCCESS; /\* Check access rights against memory mapping \*/ res = utee\_check\_access\_rights(accessFlags, buffer, size); if (res != TEE\_SUCCESS) goto out; /\* \* Check access rights against input parameters \* Previous legacy code was removed and will need to be restored \*/ res = TEE\_SUCCESS; out: return res; } void TEE\_SetInstanceData(const void \*instanceData) { tee\_api\_instance\_data = instanceData; } const void \*TEE\_GetInstanceData(void) { return tee\_api\_instance\_data; } void \*TEE\_MemMove(void \*dest, const void \*src, uint32\_t size) { return memmove(dest, src, size); } int32\_t TEE\_MemCompare(const void \*buffer1, const void \*buffer2, uint32\_t size) { return memcmp(buffer1, buffer2, size); } void \*TEE\_MemFill(void \*buff, uint32\_t x, uint32\_t size) { return memset(buff, x, size); } /\* Date & Time API \*/ void TEE\_GetSystemTime(TEE\_Time \*time) { TEE\_Result res = utee\_get\_time(UTEE\_TIME\_CAT\_SYSTEM, time); if (res != TEE\_SUCCESS) TEE\_Panic(res); } TEE\_Result TEE\_Wait(uint32\_t timeout) { TEE\_Result res = utee\_wait(timeout); if (res != TEE\_SUCCESS && res != TEE\_ERROR\_CANCEL) TEE\_Panic(res); return res; } TEE\_Result TEE\_GetTAPersistentTime(TEE\_Time \*time) { TEE\_Result res; res = utee\_get\_time(UTEE\_TIME\_CAT\_TA\_PERSISTENT, time); if (res != TEE\_SUCCESS && res != TEE\_ERROR\_OVERFLOW) { time\->seconds = 0; time\->millis = 0; } if (res != TEE\_SUCCESS && res != TEE\_ERROR\_TIME\_NOT\_SET && res != TEE\_ERROR\_TIME\_NEEDS\_RESET && res != TEE\_ERROR\_OVERFLOW && res != TEE\_ERROR\_OUT\_OF\_MEMORY) TEE\_Panic(res); return res; } TEE\_Result TEE\_SetTAPersistentTime(const TEE\_Time \*time) { TEE\_Result res; res = utee\_set\_ta\_time(time); if (res != TEE\_SUCCESS && res != TEE\_ERROR\_OUT\_OF\_MEMORY && res != TEE\_ERROR\_STORAGE\_NO\_SPACE) TEE\_Panic(res); return res; } void TEE\_GetREETime(TEE\_Time \*time) { TEE\_Result res = utee\_get\_time(UTEE\_TIME\_CAT\_REE, time); if (res != TEE\_SUCCESS) TEE\_Panic(res); } void \*TEE\_Malloc(uint32\_t len, uint32\_t hint) { return tee\_user\_mem\_alloc(len, hint); } void \*TEE\_Realloc(const void \*buffer, uint32\_t newSize) { /\* \* GP TEE Internal API specifies newSize as 'uint32\_t'. \* use unsigned 'size\_t' type. it is at least 32bit! \*/ return tee\_user\_mem\_realloc((void \*)buffer, (size\_t) newSize); } void TEE\_Free(void \*buffer) { tee\_user\_mem\_free(buffer); } /\* Cache maintenance support (TA requires the CACHE\_MAINTENANCE property) \*/ TEE\_Result TEE\_CacheClean(char \*buf, size\_t len) { return utee\_cache\_operation(buf, len, TEE\_CACHECLEAN); } TEE\_Result TEE\_CacheFlush(char \*buf, size\_t len) { return utee\_cache\_operation(buf, len, TEE\_CACHEFLUSH); } TEE\_Result TEE\_CacheInvalidate(char \*buf, size\_t len) { return utee\_cache\_operation(buf, len, TEE\_CACHEINVALIDATE); }

CVE-2022-38155: mTower/tee_api.c at 18f4b592a8a973ce5972f4e2658ea0f6e3686284 · Samsung/mTower

In Task.java, there is a possible escalation of privilege due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12Android ID: A-185810717

_Published August 1, 2022 | Updated August 3, 2022_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2022-08-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version.

Android partners are notified of all issues at least a month before publication. Source code patches for these issues have been released to the Android Open Source Project (AOSP) repository and linked from this bulletin. This bulletin also includes links to patches outside of AOSP.

The most severe of these issues is a critical security vulnerability in the System component that could lead to remote code execution over Bluetooth with no additional execution privileges needed. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.

**Android and Google service mitigations**

This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android.

*   Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible.
*   The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play.

**2022-08-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-08-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates.

**Framework**

The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2021-39696

A-185810717

EoP

High

10, 11, 12

CVE-2022-20344

A-232541124

EoP

High

10, 11, 12, 12L

CVE-2022-20348

A-228315529

EoP

High

10, 11, 12, 12L

CVE-2022-20349

A-228315522

EoP

High

10, 11, 12, 12L

CVE-2022-20356

A-215003903

EoP

High

11, 12, 12L

CVE-2022-20350

A-228178437 \[2\]

ID

High

10, 11, 12, 12L

CVE-2022-20352

A-222473855

ID

High

12, 12L

CVE-2022-20357

A-214999987

ID

High

12, 12L

CVE-2022-20358

A-203229608

ID

High

10, 11, 12, 12L

**Media Framework**

The most severe vulnerability in this section could lead to remote information disclosure with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20346

A-230493653

ID

High

10, 11, 12, 12L

CVE-2022-20353

A-221041256 \[2\] \[3\]

ID

High

10, 11, 12, 12L

**System**

The most severe vulnerability in this section could lead to remote code execution over Bluetooth with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20345

A-230494481

RCE

Critical

12, 12L

CVE-2022-20347

A-228450811

EoP

High

10, 11, 12, 12L

CVE-2022-20354

A-219546241

EoP

High

11, 12, 12L

CVE-2022-20360

A-228314987

EoP

High

10, 11, 12, 12L

CVE-2022-20361

A-231161832

EoP

High

10, 11, 12, 12L

CVE-2022-20355

A-219498290 \[2\]

DoS

High

10, 11, 12, 12L

**Google Play system updates**

The following issues are included in Project Mainline components.

 

Component

CVE

Media Framework components

CVE-2022-20346

**2022-08-05 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-08-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.

**Kernel components**

The vulnerability in this section could lead to local escalation of privileges with User execution privileges needed.

    

CVE

References

Type

Severity

Component

CVE-2022-1786

A-233078742  
Upstream kernel

EoP

High

Filesystem (fs)

**Imagination Technologies**

These vulnerabilities affect Imagination Technologies components and further details are available directly from Imagination Technologies. The severity assessment of these issues is provided directly by Imagination Technologies.

   

CVE

References

Severity

Component

CVE-2021-0698  

A-236848165\*

High

PowerVR-GPU

CVE-2021-0887  

A-236848817\*

High

PowerVR-GPU

CVE-2021-0891

A-236849490\*

High

PowerVR-GPU

CVE-2021-0946  

A-236846966\*

High

PowerVR-GPU

CVE-2021-0947  

A-236838960\*

High

PowerVR-GPU

CVE-2021-39815

A-232440670\*

High

PowerVR-GPU

CVE-2022-20122

A-232441339\*

High

PowerVR-GPU

**MediaTek components**

This vulnerability affects MediaTek components and further details are available directly from MediaTek. The severity assessment of this issue is provided directly by MediaTek.

   

CVE

References

Severity

Component

CVE-2022-20082

A-231271467  
M-ALPS07044730\*

High

GPU

**Unisoc components**

This vulnerability affects Unisoc components and further details are available directly from Unisoc. The severity assessment of this issue is provided directly by Unisoc.

   

CVE

References

Severity

Component

CVE-2022-20239

A-233972091  
U-1883877\*

High

VSP

**Qualcomm components**

This vulnerability affects Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of this issue is provided directly by Qualcomm.

   

CVE

References

Severity

Component

CVE-2022-22080  

A-231156274  
QC-CR#2898981

High

Audio

**Qualcomm closed-source components**

These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

   

CVE

References

Severity

Component

CVE-2021-30259

A-187074564\*

High

Closed-source component

CVE-2022-22059

A-231156126\*

High

Closed-source component

CVE-2022-22061

A-218338332\*

High

Closed-source component

CVE-2022-22062  

A-218338070\*

High

Closed-source component

CVE-2022-22067

A-218338889\*

High

Closed-source component

CVE-2022-22069

A-218339148\*

High

Closed-source component

CVE-2022-22070

A-218338870\*

High

Closed-source component

CVE-2022-25668

A-231156523\*

High

Closed-source component

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

To learn how to check a device's security patch level, see Check and update your Android version.

*   Security patch levels of 2022-08-01 or later address all issues associated with the 2022-08-01 security patch level.
*   Security patch levels of 2022-08-05 or later address all issues associated with the 2022-08-05 security patch level and all previous patch levels.

Device manufacturers that include these updates should set the patch string level to:

*   \[ro.build.version.security\_patch\]:\[2022-08-01\]
*   \[ro.build.version.security\_patch\]:\[2022-08-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2022-08-01 security patch level. Please see this article for more details on how to install security updates.

**2\. Why does this bulletin have two security patch levels?**

This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.

*   Devices that use the 2022-08-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.
*   Devices that use the security patch level of 2022-08-05 or newer must include all applicable patches in this (and previous) security bulletins.

Partners are encouraged to bundle the fixes for all issues they are addressing in a single update.

**3\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**4\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference mvalue belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**5\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**6\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**

Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

**Versions**

  

Version

Date

Notes

1.0

August 1, 2022

Bulletin Published

1.1

August 3, 2022

Bulletin revised to include AOSP links

CVE-2021-39696: Android Security Bulletin—August 2022  |  Android Open Source Project

Implicit Intent hijacking vulnerability in Samsung Internet Browser prior to version 17.0.7.34 allows attackers to access arbitrary files.

CVE-2022-36835

The TEE_PopulateTransientObject and __utee_from_attr functions in Samsung mTower 0.3.0 allow a trusted application to trigger a memory overwrite, denial of service, and information disclosure by invoking the function TEE_PopulateTransientObject with a large number in the parameter attrCount.

**Affected components：**

affected source code file: /tee/lib/libutee/tee\_api\_objects.c, affected functions: TEE\_PopulateTransientObject and \_\_utee\_from\_attr

**Attack vector(s)**

To exploit the vulnerability, invoke the function TEE\_PopulateTransientObject and pass a large number of the parameter "attrCount"

**Suggested description of the vulnerability for use in the CVE**

Memory leak in TEE\_PopulateTransientObject and \_\_utee\_from\_attr functions in Samsung Electronics mTower v0.3.0(and earlier) allows a trusted application to trigger denial of service and information disclosure via invoking the function TEE\_PopulateTransientObject with a large number of the parameter "attrCount".

**Reference(s)**

https://github.com/Samsung/mTower  

TEE\_Result TEE\_PopulateTransientObject(TEE\_ObjectHandle object,

**Additional information**

The TEE\_PopulateTransientObject function takes a number "attrCount" and create an array "ua". This value is passed by TA, and TEE\_PopulateTransientObject does not check its size. Then it is passed to \_\_utee\_from\_attr. The \_\_utee\_from\_attr function tries to copy data from "attrs" to "ua". The problem appears in the assignments in the for loop. If the attr\_count is too large, "ua" will overlap the memory region of other TAs' (tampering data such as global variables, or causing TEE crash and triggers denial of service because of illegal address dereference).

**Contact**

c01dkit@outlook.com

CVE-2022-35858: Security: Memory Leak in the function TEE_PopulateTransientObject · Issue #71 · Samsung/mTower

The embedded neutralization of Script-Related HTML Tag, was by-passed in the case of some extra conditions.

French President uses Cryptosmart **to secure his devices and mobile communications** Learn more

*   Group
*   solutions
    
      
    
    **Messaging, voice and videoconferencing Citadel Team**
    
    The trusted alternative to mass market instant messaging solutions
    
    See more >
    
    **Collaboration is a matter of trust**
    
    Boost communication by inviting thousands of members in dedicated chat rooms!
    
    See more >
    
    **Presentation**
    
    Cryptobox provides businesses and organizations with a sharing and collaboration solution to secure internal and external exchanges, using end-to-end encryption.
    
    See more >
    
    **Presentation**
    
    Cryptobox is the first secure sharing and collaboration solution to provide end-to-end data encryption, whether your device is a smartphone or a computer.
    
    See more >
    
    **Presentation**
    
    The digital transformation affects all businesses and organizations, from the smallest to the largest. This transformation brought about by technological developments offers many benefits:
    
    See more >
    
    **Presentation**
    
    To meet the new challenges of mobility and remote work, Ercom has developed Cryptosmart PC, a sovereign VPN solution to secure the connections of your remote Windows computers.
    
    See more >
    
    **Presentation**
    
    Cryptosmart is the only “Restricted” French & NATO certified solution, jointly developed with Samsung, to secure end-to-end mobile communications on consumer devices.
    
    See more >
    
*   Talents
*   Newsroom
    
*   Ressources
    
*   Contact-Us

*   Home
*   Security Updates

**CVE-2022-1293 | XSS vulnerability in Citadel**

*   **Publication date**: 2022-04-13T09:42:00.000Z
*   **State**: public
*   **Description**: We have discovered a vulnerability that can affect the Citadel client. The embedded neutralization of Script-Related HTML Tag, was by-passed in the case of some extra conditions.
*   **Affected versions**: 7.1.1 and lower
*   **Remediation**: update to version 7.1.2 or higher
    *   web client: just reload the page
    *   desktop client: launch update from the menu

Tag

#samsung