One Article Review
| Source |  ProjectZero |
|---|---|
| Identifiant | 8364821 |
| Date de publication | 2023-08-02 09:30:22 (vue: 2023-08-02 17:05:49) |
| Titre | MTE comme mis en œuvre, partie 3: le noyau MTE As Implemented, Part 3: The Kernel (Recyclage) |
| 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. 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" |
| Envoyé | Oui |
| Condensat | a it the 0b1111 can 1 is 1 we 1/15 2 we 2018 :the about above accelerators access accesses accounted addition additional additionally address advantage after against allocations allow allows alone already also any approaches appropriately architecturally architecture are areas arm asymmetric async asynchronous attacker attackers available avoided based bear been believe bits brand breach browser built but bypass bypassed bypasses bypasses calls can capable case cases chance channel channels check checks chrome classes clear clearing code compare complex condition confidentiality consider considered considering construct constructing context contexts continue continued coprocessor coprocessors cores correctly could coverage cpu critical current currently data delivered dereferenceable dereferenced design despite details detect detectable detected detection deterministic device devices difficult direct directly disable discussed discussion dispatch dma does due during dynamically effectiveness effects el1 is elx enabled enforce enforcement: enforcing ensure epoll equality error especially essential example exist expect exploit exploitation exploits extensions factors failure failures fault faulting fdinfo file* pointers first flag flags following:known forge form free from fundamental fundamentally fuse general generally gpus guaranteeing had hard hardware has have here highlighting highly implementation implemented implications imply includes incorrect indirectly information instances instruction invalid isn issue itself just kasan kcmp syscall kernel kernels key keys know known leak level likely limit limitations limits linux list local lock lower main make makes making many mapping mappings mark may mean means memory might mind mitigation mitigations mode modes more moving mte multiple must necessary need non normal not now number observable offset one only opportunities other owner page panic part parts pattern per performing perspective physical place places point pointer pointers pose possible post potentially powerful presence primitives probabilistic probably problematic problems process produce project proposed protected protection provide publicly rcu regions reads reason reasons recap referred regions register reliably renderer require/allow required reserved result results retirement robust scenario search security see seen sets several should side significant similar similarly simplest since single skipping software some something space specific spectre speculative stability standard start status struct structures success such sync synchronous system systematically: tag tagged tagging tags tcma1 is tcr technical techniques testing tfsr therefore these think those thread for transition two typesafe typically universally unknown use used user using value values various version of vulnerabilities vulnerability weakness well what when where which wild will winning without would write writes zerobackground |
| Tags | Vulnerability |
| Stories | |
| Notes | ★★ |
| Move | 
|
Les reprises de l'article (1):
| 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 | Vulnerability Studies |
| Stories | |
| Notes | ★★ |
| Move |
|
L'article ne semble pas avoir été repris sur un précédent.