So che parlare di stampa può sembrare molto retro ma vi assicuro che qualcuno, là fuori, ne ha ancora bisogno; e magari ha anche bisogno di tener traccia di chi stampa cosa e quanto; e magari lo deve fare in un ambiente misto.Insomma, un mezzo incubo.

Fino ad oggi, sotto Mac OS X era pos­sibile autenticarsi per la stampa in IPP usando un URL del tipo ipp://account:password@server/printer e quindi esponendo informazioni potenzialmente sensibili.Leopard irrobustisce il supporto all’IPP autenticato, anche se ancora con qualche difetto, permettendo un uso meno fragile delle credenziali.

Per aggirare i problemi di usabilità seguite queste istruzioni, su Mac OS X Hints: “10.5: Set up authenticated printing via IPP”.

Questo articolo di Apple sul firewall di Leopard contiene alcuni dettagli interes­santi. Il primo – e più noto – è che si tratta di un firewall che lavora a livello di applicazione e non a livello di porte: mi basta dire che deve accettare le connes­sioni entranti per iTunes, invece che dover specificare quali siano le porte usate dall’applicazione, ad esempio.

Ma più oltre si trovano pre­cisazioni da tenere a mente. Sul “livello” a cui lavora questo software:

The Application Firewall does not overrule rules set with ipfw, because ipfw operates on packets at a lower level in the networking stack.

Riguardo ai legami fra il firewall e il code signing:

When you add an application to this list, Mac OS X digitally signs the application (if it has not been signed already). If the application is modified, you will be prompted to allow or deny incoming network connections to it. Most applications do not modify themselves, and this is a safety feature that notifies you of the change.

Quindi il code signing può avvenire anche ex post, per una singola applicazione, mentre pensavo fosse una pre–condizione da soddisfare prima di applicare delle regole con il firewall. Tant’è vero che più sotto si pre­cisa che se un’applicazione non pre­sente nell’elenco cerca di effettuare un qualche tipo di connes­sione, viene pre­sentata una finestra di dialogo che chiede all’utente cosa fare e, nel caso in cui, acconsenta all’esecuzione dell’applicazione, quest’ultima viene firmata.

Infine, se non esplicitamente aggiunte come applicazioni escluse, tutti i processi che girano come root o sono firmate da una Certificate Authority fidata (come quelle di Apple) hanno pos­sibilità di effettuare connessioni.

Matasano ha postato degli aggiornamenti all’analisi di Leopard nell’ambito della sicurezza, in parte per pre­cisare, chiarire e sintetizzare la messe di informazioni dai commenti, in parte per analizzare altre novità.

Fra queste novità la più rilevante – dal punto di vista di Matasano – è il “Parental Control”. Questo sistema può essere usato per controllare quali eseguibili un certo account può utilizzare e fornisce gratis quello che sotto Windows viene venduto a caro prezzo come software aggiuntivo di terze parti. Purtroppo è pos­sibile aggirare la limitazione sugli eseguibili compilando del codice come dylib e “iniettarlo” in un’applicazione autorizzata all’esecuzione tramite DYLDINSERTLIBRARIES.

A proposito del code signing, contrariamente a quanto riportato, sembra che Mac OS 10.5 (più pre­cisamente il firewall) lo usi per delle effettive restrizioni.

Appena posso, riporto volentieri gli articoli di Bruce Schneier perché mi aiutano a guardare le cose con un occhio un po’ più critico di quanto solitamente non faccia.

Nel suo ultimo articolo, apparso anche su Wired, Schneier analizza le conseguenze delle campagne di sensibilizzazione condotte negli USA per stimolare la collaborazione dei cittadini. Ad es. quella diffusa nella metropolitana di New York e che usato per il titolo. La prima volta che ne ho sentito parlare mi sembrava una cosa lodevole, tipo “Pubblicità Progresso” ma Schneier ci fa notare come troppo spesso le segnalazioni dei cittadini si traducano in falsi allarmi e tutto questo perché, una volta innescato il meccanismo, nes­suno vuole rischiare di essere accusato di non fare il suo dovere; senza contare lo stimolo ad assumere atteggiamenti isterici verso ogni stranezza.

A distanza di pochi giorni dal rilascio di Leopard, si moltiplicano voci e analisi sugli aspetti legati alla sicurezza, in particolare, il primo trojan di una qualche pericolosità è stato “avvistato” pochi giorni fa.

Tralasciando tutte le considerazioni legate strettamente al trojan in questione, mi pare interes­sante cercare di capire se questo indichi il superamento di una qualche soglia da parte di Mac OS X, dato che uno degli argomenti clas­sici per spiegare l’assenza di malware su Mac è sempre stato che non valeva la pena, vista l’esiguità della fetta di mercato.

Credo che forse stia per arrivare il momento di verificare l’esattezza di questa ipotesi: forse l’introduzione di Mac OS X 10.5 può significare il momento in cui questo sistema operativo viene preso sul serio, anche dai programmatori di malware.

Altri link:

• “RSPlug.A Mac OS X trojan: a new threat, but the sky is not falling”;
• “The New Trojan: Proof You Can’t Cure Stupidity”;
• “Heise reports Mac Trojan”.

Se siete minimamente interes­sati agli aspetti di sicurezza in relazione a Mac OS X, questo post è da leggere, commenti compresi. È una critica ragionata sulle novità per la sicurezza introdotte dalla versione 10.5. In particolare, mi lascia un po’ perplesso il fatto che Apple si sia presa la briga di implementare un sistema di sandboxing (che fra l’altro sembra scritto in Scheme) per poi lasciare fuori da questo sistema di protezione applicazioni come Mail e Safari.

Anche per la firma degli eseguibili il pattern è lo stesso: sono firmati e verificati ma in caso di manipolazione dell’eseguibile sembra che l’unica azione sia scrivere un mes­saggio nei log… mah. Codesign(1) sembra pre­vedere anche pos­sibilità più drastiche ma, in base alle note di rilascio sembra che per ora non sia questo il caso:

Your code must be immutable once signed. After signing, do not attempt to change executable code (including symbol tables), the Info.plist, or your program’s resource files. Do all that before signing. If you make modifications after signing, the signature may be invalid. Programs with invalid signatures will be treated as unidentified, will not gain any benefits from their signature, and may trigger additional dialogs from the Security system.

Dirlo per un prodotto uscito da meno di una settimana mi fa un po’ ridere ma che ci posso fare? Speriamo che le pros­sime versioni correggano queste “sviste”.

Che Kerberos venisse usato ormai da qualche tempo nella versione server di Mac OS X, lo sanno tutti; oggi questa infrastruttura di autenticazione viene anche usata sui client.

Secondo questa technote, l’uso di Kerberos è limitato solo alle connes­sioni via Bonjour e quindi sembra che non abbia nes­sun ruolo nel “Back to My Mac”.

L’ultimo saggio di Bruce Schneier su Wired, Gathering ‘Storm’ Superworm Poses Grave Threat to PC Nets riguarda questo nuovo worm – anche se in realtà, secondo Schneier, si tratta di un incrocio fra un worm, un trojan e un bot – ed è veramente interes­sante, oltre che preoccupante.

La cosa che mi ha colpito di più è il punto 3 dell’analisi:

Storm doesn’t cause any damage, or noticeable performance impact, to the hosts. Like a para­site, it needs its host to be intact and healthy for its own survival.

Mi fa pensare ad un futuro non poi molto lontano in cui i sistemi saranno talmente complessi da dare per scontato la pre­senza di forme di opportunismo/parassitismo; un po’ come le miriadi di colonie batteriche che scarrozziamo in giro ogni giorno.

Come molti di voi sapranno, l’avvio in single user mode, sotto Mac OS X, non richiede l’inserimento di alcuna pas­sword. In aggiunta all’uso della pas­sword sul firmware, pos­siamo fare in modo che venga chiesta la pas­sword di root anche in single usare mode modificando il file /etc/ttys. Da:

console "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" \
  vt100 on secure onoption="/usr/libexec/getty std.9600"

a:

console "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" \
  vt100 on onoption="/usr/libexec/getty std.9600"

Occhio agli “a–capo”!

Post originale

A Pilot on Airline Security.

Da leggere, per sfatare un sacco di miti sulla sicurezza negli aeroporti.