Buongiorno nexiani, <premessa> molti di voi sanno già di cosa si tratta ma per coloro che non sanno di cosa si tratta mi permetto una brevissima spiegazione del concetto opposto - la memory safety - estrapolata e tradotta da Wikipedia [1] --8<---------------cut here---------------start------------->8--- La memory safety (sicurezza della memoria) è la condizione di essere protetti da svariati errori software e vulnerabilità di sicurezza quando si gestisce l'accesso alla memoria --8<---------------cut here---------------end--------------->8--- Esistono linguaggi di programmazione che sono storicamente memory unsafe, tra questi il C/C++, e ne esistono altri che sono memory safe, tra questi Java, Rust e molti altri. Quando si verificano errori di programmazione nella gestione della memoria in linguaggi memory unsafe, succede che i programmi abortiscono, nel migliore dei casi, oppure espongono il sistema alle vulnerabilità di sicurezza che possono essere usate da un attaccante a proprio vantaggio. Con in linguaggi memory safe questi problemi non si verificano perché hanno meccanismi di individuazione degli errori prima che il programma scriva effettivamente in locazioni della memoria che non deve usare. (Se mi sbaglio mi corrigerete) </premessa> Perdonate la piccola divagazione, torno al punto. Un amico mi segnala questo documento di Google (non trovo a quando è aggiornato): https://www.chromium.org/Home/chromium-security/memory-safety: --8<---------------cut here---------------start------------->8--- The Chromium project finds that around 70% of our serious security bugs are memory safety problems. Our next major project is to prevent such bugs at source. [...] Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. [...] we are reaching the limits of sandboxing and site isolation. [...] We can no longer derive sufficient innovation from more processes or stronger sandboxes (though such things continue to be necessary). [...] We’re tackling the memory unsafety problem — fixing classes of bugs at scale, rather than merely containing them — by any and all means necessary, including: [...] Using safer languages anywhere applicable --8<---------------cut here---------------end--------------->8--- Poi c'è un grafico che tradurrei così: - minor costo, minor miglioramento: migliorare il codice C++ eliminando gli errori - maggior costo, maggior miglioramento: usare componenti in Rust (un linguaggio memory safe) La memory unsafety è la bestia nera della sicurezza software... da sempre, praticamente da quando si programma; per dare un'idea di quanto pesa, cito https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-o...: --8<---------------cut here---------------start------------->8--- A recent study found that 60-70% of vulnerabilities in iOS and macOS are caused by memory unsafety. Microsoft estimates that 70% of all vulnerabilities in their products over the last decade have been caused by memory unsafety. Google estimated that 90% of Android vulnerabilities are memory unsafety. An analysis of 0-days that were discovered being exploited in the wild found that more than 80% of the exploited vulnerabilities were due to memory unsafety. [...] These vulnerabilities are exploited, to the peril of hospitals, human rights dissidents, and health policy experts [...] --8<---------------cut here---------------end--------------->8--- Una classe di software dove i problemi di memory safety sono all'ordine del giorno e un rischio costante per gli utenti sono i browser web, perché sono maledettamente complessi e _soprattutto_ perché interpretano codice Javascript scaricato dalle pagine che si visitiamo (se non glielo si impedisce, con evidenti conseguenze sull'esperienza utente nella navigazione). Non vorrei aprire qui una flamewar sui linguaggi di programmazione, l'argomento è complesso e non può essere discusso efficacemente via email: dico solo che ho studiato ed è da quando ho iniziato a studiare c'è sempre qualcuno che sostiene che con la buona pratica egli è capace di evitare errori di memoria in C/C++ e sono gli altri che non sono capaci di programmare. Riporto qui la **provocazione** di Gaynor (non è il solo ad aver scritto cose analoghe): --8<---------------cut here---------------start------------->8--- Using C and C++ is bad for society, bad for your reputation, and it’s bad for your customers. --8<---------------cut here---------------end--------------->8--- La questione potrebbe essere riassunta così, secondo quanto ho capito fino ad ora: 1. per diversi "componenti" di basso livello (per esempio il kernel) il vantaggio competitivo di C è ancora alto (soprattutto per la quantità di codice già scritto) e forse vale la pena investire molte ore/uomo per eliminare gli errori di gestione della memoria; 2. per i componenti più ad alto livello (applicativi) varrebbe la pena cominciare a investire seriamente sulla riscrittura del software con linguaggi memory safe. Perché lo dico qui? Perché sul software c'è ancora una mole imponente di lavoro da fare e in questa mole buona parte dello spazio è occupata dalla soluzione di questa classe di problemi che *quotidianamente* rendono insicuri i nostri sistemi digitali. Se anche Google valuta che continuare a buttare via ore e ore di sessioni di debugging per risolvere i problemi di memoria costa meno che riscrivere il (o almeno parti del) software in linguaggi memory safe, se la stessa cosa sono costretti a fare in centinaia di aziende grandi e piccole, significa che abbiamo un problema che *forse* il mercato per come è strutturato oggi non riesce a risolvere da solo. Io non lo so qual'è la soluzione, sempre che esista una soluzione applicabile (actionable). Questo dibattito però non deve rimanere "confinato" agli specialisti e TANTOMENO essere declassato a una questione di "gusti" dei programmatori sul linguaggio che preferiscono: anche i non programmatori _devono_ sapere di cosa si tratta e questo dibattito dovrebbe diventare pubblico, dovrebbe diventare **politico**; oltre che di competenze qui si tratta di avere anche adeguate risorse per affrontare questi problemi, che NON SONO dei programmatori, sono di tutti noi, sono _anche_ di sicurezza nazionale. ...però mi rendo conto di essere anche piuttosto ingenuo nello sperare che questo possa diventare un dibattito politico :-D Cordiali saluti. Giovanni. [1] https://en.wikipedia.org/wiki/Memory_safety -- Giovanni Biscuolo