Tempo fa ho preso postfix come esempio di programmazione sicura, così mi ha un po’ spiazzato la notizia pubblicata da Heise titolata: “Postfix mail servers under pressure“. Poi ho letto l’articolo ed ho capito: il problema è legato ad un modulo policyd, un modulo per il graylisting che non è parte di postfix ma è sviluppato da terzi. È chiaro che moduli aggiunti possono tranquillamente avere qualità diversa dal codice originale. È una cosa della quale i creatori di software modulari si lamentano sempre, in quanto poi i difetti vengono associati, come in questo caso, al programma. Al riguardo ricordo in particolare le sfuriate sulle mailing list di Bernstein, autore di qmail. Tuttavia, c’è un altro punto che mi lascia perplesso: guardando le statistiche su Sourceforge del progetto policyd, si vede che di fatto il codice ha cominciato ad essere scaricato due o tre mesi fa. Tutto, dalle statistiche alle maling list al Changelog, sembra indicare che è un progetto molto giovane, sviluppato negli ultimi tre mesi. Invece, andando a leggere il codice o le statistiche della distribuzione Debian, risulta che il progetto è attivo addirittura dal 2004, e che Debian lo segue da metà del 2005. In effetti, la maggior parte dei link che si trovano su policyd riguarda Debian. Qual’è il problema? Nello scegliere quale software utilizzare, in particolare software di sicurezza per un servizio pubblico come l’SMTP, la valutazione dovrebbe comprendere la stabilità e la storia di “non insicurezza” del software. Cosa bisogna allora considerare: che è un pacchetto sviluppato e utilizzato da due anni, e che questa è la prima segnalazione di sicurezza, o che di fatto è un pacchetto sviluppato negli ultimi tre mesi e quindi da considerare ancora poco testato?
Il problema del dover utilizzare soluzioni ancora poco stabili era già chiaro per altre tipologie di software, ma sta diventando sempre più frequente anche per prodotti di sicurezza. In mancanza di lunghi periodi di test e verifica della stabilità, è ancora più necessario spooerire con una buona progettazione del software, prima ancora che con la scrittura di buon codice. Diventa quindi ancora più importante che non solo il software venga accuratamente progettato, ma che la logica del progetto sia descritta in modo convincente nella documentazione. Di nuovo, il Postfix originale aveva ben documentato la propria logica e i motivi per cui quel disegno era sicuro, e il tempo gli ha dato ragione: essere in grado di descrivere perché il codice è sicuro è una garanzia che il progetto è stato ragionato, mentre indicare seplicemente che il codice è stato auditato dice veramente poco sulla reale qualità.
Per concludere, l’articolo parla anche (in modo più appropriato per il titolo) di un problema di connessioni terminate in modo anomalo che starebbe interessando particolarmente i server SMTP postfix. La possibilità che un numero elevato di connessioni terminte in modo anomalo possa mettere in crisi un server è un problema (anche di DoS se il server è pubblico) che in sè non ha soluzione. Tuttavia, codice e configurazione anche qui possono fare differenza sull’entità del problema. Qui, come segnalato da Heise, vengono indicati alcuni miglioramenti alla configurazione di postfix che possono aiutare ad affrontare eventuali difficoltà.
