Ci sarà anche chi si preoccupa del diritto all’oblio, ma secondo me è qualcuno che non ha provato a cercare un’informazione più vecchia di dieci anni… ho perso più tempo a cercare questo link che a scrivere il post… Giusto quest’anno avevo deciso di escludere dalla “casistica di vulnerabilità” che presento delle mie lezioni il problema del path nel caricamento di librerie dinamiche. Roba ormai vecchia, mi sono detto, adesso i problemi sono i mille modi in cui browser e web server interagiscono, come evitare certi problemi a livello di sistema è ormai patrimonio almeno delle aziende più grosse… il mio vecchio esempio del telnet lo avevo solo tirato fuori all’ultimo giorno di lezione, che è stata più che altro una chiacchierata… poi è venuto fuori il problema delle DLL. Qualcuno ha sottolineato che è un problema vecchio di dieci anni tornato alla luce. Ero stato tentato dal fare un post per ricordare che il problema è vecchio almeno di quindici, poi ho pensato che fosse pura polemica ed ho lasciato perdere…
Ora salta fuori che il problema riguarda anche gli exe… con il che si va ancora più indietro, e non posso non ricordare un vecchio giochetto che si poteva fare ai sistemisti Unix sui sistemi multiutente delle università… almeno questo spero non funzioni più 😉 Ma prima una breve spiegazione del problema generale, per chi non l’ha chiaro, che nel caso degli exe si capisce molto bene.
Quando lancio un programma, ad esempio da terminale, ma anche da un link sul desktop, posso fare essenzialmente due cose:
- indicare esplicitamente il path dell’eseguibile che voglio lanciare, ad esempio /bin/ls in Unix, o C:\Windows\Notepad.exe in Windows
- indicare il nome del programma, e lasciare che sia il sistema operativo a cercarlo
Nel secondo caso, dove può cercarlo il sistema operativo? Certo non fa sul momento una ricerca su tutto il disco, sarebbe troppo lungo. Nell’ambiente dell’utente esistono delle variabili (d’ambiente, appunto) che contengono un elenco ordinato di directory in cui cercare. La variabile in questione si chiama generalmente PATH o qualche variazione su questo nome. Siccome questo elenco è piuttosto breve, la ricerca è molto veloce, ma c’è anche un riflesso sulla sicurezza. Se il sistema operativo cercasse a caso sul disco, potrebbe eseguire un file che ha lo stesso nome, ma non è quello che cerchiamo: magari un programma pericoloso. Per questo, la variabile PATH deve contenere solo percorsi che noi consideriamo fidati e che, cosa importante, vengono esaminati nell’ordine. La situazione più comune è che la variabile contenga alcune directory di sistema (ad esempio “C:\Windows\system32;C:Windows;…”) in cui trovare i comandi di sistema, e poi, se lì non si è trovato niente, eventualmente la directory “.”, cioè la directory corrente (quella in cui si sta lavorando quando si prova a lanciare il programma).
I problemi nascono quando questa variabile è impostata male, o può essere modificata in modo imprevisto. E qui torniamo al nostro giochetto. Anni fa, era frequente, se non normale, che la variabile PATH, almeno nei sistemi Unix, iniziasse con la directory “.”, anziché averla alla fine. Quello che doveva fare quindi un utente per ottenere la possibilità di accedere agli account/diritti di altri, e di un amministratore, era di creare in una propria directory un programma “ls” (equivalente del comando “dir” del DOS) che altro non era se non uno script che copiava la shell /bin/sh (l’equivalente di cmd.exe di Windows) in una directory, settando lo sticky bit: per chi non ha pratica di Unix, vuole dire che chi crea il file “concede” i propri diritti a chi lo esegue, almeno per l’esecuzione di quel file. Dopodiché lo script chiamava il vero comando “/bin/ls”. A questo punto, tutto quello che serviva era convincere la vittima a guardare la directory contaminata. Ad esempio, si chiedeva al sistemista: “Sai, ho creato in una mia directory un file, ma per qualche motivo non riesco più a cancellarlo. Puoi provare a cancellarlo tu?” Siccome succede che con nomi contenenti caratteri speciali ci siano delle difficoltà, la vittima non si stupiva della richiesta. Accedeva quindi alla directory incriminata, eseguiva il comando “ls” per vedere il nome del file da cancellare, ma a causa dell’errore nella variabile PATH, il comando “ls” veniva cercato prima nella directory corrente, dove trovava lo script; quest’ultimo creava una copia di /bin/sh mettendoci lo sticky bit, e siccome era stato lanciato dall’amministratore, ci si trovava a disposizione una shell che eseguiva qualsiasi comando con i diritti di amministratore. Siccome lo script poi eseguiva il vero comando ls, l’amministratore non si accorgeva di niente…
A parte i ricordi, tutto questo dovrebbe far capire quanto sono delicati questi meccanismi, ma anche da quanto tempo la cosa è nota. Non è tanto sconfortante il fatto che tuttora si trovino di queste vulnerabilità (un po’ lo è), ma vale la pena di ragionare sull’effetto dirompente che possono avere dopo anni delle cattive pratiche, notoriamente tali, che sul momento vengono considerate poco gravi. L’effetto è simile a quello della vulnerabilità di “format string“, per anni introdotta nei programmi nonostante violasse le specifiche del C, fino a quando se ne sono scoperte le conseguenze. Lo so, è facile pontificare sul lavoro degli altri, ma io non ne sto facendo una colpa ai programmatori. So benissimo che lavorano sotto pressione ecc. ecc. Il vero problema è che la sicurezza non è ancora parte delle competenze “normali” di un programmatore, e tanto meno è negli interessi e nelle priorità della maggior parte delle software house. Il programmatore ancora non impara la sicurezza quando impara a programmare, e questo anche perché chi gli insegna a programmare a sua volta non la conosce. È già qualcosa che si comincino a trovare con frequenza corsi e seminari di programmazione sicura, ma la strada è ancora lunga, e non dovrebbero essere corsi specifici, ma parte della formazione normale, esattamente come si insegnano gli algoritmi di ordinamento. Soprattutto, andrebbe insegnata l’impostazione, più che i dettagli. Perché chi impara a programmare imparerà forse un decimo dai corsi, ma il resto lo impara guardando il codice di altri o, se è fortunato, dai colleghi, e questo non facilita certo la formazione di un’impostazione corretta. Più ancora, le aziende continuano a non avere attenzione alla sicurezza nello sviluppo del software. Il caso delle DLL è significativo, perché esistono ed esistevano delle linee guida che chiariscono il comportamento corretto, e perché non si tratta del processo invasivo e oneroso della validazione dell’input o della gestione delle eccezioni, ma di una operazione per la quale l’unico vero onere è riconoscerne la necessità.
È spiacevole che in alcuni casi la stessa Microsoft non abbia seguito le proprie linee guida: è chiaro che c’è un problema di processo, uno di quei problemi che con l’impegno dichiarato da Microsoft verso la sicurezza non si sarebbe più dovuto presentare. Tuttavia, quello che è veramente spiacevole è che come per il caso della format string, nei prossimi mesi, o anni, verrà fuori una pletora di applicazioni, più o meno importanti, che presentano questo tipo di vulnerabilità, la cui verifica entrerà a far parte degli strumenti abituali di assessment e che comporterà in generale una maggiore vulnerabilità diffusa, una vulnerabilità che si sarebbe evitata “semplicemente” seguendo le linee guida di Microsoft… ma quanti sviluppatori sanno di doverle seguire, quindi di doverle cercare, e dove cercarle?
