This is the RSS 2.0 feed from www.secnews.physaphae.fr. IT's a simple agragated flow of multiple articles soruces. Liste of sources, can be found on www.secnews.physaphae.fr. 2024-05-18T06:15:16+00:00 www.secnews.physaphae.fr ProjectZero - Blog de recherche Google 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]]> 2024-04-18T09:53:59+00:00 https://googleprojectzero.blogspot.com/2024/04/the-windows-registry-adventure-1.html www.secnews.physaphae.fr/article.php?IdArticle=8484833 False Tool,Vulnerability,Threat,Studies None 4.0000000000000000 ProjectZero - Blog de recherche Google Hives Load hive Unload hive Flush hive to disk Keys Open key Create key Delete key ]]> 2024-04-18T09:46:51+00:00 https://googleprojectzero.blogspot.com/2024/04/the-windows-registry-adventure-2.html www.secnews.physaphae.fr/article.php?IdArticle=8484832 False Tool,Prediction,Technical None 4.0000000000000000 ProjectZero - Blog de recherche Google 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 ]]> 2023-11-03T10:04:59+00:00 https://googleprojectzero.blogspot.com/2023/11/first-handset-with-mte-on-market.html www.secnews.physaphae.fr/article.php?IdArticle=8405411 False Tool,Mobile None 2.0000000000000000 ProjectZero - Blog de recherche Google 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. ]]> 2023-10-13T03:47:17+00:00 https://googleprojectzero.blogspot.com/2023/10/an-analysis-of-an-in-the-wild-ios-safari-sandbox-escape.html www.secnews.physaphae.fr/article.php?IdArticle=8395081 False Tool,Vulnerability,Threat None 2.0000000000000000 ProjectZero - Blog de recherche Google 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]]> 2023-09-19T09:01:22+00:00 https://googleprojectzero.blogspot.com/2023/09/analyzing-modern-in-wild-android-exploit.html www.secnews.physaphae.fr/article.php?IdArticle=8385365 False Vulnerability,Threat,Technical None 2.0000000000000000 ProjectZero - Blog de recherche Google v8.5a version of the ARM architecture, ARM proposed a hardware implementation of tagged memory, referred to as MTE (Memory Tagging Extensions). In Part 1 we discussed testing the technical (and implementation) limitations of MTE on the hardware that we\'ve had access to. In Part 2 we discussed the implications of this for mitigations built using MTE in various user-mode contexts. This post will now consider the implications of what we know on the effectiveness of MTE-based mitigations in the kernel context. To recap - there are two key classes of bypass techniques for memory-tagging based mitigations, and these are the following:Known-tag-bypasses - In general, confidentiality of tag values is key to the effectiveness of memory-tagging as a mitigation. A breach of tag confidentiality allows the attacker to directly or indirectly ensure that their invalid memory accesses will be correctly tagged, and therefore not detectable.Unknown-tag-bypasses - Implementation limits might mean that there are opportunities for an attacker to still exploit a vulnerability despite performing memory accesses with incorrect tags that could be detected. There are two main modes for MTE enforcement: Synchronous (sync-MTE) - tag check failures result in a hardware fault on instruction retirement. This means that the results of invalid reads and the effects of invalid writes should not be architecturally observable.Asynchronous (async-MTE) - tag check failures do not directly result in a fault. The results of invalid reads and the effects of invalid writes are architecturally observable, and the failure is delivered at some point after the faulting instruction in the form of a per-cpu flag. Since Spectre, it has been clear that using standard memory-tagging approaches as a "hard probabilistic mitigation"]]> 2023-08-02T09:30:22+00:00 https://googleprojectzero.blogspot.com/2023/08/mte-as-implemented-part-3-kernel.html www.secnews.physaphae.fr/article.php?IdArticle=8364821 True Vulnerability None 2.0000000000000000 ProjectZero - Blog de recherche Google v8.5a version of the ARM architecture, ARM proposed a hardware implementation of tagged memory, referred to as MTE (Memory Tagging Extensions). In Part 1 we discussed testing the technical (and implementation) limitations of MTE on the hardware that we\'ve had access to. This post will now consider the implications of what we know on the effectiveness of MTE-based mitigations in several important products/contexts. To summarize - there are two key classes of bypass techniques for memory-tagging based mitigations, and these are the following (for some examples, see Part 1):Known-tag-bypasses - In general, confidentiality of tag values is key to the effectiveness of memory-tagging as a mitigation. A breach of tag confidentiality allows the attacker to directly or indirectly ensure that their invalid memory accesses will be correctly tagged, and are therefore not detectable.Unknown-tag-bypasses - Implementation limits might mean that there are opportunities for an attacker to still exploit a vulnerability despite performing memory accesses with incorrect tags that could be detected. There are two main modes for MTE enforcement: Synchronous (sync-MTE) - tag check failures result in a hardware fault on instruction retirement. This means that the results of invalid reads and the effects of invalid writes should not be architecturally observable.Asynchronous (async-MTE) - tag check failures do not directly result in a fault. The results of invalid reads and the effects of invalid writes are architecturally observable, and the failure is delivered at some point after the faulting instruction in the form of a per-cpu flag. Since Spectre, it has been clear that using standard memory-tagging approaches as a "hard probabilistic mitigation"]]> 2023-08-02T09:30:14+00:00 https://googleprojectzero.blogspot.com/2023/08/mte-as-implemented-part-2-mitigation.html www.secnews.physaphae.fr/article.php?IdArticle=8364822 False Vulnerability,Studies None 2.0000000000000000 ProjectZero - Blog de recherche Google v8.5a version of the ARM architecture, ARM proposed a hardware implementation of tagged memory, referred to as MTE (Memory Tagging Extensions). Through mid-2022 and early 2023, Project Zero had access to pre-production hardware implementing this instruction set extension to evaluate the security properties of the implementation. In particular, we\'re interested in whether it\'s possible to use this instruction set extension to implement effective security mitigations, or whether its use is limited to debugging/fault detection purposes. As of the v8.5a specification, MTE can operate in two distinct modes, which are switched between on a per-thread basis. The first mode is sync-MTE, where tag-check failure on a memory access will cause the instruction performing the access to deliver a fault at retirement. The second mode is async-MTE, where tag-check failure does not directly (at the architectural level) cause a fault. Instead, tag-check failure will cause the setting of a per-core flag, which can then be polled from the kernel context to detect when an invalid access has occurred. This blog post documents the tests that we have performed so far, and the conclusions that we\'ve drawn from them, together with the code necessary to repeat these tests. This testing was intended to explore both the details of the hardware implementation of MTE, and the current state of the software support for MTE in the Linux kernel. All of the testing is based on manually implemented tagging in statically-linked standalone binaries, so it should be easy to reproduce these results on any compatible hardware.Terminology When designing and implementing security features, it\'s important to be conscious of the specific protection goal. In order to provide clarity in the rest of this post, we\'ll define some specific terminology that we use when talking about this:Mitigation - A mitigation is something that reduces real exploitability of a vulnerability or class of vulnerability. The expectation is that attackers can (and eventually will) find their way around it. Examples would ]]> 2023-08-02T09:30:09+00:00 https://googleprojectzero.blogspot.com/2023/08/mte-as-implemented-part-1.html www.secnews.physaphae.fr/article.php?IdArticle=8364823 False Vulnerability None 2.0000000000000000 ProjectZero - Blog de recherche Google AddressSanitizer/HWAsan. It\'s clear that such an overhead is not acceptable for most production workloads. Products that expect to contain large C/C++ codebases in the long term, who consider the exploitation of memory corruption vulnerabilities to be a key risk for their product security, should actively drive support for ARM\'s MTE in their products.For a more detailed analysis, see the following linked blog posts: Implementation Testing - An objective summary of the tests performed, and some basic analysis. If you\'re interested in implementing a mitigation based on MTE, you should read this document]]> 2023-08-02T09:30:01+00:00 https://googleprojectzero.blogspot.com/2023/08/summary-mte-as-implemented.html www.secnews.physaphae.fr/article.php?IdArticle=8364824 False Vulnerability None 3.0000000000000000 ProjectZero - Blog de recherche Google 2023-04-24T09:27:24+00:00 https://googleprojectzero.blogspot.com/2023/04/technical-report-into-intel-tdx.html www.secnews.physaphae.fr/article.php?IdArticle=8330640 False Cloud None 2.0000000000000000 ProjectZero - Blog de recherche Google Samsung Semiconductor's advisories provide the list of Exynos chipsets that are affected by these vulnerabilities. Based on information from public websites that map chipsets to devices, affected products likely include: Mobile devices from Samsung, including those in the S22, M33, M13, M12, A71, A53, A33, A21, A13, A12 and A04 series;Mobile devices from Vivo, including those in the S16, S15, S6, X70, X60 and X30 series;The Pixel 6 and Pixel 7 series of devices from Google;any wearables that use the Exynos W920 chipset; andany vehicles that use the Exynos Auto T5123 chipset. Patch timelines We expect that patch timelines will vary per manufacturer (for example, affected Pixel devices have already received a fix for CVE-2023-24033 in the March 2023 security update). In the meantime, users w]]> 2023-03-16T11:09:25+00:00 https://googleprojectzero.blogspot.com/2023/03/multiple-internet-to-baseband-remote-rce.html www.secnews.physaphae.fr/article.php?IdArticle=8319206 False Vulnerability,Vulnerability None 4.0000000000000000 ProjectZero - Blog de recherche Google oops, which is distinct from a kernel panic. A panic occurs when the kernel determines that there is no safe way to continue execution, and that therefore all execution must cease. However, the kernel does not stop all execution during an oops - instead the kernel tries to recover as best as it can and continue execution. In the case of a task, that involves throwing out the existing kernel stack and going directly to make_task_dead which calls do_exit. The kernel will also publish in dmesg a “crash” log and kernel backtrace depicting what state the kernel was in when the oops occurred. This may seem like an odd choice to make when memory corruption has clearly occurred - however the intention is to allow kernel bugs to more easily be detectable and loggable under the philosophy that a working system is much easier to debug than a dead one. The unfortunate side effect of the oops recovery path is that the kernel is not able to perform any associated cleanup that it would normally perform on a typical syscall error recovery path. This means that any locks that were locked at the moment of the oops stay locked, any refcounts remain taken, any memory otherwise temporarily allocated remains allocated, etc. However, the process that generated the oops, its associated kernel stack, task struct and derivative members etc. can and often will be freed, meaning that depending on the precise circumstances of the oops, it’s possible that no memory is actually leaked. This becomes particularly important in regards to exploitation later. Reference count mismanagement overview Refcount mismanagement is a fairly well-known and exploitable issue. In the case where software improperly]]> 2023-01-19T09:33:48+00:00 https://googleprojectzero.blogspot.com/2023/01/exploiting-null-dereferences-in-linux.html www.secnews.physaphae.fr/article.php?IdArticle=8302606 False Guideline None 4.0000000000000000 ProjectZero - Blog de recherche Google XMPP, an instant messaging protocol based on XML. More specifically, my research focused on how subtle quirks in XML parsing can be used to undermine the security of such applications. (If you are interested in learning more about that research, I did a talk on it at Black Hat USA 2022. The slides and the recording can be found here and here). At some point, when a part of my research was published, people pointed out other examples (unrelated to XMPP) where quirks in XML parsing led to security vulnerabilities. One of those examples was a vulnerability dubbed Psychic Paper, a really neat vulnerability in the way Apple operating system checks what entitlements an application has. Entitlements are one of the core security concepts of Apple’s operating systems. As Apple’s documentation explains, “An entitlement is a right or privilege that grants an executable particular capabilities.” For example, an application on an Apple operating system can’t debug another application without possessing proper entitlements, even if those two applications run as the same user. Even applications running as root can’t perform all actions (such as accessing some of the kernel APIs) without appropriate entitlements. Psychic Paper was a vulnerability in the way entitlements were checked. Entitlements were stored inside the application’s signature blob in the XML format, so naturally the operating system needed to parse those at some point using an XML parser. The problem was that the OS didn’t have a single parser for this, but rather a staggering four parsers that were used in different places in the operating system. One parser was used for the initial check that the application only has permitted entitlements, and a different parser was later used when checking whether the application has an entitlement to perform a specific action. ]]> 2023-01-12T08:59:29+00:00 https://googleprojectzero.blogspot.com/2023/01/der-entitlements-brief-return-of.html www.secnews.physaphae.fr/article.php?IdArticle=8300585 False Vulnerability,Guideline,Prediction None 3.0000000000000000 ProjectZero - Blog de recherche Google CVE-2022-42703 (P0 issue 2351 - Fixed 5 September 2022), a bug Jann Horn found in the Linux kernel's memory management (MM) subsystem that leads to a use-after-free on struct anon_vma. As the bug is very complex (I certainly struggle to understand it!), a future blog post will describe the bug in full. For the time being, the issue tracker entry, this LWN article explaining what an anon_vma is and the commit that introduced the bug are great resources in order to gain additional context.Setting the sceneSuccessfully triggering the underlying vulnerability causes folio->mapping to point to a freed anon_vma object. Calling madvise(..., MADV_PAGEOUT)can then be used to repeatedly trigger accesses to the freed anon_vma in folio_lock_anon_vma_read():struct anon_vma *]]> 2022-12-08T11:04:18+00:00 https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html www.secnews.physaphae.fr/article.php?IdArticle=8289267 False Vulnerability,Guideline None 3.0000000000000000 ProjectZero - Blog de recherche Google FirstCon22 titled 0-day In-the-Wild Exploitation in 2022…so far. A key takeaway was that approximately 50% of the observed 0-days in the first half of 2022 were variants of previously patched vulnerabilities. This finding is consistent with our understanding of attacker behavior: attackers will take the path of least resistance, and as long as vendors don't consistently perform thorough root-cause analysis when fixing security vulnerabilities, it will continue to be worth investing time in trying to revive known vulnerabilities before looking for novel ones. The presentation discussed an in the wild exploit targeting the Pixel 6 and leveraging CVE-2021-39793, a vulnerability in the ARM Mali GPU driver used by a large number of other Android devices. ARM's advisory described the vulnerability as: Title                    Mali GPU Kernel Driver may elevate CPU RO pages to writable CVE                   CVE-2022-22706 (also reported in CVE-2021-39793) Date of issue      6th January 2022 Impact                A non-privileged user can get a write access to read-only memory pages [sic]. The week before FirstCon22, Maddie gave an internal preview of her talk. Inspired by the description of an in-the-wild vulnerability in low-level memory management code, fellow Project Zero researcher Jann Horn started auditing the ARM Mali GPU driver. Over the next three weeks, Jann found five more exploitable vulnerabilities (2325, 2327, ]]> 2022-11-22T13:05:40+00:00 https://googleprojectzero.blogspot.com/2022/11/mind-the-gap.html www.secnews.physaphae.fr/article.php?IdArticle=8221922 False Vulnerability,Guideline None None ProjectZero - Blog de recherche Google 2022-11-10T13:10:11+00:00 https://googleprojectzero.blogspot.com/2022/11/a-very-powerful-clipboard-samsung-in-the-wild-exploit-chain.html www.secnews.physaphae.fr/article.php?IdArticle=8221923 False Vulnerability,Threat,Guideline None None ProjectZero - Blog de recherche Google CVE-2022-34169, an integer truncation bug in this JIT compiler resulting in arbitrary code execution in many Java-based web applications and identity providers that support the SAML single-sign-on standard. OpenJDK fixed the discussed issue in July 2022. The Apache BCEL project used by Xalan-J, the origin of the vulnerable code, released a patch in September 2022. While the vulnerability discussed in this post has been patched , vendors and users should expect further vulnerabilities in SAML.From a security researcher's perspective, this vulnerability is an example of an integer truncation issue in a memory-safe language, with an exploit that feels very much like a memory corruption. While less common than the typical memory safety issues of C or C++ codebases, weird machines still exist in memory safe languages and will keep us busy even after we move into a bright memory safe future.Before diving into the vulnerability and its exploit, I'm going to give a quick overview of XML signatures and SAML. What makes XML signatures such an interesting target and why should we care about them?IntroductionXML Signatures are a typical example of a security protocol invented in the early 2000's. They suffer from high complexity, a large attack surface and a wealth of configurable features that can weaken or bre]]> 2022-11-04T07:39:42+00:00 https://googleprojectzero.blogspot.com/2022/11/gregor-samsa-exploiting-java-xml.html www.secnews.physaphae.fr/article.php?IdArticle=8221924 False Vulnerability None None ProjectZero - Blog de recherche Google 2310 with the handling of RC4 encryption that allowed you to authenticate as another user if you could either interpose on the Kerberos network traffic to and from the KDC or directly if the user was configured to disable typical pre-authentication requirements.This blog post goes into more detail on how this vulnerability works and how I was able to exploit it with only a bare minimum of brute forcing required. Note, I'm not going to spend time fully explaining how Kerberos authentication works, there's plenty of resources online. For example this blog post by Steve Syfuhs who works at Microsoft is a good first start.BackgroundKerberos is a very old authentication protocol. The current version (v5) was described in RFC1510 back in 1993, although it was updated in RFC4120 in 2005. As Kerberos' core security concept is using encryption to prove knowledge of a user's credentials the design allows for negotiating the encryption and checksum algorithms that the client and server will use. For example when sending the initial authentication service request (AS-REQ) to the Key Distribution Center (KDC) a client can specify a list supported encryption algorithms, as predefined integer identifiers, as shown below in the snippet of the ASN.1 definition from RFC4120.]]> 2022-10-27T12:48:24+00:00 https://googleprojectzero.blogspot.com/2022/10/rc4-is-still-considered-harmful.html www.secnews.physaphae.fr/article.php?IdArticle=8221925 False Vulnerability,Guideline None None ProjectZero - Blog de recherche Google 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 ]]> 2022-08-24T12:08:43+00:00 https://googleprojectzero.blogspot.com/2022/03/racing-against-clock-hitting-tiny.html www.secnews.physaphae.fr/article.php?IdArticle=8221935 False Tool,Guideline APT 25 2.0000000000000000 ProjectZero - Blog de recherche Google we published a writeup of the initial remote code execution stage of FORCEDENTRY, the zero-click iMessage exploit attributed by Citizen Lab to NSO. By sending a .gif iMessage attachment (which was really a PDF) NSO were able to remotely trigger a heap buffer overflow in the ImageIO JBIG2 decoder. They used that vulnerability to bootstrap a powerful weird machine capable of loading the next stage in the infection process: the sandbox escape. In this post we'll take a look at that sandbox escape. It's notable for using only logic bugs. In fact it's unclear where the features that it uses end and the vulnerabilities which it abuses begin. Both current and upcoming state-of-the-art mitigations such as Pointer Authentication and Memory Tagging have no impact at all on this sandbox escape.An observation During our initial analysis of the .gif file Samuel noticed that rendering the image appeared to leak memory. Running the heap tool after releasing all the associated resources gave the following output: $ heap $pid ------------------------------------------------------------ All zones: 4631 nodes (826336 bytes)                          COUNT    BYTES     AVG   CLASS_NAME   TYPE   BINARY              =====    =====     ===   ==========   ====   ======             1969   469120   238.3   non-object      825    26400    32.0   JBIG2Bitmap  C++   CoreGraphics ]]> 2022-08-24T12:04:44+00:00 https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html www.secnews.physaphae.fr/article.php?IdArticle=8221934 False Vulnerability,Technical None 3.0000000000000000 ProjectZero - Blog de recherche Google @xerub. Phrack published @xerub's writeup so go check that out first. As well as doing my own vulnerability research I also spend time trying as best as I can to keep up with the public state-of-the-art, especially when details of a particularly interesting vulnerability are announced or a new in-the-wild exploit is caught. Originally this post was just a series of notes I took last year as I was trying to understand this bug. But the bug itself and the narrative around it are so fascinating that I thought it would be worth writing up these notes into a more coherent form to share with the community.Background On April 14th 2021 the Washington Post published an article on the unlocking of the San Bernardino iPhone by Azimuth containing a nugget of non-public information: "Azimuth specialized in finding significant vulnerabilities. Dowd [...] had found one in open-source code from Mozilla that Apple used to permit accessories to be plugged into an iPhone’s lightning port, according to the person." There's not that much Mozilla code running on an iPhone and even less which is likely to be part of such an attack surface. Therefore, if accurate, this quote almost certainly meant that Azimuth had exploited a vulnerability in the ASN.1 parser used by Security.framework, which is a fork of Mozilla's NSS ASN.1 parser. I searched around in bugzilla (Mozilla's issue tracker) looking for candidate vulnerabilities which matched the timeline discussed in the Post article and narrowed it down to a handful of plausible bugs including: 1202868, 1192028, 1245528. I was surprised that there had been so many exploitable-looking issues in the ASN.1 code and decided to add auditing the NSS ASN.1 parser as an quarterly goal. A month later, having predictably done absolutely ]]> 2022-08-24T12:04:12+00:00 https://googleprojectzero.blogspot.com/2022/04/cve-2021-30737-xerubs-2021-ios-asn1.html www.secnews.physaphae.fr/article.php?IdArticle=8221933 False Vulnerability,Guideline None 3.0000000000000000 ProjectZero - Blog de recherche Google 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: ]]> 2022-08-24T12:02:07+00:00 https://googleprojectzero.blogspot.com/2022/04/cve-2021-1782-ios-in-wild-vulnerability.html www.secnews.physaphae.fr/article.php?IdArticle=8221932 False Hack,Tool,Vulnerability,Guideline None 3.0000000000000000 ProjectZero - Blog de recherche Google 2020, 2019]. Each year we’ve looked back at all of the detected and disclosed in-the-wild 0-days as a group and synthesized what we think the trends and takeaways are. The goal of this report is not to detail each individual exploit, but instead to analyze the exploits from the year as a group, looking for trends, gaps, lessons learned, successes, etc. If you’re interested in the analysis of individual exploits, please check out our root cause analysis repository. We perform and share this analysis in order to make 0-day hard. We want it to be more costly, more resource intensive, and overall more difficult for attackers to use 0-day capabilities. 2021 highlighted just how important it is to stay relentless in our pursuit to make it harder for attackers to exploit users with 0-days. We heard over and over and over about how governments were targeting journalists, minoritized populations, politicians, human rights defenders, and even security researchers around the world. The decisions we make in the security and tech communities can have real impacts on society and our fellow humans’ lives. We’ll provide our evidence and process for our conclusions in the body of this post, and then wrap it all up with our thoughts on next steps and hopes for 2022 in the conclusion. If digging into the bits and bytes is not your thing, then feel free to just check-out the Executive Summary and Conclusion.Executive Summary 2021 included the detection and disclosure of 58 in-the-wild 0-days, the most ever recorded since Project Zero began tracking in mid-2014. That’s more than double the previous maximum of 28 detected in 2015 and especially stark when you consider that there were only 25 detected in 2020. We’ve tracked publicly known in-the-wild 0-day exploits in this spreadsheet since mid-2014. While we often talk about t]]> 2022-08-24T12:00:49+00:00 https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html www.secnews.physaphae.fr/article.php?IdArticle=8221931 False Vulnerability,Patching,Guideline None 2.0000000000000000 ProjectZero - Blog de recherche Google App splash screen showing the Vodafone carrier logo and the text "My Vodafone" (not the legitimate Vodadone app) Although this looks like the real My Vodafone carrier app available in the App Store, it didn't come from the App Store and is not the real application from Vodafone. TAG suspects that a target receives a link to this app in an SMS, after the attacker asks the carrier to disable the target's mobile data connection. The SMS claims that in order to restore mobile data connectivity, the target must install the carrier app and includes a link to download and install this fake app. This sideloading works because the app is signed with an enterprise certificate, which can be purchased for $299 via the Apple Enterprise developer program. This program allows an eligible enterprise to obtain an Apple-signed embedded.mobileprovision file with the ProvisionsAllDevices key set. An app signed with the developer certificate embedded within that mobileprovision file can be sideloaded on any iPhone, bypassing Apple's App Store review process. While we understand that the Enterprise developer program is designed for companies to push "trusted apps" to their staff's iOS devices, in this case, it appears that it was being used to sideload this fake carrier app. In collaboration with Project Zero, ]]> 2022-08-24T11:58:33+00:00 https://googleprojectzero.blogspot.com/2022/06/curious-case-carrier-app.html www.secnews.physaphae.fr/article.php?IdArticle=8221928 False Vulnerability,Threat,Guideline None None ProjectZero - Blog de recherche Google 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)]]> 2022-08-24T11:55:31+00:00 https://googleprojectzero.blogspot.com/2022/08/the-quantum-state-of-linux-kernel.html www.secnews.physaphae.fr/article.php?IdArticle=8221926 False Vulnerability,Threat,Guideline None None ProjectZero - Blog de recherche Google configuration issue with the Windows Firewall which allowed the restrictions to be bypassed and allowed an AppContainer process to access the network. Unfortunately Microsoft decided it didn't meet the bar for a security bulletin so it's marked as WontFix. As the mechanism that the Windows Firewall uses to restrict access to the network from an AppContainer isn't officially documented as far as I know, I'll provide the details on how the restrictions are implemented. This will provide the background to understanding why my configuration issue allowed for network access. I'll also take the opportunity to give an overview of how the Windows Firewall functions and how you can use some of my tooling to inspect the current firewall configuration. This will provide security researchers with the information they need to better understand the firewall and assess its configuration to find other security issues similar to the one I reported. At the same time I'll note some interesting quirks in the implementation which you might find useful.Windows Firewall Architecture Primer Before we can understand how network access is controlled in an AppContainer we need to understand how the built-in Windows firewall functions. Prior to XP SP2 Windows didn't have a built-in firewall, and you would typically install a third-party firewall such as ZoneAlarm. These firewalls were implemented by hooking into Network Driver Interface Specification (NDIS) drivers or implementing user-mode Winsock Service Providers but this was complex and error prone. While XP SP2 introduced the built-in firewall, the basis for the one used in modern versions of Windows was introduced in Vista as the Windows Filtering Platform (WFP). However, as a user you wouldn't typically interact directly with WFP. Instead you'd use a firewall product which exposes a user interface, and then configures WFP to do the actual firewalling. On a default installation of Windows this would be the Windows Defender Firewall. If you installed a third-party firewall this would replace the Defender component but the actual firewall would still be implemented through configuring WFP. ]]> 2022-08-23T12:40:09+00:00 https://googleprojectzero.blogspot.com/2021/08/understanding-network-access-windows-app.html www.secnews.physaphae.fr/article.php?IdArticle=8221942 False Guideline None 2.0000000000000000 ProjectZero - Blog de recherche Google Fuzzilli (an open-source JavaScript engine fuzzer), with TinyInst (an open-source dynamic instrumentation library for fuzzing). I also added grammar-based mutation support to Jackalope (my black-box binary fuzzer). So far, these two approaches resulted in finding three security issues in jscript9.dll (default JavaScript engine used by Internet Explorer).Introduction or “when you can’t beat them, join them” In the past, I’ve invested a lot of time in generation-based fuzzing, which was a successful way to find vulnerabilities in various targets, especially those that take some form of language as input. For example, Domato, my grammar-based generational fuzzer, found over 40 vulnerabilities in WebKit and numerous bugs in Jscript.  While generation-based fuzzing is still a good way to fuzz many complex targets, it was demonstrated that, for finding vulnerabilities in modern JavaScript engines, especially engines with JIT compilers, better results can be achieved with mutational, coverage-guided approaches. My colleague Samuel Groß gives a compelling case on why that is in his OffensiveCon talk. Samuel is also the author of Fuzzilli, an open-source JavaScript engine fuzzer based on mutating a custom intermediate language. Fuzzilli has found a large number of bugs in various JavaScript engines. While there has been a lot of development on coverage-guided fuzzers over the last few years, most of the public tooling focuses on open-source targets or software running on the Linux operating system. Meanwhile, I focused on developing tooling for fuzzing of closed-source binaries on operating systems where such software is more prevalent (currently Windows and macOS). Some years back, I published WinAFL, the first performant AFL-based fuzzer for Windows. About a year and a half ago, however, I started working on a brand new toolset for black-box coverage-guided fuzzing. TinyInst and Jackalope are the two outcomes of this effort. It comes somewhat naturally to combine the tooling I’ve been working on with techniques that have been so successful in finding JavaScript bugs, and try to use the resulting tooling to fuzz JavaScript engines for which the source code is not available. Of such engines, I know two: jscript and jscript9 (implemented in jscript.dll and jscript9.dll) on Windows, whic]]> 2022-08-23T12:32:29+00:00 https://googleprojectzero.blogspot.com/2021/09/fuzzing-closed-source-javascript.html www.secnews.physaphae.fr/article.php?IdArticle=8221941 False None None 2.0000000000000000 ProjectZero - Blog de recherche Google previous blog post I discussed the possibility of relaying Kerberos authentication from a DCOM connection. I was originally going to provide a more in-depth explanation of how that works, but as it's quite involved I thought it was worthy of its own blog post. This is primarily a technique to get relay authentication from another user on the same machine and forward that to a network service such as LDAP. You could use this to escalate privileges on a host using a technique similar to a blog post from Shenanigans Labs but removing the requirement for the WebDAV service. Let's get straight to it.Background The technique to locally relay authentication for DCOM was something I originally reported back in 2015 (issue 325). This issue was fixed as CVE-2015-2370, however the underlying authentication relay using DCOM remained. This was repurposed and expanded upon by various others for local and remote privilege escalation in the RottenPotato series of exploits, the latest in that line being RemotePotato which is currently unpatched as of October 2021. The key feature that the exploit abused is standard COM marshaling. Specifically when a COM object is marshaled so that it can be used by a different process or host, the COM runtime generates an OBJREF structure, most commonly the OBJREF_STANDARD form. This structure contains all the information necessary to establish a connection between a COM client and the original object in the COM server. Connecting to the original object from the OBJREF is a two part process:The client extracts the Object Exporter ID (OXID) from the structure and contacts the OXID resolver service specified by the RPC binding information in the OBJREF.The client uses the OXID resolver service to find the RPC binding information of the COM server which hosts the object and establishes a connection to the RPC endpoint to access the object's interfaces. Both of these steps require establishing an MSRPC connection to an endpoint. Commonly this is either locally over ALPC, or remotely via TCP. If a TCP connection is used then the client will also authenticate to the RPC server using NTLM or Kerberos based on the security bindings in the OBJREF.]]> 2022-08-23T12:22:51+00:00 https://googleprojectzero.blogspot.com/2021/10/windows-exploitation-tricks-relaying.html www.secnews.physaphae.fr/article.php?IdArticle=8221940 False Technical None 3.0000000000000000 ProjectZero - Blog de recherche Google iOS 14.8 as CVE-2021-30860. NSO NSO Group is one of the highest-profile providers of "access-as-a-service", selling packaged hacking solutions which enable nation state actors without a home-grown offensive cyber capability to "pay-to-play", vastly expanding the number of nations with such cyber capabilities. For years, groups like Citizen Lab and Amnesty International have been tracking the use of NSO's mobile spyware package "Pegasus". Despite NSO's claims that they "[evaluate] the potential for adverse human rights impacts arising from the misuse of NSO products" Pegasus has been linked to the hacking of the New York Times journalist Ben Hubbard by the Saudi regime, hacking of human rights defenders in Morocco and Bahrain, the targeting of Amnesty ]]> 2022-08-23T12:03:57+00:00 https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html www.secnews.physaphae.fr/article.php?IdArticle=8221938 False Vulnerability,Technical None 3.0000000000000000 ProjectZero - Blog de recherche Google 90-day deadline, we have also seen a dropoff in vendors missing the deadline (or the additional 14-day grace period). In 2021, only one bug exceeded its fix deadline, though 14% of bugs required the grace period.Differences in the amount of time it takes a vendor/product to ship a fix to users reflects their product design, development practices, update cadence, and general processes towards security reports. We hope that this comparison can showcase best practices, and encourage vendors to experiment with new policies.This data aggregation and analysis is relatively new for Project Zero, but we hope to do it more in the future. We encourage all vendors to consider publishing aggregate data on their time-to-fix and time-to-patch for externally reported vulnerabilities, as well as more data sharing and transparency in general. Overview For nearly ten years, Google’s Project Zero has been working to make it more difficult for bad actors to find and exploit security vulnerabilities, significantly improving the security of the Internet for everyone. In that time, we have partnered with folks across industry to transform the way organizations prioritize and approach fixing security vulnerabilities and updating people’s software. To help contextualize the shifts we are seeing the ecosystem make, we looked back at the set of vulnerabilities Project Zero has been reporting, how a range of vendors have been responding to them, and then attempted to identify trends in this data, such as how the industry as a whole is patching vulnerabilities faster. For this post, we look at fixed bugs that were reported between January 2019 and December 2021 (2019 is the year we made changes to our disclosure policies and also began recording more detailed metrics on our reported bugs). The data we'll be referencing is publicly available on the Project Zero Bug Tracker, and on various open source project repositories (in the case of the data used below to track the timeline of open-source browser bugs). There are a number of caveats with our data, the largest being that we'll be looking at a small number of samples, so differences in numbers may or may not be statistically significant. Also, the direction of Project Zero's research is almost entirely influenced by the choices of individual researchers, so changes in our researc]]> 2022-08-23T11:50:56+00:00 https://googleprojectzero.blogspot.com/2022/02/a-walk-through-project-zero-metrics.html www.secnews.physaphae.fr/article.php?IdArticle=8221936 False Vulnerability,Patching Uber 2.0000000000000000 ProjectZero - Blog de recherche Google here. For the last three years, we’ve published annual year-in-review reports of 0-days found exploited in the wild. The most recent of these reports is the 2021 Year in Review report, which we published just a few months ago in April. While we plan to stick with that annual cadence, we’re publishing a little bonus report today looking at the in-the-wild 0-days detected and disclosed in the first half of 2022.         As of June 15, 2022, there have been 18 0-days detected and disclosed as exploited in-the-wild in 2022. When we analyzed those 0-days, we found that at least nine of the 0-days are variants of previously patched vulnerabilities. At least half of the 0-days we’ve seen in the first six months of 2022 could have been prevented with more comprehensive patching and regression tests. On top of that, four of the 2022 0-days are variants of 2021 in-the-wild 0-days. Just 12 months from the original in-the-wild 0-day being patched, attackers came back with a variant of the original bug.   Product 2022 ITW 0-day Variant Windows win32k CVE-2022-21882 CVE-2021-1732 (2021 itw) iOS IOMobileFrameBuffer CVE-2022-22587 ]]> 2022-06-30T06:00:00+00:00 https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html www.secnews.physaphae.fr/article.php?IdArticle=8221927 False Vulnerability,Patching,Guideline None None ProjectZero - Blog de recherche Google 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 ]]> 2022-06-14T09:00:24+00:00 https://googleprojectzero.blogspot.com/2022/06/an-autopsy-on-zombie-in-wild-0-day.html www.secnews.physaphae.fr/article.php?IdArticle=8221929 False Tool,Vulnerability,Patching None None ProjectZero - Blog de recherche Google technical report on a security review of AMD Secure Processor (ASP). The ASP is an isolated ARM processor in AMD EPYC CPUs that adds a root of trust and controls secure system initialization. As it's a generic processor AMD can add additional security features to the firmware, but like with all complex systems it's possible these features might have security issues which could compromise the security of everything under the ASP's management. The security review undertaken was on the implementation of the ASP on the 3rd Gen AMD EPYC CPUs (codenamed "Milan"). One feature of the ASP of interest to Google is Secure Encrypted Virtualization (SEV). SEV adds encryption to the memory used by virtual machines running on the CPU. This feature is of importance to Confidential Computing as it provides protection of customer cloud data in use, not just at rest or when sending data across a network. A particular emphasis of the review was on the Secure Nested Paging (SNP) extension to SEV added to "Milan". SNP aims to further improve the security of confidential computing by adding integrity protection and mitigations for numerous side-channel attacks. The review was undertaken with full cooperation with AMD. The team was granted access to source code for the ASP, and production samples to test hardware attacks. The review discovered 19 issues which have been fixed by AMD in public security bulletins. These issues ranged from incorrect use of cryptography to memory corruption in the context of the ASP firmware. The report describes some of the more interesting issues that were uncovered during the review as well as providing a background on the ASP and the process the team took to find security issues. You can read more about the review on the Google Cloud security blog and the final report.]]> 2022-06-08T14:08:01+00:00 https://googleprojectzero.blogspot.com/2022/05/release-of-technical-report-into-amd.html www.secnews.physaphae.fr/article.php?IdArticle=8221930 False None None None ProjectZero - Blog de recherche Google revealed at Pwn2Own, showing that it does indeed have a fully remote attack surface. The following post details my investigation into Zoom. This analysis resulted in two vulnerabilities being reported to Zoom. One was a buffer overflow that affected both Zoom clients and MMR servers, and one was an info leak that is only useful to attackers on MMR servers. Both of these vulnerabilities were fixed on November 24, 2021. Zoom Attack Surface Overview Zoom’s main feature is multi-user conference calls called meetings that support a variety of features including audio, video, screen sharing and in-call text messages. There are several ways that users can join Zoom meetings. To start, Zoom provides full-featured installable clients for many platforms, including Windows, Mac, Linux, Android and iPhone. Users can also join Zoom meetings using a browser link, but they are able to use fewer features of Zoom. Finally, users can join a meeting by dialing phone numbers provided in the invitation on a touch-tone phone, but this only allows access to the audio stream of a meeting. This research focused on the Zoom client software, as the other methods of joining calls use existing device features. Zoom clients support several communication features other than meetings that are available to a user’s Zoom Contacts. A Zoom Contact is a user that another user has added as a contact using the Zoom user interface. Both users must consent before they become Zoom Contacts. Afterwards, the users can send text messages to one another outside of meetings and start channels for persistent group conversations. Also, if either user hosts a meeting, they can invite the other user in a manner that is similar to a phone call: the other user is immediately notified and they can join the meeting with a single click. These features represent the zero-click attack surface of Zoom. Note that this attack surface is only available to attackers that have convinced their target to accept them as a contact. Likewise, meetings are part of the one-click attack surface only for Zoom Contacts, as other users need to click several times to enter a meeting. That said, it’s likely not that difficult for a dedicated attacker to convince a target to join a Zoom call even if it takes multiple clicks, and the way some organizations use Zoom presents interesting attack scenarios. For example, many groups host public Zoom meetings, and Zoom supports a paid Webinar feature where large groups of unknown attendees can join a one-way video conference. It could be possible for an attacker to join a public meeting and target other attendees. Zoom also relies on a server to transmit audio and video streams, and end-to-end encryption is off by default. It could be possible for an attacker to compromise Zoom’s servers and gain access to meeting data.]]> 2022-01-18T09:28:18+00:00 https://googleprojectzero.blogspot.com/2022/01/zooming-in-on-zero-click-exploits.html www.secnews.physaphae.fr/article.php?IdArticle=8221937 False Vulnerability,Guideline None 3.0000000000000000 ProjectZero - Blog de recherche Google Network Security Services (NSS) is Mozilla's widely used, cross-platform cryptography library. When you verify an ASN.1 encoded digital signature, NSS will create a VFYContext structure to store the necessary data. This includes things like the public key, the hash algorithm, and the signature itself. struct VFYContextStr {    SECOidTag hashAlg; /* the hash algorithm */    SECKEYPublicKey *key;    union {        unsigned char buffer[1];        unsigned char dsasig[DSA_MAX_SIGNATURE_LEN];        unsigned char ecdsasig[2 * MAX_ECKEY_LEN];        unsigned char rsasig[(RSA_MAX_MODULUS_BITS + 7) / 8];    } u;    unsigned int pkcs1RSADigestInfoLen;    unsigned ch]]> 2021-12-01T14:27:11+00:00 https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html www.secnews.physaphae.fr/article.php?IdArticle=8221939 False Vulnerability,Guideline None 2.0000000000000000