One Article Review
| Source |  ProjectZero |
|---|---|
| Identifiant | 8364822 |
| Date de publication | 2023-08-02 09:30:14 (vue: 2023-08-02 17:05:49) |
| Titre | MTE tel que mis en œuvre, partie 2: études de cas d'atténuation MTE As Implemented, Part 2: Mitigation Case Studies |
| Texte | By Mark Brand, Project ZeroBackground In 2018, in the 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" |
| Envoyé | Oui |
| Condensat | ♻️: 🐛* 🐛: 🛠️: 🛠️chrome: between we *scan+mte 1 is 1 we 1/15 2018 3 continues :known able about absence absolute access accesses accordingly accounted achieving across addition additional after against all allocation allow allowing allows also alternative android: another any app applicable application applications applying approach approaches architecturally architecture are arm around art assessed assumptions async asynchronous attack attacker attackers attempts available avoid avoiding based become been believe below bespoke between binder bits both bound brand breach break browser bug bugs but bypass bypassed bypasses bypasses call calls can carefully case cases caused certainty chance channel channels check choke chrome chrome: circumstances classes clear code combinations proposed combining complete completely complex complexity compromised condition confidentiality confusion consider constraint constraints construct contain context contexts correct correctly corruption cost could cpu current currently data data section degree delivered demonstrated depend design desire despite detail detailed detectable detected detection deterministic develop developed development different difficulty directly discuss discussed discussion does drop due duration easy effective effectiveness effects eliminating enforcement: enough ensure ensuring escape especially even eventually example examples execution expect expected exploit exploitable exploitation exploiting exploits extensions extremely face failure failures fault faulting file finds fixed flag following force forging form format free from fundamental general generally generic going good had hard hardware has have haven here high higher highly hold hosted how however hurt implementation implemented implications implies imply implying important imposed impossible inconvenience incorrect increase increasing indirectly information inserting instruction interest interested interpreted invalid invest investigated involved ioctl ipc issues javascript kernel key know known large leading least less likely limit limitations limited limits low to lower made main make mandatory many mark may mean means meet meeting memory message messages messaging might mitigate mitigation mitigation: mitigations mode modes mojo more most mte much multiple must necessary need needing needs not note now nuance number observable observed once one oneshot only operational opportunities order over pain parsing part party per perform performing point pointer pointers pointing points possibility possible post potentially practicality present prevent prevented primary privileged probabilistic probably process processed processes products/contexts project proposed protection prove provide public rare read reads reduced referred relevant/likely reliability remote renderer repeated require required reserved restrictive result results retirement reusable reuse reused risk roughly sandbox second see seems series service services several shared shot should side significant significantly since situations soft software some space specific specifics spectre speculative stale standard state studies subset success such sufficient suitable summarize supply sync synchronous system tag tagged tagging tags target technical technique techniques testing than themself therefore these third those tier time too treat triggering trivial trivial ♻️ two type under understand universally unknown unless unlikely unreliable until upper usage use used useful user usermode using value values version of very vulnerabilities vulnerability want as we believe that weakness weaknesses what when where which wild will winning within without would write writes writing you zerobackground zygote |
| Tags | Studies Vulnerability |
| Stories | |
| Notes | ★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ressemble à 1 autre(s) article(s):
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
|
2023-08-02 09:30:22 | (Déjà vu) MTE comme mis en œuvre, partie 3: le noyau MTE As Implemented, Part 3: The Kernel (lien direct) |
By Mark Brand, Project ZeroBackground In 2018, in the 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" | Vulnerability | ★★ |