What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
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 | ★★★★ | |
|
2024-04-18 09:46:51 | The Windows Registry Adventure # 2: Une brève histoire de la fonctionnalité The Windows Registry Adventure #2: A brief history of the feature (lien direct) |
Posted by Mateusz Jurczyk, Google Project Zero Before diving into the low-level security aspects of the registry, it is important to understand its role in the operating system and a bit of history behind it. In essence, the registry is a hierarchical database made of named "keys" and "values", used by Windows and applications to store a variety of settings and configuration data. It is represented by a tree structure, in which keys may have one or more sub-keys, and every subkey is associated with exactly one parent key. Furthermore, every key may also contain one or more values, which have a type (integer, string, binary blob etc.) and are used to store actual data in the registry. Every key can be uniquely identified by its name and the names of all of its ascendants separated by the special backslash character (\'\\'), and starting with the name of one of the top-level keys (HKEY_LOCAL_MACHINE, HKEY_USERS, etc.). For example, a full registry path may look like this: HKEY_CURRENT_USER\Software\Microsoft\Windows. At a high level, this closely resembles the structure of a file system, where the top-level key is equivalent to the root of a mounted disk partition (e.g. C:\), keys are equivalent to directories, and values are equivalent to files. One important distinction, however, is that keys are the only type of securable objects in the registry, and values play a much lesser role in the database than files do in the file system. Furthermore, specific subtrees of the registry are stored on disk in binary files called registry hives, and the hive mount points don\'t necessarily correspond one-to-one to the top-level keys (e.g. the C:\Windows\system32\config\SOFTWARE hive is mounted under HKEY_LOCAL_MACHINE\Software, a one-level nested key). Fundamentally, there are only a few basic operations that can be performed in the registry. These operations are summarized in the table below: Hives Load hive Unload hive Flush hive to disk Keys Open key Create key Delete key | Tool Prediction Technical | ★★★★ | |
|
2023-11-03 10:04:59 | Premier combiné avec MTE sur le marché First handset with MTE on the market (lien direct) |
By Mark Brand, Google Project ZeroIntroduction It\'s finally time for me to fulfill a long-standing promise. Since I first heard about ARM\'s Memory Tagging Extensions, I\'ve said (to far too many people at this point to be able to back out…) that I\'d immediately switch to the first available device that supported this feature. It\'s been a long wait (since late 2017) but with the release of the new Pixel 8 / Pixel 8 Pro handsets, there\'s finally a production handset that allows you to enable MTE! The ability of MTE to detect memory corruption exploitation at the first dangerous access is a significant improvement in diagnostic and potential security effectiveness. The availability of MTE on a production handset for the first time is a big step forward, and I think there\'s real potential to use this technology to make 0-day harder. I\'ve been running my Pixel 8 with MTE enabled since release day, and so far I haven\'t found any issues with any of the applications I use on a daily basis1, or any noticeable performance issues. Currently, MTE is only available on the Pixel as a developer option, intended for app developers to test their apps using MTE, but we can configure it to default to synchronous mode for all2 apps and native user mode binaries. This can be done on a stock image, without bootloader unlocking or rooting required - just a couple of debugger commands. We\'ll do that now, but first:Disclaimer This is absolutely not a supported device configuration; and it\'s highly likely that you\'ll encounter issues with at least some applications crashing or failing to run correctly with MTE if you set your device up in this way. This is how I\'ve configured my personal Pixel 8, and so far I\'ve not experienced any issues, but this was somewhat of a surprise to me, and I\'m still waiting to see what the first app that simply won\'t work at all will be...Enabling MTE on Pixel 8/Pixel 8 Pro | Tool Mobile | ★★ | |
|
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 | ★★ | |
|
2022-08-24 12:08:43 | Racing against the clock -- hitting a tiny kernel race window (lien direct) | TL;DR: How to make a tiny kernel race window really large even on kernels without CONFIG_PREEMPT:use a cache miss to widen the race window a little bitmake a timerfd expire in that window (which will run in an interrupt handler - in other words, in hardirq context)make sure that the wakeup triggered by the timerfd has to churn through 50000 waitqueue items created by epoll Racing one thread against a timer also avoids accumulating timing variations from two threads in each race attempt - hence the title. On the other hand, it also means you now have to deal with how hardware timers actually work, which introduces its own flavors of weird timing variations.Introduction I recently discovered a race condition (https://crbug.com/project-zero/2247) in the Linux kernel. (While trying to explain to someone how the fix for CVE-2021-0920 worked - I was explaining why the Unix GC is now safe, and then got confused because I couldn't actually figure out why it's safe after that fix, eventually realizing that it actually isn't safe.) It's a fairly narrow race window, so I was wondering whether it could be hit with a small number of attempts - especially on kernels that aren't built with CONFIG_PREEMPT, which would make it possible to preempt a thread with another thread, as I described at LSSEU2019. This is a writeup of how I managed to hit the race on a normal Linux desktop kernel, with a hit rate somewhere around 30% if the proof of concept has been tuned for the specific machine. I didn't do a full exploit though, I stopped at getting evidence of use-after-free (UAF) accesses (with the help of a very large file descriptor table and userfaultfd, which might not be available to normal users depending on system configuration) because that's the part I was curious about. This also demonstrates that even very small race conditions can still be exploitable if someone sinks enough time into writing an exploit, so be careful if you dismiss very small race windows as unexploitable or don't treat such issues as security bugs. The UAF reproducer is in our bugtracker.The bug In the UNIX domain socket garbage collection code (which is needed to deal with reference loops formed by UNIX domain sockets that use SCM_RIGHTS | Tool Guideline | APT 25 | ★★ |
|
2022-08-24 12:02:07 | CVE-2021-1782, an iOS in-the-wild vulnerability in vouchers (lien direct) | Posted by Ian Beer, Google Project Zero This blog post is my analysis of a vulnerability exploited in the wild and patched in early 2021. Like the writeup published last week looking at an ASN.1 parser bug, this blog post is based on the notes I took as I was analyzing the patch and trying to understand the XNU vouchers subsystem. I hope that this writeup serves as the missing documentation for how some of the internals of the voucher subsystem works and its quirks which lead to this vulnerability. CVE-2021-1782 was fixed in iOS 14.4, as noted by @s1guza on twitter:  This vulnerability was fixed on January 26th 2021, and Apple updated the iOS 14.4 release notes on May 28th 2021 to indicate that the issue may have been actively exploited: |
Hack Tool Vulnerability Guideline | ★★★ | |
|
2022-06-14 09:00:24 | An Autopsy on a Zombie In-the-Wild 0-day (lien direct) | Posted by Maddie Stone, Google Project Zero Whenever there’s a new in-the-wild 0-day disclosed, I’m very interested in understanding the root cause of the bug. This allows us to then understand if it was fully fixed, look for variants, and brainstorm new mitigations. This blog is the story of a “zombie” Safari 0-day and how it came back from the dead to be disclosed as exploited in-the-wild in 2022. CVE-2022-22620 was initially fixed in 2013, reintroduced in 2016, and then disclosed as exploited in-the-wild in 2022. If you’re interested in the full root cause analysis for CVE-2022-22620, we’ve published it here. In the 2020 Year in Review of 0-days exploited in the wild, I wrote how 25% of all 0-days detected and disclosed as exploited in-the-wild in 2020 were variants of previously disclosed vulnerabilities. Almost halfway through 2022 and it seems like we’re seeing a similar trend. Attackers don’t need novel bugs to effectively exploit users with 0-days, but instead can use vulnerabilities closely related to previously disclosed ones. This blog focuses on just one example from this year because it’s a little bit different from other variants that we’ve discussed before. Most variants we’ve discussed previously exist due to incomplete patching. But in this case, the variant was completely patched when the vulnerability was initially reported in 2013. However, the variant was reintroduced 3 years later during large refactoring efforts. The vulnerability then continued to exist for 5 years until it was fixed as an in-the-wild 0-day in January 2022.Getting Started In the case of CVE-2022-22620 I had two pieces of information to help me figure out the vulnerability: the patch (thanks to Apple for sharing with me!) and the description from the security bulletin stating that the vulnerability is a use-after-free. The primary change in the patch was to change the type of the second argument (stateObject) to the function FrameLoader::loadInSameDocument from a raw pointer, SerializedScriptValue* to a reference-counted pointer, RefPtr. trunk/Source/WebCore/loader/FrameLoader.cpp | Tool Vulnerability Patching |
1
We have: 7 articles.
We have: 7 articles.
To see everything:
Our RSS (filtrered)
