An improper implementation logic in Secure Folder prior to SMR Jan-2023 Release 1 allows the Secure Folder container remain unlocked under certain condition.

This Cookie Policy describes the different types of cookies that may be used in connection with Samsung Mobile Security website which is owned and controlled by Samsung Electronics Co., Ltd (“Samsung Electronics”). This Cookie Policy also describes how you can manage cookies.

It’s important that you check back often for updates to the Policy as we may change it from time to time to reflect changes to our use of cookies. Please check the date at the top of this page to see when this Policy was last revised. Any changes to this Policy will become effective when we make the revised Policy available on our website.

Samsung Electronics has offices across Europe, so we can ensure that your request or query will be handled by the data protection team based in your region. If you have any questions, the easiest way to contact us is through our Privacy Support Page at https://www.samsung.com/request-desk.

You can also contact us at:

European Data Protection Officer  
Samsung Electronics (UK) Limited  
Samsung House, 2000 Hillswood Drive, Chertsey, Surrey KT16 0RS

**Cookies**

Cookies are small files that store information on your computer, TV, mobile phone, or other device. They enable the entity that put the cookie on your device to recognize you across different websites, services, devices, and/or browsing sessions.

We use the following types of cookies on this website:

**Essential Cookies**: enable you to receive the services you request via our website. Without these cookies, services that you have asked for cannot be provided. For example, these enable to identify users and provide proper service for each user. These cookies are automatically enabled and cannot be turned off because they are essential to enable you to browse our website. Without these cookies this Samsung Mobile Security website could not be provided.

Cookie

Domain

Purpose

JSESSIONID

security.samsungmobile.com

to keep login session

lastActivityTime

security.samsungmobile.com

to save the user's last activity time to automatically logout after 30 minutes of inactivity

**Managing Cookies and Other Technologies**

You can also update your browser settings at any time, if you want to remove or block cookies from your device (consult your browser's "help" menu to learn how to remove or block cookies). Samsung Electronics is not responsible for your browser settings. You can find good and simple instructions on how to manage cookies on the different types of web browsers at http://www.allaboutcookies.org.

CVE-2023-21419: Samsung Mobile Security

Improper input validation vulnerability in Galaxy Store prior to version 4.5.49.8 allows local attackers to execute JavaScript by launching a web page.

CVE-2023-21434: Samsung Mobile Security

Moscow promised residents lower crime rates through an expansive smart city project. Then Vladimir Putin invaded Ukraine.

Sergey Vyborov was on his way to the Moscow Metro’s Aeroport station last September when police officers stopped him. The 49-year-old knew that taking the metro could spell trouble. During a protest against Russia’s invasion of Ukraine, police had fingerprinted and photographed him. He’d already been detained four times in 2022. But he was rushing to his daughter’s birthday, so he took a chance.

Vyborov wasn’t arrested that day, but the police informed him that he was under surveillance through Sfera, one of Moscow’s face recognition systems, for participating in unsanctioned rallies. Considered one of the most efficient surveillance systems, Sfera led to the detention of 141 people last year. “Facial recognition, and video cameras in general in a totalitarian state, are an absolute evil,” Vyborov says. 

Vyborov finds himself at the bottom of a slippery slope that privacy advocates have long warned about. Under the guise of smart city technology, authoritarian and democratic governments have rolled out huge networks of security cameras and used artificial intelligence to try to ensure there is no place to hide. Cities have touted the ability of such systems to tackle crime, manage crowds, and better respond to emergencies. Privacy campaigners say such systems could be used as tools of oppression. In Moscow, Vyborov and countless others now face that oppression on a daily basis.

The Russian capital is now the seventh\-most-surveilled city in the world. Across Russia, there are an estimated 21 million surveillance cameras, and the country ranks among the top in the world in terms of the number of connected surveillance cameras. The system created by Moscow’s government, dubbed Safe City, was touted by city officials as a way to streamline its public safety systems. In recent years, however, its 217,000 surveillance cameras, designed to catch criminals and terrorists, have been turned against protestors, political rivals, and journalists. 

“Facial recognition was supposed to be the ‘cherry on top,’ the reason why all of this was built,” says a former employee of NTechLab, one of the principal companies building Safe City’s face recognition system.

Following Russia’s invasion of Ukraine, Safe City’s data collection practices have become increasingly opaque. The project is now seen as a tool of rising digital repression as Russia wages war against Ukraine and dissenting voices within its own borders. It is an example of the danger smart city technologies pose. And for the engineers and programmers who built such systems, its transformation into a tool of oppression has led to a moment of reckoning. 

An Innocent Start

Founded in 2015, NTechLab caught the attention of the global press with the February 2016 launch of FindFace, an app that allowed anyone to identify faces by matching them with images gathered from social network VKontakte, Russia’s Facebook equivalent. Met with warnings of the “end to public anonymity,” the app was reportedly downloaded by 500,000 people within two months of its launch. But for NTechLab, it was primarily a proof of concept for its nascent face recognition algorithm.

NTechLab still felt like a startup when one former employee, who asked not to be named for privacy reasons, joined the company. And he was drawn in by the complexity of the work.

“From \[an\] engineering point of view, it’s very interesting to work with: It’s very difficult,” he says. 

After the release of FindFace, NTechLab began selling its face recognition tech to small businesses, such as shopping malls that could use it to catch shoplifters or see how many people return to certain stores. But NTechLab was also working with the Moscow Department of IT Technology (DIT), the government department tasked with building Moscow’s digital infrastructure. In 2018, when Russia hosted the FIFA World Cup, NTechLab’s face recognition tech was connected to more than 450 security cameras around Moscow, and its tech reportedly helped police detain 180 people whom the state deemed “wanted criminals.”

At its inception, Moscow’s face recognition system was fed official watchlists, like the database of wanted people. The system uses these lists to notify the police once a person on the list is detected, but law enforcement can also upload an image and search for where a person has appeared. Over the years, security and law enforcement agencies have compiled a database of the leaders of the political opposition and prominent activists, according to Sarkis Darbinyan, cofounder of digital rights group Roskomsvoboda, which has been campaigning for a suspension of the technology. It remains unclear who is in charge of adding activists and protesters to watchlists.

In March 2019, following the success of the World Cup trial—some of Russia’s “most wanted” people were arrested while trying to attend matches—the Moscow Department of Transportation, which operates the city’s metro, launched its own surveillance system, Sfera. By October 2019, 3,000 of the city’s 160,000 cameras were enabled with face recognition tech, according to interior minister Vladimir Kolokoltsev.

NTechLab was one of many companies building the slew of systems that would later be branded Safe City. International companies, from US tech firms such as Nvidia, Intel, and Broadcom to South Korea’s Samsung and Chinese camera maker Hikvision, worked alongside local firms such as HeadPoint, Netris, and Rostelecom that have developed various components of the surveillance systems. According to procurement documents cited by the UK’s BBC, three companies besides NTechLab created face recognition tech for Moscow’s growing surveillance apparatus, including Tevian, and Kipod, and VisionLabs. Moscow's Transportation Department said in social media posts that Sfera was built using VisionLabs technology, although the company downplays its involvement.

NtechLab says it operates in compliance with local laws and does not have access to customer data or camera video streams. Nvidia and Intel say they left Russia in 2022, with Nvidia adding that it does not create software or algorithms for surveillance. Broadcom and Samsung also say they stopped doing business in Russia following the invasion. VisionLabs says it only provides the Moscow Metro with its face recognition payment system. Other companies did not respond to requests for comment. The DIT and the Moscow Department of Transportation did not respond to requests for comment.

At the end of 2018, as Russia cracked down harder on political dissent online and in the streets, the DIT started to change, says a former employee who asked to remain anonymous for safety reasons. The department used to just be the “technical guys” providing assistance to security services, with the Moscow government recruiting highly paid IT specialists to make the most efficient systems possible, according to Andrey Soldatov, an investigative journalist and Russian security services expert. But according to the former employee, the DIT was beginning to reflect the Kremlin’s authoritarian bent.

Then came Covid. 

Safe City launched in 2020, at the height of the Covid-19 pandemic. Russia, like some other countries, seemingly used the pandemic as grounds to expand its surveillance systems to catch people breaking self-isolation rules. By mid-March 2020, Safe City’s face recognition system had caught 200 people breaking lockdown restrictions. At the same time, Moscow introduced a regulatory sandbox for the development of AI applications with the participation of large IT companies, exempting authorities from the country’s already lax data protection requirements. “With Covid, \[the DIT\] essentially became a part of the repressive apparatus,” says Soldatov.

In addition to its network of more than 200,000 cameras, Safe City also incorporates data from 169 information systems, managing data on citizens, public services, transportation, and nearly everything else that makes up Moscow’s infrastructure. This includes anonymized cell phone geolocation data collection, vehicle license plate recognition, data from ride-hailing services, and voice recognition devices. As Safe City was still rolling out in 2020, the Russian government announced plans to spend $1.3 billion deploying similar Safe City systems across Russia. From the outside, the potential for the system to be abused seemed obvious. But for those involved in its development, it looked like many other smart city projects. “No one expected that the country would turn into hell in two years,” says one former NTechLab employee, who asked to remain anonymous for safety reasons.

The Black Box Problem

Attempts to break open Moscow’s digital black box have been stonewalled. Alena Popova, whose image was captured during a protest against politician Leonid Eduardovich Slutsky in April 2018, filed the first lawsuit against Moscow’s DIT for allegedly violating her privacy, seeking a ban on face recognition tech. The case was thrown out, but Popova has continued to file lawsuits, including one at the European Court of Human Rights—which Russia is no longer a part of. 

While Moscow operates one of the world’s most pervasive surveillance systems, Russian law does not safeguard individual privacy. With seemingly no hope of recourse, some activists have been forced to leave Russia altogether. Popova is now on the list of foreign agents and is living in an undisclosed overseas location. “I will not apply to any political asylum in any country because I would like to go back to my own country and fight back,” she says.

A key concern is that Moscow’s surveillance system was designed to conceal its data collection from Moscow’s 12 million residents, says Sergey Ross, founder of the Collective Action Center think tank and a former Moscow politician. Although the system is run by the Moscow government, elected members of the Moscow City Duma say they are excluded from regulating face recognition systems and have little insight into how it is being used. “It’s a complete black box,” says Ross.

“It was clear that sooner or later the technology would be used to catch activists and dissenters,” says Roskomsvoboda’s Darbinyan. 

Russia made almost 20,500 political arrests in 2022, according to data from human rights media organization OVD-Info, which characterizes the number as “unprecedented.” The arrests have sparked fears that Safe City will be expanded to catch draft dodgers—although former NTechLab employees say that doing so would be technically difficult to pull it off because of too many false positives. Still, Moscow police appear to be using face recognition to aid Russia’s war efforts in other ways.

In September 2022, just after Putin announced additional mobilization for the war against Ukraine, Viktor Kapitonov, a 27-year-old activist who’d protested regularly since 2013, was stopped by two police officers after being flagged by face recognition surveillance while he approached the turnstiles in Moscow’s marble-covered Avtozavdodskaya metro station. The officers took him to the military recruitment office, where around 15 people were waiting to enlist in Putin’s newly announced draft. 

“They let me in without waiting in line as if I were some sort of VIP person,” he says. The recruiters wanted to force Kapitonov to enlist, but he ended up escaping the draft. “I explained that I am not fit, I have a disability.”

A Guilty Conscience

From 2017 to 2020, NTechLab became one of Russia’s fastest-growing companies. Other face recognition firms have cashed in as well: The revenue of Russian face recognition developers grew between 30 and 35 percent in 2022, thanks in part to deals struck in the Middle East, Southeast Asia, India, and South America. Russia’s national AI strategy has supported such firms with grants, tax exemptions, and subsidies, which have benefited both startups and state corporations, including tech and finance giant Sber, telecom provider Rostelecom, and defense firm Rostec, which previously owned a minority stake in NTechLab. While NTechLab continues to work globally, reporting a revenue increase of 35 percent in 2022, it has also faced a backlash against its work with the Russian state.

In June of last year, a “name-and-shame” list of NTechLab employees was published \[in Russian\] with information collected from social media. The project went viral, and some employees reported being harassed online. Artem Zinnatullin, a software engineer now based in the US, says he published the list after NTechLab sold its new silhouette recognition technology to the Moscow government in June 2022. To him, it signaled support for Russia’s war in Ukraine. In the post, he called NTechLab “the blacksmith of the Digital Gulag.” Zinnatullin, who says he knew people arrested with the help of face recognition technology, believes publishing the list of NTechLab employees was only fair. “You recognize people on the street, it’s only fair if we use public data to recognize who you are,” he says.

Unlike many face recognition companies that keep a low profile, NTechLab’s splash with FindFace has turned it into a recognized brand. Employees say this high profile has made them into scapegoats. 

As arrests of activists and politicians mounted, the ethics of NTechLab’s technology became a recurring topic at company meetings. NTechLab staff have resisted the use of the company’s face recognition in rallies and refused to sell the technology to the military, according to people familiar with these discussions. Still, the NTechLab leadership concluded that the technology was ultimately positive—even if the occasional dissenting voice was arrested because of it. 

“We all saw these positive examples, we saw how it really catches criminals,” says one former NTechLab employee. “Most people in NTechLab would say they were doing something very good, technologies that can help and save people’s lives. It really did.”

As Russia furthered its march toward authoritarianism in 2021, NTechLab leadership began talking about moving the company abroad, according to people familiar with internal company discussions. But with lucrative government contracts abounding—NTechLab received a $13 million investment from the Russian Direct Investment Fund, the country’s sovereign wealth fund, in September 2020—its investors resisted the idea. The company was also changing. Its founders, Alexander Kabakov and Artem Kukharenko, stepped down from NTechLab—and both left Russia in December 2021 and February 2022, respectively, declaring their anti-war stance on social media. 

Other employees left amid an exodus of IT talent from Russia. The war changed how they viewed their work. “Looking back, we realize that we shouldn’t have done it,” says an NTechLab employee. “But even in 2017 and 2018, it was a completely different country. At least, that’s how it seemed to those who weren’t very immersed in politics.”

A Growing Threat

Russia’s Safe City projects show no sign of slowing. As more surveillance systems are deployed across the country, Moscow’s DIT is planning to centralize video streams collected across all regions into its own system. And new projects to digitize public services may make it even easier for the government to eventually create large databases where everyone can be found, according to Popova. “It is really scary,” she says. “If they digitalize all the databases and combine them to make this joint database, they can find everybody.” In July, Putin signed a federal law that funnels personal biometric data collected in the country into a single system—an effort to obtain an “almost unlimited monopoly” on the collection and storage of biometrics, says Roskomsvoboda’s Darbinyan. 

In a further expansion of the Safe City project, Rostec is also reportedly developing software that will help authorities predict riots and prevent their escalation by analyzing media reports, data from social networks, video cameras, and other sources. Rostec did not respond to a request for comment on its development of these systems.

Similar systems have been developed in some Chinese cities, and Russia is now playing catch-up. “The Russian government would probably like to move toward China, but they do not yet have the necessary technology,” says Kiril Koroteev, head of international practice at the Russia-based Agora International Human Rights Group.

For now, many activists in Russia are left to do whatever they can to skirt the country’s growing surveillance apparatus, including avoiding the Moscow Metro. Kapitonov hopes that a balaclava will keep him safe, while Vyborov aims to ride the metro early in the morning, when there are fewer police around to detain him. 

“I think that it was inevitable that such a system would be made sooner or later,” says one former NTechLab employee. Face recognition is like a knife, he says: It can be used to cut food, but it can also be used to cut innocent people. He now regrets that NTechLab played a key role in building Moscow’s Safe City project. He has left Russia and doesn’t think he will work on face recognition again. “I do not want to mess with it anymore,” he says.

_Update 9:25 am ET, February 6, 2023: Clarified the role of VisionLabs in the Sfera system and that NTechLab's founders have since left the company._

Inside Safe City, Moscow’s AI Surveillance Dystopia

Do you know where your secrets are? If not, I can tell you: you are not alone.
Hundreds of CISOs, CSOs, and security leaders, whether from small or large companies, don't know either. No matter the organization's size, the certifications, tools, people, and processes: secrets are not visible in 99% of cases.
It might sound ridiculous at first: keeping secrets is an obvious first thought when

Do you know where your secrets are? If not, I can tell you: you are not alone.

Hundreds of CISOs, CSOs, and security leaders, whether from small or large companies, don't know either. No matter the organization's size, the certifications, tools, people, and processes: secrets are not visible in 99% of cases.

It might sound ridiculous at first: keeping secrets is an obvious first thought when thinking about security in the development lifecycle. Whether in the cloud or on-premise, you know that your secrets are safely stored behind hard gates that few people can access. It is not just a matter of common sense since it's also an essential compliance requirement for security audits and certifications.

Developers working in your organization are well-aware that secrets should be handled with special care. They have put in place specific tools and procedures to correctly create, communicate, and rotate human or machine credentials.

Still, do you know where your secrets are?

Secrets sprawl everywhere in your systems, and faster than most realize. Secrets are copied and pasted into configuration files, scripts, source code, or private messages without much thought. Think about it: a developer hard-codes an API key to test a program quickly and accidentally commits and pushes their work on a remote repository. Are you confident that the incident can be detected in a timely manner?

Insufficient audit and remediation capabilities are some of the reasons why secrets management is hard. They are also the least addressed by security frameworks. Yet these grey areas—where unseen vulnerabilities remain hidden for a long time—are blatant holes in your defense layers.

Recognizing this gap, we developed a self-assessment tool to evaluate the size of this unknown. To take stock of your _real_ security posture regarding secrets in your organization, take five minutes to answer the eight questions (it's completely anonymous).

So, how much do you _not_ know about your secrets?

**Secrets Management Maturity Model**

Sound secrets management is a crucial defensive tactic that requires some thought to build a comprehensive security posture. We built a framework (you can find the white paper here) to help security leaders make sense of their actual posture and adopt more mature enterprise secrets management practices in three phases:

1.  Assessing secrets leakage risks
2.  Establishing modern secrets management workflows
3.  Creating a roadmap to improvement in fragile areas

The fundamental point addressed by this model is that secrets management goes well beyond how the organization stores and distributes secrets. It is a program that not needs to align people, tools, and processes, but also to account for human error. Errors are _not_ evitable! Their consequences are. That's why detection and remediation tools and policies, along with secrets storage and distribution, form the pillars of our maturity model.

The secrets management maturity model considers four attack surfaces of the DevOps lifecycle:

*   Developer environments
*   Source code repositories
*   CI/CD pipelines & artifacts
*   Runtime environments

We then built a maturity ramp-up over five levels, going from 0 (Uninitiated) to 4 (Expert). Going 0 to 1 is mostly about assessing the risks posed by insecure software development practices, and starting auditing digital assets for hardcoded credentials. At the intermediate level (level 2), secrets scanning is more systematic, and secrets are cautiously shared across the DevOps lifecycle. Levels 3 (Advanced) and 4 (Expert) are focused on risk mitigation with clearer policies, better controls, and increased shared responsibility for remediating incidents.

Another core consideration for this framework is that making it hard to use secrets in a DevOps context will inevitably lead to the bypassing of the protective layers in place. As with everything else in security, the answers lay between protection and flexibility. This is why the use of a vault/secrets manager starts at the intermediate level only. The idea is that the use of a secrets manager should not be seen as a stand-alone solution but as an additional layer of defense. To be effective, it requires other processes, like continuous scanning of pull requests, to be mature enough.

Here are some questions that this model should raise in order to help you evaluate your maturity: how frequently are your production secrets rotated? How easy is it to rotate secrets? How are secrets distributed at the development, integration, and production phase? What measures are put in place to prevent the unsafe dissemination of credentials on local machines? Do CI/CD pipelines' credentials adhere to the least privileges principle? What are the procedures in place for when (not if) secrets are leaked?

Reviewing your secrets management posture should be top of mind in 2023. First, everyone working with source code has to handle secrets, if not daily, at least once in a while. Secrets are no longer the prerogative of security or DevOps engineers. They are required by more and more people, from ML engineers, data scientists, product, ops, and even more. Second, if you don't find where your secrets are, hackers will.

**Hackers will find your secrets**

The risks posed to organizations failing to adopt mature secrets management practices cannot be overstated. Development environments, source code repositories and CI/CD pipelines have become favorite targets for hackers, for whom secrets are a gateway to lateral movement and compromise.

Recent examples highlight the fragility of secrets management even in the most technologically mature organizations.

In September 2022, an attacker got access to Uber's internal network, where he found hardcoded admin credentials on a network drive. The secrets were used for logging in to Uber's privileged access management platform, where many more plaintext credentials were stored throughout files and scripts. The attacker was then able to take over admin accounts in AWS, GCP, Google Drive, Slack, SentinelOne, HackerOne, and more.

In August of the same year, the password manager LastPass fell victim of an attacker who gained access toits development environment by stealing the credentials of a software developer and impersonating that individual. Later in December, the firm disclosed that someone used that information to steal source code and customer data.

In fact, in 2022, source code leaks have proven to be a true minefield for organizations: NVIDIA, Samsung, Microsoft, Dropbox, Okta, and Slack, among others, have been victims of source code leaks. In May, we were warning about the important volume of credentials that could be harvested by analyzing these codebases. Armed with these, attackers can gain leverage and pivot into hundreds of dependent systems in what is known as supply chain attacks.

Finally, even more recently, in January 2023, the continuous integration provider CircleCI was also breached, leading to the compromise of hundreds of customer environment variables, tokens, and keys. The company urged its customers to immediately change their passwords, SSH keys, or any other secrets stored on or managed by the platform. Still, victims need to find out where these secrets are and how they are being used to press the emergency button!

This was a strong case for having an emergency plan ready to go.

The lesson from all these incidents is that attackers have realized that compromising machine or human identities gives a higher return on investment. They are all warning signs of the urgency to deal with hardcoded credentials and to dust off secrets management in general.

**Final word**

We have a saying in cybersecurity: "encryption is easy, but key management is hard." This still holds true today, although it isn't just about encryption keys anymore. Our hyper-connected services world relies on hundreds of types of keys, or secrets, to function properly. These could be as many potential attack vectors if mismanaged.

Knowing where your secrets are, not just in theory but in practice, and how they are used along the software development chain is crucial for security. To help you, we created a maturity model specifically about secrets distribution, leak detection, remediation process, and rotation habits.

The first step is always to get a clear audit of the organization's security posture regarding secrets: where and how are they used? Where do they leak? How to prepare for the worst? This alone could prove to be a lifesaver in an emergency situation. Find out where you stand with the questionnaire and learn where to go from there with the white paper.

In the wake of recent attacks on development environments and business tools, companies that want to defend themselves effectively must ensure that the grey areas of their development cycle are cleared as soon as possible.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

You Don't Know Where Your Secrets Are

January saw a slew of security patches for iOS, Chrome, Windows, and more.

The Android security patch is available to Google’s Pixel devices, which have their own specific updates, and Samsung’s Galaxy range, including Samsung Galaxy Note 10, Galaxy S21, and Galaxy A73. You can check for the update in your settings.

Microsoft Patch Tuesday

Microsoft fixed a rather hefty 98 security issues in its first Patch Tuesday of the year, including an already exploited vulnerability: CVE-2023-21674 is an elevation of privilege flaw impacting the Windows Advanced Local Procedure Call that could lead to browser sandbox escape. 

By exploiting the bug, an adversary could gain System privileges, Microsoft wrote, confirming that the flaw has been detected in real-life attacks.

Another elevation of privilege vulnerability in the Windows Credential Manager User Interface, CVE-2023-21726, is relatively easy to exploit and doesn’t require any interaction from the user.

January’s Patch Tuesday also saw Microsoft fix nine Windows Kernel vulnerabilities, eight of which are elevation of privilege issues and one information disclosure vulnerability.

Mozilla Firefox

Software firm Mozilla has released important updates for its Firefox browser, the most serious of which have been the subject of a warning by the US Cybersecurity and Infrastructure Security Agency (CISA). 

Among the 11 flaws fixed in Firefox 109 are four rated as having a high impact, including CVE-2023-23597, a logic bug in process allocation that could allow adversaries to read arbitrary files. Meanwhile, Mozilla said its security team found memory safety bugs in Firefox 108. “Some of these bugs showed evidence of memory corruption and we presume that with enough effort, some could have been exploited to run arbitrary code,” it wrote.

An attacker could exploit some of these vulnerabilities to take control of an affected system, CISA said in its advisory. “CISA encourages users and administrators to review Mozilla’s security advisories for Firefox ESR 102.7 and Firefox 109 for more information and apply the necessary updates.”

VMWare

Enterprise software maker VMWare has published a security advisory detailing four flaws affecting its VMware vRealize Log Insight product. Tracked as CVE-2022-31706, the first is a directory traversal vulnerability with a CVSSv3 base score of 9.8. By exploiting the flaw, an unauthenticated, malicious actor could inject files into the operating system of an impacted appliance, resulting in RCE, VMWare says.

Meanwhile, a broken access control RCE vulnerability tracked as CVE-2022-31704 also has a CVCCv3 base score of 9.8. It goes without saying that those impacted by these vulnerabilities should patch as soon as possible.

Oracle

Software giant Oracle has released patches for a whopping 327 security vulnerabilities, 70 of which are rated as having a critical impact. Worryingly, 200 of the issues patched in January can be exploited by a remote unauthenticated attacker.

Oracle is recommending that people update their systems as soon as possible, warning that it has received reports of “attempts to maliciously exploit vulnerabilities for which Oracle has already released security patches.”

In some instances, it has been reported that attackers have been successful because targeted customers had failed to apply available Oracle patches, it says.

SAP

SAP’s January Patch Day has seen the release of 12 new and updated security notes. With a CVSS score of 9.0, CVE-2023-0014 is rated as the most severe bug by security firm Onapsis. The flaw affects the majority of all SAP customers and its mitigation is a challenge, Onapsis says. 

The capture-replay vulnerability is a risk because it could allow malicious users to obtain access to an SAP system. “Complete patching of the vulnerability includes applying a kernel patch, an ABAP patch, and a manual migration of all trusted RFC and HTTP destinations,” Onapsis explains.

You Really Need to Update Firefox and Android Right Now

Improper input validation in driver adgnetworkwfpdrv.sys in Adguard For Windows x86 up to version 7.11 allows attacker to gain local privileges escalation.

CVE-2022-45770: Versions history | AdGuard

The PowerVR GPU kernel driver maintains an "Information Page" used by its cache subsystem. This page can only be written by the GPU driver itself, but prior to DDK 1.18 however, a user-space program could write arbitrary data to the page, leading to memory corruption issues.Product: AndroidVersions: Android SoCAndroid ID: A-259967780

_Published January 3, 2023 | Updated January 10, 2023_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2023-01-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 will be released to the Android Open Source Project (AOSP) repository in the next 48 hours. We will revise this bulletin with the AOSP links when they are available.

The most severe of these issues is a high security vulnerability in the Framework component that could lead to local escalation of privilege 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.

**2023-01-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2023-01-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-2022-20456

A-242703780

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20489

A-242703460

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20490

A-242703505

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20492

A-242704043

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20493

A-242846316

EoP

High

10, 11, 12, 12L, 13

CVE-2023-20912

A-246301995

EoP

High

13

CVE-2023-20916

A-229256049

EoP

High

12, 12L

CVE-2023-20919

A-252663068

EoP

High

13

CVE-2023-20920

A-204584366

EoP

High

10, 11, 12, 12L, 13

CVE-2023-20921

A-243378132

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20494

A-243794204

DoS

High

10, 11, 12, 12L, 13

CVE-2023-20908

A-239415861

DoS

High

10, 11, 12, 12L, 13

CVE-2023-20922

A-237291548

DoS

High

11, 12, 12L, 13

**System**

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

**Google Play system updates**

The following issues are included in Project Mainline components.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20461

A-228602963

EoP

High

10, 11, 12, 12L, 13

CVE-2023-20904

A-246300272

EoP

High

12L, 13

CVE-2023-20905

A-241387741

EoP

High

10

CVE-2023-20913

A-246933785

EoP

High

10, 11, 12, 12L, 13

CVE-2023-20915

A-246930197

EoP

High

10, 11, 12, 12L, 13

 

Subcomponent

CVE

MediaProvider

CVE-2023-20912

**2023-01-05 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2023-01-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**

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

    

CVE

References

Type

Severity

Subcomponent

CVE-2022-42719

A-253642087  
Upstream kernel \[2\] \[3\] \[4\] \[5\] \[6\] \[7\] \[8\] \[9\] \[10\] \[11\] \[12\] \[13\] \[14\]

RCE

Critical

mac80211

CVE-2022-42720

A-253642015  
Upstream kernel \[2\] \[3\] \[4\] \[5\] \[6\] \[7\] \[8\] \[9\] \[10\] \[11\] \[12\] \[13\] \[14\]

RCE

Critical

WLAN

CVE-2022-42721

A-253642088  
Upstream kernel \[2\] \[3\] \[4\] \[5\] \[6\] \[7\] \[8\] \[9\] \[10\] \[11\] \[12\] \[13\] \[14\]

RCE

Critical

Multiple Modules

CVE-2022-2959

A-244395411  
Upstream kernel

EoP

High

Pipe

**Kernel components**

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

    

CVE

References

Type

Severity

Subcomponent

CVE-2022-41674

A-253641805  
Upstream kernel \[2\] \[3\] \[4\] \[5\] \[6\] \[7\] \[8\] \[9\] \[10\] \[11\] \[12\] \[13\] \[14\]

RCE

Critical

WLAN

CVE-2023-20928

A-254837884  
Upstream kernel

EoP

High

Binder driver

**Kernel LTS**

The following kernel versions have been updated. Kernel version updates are dependent on the version of Android OS at the time of device launch.

  

References

Android Launch Version

Minimum Kernel Version

A-224575820

12

5.10.101

**Imagination Technologies**

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

    

CVE

References

Severity

Subcomponent

CVE-2022-20235  

A-259967780 \*

High

PowerVR-GPU

**MediaTek components**

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

    

CVE

References

Severity

Subcomponent

CVE-2022-32635  

A-257714327  
M-ALPS07573237 \*

High

gps

CVE-2022-32636  

A-257846591  
M-ALPS07510064 \*

High

keyinstall

CVE-2022-32637  

A-257860658  
M-ALPS07491374 \*

High

hevc decoder

**Unisoc components**

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

    

CVE

References

Severity

Subcomponent

CVE-2022-44425  

A-258731891  
U-2028856 \*

High

Kernel

CVE-2022-44426  

A-258728978  
U-2028856 \*

High

Kernel

CVE-2022-44427  

A-258736883  
U-1888565 \*

High

Kernel

CVE-2022-44428  

A-258741356  
U-1888565 \*

High

Kernel

CVE-2022-44429  

A-258743555  
U-1981296 \*

High

Kernel

CVE-2022-44430  

A-258749708  
U-1888565 \*

High

Kernel

CVE-2022-44431  

A-258741360  
U-1981296 \*

High

Kernel

CVE-2022-44432  

A-258743558  
U-1981296 \*

High

Kernel

CVE-2022-44434  

A-258760518  
U-2064988 \*

High

Android

CVE-2022-44435  

A-258759189  
U-2064988 \*

High

Android

CVE-2022-44436  

A-258760519  
U-2064988 \*

High

Android

CVE-2022-44437  

A-258759192  
U-2064988 \*

High

Android

CVE-2022-44438  

A-258760781  
U-2064988 \*

High

Android

**Qualcomm components**

These vulnerabilities affect Qualcomm 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

Subcomponent

CVE-2022-22088  

A-231156521  
QC-CR#3052411

Critical

Bluetooth

CVE-2022-33255  

A-250627529  
QC-CR#3212699

High

Bluetooth

**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

Subcomponent

CVE-2021-35097  

A-209469821 \*

Critical

Closed-source component

CVE-2021-35113  

A-209469998 \*

Critical

Closed-source component

CVE-2021-35134  

A-213239776 \*

Critical

Closed-source component

CVE-2022-23960  

A-238203772 \*

High

Closed-source component

CVE-2022-25725  

A-238101314 \*

High

Closed-source component

CVE-2022-25746  

A-238106983 \*

High

Closed-source component

CVE-2022-33252  

A-250627159 \*

High

Closed-source component

CVE-2022-33253  

A-250627591 \*

High

Closed-source component

CVE-2022-33266  

A-250627569 \*

High

Closed-source component

CVE-2022-33274  

A-250627236 \*

High

Closed-source component

CVE-2022-33276  

A-250627271 \*

High

Closed-source component

CVE-2022-33283  

A-250627602 \*

High

Closed-source component

CVE-2022-33284  

A-250627218 \*

High

Closed-source component

CVE-2022-33285  

A-250627435 \*

High

Closed-source component

CVE-2022-33286  

A-250627240 \*

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 2023-01-01 or later address all issues associated with the 2023-01-01 security patch level.
*   Security patch levels of 2023-01-05 or later address all issues associated with the 2023-01-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\]:\[2023-01-01\]
*   \[ro.build.version.security\_patch\]:\[2023-01-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2023-01-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 2023-01-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 2023-01-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 value 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

January 3, 2022

Bulletin Published

1.1

January 5, 2022

Bulletin revised to include AOSP links

1.2

January 10, 2022

Revised CVE Table

CVE-2022-20235: Android Security Bulletin—January 2023  |  Android Open Source Project

In ApplicationsDetailsActivity of AndroidManifest.xml, there is a possible DoS due to a tapjacking/overlay attack. This could lead to local denial of service with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12Android ID: A-183410508

_Published January 3, 2022_

The Android Automotive OS (AAOS) Update Bulletin contains details of security vulnerabilities affecting the Android Automotive OS platform. The full AAOS update comprises the security patch level of 2023-01-05 or later from the January 2023 Android Security Bulletin in addition to all issues in this bulletin.

We encourage all customers to accept these updates to their devices.

The most severe of these issues is a high security vulnerability in the Platform Apps component that could lead to local escalation of privilege 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.

**Announcements**

*   In addition to the security vulnerabilities described in the January 2023 Android Security Bulletin, the January 2023 Android Automotive OS Update Bulletin also contains patches specifically for AAOS vulnerabilities as described below.

**2023-01-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2023-01-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.

**Media Framework**

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

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20353

A-221041256

ID

High

10, 11

**Platform Apps**

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-39738

A-216190509

EoP

High

10, 11, 12, 12L

CVE-2022-20425

A-255830464

DoS

High

10, 11

**Additional vulnerability details**

The section below provides details for security vulnerabilities that are being provided for disclosure purposes. **These issues are not required for SPL compliance.**

**Platform Apps**

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20213

A-183410508

DoS

Moderate

10, 11, 12

CVE-2022-20215

A-183794206

DoS

Moderate

10, 11, 12

CVE-2022-20214

A-183411210

EoP

Low

10, 11, 12

**System UI**

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20458

A-205567776

EoP

Moderate

12L

**Kernel Components**

    

CVE

References

Type

Severity

Subcomponent

CVE-2022-28389

A-228694270  
Upstream kernel

EoP

Moderate

USB CAN bus driver

**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, read the instructions on the Google device update schedule.

*   Security patch levels of 2023-01-01 or later address all issues associated with the 2023-01-01 security patch level.

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

*   \[ro.build.version.security\_patch\]:\[2023-01-01\]

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

**2\. 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

**3\. 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 value 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

**4\. 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.

**5\. 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.

**6\. 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 2023-01-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.

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

**Versions**

  

Version

Date

Notes

1.0

January 3, 2022

Bulletin Published

CVE-2022-20213: Android Automotive OS Update Bulletin—January 2023  |  Android Open Source Project

Your smartphone or wearable could help you out in a truly dangerous situation. Here are some options to consider.

The Best Personal Safety Devices, Apps, and Alarms (2023)

Manufacturer complacency ‘translates into an unacceptable risk for consumers’, warns security expert

Manufacturer complacency ‘translates into an unacceptable risk for consumers’, warns security expert

IoT vendors are making slow progress in making it easy for security researchers to report security bugs, with only 27.1% of suppliers offering a vulnerability disclosure policy.

The figure, based on the latest annual report from the IoT Security Foundation (IoTSF), compares to the 9.7% of IoT (Internet of Things) vendors that were reported to have a disclosure policy in the 2018 edition of the same study.

BACKGROUND IoT Security Foundation launches vulnerability disclosure platform for smart device vendors

Vulnerability management ought to be a cornerstone of connected product security, widely recommended in 30 cybersecurity guidance initiatives including the IoTSF’s IoT Security Assurance Framework.

Straightforward reporting of security issues is essential for security lifecycle maintenance, and vendors risk falling foul of newly enacted UK regulations if they ignore best practice mandates.

The UK’s Product Security and Telecoms Infrastructure – which became law in early December 2022 – requires that IoT manufacturers, importers, and distributors offer a vulnerability disclosure policy, with suppliers who breach this risking potential sanctions including penalties of up to £20,000 per day in the most severe cases.

Catch up on the latest vulnerability disclosure policy news

The IoTSF’s latest study was based on a review of practice of 332 companies who sell consumer-focused IoT products. The review, carried out by mobile and IoT security consultancy Copper Horse, covered security practices tied to a range of products ranging from tablets and routers to smart home lighting controls and smart speakers.

Vendors from Asia tended to be better at establishing vulnerability disclosure programs, with European suppliers trailing significantly behind (34.7% versus 14.5%, respectively).

Laurie Mercer, senior manager of security engineering at HackerOne, said: “Knowing about security vulnerabilities within products and services through a Vulnerability Disclosure Policy (VDP) is an important way to identify and rectify them as part of the product security lifecycle.

“It’s a best practice that customers are increasingly looking for their supplier to adopt, but this research suggests it is not yet common practice.”

**Increased regulation**

Lawmakers across the world are looking to introduce regulations in order to push IoT vendors into making their products more secure. For example in the US lawmakers have established the IoT Cybersecurity Improvement Act (2020).

The draft European Cyber Resilience Act covers similar ground.

David Rogers, CEO of Copper Horse, told The Daily Swig: “The trend is towards mandating it – which makes you wonder again, why aren’t companies realising this? The writing is on the wall!”

Rogers added: “Even with the threat of incoming legislation, there is complacency in manufacturers that translates into an unacceptable risk for consumers when it comes to the security of IoT devices.”

During the study, researchers identified increases in the use of the ‘/security’ contact page, the use of machine-readable ‘secuity.txt’ files and a small decline in PGP key usage for secure submissions.

Other trends uncovered were an increase in the number of vendors that updated their policies and a rise in the number of companies using a third-party ‘proxy service’ to host and maintain their policies.

**Best practice**

It’s not all doom and gloom, however, as the report did highlight examples of good practice by some vendors.

Rogers explained: “Some companies and industries are starting to act in a much better way – there are some examples in the car industry such as Volkswagen Group where they have completely transformed their approach, in a positive way.

“I think these companies can set a good example to their peers in showing that you can work with the security research community without all the brinksmanship.”

Vendors would do well to have a safe harbor policy, a legal framework that allows ethical hackers to look for flaws in systems with risking legal threats or potential prosecution. LG, for example, operates a safe harbor policy for its IoT products.

Looking more broadly, the IoTSF report commends 34 vendors that “meet or exceed what will be required by legislation” based on a review of their policies by security researchers from Copper Horse. Firms listed include Bosch, BT, Canon, Huawei, LG, Logitech, Microsoft, Peloton, Samsung, and Wink.

YOU MAY ALSO LIKE WAGO fixes config export flaw threatening data leak from industrial devices

Tag

#samsung