Ventoy è sicuro?

[marcobi1964]

Ho letto con molto interesse l'articolo su Ventoy di crazy cat e Zane, e vorrei creare un supporto usb con le varie ISO. Ho scaricato l'eseguibile, e prima di installarlo l'ho passato su VirusTotal e qui, dopo la scansione, alcuni antivirus,tra l'altro mai sentiti, lo rilevano come troyan. Possono essere falsi positivi? Grazie

[crazy.cat]

Sono falsi positivi

[ctsvevo]

Brutta cosa la paranoia...

[CUB3]

Brutta cosa la paranoia...

Forse è solo un lecito dubbio.

Adoro Ventoy, mi consente di provare un sacco di ISO senza dover ogni volta creare una chiavetta ma, ad un certo punto ho anche io avuto un qualche dubbio sulla natura di Ventoy, per il semplice fatto che, un sistema operativo avviato (o installato!) in questo modo potrebbe avere un bootkit impossibile da rilevare dal sistema stesso. Approfondendo la questione sono incappato in molti post che chiedono la stessa cosa di marcobi1964: Ventoy è sicuro?. Tra tutti i post dove si può trovare tutto e il contrario di tutto mi hanno incuriosito di più quelli che chiedono come mai in Ventoy sono presenti numerosi BLOB (Binary Large OBject) con scarsa o nessuna documentazione in merito?

Bene la issue di cui ho messo il link, aperta 8 mesi fa, non è ancora stata chiusa ma lo sviluppo di Ventoy ha continuato ad andare avanti.

Per tornare alla domanda principale della discussione, con questo voglio dire che Ventoy non è sicuro? Assolutamente no, ma è almeno lecito farsi qualche domanda.
Io continuerò ad utilizzare Ventoy per provare sistemi LIVE ma se devo installare un sistema operativo, preferisco creare una chiavetta ad hoc.

[marcobi1964]

Ho letto parte della discussione postata da Cub3 su Reddit riguardo Ventoy, e da quello che ho capito, nessuno può affermare con certezza che il sofware sia completamente pulito, ma neanche il contrario. Alcuni dicono che se ci fosse davvero all'nterno del codice malevolo,dopo tutto questo tempo, qualcuno se ne sarebbe accorto. Ma qualcun'altro ha portato ad esempio quello che è successo con la backdoor XZ inserita in molte distribuzioni Linux, e scoperto per puro caso.
E a proposito di paranoia, lascio il link a questo video dal titolo sicuramente poco rassicurante.

https://www.youtube.com/watch?v=FpT_cYUaxkU

[rapaceto]

Uso ventoy per avviare i live cd di 'servizio' e benedetto chi lo ha progettato. Si crea una chiave avviabile veloce e funzionante, basta aggiornare le iso e si evita di perdere tempo, per chi fa questo lavoro è importante avere a disposizione strumenti stabili e funzionali, mi trovo bene con Ventoy e non mi sono posto domande se ha o meno una backdoor, partendo da questo principio qualsiasi programma potrebbe avere una backdoor nascosta.

[CUB3]

partendo da questo principio qualsiasi programma potrebbe avere una backdoor nascosta.

Tranne quelli il cui codice sorgente è completamente aperto

[Zigul]

In realtà, purtroppo codice aperto non significa codice controllato, ma solo codice controllabile. Anzi, l'unica certezza del codice aperto è che, salvo rari casi, nessuno ha il dovere di controllarlo prima che venga diffuso; quindi solitamente è codice che si aggira "allo stato brado", richiedendo principalmente che ci si fidi dello sviluppatore. Diciamolo: quando scarichiamo codice open source ci rassicuriamo pensando che qualcuno, con più competenze di noi, "lo avrà certamente controllato...", ma è una speranza, non una certezza.
Resta vero che la casistica di applicazioni a codice aperto volutamente malevole è molto rarefatta, ma ciò non toglie che il codice aperto di per sé non è automaticamente garanzia di affidabilità, ma solo di potenziale controllabilità e possono infatti esserci vulnerabilità (sebbene non volutamente introdotte) che rendono comunque un programma open source insicuro, proprio come capita con quelli "chiusi".
Inoltre sembra che chi abbia davvero controllato recentemente la sicurezza dei programmi open source, segnali una crescente presenza di codice malevolo; per fortuna, la comunità open source risponde al problema con repository (come questo) in cui prova a tenere traccia dei pacchetti con codice malevolo (il che dimostra una volta di più che l'open source non è "il paese dei balocchi" per la sicurezza).

[Janez]

bhe! istintivamente quando vedo che un programma è open source tendo a fidarmi di più, però è come dice @Zigul, perché spero che qualcuno più competente di me (non ci vuole molto) lo abbia controllato.
La mia precedente esperienza sull'ambiente mainframe, anche ne avessi una qualche reminisceza, è completamente inutile sul software di questo tipo.
Però un dubbio ce l'ho comunque.
Quando scarico un eseguibile open source, chi mi garantisce che corrisponda al sorgente indicato nello stesso sito ?

[CUB3]

In realtà, purtroppo codice aperto non significa codice controllato, ma solo codice controllabile. Anzi, l'unica certezza del codice aperto è che, salvo rari casi, nessuno ha il dovere di controllarlo prima che venga diffuso; quindi solitamente è codice che si aggira "allo stato brado", richiedendo principalmente che ci si fidi dello sviluppatore.

Questo è un grande vantaggio dell'open source! Il codice può essere ispezionato da chiunque ne abbia le capacità molto prima che entri in produzione, prima del rilascio di una qualunque versione di sviluppo o prova ma al momento stesso del cambiamento del codice. Riguardo alla fiducia dello sviluppatore credo che sia più necessaria riguardo a programmi a codice chiuso (ma forse in questo caso dovremo parlare di fede?) e più ben riposta nel caso di sorgente aperto, non trovi?

Diciamolo: quando scarichiamo codice open source ci rassicuriamo pensando che qualcuno, con più competenze di noi, "lo avrà certamente controllato...", ma è una speranza, non una certezza.

Se generalizziamo posso anche essere d'accordo con te ma se analizziamo attentamente la questione vedrai bene che può essere vero anche il contrario. Un esempio, giusto per farti capire dove voglio andare a parare: stai sicuro che coloro che controllano il kernel Linux sono molti ma molti di più di quelli che controllano il kernel di Windows!

Resta vero che la casistica di applicazioni a codice aperto volutamente malevole è molto rarefatta, ma ciò non toglie che il codice aperto di per sé non è automaticamente garanzia di affidabilità, ma solo di potenziale controllabilità e possono infatti esserci vulnerabilità (sebbene non volutamente introdotte) che rendono comunque un programma open source insicuro, proprio come capita con quelli "chiusi".
Inoltre sembra che chi abbia davvero controllato recentemente la sicurezza dei programmi open source, segnali una crescente presenza di codice malevolo; per fortuna, la comunità open source risponde al problema con repository (come questo) in cui prova a tenere traccia dei pacchetti con codice malevolo (il che dimostra una volta di più che l'open source non è "il paese dei balocchi" per la sicurezza).

Sappiamo ormai bene che la natura del codice, aperto o chiuso, non garantisce di per sé sicurezza e a poco senso sia comparare la natura di questi due mondi, riguardo questo aspetto, data la loro eterogeneità sia fare un parallelo di un programma open source con un alternativa closed perché estremamente riduttivo.
Allo stesso modo, c'è da dire che il trend di aumento nella scoperta di vulnerabilità o malware è generalizzato e non relativo soltanto dell'open source.

Quello che può garantire l'open source è che una vulnerabilità o un malware sia scoperto prima che il software affetto entri in produzione e che quindi sia sfruttabile su larga scala e questo vale tanto più quanto più è diffuso e utilizzato il software in oggetto. Prova di questo è data dal numero delle vulnerabilità 0days che vengono scoperte.
Un altra cosa che di solito è a favore dell'open source (anche in questo caso l'affermazione che segue è tanto più vera quanto più è diffuso e utilizzato il software) è il tempo che intercorre tra la scoperta di una vulnerabilità e il rilascio di una patch.

[marcobi1964]

Ma se Ventoy contenesse del codice malevolo all'interno, potremmo infettare sia la macchina sulla quale viene installato, sia quelle eventuali a cui verrebbe connessa la chiavetta creata?

[Zigul]

Sappiamo ormai bene che la natura del codice, aperto o chiuso, non garantisce di per sé sicurezza e ha poco senso sia comparare la natura di questi due mondi, riguardo questo aspetto, data la loro eterogeneità sia fare un parallelo di un programma open source con un alternativa closed perché estremamente riduttivo.
Allo stesso modo, c'è da dire che il trend di aumento nella scoperta di vulnerabilità o malware è generalizzato e non relativo soltanto dell'open source.

Questo è un po' il fulcro di quello che intendevo: mi sembra che a volte si abbia la falsa percezione che ciò che è open source sia sicuro, per il solo fatto di essere trasparente e controllabile. Purtroppo invece, ad essere realisti, il "re è nudo": l'open source non è sicuro proprio perché open (uno sviluppatore può metterci mano senza essere sempre e necessariamente "filtrato", v. faccenda XZ); ha bisogno di controlli (e non solo di potenziale controllabilità), proprio come qualunque codice in quanto tale (non sto quindi dicendo che l'open sia meno sicuro del closed).
I kernel in ambito Linux sembrano essere un buon esempio d'affidabilità, ma in fondo quanti di quegli sviluppatori si erano accorti della vulnerabilità in XZ? Di fatto non era loro compito (per ironia del destino, mi pare sia stato uno sviluppatore Microsoft), proprio perché, come detto sopra, non è compito di nessuno controllare l'open source; sono controlli che possono avvenire o meno, ma intanto il codice si diffonde anche in produzione (e più si diffonde, più crescerà la fiducia sulla sua presunta sicurezza). Comunque, al di là della questione di XZ, che è sicuramente una mosca bianca, il pullulare di 0-day e la continua necessità di patch, a mio avviso, confermano che la questione della sicurezza è trasversale a quella dell'apertura o meno del codice, rendendo infondato lo stereotipo del "codice sicuro perché open". Con questo non intendo contrapporre filosofia open e closed, ma piuttosto accomunarle nella basilare esigenza di controlli di sicurezza (fermo restando che i due mondi hanno dinamiche differenti).

Però un dubbio ce l'ho comunque.
Quando scarico un eseguibile open source, chi mi garantisce che corrisponda al sorgente indicato nello stesso sito ?

Credo che l'unico garante sia il sito stesso; qualora venisse "avvelenato" il link o il file scaricato (come capitò con CCleaner, se non ricordo male), se non è un file firmato digitalmente (come può capitare nell'open source meno popolare) e se non c'è nemmeno un hash ufficiale per verificare l'eseguibile, l'untente potrebbe non accorgersi subito della discrepanza. Per fortuna, non dovrebbe essere troppo facile manomettere i principali siti di condivisione di codice open source per iniettare modifiche malevole; forse è più probabile (comunque poco) che venga violato l'account di uno sviluppatore e venga usata la sua credibilità per contaminare tempestivamente il codice dei suoi progetti, ma non so se ci sono mai stati casi simili.

Ma se Ventoy contenesse del codice malevolo all'interno, potremmo infettare sia la macchina sulla quale viene installato, sia quelle eventuali a cui verrebbe connessa la chiavetta creata?

Dipende da quale è l'azione perpetrata dal codice malevolo; se non si conosce l'arma, non si può ipotizzare il danno.