One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 8595497 |
| Date de publication | 2024-10-10 12:00:46 (vue: 2024-10-10 16:17:04) |
| Titre | Utilisation des API de l'accessibilité de Chrome pour trouver des bogues de sécurité Using Chrome\\'s accessibility APIs to find security bugs |
| Texte | Posted by Adrian Taylor, Security Engineer, Chrome
Chrome\'s user interface (UI) code is complex, and sometimes has bugs.
Are those bugs security bugs? Specifically, if a user\'s clicks and actions result in memory corruption, is that something that an attacker can exploit to harm that user?
Our security severity guidelines say “yes, sometimes.” For example, an attacker could very likely convince a user to click an autofill prompt, but it will be much harder to convince the user to step through a whole flow of different dialogs.
Even if these bugs aren\'t the most easily exploitable, it takes a great deal of time for our security shepherds to make these determinations. User interface bugs are often flakey (that is, not reliably reproducible). Also, even if these bugs aren\'t necessarily deemed to be exploitable, they may still be annoying crashes which bother the user.
It would be great if we could find these bugs automatically.
If only the whole tree of Chrome UI controls were exposed, somehow, such that we could enumerate and interact with each UI control automatically.
Aha! Chrome exposes all the UI controls to assistive technology. Chrome goes to great lengths to ensure its entire UI is exposed to screen readers, braille devices and other such assistive tech. This tree of controls includes all the toolbars, menus, and the structure of the page itself. This structural definition of the browser user interface is already sometimes used in other contexts, for example by some password managers, demonstrating that investing in accessibility has benefits for all users. We\'re now taking that investment and leveraging it to find security bugs, too.
Specifically, we\'re now “fuzzing” that accessibility tree - that is, interacting with the different UI controls semi-randomly to see if we can make things crash. This technique has a long pedigree.
Screen reader technology is a bit different on each platform, but on Linux the tree can be explored using Accerciser.
Screenshot of Accerciser showing the tree of UI controls in Chrome
All we have to do is explore the same tree of controls with a fuzzer. How hard can it be?
“We do this not because it is easy, but because we thought it would be easy” - Anon.
Actually we never thought this would be easy, and a few different bits of tech have had to fall into place to make this possible. Specifically,
There are lots of combinations of ways to interact with Chrome. Truly randomly clicking on UI controls probably won\'t find bugs - we would like to leverage coverage-guided fuzzing to help the fuzzer select combinations of controls that seem to reach into |
| Notes | ★★★ |
| Envoyé | Oui |
| Condensat | 124 125 126 able about accerciser access accessibility achieved across action actionable actions actual actually add added adrian aha all along already also amortize annoying anon anonymous any apis applied approach are aren assistive assuming attacker autofill automatically based batch because been benefits best binary bisect bit bits blog bookmarks both bother braille browser bug bugs but can case cases centipede challenges chance chart chrome chromium click clicking clicks clusterfuzz code combination combinations comes common comparisons complex concatenation concerns confuse context contexts control controls convince corruption cost could couple cover coverage crash crashes currently custom dashboard deal deemed deeply definition demonstrating descriptive designed determinations devices diagnostics dialogs different discover does don each easily easy easy” effective engineer enough ensure entire enumerate environment essentially even evolves example exercising exist expands exploit exploitable explore explored exposed exposes eye fact fall far find finding fixed flakey flow follow found framework fundamental fuzz fuzzer fuzzers fuzzing gathering genuine get given gives goes great guided guidelines had hard harder harm has hasn have help here high hopefully hours how human id: ideally idempotent identified includes infrastructure initially inprocessfuzzer instance instead instrumentation intend interact interacting interface introduced investing investment invocation ipc isn its itself keep know known large lengths level leverage leveraging libprotobuf like likely linux long lots make managers may mean means: memory menus minimize minutes modified most much mutator name name: named names necessarily need nested never new noisy not notably now often only order ordinal original other otherwise out over page panel parts password path paths pedigree picked picking place platform play possible posted posts potential present presented probably prompt proven providing put quick randomly rather reach reader readers real reliably reproduce reproducer reproduces reproducible requirements resolve restricted result role role: roles run running runs same say says screen screenshot security see seem select semi set settled severity shepherds should showing similar simply since slow smallest smart some somehow something sometimes specific specifically stable standard startup state step strategies string structural structure stumble successfully successively such take takes taking taylor tech technique technology test test; tests than that them therefore these they things this: thorough those thought thousands through time timers together too toolbars tree tricky truly turned unit unlikely unrealistic use used useful user users using version very ways well when where which whole will within won work working worlds would writing yet yields you “control “fuzzing” “we “yes |
| Tags | Threat |
| Stories | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.