May 2020 - nexa - server-nexa.polito.it

la madre di tutte le vulnerabilità: memory unsafety.

by Giovanni Biscuolo

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-…: --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

May 26, 2020

Re: [nexa] Codice aperto di Immuni

by M. Fioretti

On Tue, May 26, 2020 09:30:20 AM +0200, Giuseppe Attardi wrote: > Come richiesto a più voci, il codice di Immuni è stato rilasciato Open Source. > > Ora è possibile farne una code review, analizzarlo e provare a migliorarlo. > Chi ha dei dubbi se i dati vengano raccolti da Google o Apple, lo potrà verificare. > Se teme che ciò avvenga all’interno della libreria di supporto, potrà verificarlo facendo sniffing dei pacchetti. > > https://www.agendadigitale.eu/sanita/immuni-prima-analisi-del-codice-bene-m… Prima ancora di leggere quell'articolo, copio e incollo quanto appena scritto da tale Massimiliano Uggeri su FB: Massimiliano Uggeri 23 hrs · OK, lo scrivo qui così è per tutti e facciamo prima e lo potete condividere se volete. Ovviamente è pieno di tecnicismi, se non capite chiedete, ma sono purtroppo necessari. Ho clonato il repo iOS da GitHub di #IMMUNI ed ho iniziato a curiosarci dentro mettendoci le mani. Dalla prima analisi questo è quello che ho trovato 1 - Utilizzo di CocoaPods come se piovesse (non che sia male, per carità, ma li ho sempre odiati) e questo, a parte i Pods fatti direttamente da Bending Spoons, non garantisce il controllo completo del codice. Certo, sono Pods ormai di uso comune, ma non c'è di fatto controllo su tutto; 2 - Il codice è scritto e documentato benissimo, c'è solo qualche warning nel build ma nulla di terribile, la prima cosa che si nota è che il Pod "KATANA" va aggiornato, per cui è come dicevo sopra, il controllo del codice è troppo frammentato per un'App così "delicata"; 3 - Gli errori (sono tutti trappati, per cui si vedono solo sulla console di debug) sono tutti sul collegamento che dovrebbe recuperare le chiavi di crittografia dal server che - di fatto - non esiste ("get.immuni.gov.it/v1/keys/index"), per cui mi chiedo come faccia Apple ad approvarla: se la mandano non passa nemmeno il primo ciclo di review e viene ritardato il rilascio. Il nome del server è farlocco, quello vero sarà un'altro e vabbè, si farà alla svelta a vedere sniffando il traffico; 4 - Questa è una versione che - come scritto chiaramente nel README e nel codice - lavora senza backend, per cui non raccontiamocela, questa è una versione "stubbata" per far star buona la gente; 5 - Non c'è nessuna richiesta di autenticazione, chiede solo regione e città, e per "caricare i dati" (non si sa quali e non si sa dove) viene effettivamente generato un codice che cambia ogni volta, per cui di fatto l'anonimato sembra realmente garantito; 6 - le chiamate per caricare ToS, Privacy, etc sono tutte dirette a "example.com", ragione per cui è chiarissimo che questa è solo una DEMO, pubblicata per far star buona la gente e non quello che Apple ha in approvazione. Concludendo, questa è una presa per il culo, l'ennesima dimostrazione che ci considerano dei poveri cretini ignoranti come loro. -- M. Fioretti http://mfioretti.com http://stop.zona-m.net Your own civil rights and the quality of your life heavily depend on how software is used *around* you

May 26, 2020

Re: [nexa] Codice aperto di Immuni

by Giovanni Biscuolo

Buongiorno Giuseppe, Giuseppe Attardi <attardi(a)di.unipi.it> writes: [...] > Se teme che ciò avvenga all’interno della libreria di supporto, potrà > verificarlo facendo sniffing dei pacchetti. Non ho approfondito la cosa ma immagino che sia perché della libreria di supporto non è disponibile il codice sorgente: ho capito bene? Se così fosse, quindi il codice delle librerie fosse proprietario, l'unico modo che c'è per capire cosa fa la libreria è applicare tecniche di reverse engineering (tra cui lo sniffing); però non è proprio la stessa cosa che poter analizzare il codice, richiede ulteriori competenze. Nell'articolo c'è scrtitto «l’utilizzo dell API di Apple e Google è riservato alle entità governative e ai dev approvati» e non ho la più pallida idea di come funzioni l'autorizzazione di accesso alle API. Sono sicuro che la cosa sarà documentata chiaramente in qualche pagina di https://www.google.com/covid19/exposurenotifications/ ma non ho sufficiente tempo per stare a studiare la cosa :-S > https://www.agendadigitale.eu/sanita/immuni-prima-analisi-del-codice-bene-m… Per completezza: --8<---------------cut here---------------start------------->8--- abbiamo per ora solo il codice dell’app, ma non i codici del server e quelli del backend usato per validare i codici (che sarà gestito dal ministero della Salute). --8<---------------cut here---------------end--------------->8--- [...] Cordiali saluti. Giovanni -- Giovanni Biscuolo

May 26, 2020

Codice aperto di Immuni

by Giuseppe Attardi

Come richiesto a più voci, il codice di Immuni è stato rilasciato Open Source. Ora è possibile farne una code review, analizzarlo e provare a migliorarlo. Chi ha dei dubbi se i dati vengano raccolti da Google o Apple, lo potrà verificare. Se teme che ciò avvenga all’interno della libreria di supporto, potrà verificarlo facendo sniffing dei pacchetti. https://www.agendadigitale.eu/sanita/immuni-prima-analisi-del-codice-bene-m… —

May 26, 2020

Small governments big failure

by Giuseppe Attardi

https://www.project-syndicate.org/commentary/small-governments-big-failure-…

May 26, 2020

Thai Database Leaks 8.3 Billion Internet Records

by Alberto Cammozzo

<https://rainbowtabl.es/2020/05/25/thai-database-leaks-internet-records/?=ma…> I recently discovered an exposed ElasticSearch database when browsing BinaryEdge and Shodan. This database appears to be controlled by a subsidiary of a major Thailand-based mobile network operator named Advanced Info Service (AIS). According to Wikipedia, AIS is "Thailand's largest GSM mobile phone operator with 39.87 million customers" as of 2016. The database was likely controlled by AIS subsidiary Advanced Wireless Network (AWN). It contained a combination of DNS query logs and NetFlow logs for what appears to be AWN customers. Using this data it is quite simple to paint a picture of what a person does on the Internet. I made multiple attempts to contact AIS to get the database secured without success. At that point I contacted Zack Whittaker – a journalist from TechCrunch – for assistance. We were still unable to make contact with AIS. I then contacted the Thailand National CERT team (ThaiCERT). ThaiCERT who was able to make contact with AIS, and we were successful in getting the database secured. [...]

May 26, 2020

Re: [nexa] Project Gutenberg oscurato (via DNS) in Italia

by Giovanni Biscuolo

Buongiorno, alcuni miei commenti e una domanda. Il primo è che da tempo non uso più i DNS del mio ISP ma uso https://dnscrypt.info/ (via dnscrypt-proxy [1] sul mio router openwrt): fatelo anche voi, è un piccolo sforzo che ripaga molto. Il secondo è che la collezione Project Gutemberg con 59105 pubblicazioni fa parte di Internet Archive: https://archive.org/details/gutenberg Sono in imbarazzo perché non so se segnalarlo alle forze dell'ordine possa comportare il sequestro dell'intero Internet Archive. Giovanni Biscuolo <giovanni(a)biscuolo.net> writes: [...] > Il decreto di sequestro preventivo è qui: > https://web.archive.org/web/20200525125134/https://lumendatabase.org/file_u… [...] > --8<---------------cut here---------------start------------->8--- > > Gli operanti hanno, dunque, verificato quanto effettivamente contenuto > nei siti internet sopra indicati, raccogliendo materiale di cui al > documento allegato 29. [...] [...] > [...] il fine di lucro emergendo dagli introiti delle inserzioni > pubblicitarie a pagamento. [...] > --8<---------------cut here---------------end--------------->8--- Sono sicuro al 99.99% che http://www.gutenberg.org/ NON ha nessun introito da inserzioni pubblicitarie, si può solo effettuare una donazione: io adesso faccio subito una donazione per chiedere scusa che sia stato oscurato anche a nome mio. Infine, senza avere dettagli su quali sono le opere analizzate dagli operanti, sono sicuro al 99.99% che le opere pubblicate da http://www.gutenberg.org/ sono di pubblico dominio in USA, c'è anche scritto chiaro nella homepage: --8<---------------cut here---------------start------------->8--- You will find the world's great literature here, with focus on older works for which U.S. copyright has expired. Thousands of volunteers digitized and diligently proofread the eBooks, for enjoyment and education. --8<---------------cut here---------------end--------------->8--- Domanda: si tratta di un refuso e gutemberg.org è stato sfortunato (sfortunato?!?) o davvero su http://www.gutenberg.org/ c'è qualche opera protetta dal diritto d'autore? Se non si tratta di un refuso, nel 2020 è normale che per _massimo_ un libro illegale (che dovrebbe essere esplicitato) venga oscurato un intero sito? Saluti, Giovanni [1] https://github.com/dnscrypt/dnscrypt-proxy/wiki/installation -- Giovanni Biscuolo

May 25, 2020

Project Gutenberg oscurato (via DNS) in Italia

by Giovanni Biscuolo

Buongiorno, come parte del procedimento penale n. 52127/20 RGNR - n. 35139/2020 RG GIP acceso presso Procura della Repubblica presso Tribunale di Roma è stata emessa una notifica di sequestro preventivo del Nucleo Speciale Tutela Privacy e Frodi Tecnologiche della GdF che include tra altri anche l'oscuramento - tramite oscuramento DNS - di http://www.gutenberg.org/ Questo l'annuncio del progetto: https://twitter.com/gutenberg_org/status/1264512881309085702 Il decreto di sequestro preventivo è qui: https://web.archive.org/web/20200525125134/https://lumendatabase.org/file_u… gutemberg.org è elencato per ben **due** volte: 1. al punto A.25) («in esecuzione di un medesimo disegno criminoso...») 2. al punto 25 del paragrafo «A sostegno di tale ricostruzione, gli operanti hanno individuato i seguenti siti [...] quindi gli operanti hanno provveduto ad estrapolare la relativa home page di accesso e ad individuarne gli elementi identificativi, ovvero: [segue scheda simil whois records per ogni sito, tra cui gnutemberg.org, n.d.r.]» Il documento prosegue poi: --8<---------------cut here---------------start------------->8--- Gli operanti hanno, dunque, verificato quanto effettivamente contenuto nei siti internet sopra indicati, raccogliendo materiale di cui al documento allegato 29. [...] Ciò premesso, le indagini finora condotte sono altamente significative per la sussistenza del fumiu boni iuris del reato ipotizzato, risultando accertate le illecite condotte di divulgazuione del contenuto di pubblicazioni protette dal diritto d'autore attraverso le reti telematiche sopra indicate. [...] il fine di lucro emergendo dagli introiti delle inserzioni pubblicitarie a pagamento. [...] consentire il legittimo sequestro preventivo mediante "oscuramento" di un intero sito telematico o di una pagina web [...] ORDINA il sequestro preventivo dei seguenti siti internet e/o risorse web: [OMISSIS] 14) quotidianionline.blogspot.com [OMISSIS] nonché dei "canali" sotto indicati tramite la piattaforma "Telegram" [OMISSIS] mediante oscuramento con notifica a tutti gli Internet Service Provider italiani al fine di inibirne il raggiungimento da parte degli utenti residenti sul territorio dello Stato Italiano. --8<---------------cut here---------------end--------------->8--- Manca l'allegato 29 nel quale dovrebbe essere raccolto il materiale che prova che anche www.gnutemberg.org stesse distribuendo materiale protetto dal diritto d'autore. Saluti, Giovanni. -- Giovanni Biscuolo

May 25, 2020

Re: [nexa] Copiare i dati e formattare il disco costituisce appropiazione indebita

by Giovanni Biscuolo

Ciao Giacomo, Giacomo Tesio <giacomo(a)tesio.it> writes: [...] > Ora parlare di possesso e furto di dati (e dunque di informazioni) è > abbastanza inappropriato. e infatti la sentenza della Corte Suprema USA diverge dai casi precedenti (in regime di common law fa un bel precedente): --8<---------------cut here---------------start------------->8--- Decision The Supreme Court justifiably diverged from predominant case law, which considers computer data to lack the physicality typical of tangible assets (ie, the object of such conduct as referred to in Article 646 of the Criminal Code). The judgment highlighted the following points with regard to computer files: * Although a computer file cannot be physically perceived, it has a physical dimension consisting of the amount of data of which it is composed, as demonstrated by the existence of units measuring the capacity of a file to hold data and the various dimensions of the hardware in which files are stored and processed. * Computer files can be transferred from one digital device to another, maintaining their structural characteristics as well as the possibility that the same data can be transferred via an internet network to be sent from one system or device to another at considerable distances or stored in virtual environments (corresponding to physical places where computers store and process computer data). These characteristics confirm the logical assumption of the possibility that computer data can be the object of theft and appropriation. Moreover, the same case law has set out the criminal notion of tangible assets through the identification of some essential characteristics (ie, the materiality and physicality of the object), which must be definable in space and susceptible to transfer from one place to another, thus making possible one of the typical characteristics of the seizure of property (ie, the removal of an object from the control of its owner or rights holder). Having clarified, therefore, that a computer file constitutes a tangible asset, the court stated that in order for embezzlement to exist, computer data needs to move from being a temporary possession (acquired as a result of contractual or negotiated agreements with the obligation to return it) to a definitive possession. However, there must also be evidence of clear and permanent misappropriation of such data after its deletion from a company computer. Only in such cases will such actions be considered property theft. --8<---------------cut here---------------end--------------->8--- In questo la corte mi pare riconosca che in effetti l'informazione ha anche una componente fisica (come ha illustrato tu nei vari passaggi) non trascurabile... da cui anche la possibilità di avere "accesso fisico" a un file. > Se il dipendente avesse cifrato i dati, trasformandoli in una > rappresentazione accessibile solo a lui, non si sarebbe potuta > dimostrare la copia. Però, stando a quanto riportato sopra, la Corte avrebbe potuto stabilire si trattasse di sequestro, anche senza dimostrazione di esistenza della copia. > Ma la domanda è: se non li avesse eliminati, si sarebbe potuto parlare di > furto? Sopra viene riportato che «move from being a temporary possession (acquired as a result of contractual or negotiated agreements with the obligation to return it) to a definitive possession» assieme all'evidenza che si tratti di una «clear and permanent misappropriation» faccia sì che l'atto possa essere considerato furto. Io sono il primo che va in tilt quando vengono applicate norme pensate per oggetti fisici (ai quali può essere applicato il concetto di proprietà) alle informazioni digitalizzate (alle quali è *sbagliato* applicare il concetto di proprietà): secondo me le aziende per tutelare i propri diritti sui segreti industriali e la riservatezza delle informazioni hanno altri strumenti appositamente pensati; in Italia abbiamo il "Codice della proprietà indistriale" [1]. Non ho idea di come potrebbe essere giudicato in Italia un caso simile, credo che la discriminante sia l'effettivo contenuto delle informazioni copiate e l'eventuale impedimento all'azienda di ottenere una copia delle informazioni che legittimamente fanno parte del proprio bagaglio informativo, raccolto e archiviato dal dipendente nell'esecuzione delle sue mansioni (in particolare in mancanza di un adeguato backup e riesame periodico di tali informazioni da parte di un supervisore aziendale). Comunque sia è fuori di dubbio che la digitalizzazione delle informazioni abbia radicalmente cambiato anche solo il concetto di «segreto indistriale» e di conseguenza le norme e il mercato fanno fatica a star dietro a questo cambio di paradigma. Ci sarà prima o poi un cambio di paradigma anche nelle norme e in come le aziende fanno business? ...per esempio facendo business in modo innovativo partecipando al movimento https://en.wikipedia.org/wiki/Open-design_movement? :-O Ciao, Giovanni [1] https://it.wikipedia.org/wiki/Codice_della_proprietà_industriale Tutta la parte riguardante le «invenzioni bioteconologiche» e «Nuove varietà vegetali» _deve_ essere combattuta e abolita, non si può sopportare che composti biologici o addirittura specie vegetali (a quando animali?) siano brevettati/brevettabili. > On Monday, 25 May 2020, Diego Giorio <dgiorio(a)hotmail.com> wrote: >> Mi sembra che non sia ancora passato in lista: >> > https://www.lexology.com/library/detail.aspx?g=58d623c7-984c-4f11-892b-9f9d… >> [...] -- Giovanni Biscuolo

May 25, 2020

Re: [nexa] Copiare i dati e formattare il disco costituisce appropiazione indebita

by Giacomo Tesio

Grazie mille Alberto. On Monday, 25 May 2020, Alberto Cammozzo <ac+nexa(a)zeromx.net> wrote: > > La sentenza ha una argomentazione piuttosto elaborata. E devo dire, piuttosto astuta. Tuttavia questa complessità ricorda un pochino certe arzigogolate pezze che tentano di arginare (e nascondere) gli errori architetturali di un sistema concettuale (espresso come software o meno). Devo approfondire, ma trovo questa argomentazione piuttosto preoccupante. Mi ricorda che per quanto un sistema giuridico sia alienato dalla realtà, per quanto non sia in grado di comprenderla e descriverla e dunque regolarla, rimane vigente. Quanto meno formalmente. Poi ci sono i DPCM. Poi ci sono le leggi scritte da parlamenti eletti attraverso leggi elettorali incostituzionali. Etc... Giacomo

May 25, 2020