Kategorie

No zero-day bugs, so by updating promptly you are keeping ahead of the crooks, not merely catching up!

Introduction Windows Credential Manager is a Windows feature that, both due to its user friendliness and popularity, was brought over to Windows 10. Since its debut in Windows 7, Credential Manager has helped users store both their web and Windows credentials in one convenient location which can be managed with just a few clicks.  This […]

The post How to use Credential Manager in Windows 10 appeared first on Infosec Resources.

How to use Credential Manager in Windows 10 was first posted on February 13, 2020 at 8:05 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

Today, we will be continuing with our exploration of Hack the Box (HTB) machines, as seen in previous articles. This walkthrough is of an HTB machine named Wall. HTB is an excellent platform that hosts machines belonging to multiple OSes. It also has some other challenges as well. Individuals have to solve the puzzle (simple […]

The post Hack the Box (HTB) machines walkthrough series — Wall appeared first on Infosec Resources.

Hack the Box (HTB) machines walkthrough series — Wall was first posted on February 13, 2020 at 8:01 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

Introduction Telecontrol Application Service Element (TASE) 2.0 is also known as Inter Control Center Protocol (ICCP) or International Electrotechnical Commission (IEC) 60870-6, but they are more commonly referred to as ICCP. Since different vendors had their own custom and proprietary protocols, there was a need for a common protocol for communication and data exchange between […]

The post TASE 2.0 and ICCP appeared first on Infosec Resources.

TASE 2.0 and ICCP was first posted on February 13, 2020 at 8:00 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

Introduction  In this episode of the Cyber Work with Infosec podcast (formerly CyberSpeak), Chris Sienko spoke with Elias Papatestas about the path you can take to become a network admin. Eli is a long-time veteran of the IT industry going back to the 1980s and has extensive experience in the finance, pharmaceutical and telecommunication industries. […]

The post Cyber Work Podcast: How to become a network admin appeared first on Infosec Resources.

Cyber Work Podcast: How to become a network admin was first posted on February 13, 2020 at 8:00 am.
©2017 "InfoSec Resources". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at darren.dalasta@infosecinstitute.com

Users of Dell SupportAssist should patch their software immediately to fix a software bug that could lead to arbitrary code execution.

Browser makers are working hard to build new privacy features that would protect users when surfing the web, and up to this point, Mozilla seems to be one of the innovators when it comes to such capabilities bundled with browsers.

Europe’s data protection laws are some of the strictest in the world, and have long been a thorn in the side of the data-guzzling Silicon Valley tech giants since they colonized vast swathes of the internet. Two decades later, one Democratic senator wants to bring many of those concepts to the United States. What is your opinion on this bill?

Microsoft has finally patched the Internet Explorer (IE) zero-day flaw the company said in January was being used in “limited targeted attacks”.

The FBI's Internet Crime Report shows that business email comprise is the biggest money-maker for cybercriminals.

The tech giant acknowledged some achievements in efforts to bolster mobile app security but recognized more needs to be done.

Nest users who aren't using 2FA or a Google account will be required to take an extra step by verifying their identity via email.

News overview

In the past quarter, DDoS organizers continued to harness non-standard protocols for amplification attacks. In the wake of WS-Discovery, which we covered in the previous report, cybercriminals turned to Apple Remote Management Service (ARMS), part of the Apple Remote Desktop (ARD) application for remote administration. The first attacks using ARMS were registered back in June 2019, and by early October the protocol was being used by DDoS-as-a-service providers; such attacks have since become widespread. According to the BinaryEdge portal, at the beginning of the quarter, nearly 40,000 systems running macOS with ARMS were available online.

Q4 was also marked by the growing number of peer-to-peer (P2P) botnets. Unlike the classic sort, these are independent of C&C servers, and thus more difficult to neutralize. In Q4 2019, researchers at 360 Netlab told about two new such botnets. The first, nicknamed Roboto, attacks Linux servers through a known vulnerability in the Webmin remote administration application. Experts note that the botnet has yet to carry out a DDoS attack, although it does have the functionality. The second P2P network, Mozi, is aimed at IoT devices and distributed using the DHT protocol, which is applied in distributed networks, such as BitTorrent, to quickly set up a P2P network. Mozi’s authors seemingly borrowed part of the code from the Gafgyt malware, which was designed to create a “classic” botnet.

Gafgyt’s developers also updated their creation. Researchers from Palo Alto Networks detected a new version of the malware that attacks Huawei HG532, Realtek RTL81XX, and Zyxel P660HN-T1A routers. The new version of the bot has even learned to wipe competitors from infected devices.

While some cybercriminals are updating their arsenal, others are using already proven tools and methods. For instance, in October and November 2019, researchers observed a wave of TCP reflection attacks. This method involves sending requests to legitimate services under the guise of the victim, who is then flooded with responses, so the IP addresses of the attackers do not light up. Over the past two years, such attacks have been on the rise. In October, the betting website Eurobet fell victim to cybercriminals, followed by several other sports betting organizations. Later that same month, a flurry of TCP reflection attacks hit financial and telecommunications companies in Turkey. Also named among the targets were Amazon and SoftLayer (a subsidiary of IBM).

Q4 saw attacks on Internet service providers in South Africa continue. In late October, cybercriminals overwhelmed Echo Service Provider — which serves the local providers Afrihost, Axxess, and Webafrica — with junk traffic. Clients of these organizations experienced downtime when connecting to foreign segments of the Internet. The attack reoccurred approximately one month later, and this time the list of victims included the providers RSAWEB and Cool Ideas.

Among the DDoS attacks launched against commercial organizations, worth highlighting is the campaign in October against financial institutions in South Africa, Singapore, and Scandinavia. The attackers sent emails to the victims, threatening to disable their systems and demanding a ransom; and to prove their intent, they carried out a short demonstration DDoS attack. For added effect, they posed as the infamous APT group Fancy Bear, inviting victims to look online for information about their past exploits. When the media reported the attacks, the ransomers renamed themselves Cozy Bear.

Curiously, the media failed to mention a single large-scale DDoS attack timed to coincide with the runup to the festive period. But political incidents did get coverage. For instance, on November 11 and 12, a month before the UK general election, attackers tried to disable the campaign site of the Labour Party.

In December, media outlets in Kyrgyzstan that had reported an investigation into the expenses of the wife of a former official suffered from DDoS attacks. A total of seven organizations were temporarily taken down by the hired hands of the disgruntled party. Another news portal later joined the list of victims, but perhaps for a different reason.

The Minecraft server of the Vatican (that’s right) was bombarded with junk traffic immediately after launch, in what could be described as an ideological attack. The purpose of the server was to create a “less toxic environment” for players, but the project attracted not only peace-loving players. The Vatican is now beefing up its protection. Ubisoft too was engaged in DDoS fire-fighting. The developer adopted a complex of measures to protect the servers of its video game Rainbow Six Siege, which had been on the receiving end of regular attacks. As a result, according to the company, the number of incidents decreased by 93%.

Law enforcement agencies were conspicuous in the struggle against DDoSers. For instance, in early November, Chinese authorities announced the arrest of a group which controlled a botnet of more than 200,000 infected sites. The operation took place in 20 cities; 41 people were detained. In the second half of the same month, the US sentenced Sergey Usatyuk to 13 months’ imprisonment for running DDoS-for-hire services together with an unknown accomplice in Canada. The cybercriminals had been active from 2015 to 2017. In the first 13 months of the operation, the service was used by 386,000 clients and 3.8 million DDoS attacks were carried out.

Quarter and year trends

As we predicted, Q4 saw an increase in the number of attacks relative to the previous reporting period. Although the rise in the total number of incidents was modest, smart attacks grew by a quarter, which is a fair amount. What’s more, not only the number of attacks increased, but their average duration. This was expected, since Q4 is a period of retail warfare, and we observe an increase in attacks from October to December every year.

If we compare the Q4 indicators with those for the same period last year, we see a near doubling in 2019. The end of 2018 was really very calm; we only noticed renewed growth in the attack market after a significant drop, which we wrote about in last year’s report. Back then, we correctly predicted a further rise in the number of attacks. This is clearly seen when comparing full data for 2018 and 2019.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Comparison of the number and duration of DDoS attacks in Q3 and Q4 2019, as well as Q4 2018; the Q4 figures were taken as the 100% reference value (download)

Overall, in 2019 we observed clear growth in all indicators compared to 2018. The total number of smart attacks saw particularly significant growth, as did their average duration. Last year, we forecast a rise in DDoS attacks, but did not expect such a leap.

The maximum duration of attacks also climbed, but not as significantly. In calculating the indicators, we excluded from the statistics an abnormally long attack carried out in Q3 2019, because it was an outlier case that would have unfairly distorted the annual figures.\

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Comparison of the number and duration of DDoS attacks in 2018 and 2019; the 2019 figures are taken as the 100% reference value (download)

Although Q4 saw an increase in the number and duration of DDoS attacks relative to the previous reporting period, we link this to the specifics of the quarter, not to a market trend. Seems like the DDoS market have re-stabilized — we see no prerequisites for either a fall or further growth. There have been no high-profile arrests or closures of specialized websites for quite some time, and the cryptocurrency market is not showing explosive growth. Nor have any serious vulnerabilities that would facilitate attacks been found recently. Looking at the trends of past years, we expect a slight decline in Q1 2020, yet will hazard a prediction that in absolute terms it will still be higher than the same period for 2019. Last year was an interesting one in the world of DDoS attacks. Let’s hope that 2020 decides to be boring.

Statistics Methodology

Kaspersky Lab has a long history of combating cyber threats, including DDoS attacks of all types and complexity. Company experts monitor botnets using the Kaspersky DDoS Intelligence system.

A part of Kaspersky DDoS Protection, the DDoS Intelligence system intercepts and analyzes commands received by bots from C&C servers. The system is proactive, not reactive, meaning that it does not wait for a user device to get infected or a command to be executed.

This report contains DDoS Intelligence statistics for Q4 2019.

In the context of this report, the incident is counted as a single DDoS-attack only if the interval between botnet activity periods does not exceed 24 hours. For example, if the same web resource was attacked by the same botnet with an interval of 24 hours or more, then this is considered as two attacks. Bot requests originating from different botnets but directed at one resource also count as separate attacks.

The geographical locations of DDoS-attack victims and C&C servers used to send commands are determined by their respective IP addresses. The number of unique targets of DDoS attacks in this report is counted by the number of unique IP addresses in the quarterly statistics.

DDoS Intelligence statistics are limited to botnets detected and analyzed by Kaspersky Lab. Note that botnets are just one of the tools used for DDoS attacks, and that this section does not cover every single DDoS attack that occurred during the review period.

Quarter summary

• China again took first place in terms of number of attacks, although its share slightly decreased (58.46% against 62.97% in Q3).
• Two newcomers entered the Top 10: Japan (straight in at number three with 4.86%) and Vietnam (0.68%), while South Africa and the Netherlands dropped out.
• The Top 3 countries by number of targets traditionally coincides with leaders by number of attacks: China (53.07%), the US (22.01%), and Japan (6.14%).
• The past quarter was characterized by a low number of attacks: the most active days saw just over 250 attacks, and the quietest only eight.
• DDoS botnet activity was distributed fairly evenly throughout the quarter itself and on individual days of the week, with the safest and most dangerous days differing by just 2.5 p.p.
• The three longest attacks lasted more than 20 days (494, 492, and 486 hours), which is almost twice as long as last quarter’s leader.
• Among the attack types, SYN flooding (6%) still leads. The share of TCP-based attacks continued to grow and overtook UDP flooding, while ICMP flooding showed a significant increase.
• The ratio of Windows and Linux botnets remained virtually unchanged, with the latter still responsible for the overwhelming majority (97.4%) of attacks.
• The number of C&C servers in absolute terms more than halved. In the US, the absolute number changed slightly less, leading to a sharp increase in the country’s share in the overall picture (58.33% up from 47.55%), while the Netherlands this quarter fell from second position to the foot of the table.

Attack geography

In the past quarter, China held on to the lead in terms of number of attacks, although its share continued to decline (this time by 4.5 p.p. down to 58.46%). The US position did not change either, remaining in second place, with 17.49% of all attacks (almost the same as last quarter’s 17.37%). Third position enjoyed no such stability: Hong Kong, the previous occupier, fell two places to fifth (3.73% against 5.44%), making way for Romania (fourth place with 4.56%, up almost 3.5 p.p.) and Japan, which not only entered the Top 10 for the first time in a year, but shot straight into third place (4.86% against last quarter’s 0.2% and 18th place).

Another newcomer to the ranking is Vietnam. Having narrowly failed to reach the Top 10 in Q3 (11th place), at the end of the year the country experienced a rise of 0.13 p.p. in its share of attacks, enough to cross the threshold. South Africa flew out of the Top 10 almost as swiftly as it had flown in, swapping fourth place for 15th. Slightly less sharp, but also significant, was the drop in the share of attacks on targets in the Netherlands, relegating the country to 14th position.

There were no major changes in the rest of the Top 10, only some shuffling of places. Romania rose from sixth place to fourth with 4.56%; South Korea from eighth to seventh (0.94%), and Canada tenth to eighth (0.83%). The UK (1.01%) and Singapore (0.72%), meanwhile, fell slightly — from fifth to sixth and seventh to ninth, respectively.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by country, Q3 and Q4 2019 (download)

The geography of unique targets is traditionally similar to the distribution of the attacks themselves. The Top 3 in both cases is identical. The share of targets in China also fell against Q3, down to 53.07%; the US still accounts for around a fifth of targets (22.01%), while Japan’s share increased 20-fold to 6.14%.

The Top 5 was again rounded out by Romania and Hong Kong, but in reverse order: this time fourth place went to the latter (4.14%), and fifth to the former (1.95%). The UK (1.53%) retains sixth place in both categories. It is followed by Canada (0.93%) and Vietnam (0.84%). Propping up the Top 10 are Australia (0.82%), up from 14th place over the quarter, and Singapore (0.78%). As such, this quarter’s newcomers — Japan, Australia, and Vietnam — squeezed out the leaders by number of unique targets — South Africa, the Netherlands, and France, which occupied 14th, 12th, and 11th places this quarter, respectively.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of unique DDoS-attack targets by country, Q3 and Q4 2019 (download)

Dynamics of the number of DDoS attacks

Q4 was even calmer than the preceding quarter. Even on the stormiest days (November 24 and December 11), the number of attacks barely exceeded 250 (recall that last year’s likewise relatively calm Q4 experienced a maximum of 457 attacks per day — almost twice as many). The total number of days that saw more than 200 attacks was also small — besides those already mentioned, October 6 and 7 and November 25 were also quite turbulent. Meanwhile, the quietest day, October 13, set a new record with only eight attacks recorded (the previous record-holder being May 25, 2018, with 13 attacks).

Curiously, this year there were no typical Q4 peaks on Black Friday and over Christmas: both periods were reasonably calm, and the attacks throughout the quarter were distributed fairly evenly.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Dynamics of the number of DDoS attacks in Q4 2019 (download)

The attack distribution by day of the week also flattened out considerably: the difference between the calmest and most dangerous day was only about 2.5 p.p. (having approached 7.7 p.p. in the previous reporting period). Attack organizers this quarter were particularly busy on Tuesdays (15.46%), and preferred to put their feet up on Thursdays (12.98%). The former first- and second-placed Monday (down 3.5 p.p.) and Sunday (up nearly 2.5 p.p.) showed the biggest change against the preceding quarter.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by day of the week, Q3 and Q4 2019 (download)

Duration and types of DDoS attacks

While the number of attacks fell, their duration rose significantly compared to the previous quarter. As such, the three longest attacks in the three-month period were ongoing for more than 20 days (494, 492, and 486 hours), while in the quarter before not a single one lasted 12 days. Nevertheless, the record for duration remains an attack carried out in Q2 2019 (506 hours, more than 21 days).

The average attack duration stayed approximately unchanged, while the share of the longest attacks (more than 140 hours) fell by a third to just 0.08%. Meanwhile, the share of the shortest attacks (up to 4 hours) also dropped in relative terms, decreasing by 2.5 p.p. to 81.86%.

But the proportion of attacks lasting 100–139 hours grew slightly (0.14%), as did attacks lasting 10–19 and 5–9 hours (5.33% and 10.19%, respectively). The two middle groups — attacks lasting 20–49 and 50–99 hours — fell insignificantly to 2.05% and 0.36%, respectively.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by duration (hours), Q3 and Q4 2019 (download)

The share of SYN flooding this quarter amounted to 84.6%, while UDP attacks surrendered second place to TCP, but only by a whisker (5.8% of all attacks against the latter’s 5.9%). The popularity of TCP attacks thus continues to grow (recall that last quarter they moved past HTTP flooding). The bottom two places did not change, although the shares of both types in the total number of attacks increased slightly: HTTP gained 0.5 p.p. (2.2%), while ICMP added 1.1 p.p. (1.6%).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by type, Q4 2019 (download)

Linux botnets did not partake in the growth trend: this quarter their share marginally decreased to 97.4% (against 97.75% in the previous quarter). Accordingly, the share of Windows botnets grew by the same amount (0.35 p.p.) to 2.6%.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Ratio of Windows/Linux botnet attacks, Q3 and Q4 2019 (download)

Botnet distribution geography

In Q4 last year, the vast majority of botnets (58.33%) were registered in the US (up from 47.55% in the previous quarter). At the same time, the absolute number of C&C servers in the country almost halved.

The UK (14.29%) moved to runner-up spot, and China retained third (9.52%, roughly 3 p.p. higher than the quarter before). Fourth and fifth places this quarter went to Russia (3.57%) and Iran (2.38%), which climbed from 11th place. The combined share of other countries in the distribution of botnets is below 2%.

The most significant drop in the number of C&C servers was observed in the Netherlands, down from 45 to just one. In Germany and Vietnam, both in last quarter’s Top 10, no active botnets were registered this quarter.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of botnet C&C servers by country, Q4 2019 (download)

Conclusion

Q4 2019 saw stability in some areas and sharp changes in others. For instance, in the geographical distribution, Japan broke straight into the Top 3, while two of the previous quarter’s newcomers, contrary to the norm, secured a footing in the Top 10. At the same time, the geographical distribution of unique targets traditionally mirrors the distribution of the total number of attacks.

Another notable difference between Q3 and Q4 last year was the number and chronology of attacks. Thus, at the end of the year, the distribution by month, as well as by day of the week, was far more uniform. To the surprise of experts, the traditional peaks on Black Friday and over the Christmas and New Year season did not materialize. The duration of the longest attack almost doubled, coming dangerously close to the record set in Q2 2019.

Tellingly, in the last quarter of the year, the number of both attacks and C&C servers fell sharply, while the number of extra-long attacks (over 400 hours) was the highest ever recorded in the history of our observations. This is perhaps evidence of an upward trend in the number of complex and meticulously planned attacks, albeit at the expense of the total number of attacks.

Čínské ministerstvo obrany vyzvalo Spojené státy, aby stáhly obvinění proti čtyřem příslušníkům čínské armády za průnik do sítě americké úvěrové kanceláře Equifax. Informovala o tom agentura Reuters. USA obvinění za průlom, který v roce 2017 postihl na 150 milionů Američanů, oznámily v pondělí, kdy sdělily, že za akcí stála čtveřice čínských vojenských hackerů.

Posted by Andrew Ahn, Product Manager, Google Play + Android App Safety
[Cross-posted from the Android Developers Blog]

Google Play connects users with great digital experiences to help them be more productive and entertained, as well as providing app developers with tools to reach billions of users around the globe. Such a thriving ecosystem can only be achieved and sustained when trust and safety is one of its key foundations. Over the last few years we’ve made the trust and safety of Google Play a top priority, and have continued our investments and improvements in our abuse detection systems, policies, and teams to fight against bad apps and malicious actors.
In 2019, we continued to strengthen our policies (especially to better protect kids and families), continued to improve our developer approval process, initiated a deeper collaboration with security industry partners through the App Defense Alliance, enhanced our machine learning detection systems analyzing an app’s code, metadata, and user engagement signals for any suspicious content or behaviors, as well as scaling the number and the depth of manual reviews. The combination of these efforts have resulted in a much cleaner Play Store:

• Google Play released a new policy in 2018 to stop apps from unnecessarily accessing privacy-sensitive SMS and Call Log data. We saw a significant, 98% decrease in apps accessing SMS and Call Log data as developers partnered with us to update their apps and protect users. The remaining 2% are comprised of apps that require SMS and Call Log data to perform their core function.
• One of the best ways to protect users from bad apps is to keep those apps out of the Play Store in the first place. Our improved vetting mechanisms stopped over 790,000 policy-violating app submissions before they were ever published to the Play Store.
• Similarly to our SMS and Call Log policy, we also enacted a policy to better protect families in May 2019. After putting this in place, we worked with developers to update or remove tens of thousands of apps, making the Play Store a safer place for everyone.

In addition we’ve launched a refreshed Google Play Protect experience, our built-in malware protection for Android devices. Google Play Protect scans over 100B apps everyday, providing users with information about potential security issues and actions they can take to keep their devices safe and secure. Last year, Google Play Protect also prevented more than 1.9B malware installs from non-Google Play sources.
While we are proud of what we were able to achieve in partnership with our developer community, we know there is more work to be done. Adversarial bad actors will continue to devise new ways to evade our detection systems and put users in harm's way for their own gains. Our commitment in building the world's safest and most helpful app platform will continue in 2020, and we will continue to invest in the key app safety areas mentioned in last year’s blog post:

• Strengthening app safety policies to protect user privacy
• Faster detection of bad actors and blocking repeat offenders
• Detecting and removing apps with harmful content and behaviors

Our teams of passionate product managers, engineers, policy experts, and operations leaders will continue to work with the developer community to accelerate the pace of innovation, and deliver a safer app store to billions of Android users worldwide.

The release of Firefox 73 fixed high-severity memory safety bugs that could cause arbitrary code execution and missing bounds check that could enable memory corruption.

Among other issues, the music platform didn't limit the number of login attempts someone could make.

Posted by Jann Horn, Project Zero
IntroductionThis blog post discusses a bug leading to memory corruption in Samsung's Android kernel (specifically the kernel of the Galaxy A50, A505FN - I haven't looked at Samsung's kernels for other devices). I will describe the bug and how I wrote a (very unreliable) exploit for it. I will also describe how a second vulnerability, which had long been fixed in the upstream kernel, the upstream stable releases, and the Android common kernel, but not in Samsung's kernel, aided in its exploitation.
If you want to look at the corresponding source code yourself, you can download Samsung's kernel sources for the A505FN from here. The versions seem to be sorted such that the newer ones are at the top of the list; A505FNXXS3ASK9 is the newest one at the time of writing, corresponding to the November 2019 security patch level.Vendor-specific kernel modificationsOn Android, it is normal for vendors to add device-specific code to the kernel. This code is a frequent source of security vulnerabilities. Android has been reducing the security impact of such code by locking down which processes have access to device drivers, which are often vendor-specific. Modern Android phones access hardware devices through dedicated helper processes, which form the Hardware Abstraction Layer (HAL).
(As an aside: Linux supports secure, direct hardware access from userspace to PCI devices via Virtual Function I/O (since Linux 3.6), and to USB devices via /dev/bus/usb/. If more OEMs used these mechanisms instead of out-of-tree drivers, this would improve their device security. It would also help with the issue of maintaining those drivers, since these mechanisms use stable userspace APIs instead of kernel APIs that have no such guarantees.)
Unfortunately, it is more difficult to generically lock down the attack surface that is created when vendors modify core kernel functionality.
For example, Samsung's kernel adds extra "protection" to credential structures: struct cred is made read-only with the assistance of hypervisor code (CONFIG_RKP_KDP, "Protection for cred structure"), and transitions to UID 0 are subject to special checks based on the path of the current executable (CONFIG_SEC_RESTRICT_SETUID, “Restrict changing root privilege except allowed process”). But none of these modifications actually prevent an attacker who has sufficient control over the kernel to modify credential structures from reading or modifying user data directly. For example, an attacker could:

• In order to directly gain access to resources that are supposed to be inaccessible to the attacker:
• modify file-system-internal data structures to give themselves access to inodes that wouldn't be accessible normally (as demonstrated further down in this blogpost)
• directly read secrets from kernel memory
• In order to gain control over processes that have interesting privileges or access to interesting data, such as an email application, a messenger app, the zygote or system_server - since virtually all user data is accessible to at least one userspace context:
• modify userspace code that is present in the page cache through the direct mapping (also known as "physmap" among security folks)
• modify the saved register state of other userspace processes that are stored in the kernel
• modify userspace pointers that are saved in the kernel and will later be used to write to userspace
• modify memory management state such that victim-process-owned pages will become accessible to an attacker process

Of course, this is a non-exhaustive list. In other words, Samsung's protection mechanisms won't provide meaningful protection against malicious attackers trying to hack your phone, they only block straightforward rooting tools that haven't been customized for Samsung phones. My opinion is that such modifications are not worth the cost because:

• They make it more difficult to rebase onto a new upstream kernel, which should be happening more often than it currently does
• They add additional attack surface

Samsung's "Process Authenticator" (PROCA)The subsystemThe Samsung kernel on the A50 contains an extra security subsystem (named "PROCA", short for "Process Authenticator", with code in security/proca/) to track process identities. By combining several logic issues in this subsystem (which, on their own, can already cause a mismatch between the tracking state and the actual process state) with a brittle code pattern, it is possible to cause memory unsafety by winning a race condition.
PROCA seems to track information about process identities based on ASN.1-encoded signatures attached to their executable files. It might be making that information available to a hypervisor, but that's just speculation on my part. The ASN.1-encoded signatures are loaded from the extended attribute user.pa ; the extended attribute security.five also plays a role. I believe that offsets into PROCA's data structures are exposed to something outside the kernel through the GAFINFO structure in drivers/staging/samsung/sec_gaf_v5.c - this might be for a hypervisor, but if so, I haven't yet figured out where that hypervisor code is on the A50 or how that hypervisor can protect accesses to PROCA's data structures against concurrency, given that GAFINFO doesn't contain any information about where locks are located.
There are only a small number of files in the /system and /vendor filesystems that have a user.pa attribute:

• /vendor/bin/hw/wpa_supplicant
• /vendor/bin/vendor.samsung.security.wsm@1.0-service
• /system/app/SecurityLogAgent/SecurityLogAgent.apk
• /system/app/Bluetooth/oat/arm64/Bluetooth.odex
• /system/app/Bluetooth/Bluetooth.apk
• /system/priv-app/Fast/oat/arm64/Fast.odex
• /system/priv-app/Fast/Fast.apk
• /system/bin/apk_signer
• /system/bin/dex2oat
• /system/bin/patchoat
• /system/bin/vold
• /system/framework/oat/arm64/services.odex
• /system/framework/services.jar

(The signatures can be decoded on a Linux machine after mounting the filesystems from a factory image with a command like "getfattr -e base64 -n user.pa system/bin/dex2oat | grep -F 'user.pa=' | sed 's|^user.pa=0s||' | openssl asn1parse"; the ASN.1 structure can be seen in security/proca/proca_certificate.asn1.)
The main data structure of PROCA is the per-process struct proca_task_descr, which looks as follows (lightly edited output from pahole):
struct proca_task_descr {  struct task_struct *       task;                /* 0 0x8 */  struct proca_identity {    void *             certificate;           /* 0x8 0x8 */    long unsigned int  certificate_size;           /* 0x10 0x8 */    struct proca_certificate {      char *     app_name;                           /* 0x18 0x8 */      long unsigned int app_name_size;                /* 0x20 0x8 */      char *     five_signature_hash;                 /* 0x28 0x8 */      long unsigned int five_signature_hash_size;     /* 0x30 0x8 */    } parsed_cert;                                  /* 0x18 0x20 */    struct file *      file;           /* 0x38 0x8 */  } proca_identity;                               /* 0x8 0x38 */  struct hlist_node {    struct hlist_node * next;                       /* 0x40 0x8 */    struct hlist_node * * pprev;                    /* 0x48 0x8 */  } pid_map_node;                                 /* 0x40 0x10 */  struct hlist_node {    struct hlist_node * next;                       /* 0x50 0x8 */    struct hlist_node * * pprev;                    /* 0x58 0x8 */  } app_name_map_node;                            /* 0x50 0x10 */};
One instance of struct proca_task_descr exists for each running process that is currently executing an executable with the user.pa extended attribute.
Instances of struct proca_task_descr are addressed through g_proca_table, which is a global instance of struct proca_table, a container structure for two hash tables with locks:
struct proca_table { unsigned int hash_tables_shift;
DECLARE_HASHTABLE(pid_map, PROCA_TASKS_TABLE_SHIFT); spinlock_t pid_map_lock;
DECLARE_HASHTABLE(app_name_map, PROCA_TASKS_TABLE_SHIFT); spinlock_t app_name_map_lock;};
While the kernel maintains both hash tables, it only ever performs lookups in the pid_map - the app_name_map is either unused or used solely for lookups from hypervisor code.Two logic bugspid_map uses numeric PIDs as lookup keys (where PID has the kernel meaning "per-task/per-thread ID", not the userspace meaning "per-thread-group ID"). The following cases are the most interesting ones where this map is modified:

• When a task creates a child that doesn't share the parent's virtual memory mappings (CLONE_VM is unset), five_hook_task_forked() posts a TASK_FORKED work item onto the g_hook_workqueue. When this work item is asynchronously processed, if a struct proca_task_descr exists for the parent's PID, a copy is created for the child's PID. The kernel's hashtable implementation allows multiple entries with the same key, so if an entry for the child's PID already exists in the table, this adds another entry.
• When a task goes through execve() (more specifically, in search_binary_handler()), five_hook_file_processed() collects some information about the binary being executed, then posts a FILE_PROCESSED work item onto the g_hook_workqueue. When this work item is asynchronously processed, an item may be inserted into or deleted from the pid_map depending on the pre-execve() state and the new executable.
• When a struct task_struct is freed, proca_task_free_hook() synchronously removes the table entry for its PID.

This means that the state of the PROCA subsystem can easily get out of sync with the actual state of the system. One problem is that the point where PROCA believes that an execution has occurred (the security hook in search_binary_handler()) is before the "point of no return" in the execve() path: The execution may still abort at a later point, leaving the original executable running, but letting PROCA believe that a new executable is now running. If PROCA was actually used to make authentication decisions, this might allow an attacker to impersonate a privileged executable while actually running attacker-owned code.
But the more interesting logic bug is that PIDs can be reused long before the proca_task_free_hook() is triggered: On Linux, the PID of a task is available for reallocation once the task has been reaped (transitioned from Zombie to Dead), but the task is only freed (triggering the hook) once all refcounted references to the task_struct are gone. While most well-behaved kernel code only takes short-lived references to it, the binder driver takes long-term references to it - in one place in the upstream code, in two places in the version in Android's common kernel tree and Samsung's kernel (because of some priority boosting logic that doesn't exist upstream). This is a potential correctness issue for PROCA, since it means that after a PROCA-authenticated task has died, a new process that reuses the PID might incorrectly be considered authenticated; but more importantly, in combination with the following brittle code, it causes a memory safety problem.A memory safety bugThere is some suspicious locking (dropping and re-acquiring a lock in the middle of an operation) in proca_table_remove_by_pid() (at the bottom of security/proca/proca_table.c), the helper used by proca_task_free_hook() to look up and, if successful, remove an entry from the pid_map:
void proca_table_remove_task_descr(struct proca_table *table,        struct proca_task_descr *descr){[...]  spin_lock_irqsave(&table->pid_map_lock, irqsave_flags);  hash_del(&descr->pid_map_node);  spin_unlock_irqrestore(&table->pid_map_lock, irqsave_flags);
[... same thing for app_name_map ...]}
struct proca_task_descr *proca_table_get_by_pid(          struct proca_table *table, pid_t pid){  struct proca_task_descr *descr;  struct proca_task_descr *target_task_descr = NULL;  unsigned long hash_key;  unsigned long irqsave_flags;
  hash_key = calculate_pid_hash(table, pid);
  spin_lock_irqsave(&table->pid_map_lock, irqsave_flags);  hlist_for_each_entry(descr, &table->pid_map[hash_key], pid_map_node) {    if (pid == descr->task->pid) {      target_task_descr = descr;      break;    }  }  spin_unlock_irqrestore(&table->pid_map_lock, irqsave_flags);
  return target_task_descr;}
struct proca_task_descr *proca_table_remove_by_pid(          struct proca_table *table, pid_t pid){  struct proca_task_descr *target_task_descr = NULL;
  target_task_descr = proca_table_get_by_pid(table, pid);  proca_table_remove_task_descr(table, target_task_descr);
  return target_task_descr;}
As you can see, proca_table_remove_by_pid() first performs the table lookup while holding the pid_map_lock, looking for an item with a matching PID. Then, it grabs a raw pointer to the item (without incrementing a reference counter or anything like that), drops the lock, takes the lock again, and removes the element from the hash table. This pattern is only safe if it is guaranteed that there can't be two concurrent calls to proca_table_remove_by_pid() for the same PID. However, this function is called only when the last reference to a task has been dropped, which, as explained above, can be delayed to a time at which the PID has already been reused. Therefore, this function can be called concurrently for a single PID, and when that happens, this bug can cause a proca_task_descr to be torn down and released a second time. The following operations will happen on the already-freed proca_task_descr in that case:

• two hash_del() calls in proca_table_remove_task_descr()
• destroy_proca_task_descr():
• deinit_proca_identity():
• deinit_proca_certificate() calls kfree() on two members
• fput(identity->file) unless the file is NULL
• kfree(identity->certificate)
• kfree() on the proca_task_descr

There are several ways one might try to exploit this. I decided to exploit it as a use-after-free list unlink (via hash_del()) and ignore the double-free aspect.Becoming authenticatedAs a first step, we'll want to make PROCA track one of our attacker-controlled processes. As far as I can tell, this probably isn't supposed to be possible because PROCA only tracks processes that run specific binaries that are marked with special attributes, presumably based on the idea that they run trusted code; but we can make PROCA track our own processes using the logic bugs.
One way to do this would be to cause an execution to abort after the security hook in search_binary_handler() (e.g. because something goes wrong while looking up the interpreter), but I couldn't find an easy way to do this in practice. Therefore, I decided to use the second logic bug described in the section "Two logic bugs", reusing a PID while it is still being tracked:

• Let the attacker-owned process P1 create a child P2 that shares P1's file descriptor table.
• Let P2 open /dev/binder, causing the resulting file's struct binder_proc to hold a reference to P2.
• Let P2 execute /system/bin/dex2oat --blah. dex2oat is a file we're allowed to execute from app context (and also from adb shell context) that comes with a user.pa extended attribute, so at this point P2 is tracked by PROCA.
• dex2oat is called with invalid arguments, so P2 prints some usage information and exits, turning into a Zombie.
• P1 reaps P2 with waitpid(), so P2 becomes Dead. However, the /dev/binder file (which is referenced from a file descriptor table shared with P1 and therefore wasn't closed when P2 exited) still references P2, so P2's task_struct won't be freed, and the associated entry isn't removed from the pid_map.
• P1 keeps forking children until there is a child P3 which has the same PID as P2. At this point, P3 is tracked by PROCA because its PID has an entry in the pid_map. (If there is hypervisor code involved with PROCA, we don't know how it feels about this, considering that {proca_task_descr}->task still points to P2; but the kernel code doesn't care.)

Basic race scenarioTo cause the race between two concurrent proca_table_remove_by_pid() calls, we need to have two tasks with the same PID that are freed concurrently. The usual last reference to a task comes through its struct pid, whose lifetime is subject to an unusual flavor of RCU semantics. Since we don't want the freeing to happen whenever the kernel decides to run RCU callbacks, we'll have to create different counted references to the tasks.
(Irrelevant sidenote: struct pid's refcount does not have RCU semantics, instead the reference from a living task does. This means that you can, while being in an RCU read-side critical section without any extra locks and without elevating any refcounts, unconditionally increment the refcount of any struct pid as long as you got the pointer to it from a task_struct in the same RCU read-side critical section. This is a pattern that you don't see much in the Linux kernel.)
One helpful reference-counted pointer to a task exists in binder's struct binder_thread: When a binder_thread is created, it takes a reference to the calling task, and when it is destroyed via ioctl(..., BINDER_THREAD_EXIT, ...), it synchronously drops a reference on the task. At first I thought that I could only use this for one side of the race: BINDER_THREAD_EXIT only allows us to free binder_thread instances whose PID matches the caller's PID, so it seemed like it was impossible to call this twice in parallel for the same PID. For this reason, in my original crasher, I triggered the inner side of the race by closing a binder file descriptor, triggering the file's ->release() handler, which posts the work item binder_deferred_work onto the global workqueue. When this item is processed, the binder_proc's task reference is dropped.
But actually, there is a way to use BINDER_THREAD_EXIT for both sides of the race: We can create a binder_thread whose ->pid does not match the PID of its associated task (->task->pid) if we can change the task's ->pid at a later point. That is possible by calling execve() from a non-leader thread - in other words, from a thread other than the one thread the process had when it last went through execve() or was created by fork(). When this happens, the calling thread steals the ->pid of the leader. (Essentially, on Linux, when a thread that isn't the main thread calls execve(), that thread first halts all its sibling threads, then assumes the identity of the main thread. This is implemented in de_thread() in fs/exec.c.)
So, to trigger the race, we need to:

1. Let task A (with PID P1) call BINDER_THREAD_EXIT to start freeing a task with PID P1.
2. Somehow stall the execution of thread A in the middle of the race window, while the pid_map_lock is dropped.
3. Let task B (with PID P2) call BINDER_THREAD_EXIT to free a task with PID P1, using a binder_thread whose ->pid doesn't match ->task->pid. After this step, the proca_task_descr that task A is currently operating on has been freed.
4. Reallocate the proca_task_descr's memory as something else with controlled data.
5. Let task A continue deleting the already-freed object (UAF followed by double-free).

Widening the race windowTo create a sufficiently large race window while task A is between the two locked regions, we can abuse preemption, similar to the mremap() issue I have written about before (see section "Locks and preemption") and gave a talk about (in case you want the long video version). However, unlike the mremap() issue, we are holding a spinlock here until we reach the spot where we want to preempt the task. This is very helpful: On CONFIG_PREEMPT systems, if the scheduler wants to preempt a task while that task is holding a spinlock, it sets a flag on the task that causes the task to move off the CPU as soon as it's done with the spinlocked region. (Actually, I think that in this case, the flag can't even be set in the middle of the spinlocked region because interrupts are disabled, too, so I think the scheduler IPI is actually only going to be delivered when we reach spin_unlock_irqrestore(). But that doesn't really matter here.)
Since the unlocked region is very short, we'll want to instead make the spinlocked region before it as big as we can, and then try to preempt task A in the middle of it. What task A does while holding the lock is a simple hash table lookup:
  hash_key = calculate_pid_hash(table, pid);
  spin_lock_irqsave(&table->pid_map_lock, irqsave_flags);  hlist_for_each_entry(descr, &table->pid_map[hash_key], pid_map_node) {    if (pid == descr->task->pid) {      target_task_descr = descr;      break;    }  }  spin_unlock_irqrestore(&table->pid_map_lock, irqsave_flags);
Hash tables are supposed to be more or less constant-time under normal conditions, but in the worst case, they deteriorate into linked lists and have O(n) lookup time instead of ~O(1). (This was presented as the hashDoS attack at 28C3, with a focus on Denial of Service attacks, but it can also be used for various other tricks, including leaking addresses encoded in the lookup key or to widen race windows.) Since calculate_pid_hash() doesn't have any secret parameters, we can easily determine which PIDs will fall into the same list bucket as the one we're using for the race, and fill the hash table bucket with lots of proca_task_descr instances whose truncated PID hash collides while the PID itself doesn't collide, forcing lookups for the target PID to walk through a large number of non-matching entries first.An unfixed infoleak from September 2018Figuring out where preemption occurredAt this point, we can repeatedly preempt task A, and one of those preemptions will happen directly at the spin_unlock_irqrestore(). However, we need to figure out which of the preemption events happens in that spot so that we know when to run the inner side of the race. One way to do this would be to just observe scheduling latency, and that should work if we make the hash bucket sufficiently big - but there is a nicer way.
Back in September 2018, I reported a security bug in the /proc/$pid/stack interface and sent a patch that restricts this interface to root. That patch was quickly applied to mainline, the upstream stable trees, and the Android common kernel. Someone even assigned a CVE identifier to it, CVE-2018-17972. But in the Android ecosystem, that doesn't mean that it actually makes its way into device kernels - and at least on this Samsung phone, it still hadn't landed in a build with security patch level "1 November 2019". (The patch is now present in the newest kernel image, with security updates from February 2020.)
Therefore, we can still use /proc/$pid/stack in our PoC. This file intentionally allows normal users to dump kernel stack traces of any tasks they own; it contains a symbolized stack trace, like this (with the marker 0xffffffffffffffff at the end):
a50:/ $ cat /proc/$$/stack[<0000000000000000>] __switch_to+0xbc/0xd8[<0000000000000000>] sigsuspend+0x3c/0x74[<0000000000000000>] SyS_rt_sigsuspend+0xa0/0xf8[<0000000000000000>] __sys_trace+0x68/0x68[<0000000000000000>] 0xffffffffffffffff
This means that every time we have preempted task A, we can read its /proc/$pid/stack and check whether it contains "proca_table_get_by_pid+"; and when it does, we're in the race window.
(While using /proc/$pid/stack this way makes it easier to write exploits for kernel race conditions, this is not the security bug that caused the interface to be restricted to root upstream; that security bug will be described in the next section.)Bypassing PAN using the direct mapping of a user pageOn Linux, the kernel's direct mapping area (also known as "physmap" among security folks) maps almost all memory as RW, including pages that are mapped into userspace as part of normal anonymous memory mappings. If we can locate such a page in the direct mapping, we have a known kernel address at which we can arbitrarily read/write data directly from userspace.
The security bug in the /proc/$pid/stack interface was that it performs stack tracing on a task that might be running concurrently, starting with the saved frame pointer from when the task was last scheduled off a CPU - which means that if the stack changed in the meantime, the kernel's stack tracer can end up interpreting random stack data as stack frames. To make things worse, when the stack tracer was unable to symbolize a saved instruction pointer, it would simply print out the raw value as a hexadecimal number. You can easily reproduce this as follows on an Android phone affected by the bug:
130|a50:/ $ cat /dev/zero > /dev/null &[1] 8559a50:/ $ while true; do grep ' 0x' /proc/8559/stack | grep -v 0xffffffffffffffff; done                                                                      [<0000000000000000>] 0x285ab42995[<0000000000000000>] 0xffffff8009b63b80[<0000000000000000>] 0x285ab42995[<0000000000000000>] 0x285ab42995[<0000000000000000>] 0x285ab42995[<0000000000000000>] 0x285ab42995[<0000000000000000>] 0x285ab42995[<0000000000000000>] 0x285ab42995[<0000000000000000>] 0x285ab42995[<0000000000000000>] 0x285ab42995[<0000000000000000>] 0xffffffc874325280[<0000000000000000>] 0xffffffc874325280[<0000000000000000>] 0xffffffc874325280[<0000000000000000>] 0xffffffc874325280[<0000000000000000>] 0x80000000
If we could specifically target things like e.g. the kernel-virtual address of a userspace-owned page with this, that would be very helpful for exploit writing.
After a few days spent on figuring out stack frame layouts, I found that this can be done by alternating the following two syscalls:

1. Call getcwd() on a non-present page and let it block on the mmap semaphore.
• We need to let another thread perform VMA allocations and deallocations in a loop to create contention on the mmap semaphore.
• The process will be scheduled away when attempting to acquire the mmap semaphore that has already been taken in write mode. When this happens, cpu_switch_to() in arch/arm64/kernel/entry.S saves the callee-saved registers, including the frame pointer, into {task}->thread.cpu_context.
• The frame pointer that was saved when scheduling away ({task}->thread.cpu_context.fp) points to a stack frame whose saved link register is in the same location as where X1 is stored during the other syscall.
2. Call process_vm_readv() with an output pointer that points to a non-present page.
• A page fault will be taken in the middle of copyout(), saving the complete register state in the exception frame.
• The saved X1 in the exception frame contains the kernel address at which the task's page is mapped by the kernel. Since process_vm_readv() lets us control the offset of the access, we can use the low 12 bits of the address as a marker that tells us whether the stack tracing operation raced in the right way and leaked the page pointer.

See addr_leak.c in our bugtracker for the call stacks and frame sizes.
Similarly, we can leak the address of the struct file associated with a pipe using sched_yield() and pipe-to-pipe splice(). The stack layouts for this look as follows (entry-from-EL0 exception frames not shown, since they look the same for all syscalls):
In this case, since we can't specify an arbitrary offset here as a signal to distinguish the target value, I determined the correct file* by performing an otherwise identical operation on two different pipe files and filtering out any numbers that show up in the stack traces in both cases.Spraying the heapThe proca_task_descr in which the UAF occurs is allocated using kzalloc(), so it must be in one of the kmalloc-* slabs. The slab is selected based on the size of the object; a proca_task_descr is 0x60==96 bytes big, which on an X86 desktop system would mean that the allocation lands in the kmalloc-96 slab. But such a slab doesn't exist on ARM64; the smallest slab there is kmalloc-128, which is used for all kmalloc() allocations up to 128 bytes.
Normally, to spray allocations through the slab allocator, a primitive is used that allocates a memory chunk with a size that falls within the right size bucket, fills it with attacker-controlled data, and then keeps a reference to the allocation around somehow so that the allocation won't be freed again immediately. However, instead, by relying on the allocation pattern of the SLUB allocator, we can combine two primitives instead: One to allocate some memory, fill it, then free it again immediately afterwards, the other to reallocate that memory and keep a reference to it around while leaving most of it uninitialized. We can e.g. do this by alternating calls to recvmsg() with the payload in the control message and calls to signalfd(): recvmsg() allocates a temporary buffer for the control message, copies the control message into it and frees the buffer, then signalfd() reallocates the 128-byte heap chunk as an 8-byte allocation and leaves the rest of it uninitialized.
Because the UAF will happen on a proca_task_descr that was allocated from the g_hook_workqueue, whose scheduling we can't control, we don't know on which CPU's slab it was allocated. On top of that, because we need to slowly create dummy proca_task_descr instances to fill up the hash bucket after creating the to-be-UAFed allocation, a significant amount of time passes between the allocation of the proca_task_descr and the UAF. My PoC attempts to perform reallocations on all CPU cores to avoid missing percpu slabs, but it still doesn't work very reliably, and I didn't want to invest more time into investigating this in detail. (I'm not sure whether this is the only major source of unreliability, or whether there are other parts of the exploit that are unreliable.)Getting arbitrary read/writeAt this point, we have everything we need for an (unreliable, because the heapspray doesn't work great) proof-of-concept that can gain arbitrary kernel read/write.
We can trigger the race, reallocating the freed buffer using the heapspray. The sprayed fake proca_task_descr can be used to perform a linked list unlink operation on two arbitrary addresses, causing them to point to each other. As one side of the unlink operation, we can use a pointer to the ->private_data member of a pipe file whose address we've leaked; as the other side, we can use the kernel mapping of the userspace-owned page whose kernel address we've leaked. With this, we have direct, full control over the struct pipe_inode_info used by this pipe file. By controlling the pipe_buffer instances to which the pipe_inode_info points, we can cause the pipe code to read from and write to arbitrary addresses, as long as they're in the direct mapping and the access range doesn't cross page boundaries.
At this point, extending that to full arbitrary read/write is rather easy; we can overwrite all sorts of pointers to data that the kernel will hand back to us.Doing something useful with the read/writeNormally we could stop at this point; arbitrary kernel read/write clearly means that all user data reachable by userspace and the kernel is compromised (unless the files are encrypted and the user hasn't entered the corresponding PIN yet). However, because of Samsung's attempts to prevent exploits from succeeding (such as CONFIG_RKP_KDP), I felt it was necessary to demonstrate that it is possible to access sensitive data using this arbitrary kernel read/write without doing anything particularly complex. Therefore, I wrote some code that can perform path walks through the dentry cache using the arbitrary read/write (just like the kernel would do it on the fastpath), look up an inode based on its path in a filesystem, and then install its ->i_mapping as the ->f_mapping of an attacker-owned instance of struct file. The PoC uses this to dump the contents of the accounts database at /data/system_ce/0/accounts_ce.db, which contains sensitive authentication tokens. The code for this is fairly straightforward and never touches any credential structures.ConclusionLinux kernel code has quite a few sharp edges - and modifications to such a codebase, in particular in a fork without any review from upstream maintainers, can easily introduce subtle issues, even if those modifications are for implementing "security" features.
In my opinion, some of the custom features that Samsung added are unnecessary, and can be removed without any loss of value. I can't tell what PROCA is supposed to do, but e.g., SEC_RESTRICT_SETUID seems to be designed to restrict an attacker who has already gained arbitrary kernel read/write - which to me seems futile, and engineering resources would have been better spent preventing an attacker from getting to that point in the first place.
I believe that device-specific kernel modifications would be better off either being upstreamed or moved into userspace drivers, where they can be implemented in safer programming languages and/or sandboxed, and at the same time won't complicate updates to newer kernel releases.
That I was able to reuse an infoleak bug here that was fixed over a year ago shows, once again, that the way Android device branches are currently maintained is a security problem. While I have criticized some Linux distributions in the past for not taking patches from upstream in a timely manner, the current situation in the Android ecosystem is worse. Ideally, all vendors should move towards using, and frequently applying updates from, supported upstream kernels.

From March, the Firefox, Chrome, Safari and Edge browsers will show warnings when users visit websites that only support TLS versions 1.0 or 1.1.

Are you a Firefox user? Mozilla has released Firefox 73 to the Stable desktop channel for Windows, macOS, and Linux with bug fixes, new features, and security fixes.