What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2024-06-20 10:00:14 | Projet Nap-temps: évaluation des capacités de sécurité offensive des modèles de gros langues Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models (lien direct) |
Posted by Sergei Glazunov and Mark Brand, Google Project Zero IntroductionAt Project Zero, we constantly seek to expand the scope and effectiveness of our vulnerability research. Though much of our work still relies on traditional methods like manual source code audits and reverse engineering, we\'re always looking for new approaches. As the code comprehension and general reasoning ability of Large Language Models (LLMs) has improved, we have been exploring how these models can reproduce the systematic approach of a human security researcher when identifying and demonstrating security vulnerabilities. We hope that in the future, this can close some of the blind spots of current automated vulnerability discovery approaches, and enable automated detection of "unfuzzable" vulnerabilities. Earlier this year, Meta released CyberSecEval 2 (Bhatt et al., 2024), which includes new LLM benchmarks for discovering and exploiting memory safety issues. The authors presented the following conclusion: Another theme is that none of the LLMs do very well on these challenges. For each challenge, scoring a 1.0 means the challenge has been passed, with any lower score meaning the LLM only partially succeeded. The average scores of all LLMs over all tests suggests that LLMs have a ways to go before performing well on this benchmark, and aren’t likely to disrupt cyber exploitation attack and defense in their present states. We find that, by refining the testing methodology to take advantage of modern LLM capabilities, significantly better performance in vulnerability discovery can be achieved. To facilitate effective evaluation of LLMs for vulnerability discovery, we propose below a set of guiding principles. We\'ve implemented these principles in our LLM-powered vulnerability research framework, which increased CyberSecEval2 benchmark performance by up to 20x from the original paper. This approach achieves new top scores of 1.00 on the “Buffer Overflow" tests (from 0.05) and 0.76 on the "Advanced Memory Corruption" tests (from 0.24). We have included a full example trajectory/log in Appendix A. While we have shown that principled agent design can greatly improve the performance of general-purpose LLMs on challenges in the security domain, it\'s the opinion of the Project Zero team that substantial progress is still needed before these tools can have a meaningful impact on the daily work of security researchers. | Tool Vulnerability Threat | ★★ | |
|
2024-06-13 11:03:53 | Conduire dans les pilotes Android Driving forward in Android drivers (lien direct) |
Posted by Seth Jenkins, Google Project ZeroIntroduction Android\'s open-source ecosystem has led to an incredible diversity of manufacturers and vendors developing software that runs on a broad variety of hardware. This hardware requires supporting drivers, meaning that many different codebases carry the potential to compromise a significant segment of Android phones. There are recent public examples of third-party drivers containing serious vulnerabilities that are exploited on Android. While there exists a well-established body of public (and In-the-Wild) security research on Android GPU drivers, other chipset components may not be as frequently audited so this research sought to explore those drivers in greater detail.Driver Enumeration: Not as Easy as it Looks This research focused on three Android devices (chipset manufacturers in parentheses): - Google Pixel 7 (Tensor) - Xiaomi 11T (MediaTek) - Asus ROG 6D (MediaTek) In order to perform driver research on these devices I first had to find all of the kernel drivers that were accessible from an unprivileged context on each device; a task complicated by the non-uniformity of kernel drivers (and their permissions structures) across different devices even within the same chipset manufacturer. There are several different methodologies for discovering these drivers. The most straightforward technique is to search the associated filesystems looking for exposed driver device files. These files serve as the primary method by which userland can interact with the driver. Normally the “file” is open’d by a userland process, which then uses a combination of read, write, ioctl, or even mmap to interact with the driver. The driver then “translates” those interactions into manipulations of the underlying hardware device sending the output of that device back to userland as warranted. Effectively all drivers expose their interfaces through the ProcFS or DevFS filesystems, so I focused on the /proc and /dev directories while searching for viable attack surfaces. Theoretically, evaluating all the userland accessible drivers should be as simple as calling find /dev or find /proc, attempting to open every file discovered, and logging which open | Tool Vulnerability Threat Patching Mobile Technical | ★★★ | |
|
2024-04-18 09:53:59 | The Windows Registry Adventure # 1: Résultats d'introduction et de recherche The Windows Registry Adventure #1: Introduction and research results (lien direct) |
Posted by Mateusz Jurczyk, Google Project Zero In the 20-month period between May 2022 and December 2023, I thoroughly audited the Windows Registry in search of local privilege escalation bugs. It all started unexpectedly: I was in the process of developing a coverage-based Windows kernel fuzzer based on the Bochs x86 emulator (one of my favorite tools for security research: see Bochspwn, Bochspwn Reloaded, and my earlier font fuzzing infrastructure), and needed some binary formats to test it on. My first pick were PE files: they are very popular in the Windows environment, which makes it easy to create an initial corpus of input samples, and a basic fuzzing harness is equally easy to develop with just a single GetFileVersionInfoSizeW API call. The test was successful: even though I had previously fuzzed PE files in 2019, the new element of code coverage guidance allowed me to discover a completely new bug: issue #2281. For my next target, I chose the Windows registry. That\'s because arbitrary registry hives can be loaded from disk without any special privileges via the RegLoadAppKey API (since Windows Vista). The hives use a binary format and are fully parsed in the kernel, making them a noteworthy local attack surface. Furthermore, I was also somewhat familiar with basic harnessing of the registry, having fuzzed it in 2016 together with James Forshaw. Once again, the code coverage support proved useful, leading to the discovery of issue #2299. But when I started to perform a root cause analysis of the bug, I realized that: The hive binary format is not very well suited for trivial bitflipping-style fuzzing, because it is structurally simple, and random mutations are much more likely to render (parts of) the hive unusable than to trigger any interesting memory safety violations.On the other hand, the registry has many properties that make it an attractive attack | Tool Vulnerability Threat Studies | ★★★★ | |
|
2023-10-13 03:47:17 | Une analyse d'une webcontent de safari iOS dans la fenêtre dans l'exploit de processus GPU An analysis of an in-the-wild iOS Safari WebContent to GPU Process exploit (lien direct) |
By Ian Beer
A graph representation of the sandbox escape NSExpression payload
In April this year Google\'s Threat Analysis Group, in collaboration with Amnesty International, discovered an in-the-wild iPhone zero-day exploit chain being used in targeted attacks delivered via malicious link. The chain was reported to Apple under a 7-day disclosure deadline and Apple released iOS 16.4.1 on April 7, 2023 fixing CVE-2023-28206 and CVE-2023-28205.
Over the last few years Apple has been hardening the Safari WebContent (or "renderer") process sandbox attack surface on iOS, recently removing the ability for the WebContent process to access GPU-related hardware directly. Access to graphics-related drivers is now brokered via a GPU process which runs in a separate sandbox.
Analysis of this in-the-wild exploit chain reveals the first known case of attackers exploiting the Safari IPC layer to "hop" from WebContent to the GPU process, adding an extra link to the exploit chain (CVE-2023-32409).
On the surface this is a positive sign: clear evidence that the renderer sandbox was hardened sufficiently that (in this isolated case at least) the attackers needed to bundle an additional, separate exploit. Project Zero has long advocated for attack-surface reduction as an effective tool for improving security and this would seem like a clear win for that approach.
On the other hand, upon deeper inspection, things aren\'t quite so rosy. Retroactively sandboxing code which was never designed with compartmentalization in mind is rarely simple to do effectively. In this case the exploit targeted a very basic buffer overflow vulnerability in unused IPC support code for a disabled feature - effectively new attack surface which exists only because of the introduced sandbox. A simple fuzzer targeting the IPC layer would likely have found this vulnerability in seconds.
|
Tool Vulnerability Threat | ★★ | |
|
2023-09-19 09:01:22 | Analyse d'un exploit Android in-the-wild moderne Analyzing a Modern In-the-wild Android Exploit (lien direct) |
By Seth Jenkins, Project ZeroIntroductionIn December 2022, Google\'s Threat Analysis Group (TAG) discovered an in-the-wild exploit chain targeting Samsung Android devices. TAG\'s blog post covers the targeting and the actor behind the campaign. This is a technical analysis of the final stage of one of the exploit chains, specifically CVE-2023-0266 (a 0-day in the ALSA compatibility layer) and CVE-2023-26083 (a 0-day in the Mali GPU driver) as well as the techniques used by the attacker to gain kernel arbitrary read/write access.Notably, all of the previous stages of the exploit chain used n-day vulnerabilities:CVE-2022-4262, a vulnerability patched in Chrome that was unpatched in the Samsung browser (i.e. a "Chrome n-day"), was used to achieve RCE.CVE-2022-3038, another Chrome n-day, was used to escape the Samsung browser sandbox. CVE-2022-22706, a Mali n-day, was used to achieve higher-level userland privileges. While that bug had been patched by Arm in January of 2022, the patch had not been downstreamed into Samsung devices at the point that the exploit chain was discovered.We now pick up the thread after the attacker has achieved execution as system_server.Bug #1: Compatibility Layers Have Bugs Too (CVE-2023-0266)The exploit continues with a race condition in the kern | Vulnerability Threat Technical | ★★ | |
|
2022-11-10 13:10:11 | A Very Powerful Clipboard: Analysis of a Samsung in-the-wild exploit chain (lien direct) | Maddie Stone, Project ZeroNote: The three vulnerabilities discussed in this blog were all fixed in Samsung's March 2021 release. They were fixed as CVE-2021-25337, CVE-2021-25369, CVE-2021-25370. To ensure your Samsung device is up-to-date under settings you can check that your device is running SMR Mar-2021 or later.As defenders, in-the-wild exploit samples give us important insight into what attackers are really doing. We get the “ground truth” data about the vulnerabilities and exploit techniques they're using, which then informs our further research and guidance to security teams on what could have the biggest impact or return on investment. To do this, we need to know that the vulnerabilities and exploit samples were found in-the-wild. Over the past few years there's been tremendous progress in vendor's transparently disclosing when a vulnerability is known to be exploited in-the-wild: Adobe, Android, Apple, ARM, Chrome, Microsoft, Mozilla, and others are sharing this information via their security release notes.While we understand that Samsung has yet to annotate any vulnerabilities as in-the-wild, going forward, Samsung has committed to publicly sharing when vulnerabilities may be under limited, targeted exploitation, as part of their release notes. We hope that, like Samsung, others will join their industry peers in disclosing when there is evidence to suggest that a vulnerability is being exploited in-the-wild in one of their products. The exploit sampleThe Google Threat Analysis Group (TAG) obtained a partial exploit chain for Samsung devices that TAG believes belonged to a commercial surveillance vendor. These exploits were likely discovered in the testing phase. The sample is from late 2020. The chain merited further analysis because it is a 3 vulnerability chain where all 3 vulnerabilities are within Samsung custom components, including a vulnerability in a Java component. This exploit analysis was completed in collaboration with Clement Lecigne from TAG.The sample used three vulnerabilities, all patched in March 2021 by Samsung: Arbitrary file read/write via the clipboard provider - CVE-2021-25337 | Vulnerability Threat Guideline | ||
|
2022-08-24 11:58:33 | The curious tale of a fake Carrier.app (lien direct) | Posted by Ian Beer, Google Project Zero NOTE: This issue was CVE-2021-30983 was fixed in iOS 15.2 in December 2021. Towards the end of 2021 Google's Threat Analysis Group (TAG) shared an iPhone app with me:  |
Vulnerability Threat Guideline | ||
|
2022-08-24 11:55:31 | The quantum state of Linux kernel garbage collection CVE-2021-0920 (Part I) (lien direct) | A deep dive into an in-the-wild Android exploit Guest Post by Xingyu Jin, Android Security ResearchThis is part one of a two-part guest blog post, where first we'll look at the root cause of the CVE-2021-0920 vulnerability. In the second post, we'll dive into the in-the-wild 0-day exploitation of the vulnerability and post-compromise modules.Overview of in-the-wild CVE-2021-0920 exploits A surveillance vendor named Wintego has developed an exploit for Linux socket syscall 0-day, CVE-2021-0920, and used it in the wild since at least November 2020 based on the earliest captured sample, until the issue was fixed in November 2021. Combined with Chrome and Samsung browser exploits, the vendor was able to remotely root Samsung devices. The fix was released with the November 2021 Android Security Bulletin, and applied to Samsung devices in Samsung's December 2021 security update. Google's Threat Analysis Group (TAG) discovered Samsung browser exploit chains being used in the wild. TAG then performed root cause analysis and discovered that this vulnerability, CVE-2021-0920, was being used to escape the sandbox and elevate privileges. CVE-2021-0920 was reported to Linux/Android anonymously. The Google Android Security Team performed the full deep-dive analysis of the exploit. This issue was initially discovered in 2016 by a RedHat kernel developer and disclosed in a public email thread, but the Linux kernel community did not patch the issue until it was re-reported in 2021. Various Samsung devices were targeted, including the Samsung S10 and S20. By abusing an ephemeral race condition in Linux kernel garbage collection, the exploit code was able to obtain a use-after-free (UAF) in a kernel sk_buff object. The in-the-wild sample could effectively circumvent CONFIG_ARM64_UAO, achieve arbitrary read / write primitives and bypass Samsung RKP to elevate to root. Other Android devices were also vulnerable, but we did not find any exploit samples against them. Text extracted from captured samples dubbed the vulnerability “quantum Linux kernel garbage collection”, which appears to be a fitting title for this blogpost.Introduction CVE-2021-0920 is a use-after-free (UAF) | Vulnerability Threat Guideline |
1
We have: 8 articles.
We have: 8 articles.
To see everything:
Our RSS (filtrered)
