Ciao a tutti, come forse ricorderete, secondo Mozilla e Chromium, "this is the Web functioning as designed" [1], ma dopo 3 anni da Spectre (e Meltdown), Google cerca di scaricare la responsabilità della sicurezza dei suoi utenti sugli sviluppatori web. [2] L'unica soluzione semplice, che ridurrebbe enormemente la superficie di attacco (disabilitare l'esecuzione automatica di JavaScript/WASM e permetterne l'abilitazione sito per sito su richiesta degli utenti e dopo aver avvertito loro dei rischi), non viene nemmeno presa in considerazione. In pratica, se ne lavano le mani. Qualunque sito che visitiate può accedere alla memoria del vostro computer e, con un po' di tempo, leggere le vostre password o qualsiasi altro dato personale. Non vi rimane che sperare che non abbiano alcun interesse a farlo E che abbiano le competenze (ed i fondi) per verificare che nessun pacchetto NPM che utilizzano faccia lo stesso. Consiglio personale: disabilitate Javascript e WebAssmbly sul vostro browser. Non utilizzate lo stesso computer per la navigazione quotidiana e l'accesso a servizi sensibili come l'home banking o l'esecuzione di programmi con accesso a dati sensibili come un password manager. Riavviate il PC dedicato a queste attività fra una attività sul web e l'altra e non eseguite mai alcun altro programma prima di avviare il browser. Se applicati sistematicamente e senza eccezioni, queste mitigazioni dovrebbero ridurre la probabilità che qualcuno entri nel vostro PC senza che ve ne accorgiate. Se vi sembrano troppo onerosi, sappiate che lo sono. Ma "this is the Web functioning as designed". Ed infatti Google offre agli sviluppatori lo Spectroscope, un plug-in di Chrome per identificare i problemi di sicurezza del proprio sito. Un po' come quando le Google Car di Google Maps mappavano i Wifi vulnerabili sul tragitto percorso: cosa mai potrebbe andare storto? Giacomo PS di seguito cerco di riportare solo i passaggi comprensibili anche dai non informatici, ma i dettagli e gli approfondimenti tecnici sono molto interessanti, ed importanti per chi sviluppa applicazioni Web in questo ecosistema malato per provare, budget permettendo, di minimizzare i danni per gli utenti (e per interrompere i progetti in cui il budget non permette queste mitigazioni per evitare guai con il GDPR). [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c10 [2] https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spect... ______ Three years ago, Spectre changed the way we think about security boundaries on the web. It quickly became clear that flaws in modern processors undermined the guarantees that web browsers could make about preventing data leaks between applications. As a result, web browser vendors have been continuously collaborating on approaches intended to harden the platform at scale. Nevertheless, this class of attacks still remains a concern and requires web developers to deploy application-level mitigations. [...] The Spectre vulnerability, disclosed to the public in January 2018, makes use of a class of processor (CPU) design vulnerabilities that allow an attacker to change the intended program control flow while the CPU is speculatively executing subsequent instructions. For example, the CPU may speculate that a length check passes, while in practice it will access out-of-bounds memory. While the CPU state is rolled back once the misprediction is noticed, this behavior leaves observable side effects which can leak data to an attacker. In 2019, the team responsible for V8, Chrome’s JavaScript engine, published a blog post and whitepaper concluding that such attacks can’t be reliably mitigated at the software level. [...] In parallel, browser vendors and standards bodies developed security mechanisms to protect web users from these classes of attacks. [...] These mechanisms, while crucially important, don't prevent the exploitation of Spectre; rather, they protect sensitive data from being present in parts of the memory from which they can be read by the attacker. [...] Today, we’re sharing proof-of-concept (PoC) code that confirms the practicality of Spectre exploits against JavaScript engines. We use Google Chrome to demonstrate our attack, but these issues are not specific to Chrome, and we expect that other modern browsers are similarly vulnerable to this exploitation vector. We have developed an interactive demonstration of the attack available at https://leaky.page/; the code and a more detailed writeup are published on Github here. The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. [...] For the published PoC, we implemented a simple Variant 1 gadget [...] however, Chrome's V8 team concluded that this is not the case for other gadgets: “we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software.” [...] By abusing the behavior of the Tree-PLRU cache eviction strategy commonly found in modern CPUs, we were able to significantly amplify the cache timing with a single read of secret data. This allowed us to leak data efficiently even with low precision timers. For technical details, see the demonstration at https://leaky.page/plru.html. [...] While operating system and web browser developers have implemented important built-in protections where possible [...], the design of existing web APIs still makes it possible for data to inadvertently flow into an attacker's process. [...] These protections mitigate Spectre-style hardware attacks and common web-level cross-site leaks, but require developers to assess the threat these vulnerabilities pose to their applications and understand how to deploy them. To assist in that evaluation, Chrome's web platform security team has published Post-Spectre Web Development and Mitigating Side-Channel Attacks with concrete advice for developers [...] To help you protect your website from Spectre, the Google Security Team has created Spectroscope, a prototype Chrome extension that scans your application and finds resources which may require enabling additional defenses. Consider using it to assist with your deployments of web isolation features.