So che par­lare di stampa può sem­brare molto retro ma vi assi­curo che qual­cuno, là fuori, ne ha ancora biso­gno; e magari ha anche biso­gno di tener trac­cia 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­si­bile auten­ti­carsi per la stampa in IPP usando un URL del tipo ipp://account:password@server/printer e quindi espo­nendo infor­ma­zioni poten­zial­mente sensibili.Leopard irro­bu­sti­sce il sup­porto all’IPP auten­ti­cato, anche se ancora con qual­che difetto, per­met­tendo un uso meno fra­gile delle credenziali.

Per aggi­rare i pro­blemi di usa­bi­lità seguite que­ste istru­zioni, su Mac OS X Hints: “10.5: Set up authen­ti­ca­ted prin­ting via IPP”.

Questo arti­colo di Apple sul firewall di Leopard con­tiene alcuni det­ta­gli inte­res­santi. Il primo – e più noto – è che si tratta di un firewall che lavora a livello di appli­ca­zione e non a livello di porte: mi basta dire che deve accet­tare le con­nes­sioni entranti per iTu­nes, invece che dover spe­ci­fi­care quali siano le porte usate dall’applicazione, ad esempio.

Ma più oltre si tro­vano pre­ci­sa­zioni da tenere a mente. Sul “livello” a cui lavora que­sto software:

The Application Firewall does not over­rule rules set with ipfw, because ipfw ope­ra­tes on pac­kets at a lower level in the net­wor­king stack.

Riguardo ai legami fra il firewall e il code signing:

When you add an appli­ca­tion to this list, Mac OS X digi­tally signs the appli­ca­tion (if it has not been signed already). If the appli­ca­tion is modi­fied, you will be promp­ted to allow or deny inco­ming net­work con­nec­tions to it. Most appli­ca­tions do not modify them­sel­ves, and this is a safety fea­ture that noti­fies you of the change.

Quindi il code signing può avve­nire anche ex post, per una sin­gola appli­ca­zione, men­tre pen­savo fosse una pre–condizione da sod­di­sfare prima di appli­care delle regole con il firewall. Tant’è vero che più sotto si pre­cisa che se un’applicazione non pre­sente nell’elenco cerca di effet­tuare un qual­che tipo di con­nes­sione, viene pre­sen­tata una fine­stra di dia­logo che chiede all’utente cosa fare e, nel caso in cui, accon­senta all’esecuzione dell’applicazione, quest’ultima viene firmata.

Infine, se non espli­ci­ta­mente aggiunte come appli­ca­zioni escluse, tutti i pro­cessi che girano come root o sono fir­mate da una Certificate Authority fidata (come quelle di Apple) hanno pos­si­bi­lità di effet­tuare connessioni.

Matasano ha postato degli aggior­na­menti all’ana­lisi di Leopard nell’ambito della sicu­rezza, in parte per pre­ci­sare, chia­rire e sin­te­tiz­zare la messe di infor­ma­zioni dai com­menti, in parte per ana­liz­zare altre novità.

Fra que­ste novità la più rile­vante – dal punto di vista di Matasano – è il “Parental Control”. Questo sistema può essere usato per con­trol­lare quali ese­gui­bili un certo account può uti­liz­zare e for­ni­sce gra­tis quello che sotto Windows viene ven­duto a caro prezzo come soft­ware aggiun­tivo di terze parti. Purtroppo è pos­si­bile aggi­rare la limi­ta­zione sugli ese­gui­bili com­pi­lando del codice come dylib e “iniet­tarlo” in un’applicazione auto­riz­zata all’esecuzione tra­mite DYLDINSERTLIBRARIES.

A pro­po­sito del code signing, con­tra­ria­mente a quanto ripor­tato, sem­bra che Mac OS 10.5 (più pre­ci­sa­mente il firewall) lo usi per delle effet­tive restrizioni.

Appena posso, riporto volen­tieri gli arti­coli di Bruce Schneier per­ché mi aiu­tano a guar­dare le cose con un occhio un po’ più cri­tico di quanto soli­ta­mente non faccia.

Nel suo ultimo arti­colo, apparso anche su Wired, Schneier ana­lizza le con­se­guenze delle cam­pa­gne di sen­si­bi­liz­za­zione con­dotte negli USA per sti­mo­lare la col­la­bo­ra­zione dei cit­ta­dini. Ad es. quella dif­fusa nella metro­po­li­tana di New York e che usato per il titolo. La prima volta che ne ho sen­tito par­lare mi sem­brava una cosa lode­vole, tipo “Pubblicità Progresso” ma Schneier ci fa notare come troppo spesso le segna­la­zioni dei cit­ta­dini si tra­du­cano in falsi allarmi e tutto que­sto per­ché, una volta inne­scato il mec­ca­ni­smo, nes­suno vuole rischiare di essere accu­sato di non fare il suo dovere; senza con­tare lo sti­molo ad assu­mere atteg­gia­menti iste­rici verso ogni stranezza.

A distanza di pochi giorni dal rila­scio di Leopard, si mol­ti­pli­cano voci e ana­lisi sugli aspetti legati alla sicu­rezza, in par­ti­co­lare, il primo tro­jan di una qual­che peri­co­lo­sità è stato “avvi­stato” pochi giorni fa.

Tralasciando tutte le con­si­de­ra­zioni legate stret­ta­mente al tro­jan in que­stione, mi pare inte­res­sante cer­care di capire se que­sto indi­chi il supe­ra­mento di una qual­che soglia da parte di Mac OS X, dato che uno degli argo­menti clas­sici per spie­gare l’assenza di mal­ware su Mac è sem­pre stato che non valeva la pena, vista l’esiguità della fetta di mercato.

Credo che forse stia per arri­vare il momento di veri­fi­care l’esattezza di que­sta ipo­tesi: forse l’introduzione di Mac OS X 10.5 può signi­fi­care il momento in cui que­sto sistema ope­ra­tivo viene preso sul serio, anche dai pro­gram­ma­tori di malware.

Altri link:

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

Se siete mini­ma­mente inte­res­sati agli aspetti di sicu­rezza in rela­zione a Mac OS X, que­sto post è da leg­gere, com­menti com­presi. È una cri­tica ragio­nata sulle novità per la sicu­rezza intro­dotte dalla ver­sione 10.5. In par­ti­co­lare, mi lascia un po’ per­plesso il fatto che Apple si sia presa la briga di imple­men­tare un sistema di sand­bo­xing (che fra l’altro sem­bra scritto in Scheme) per poi lasciare fuori da que­sto sistema di pro­te­zione appli­ca­zioni come Mail e Safari.

Anche per la firma degli ese­gui­bili il pat­tern è lo stesso: sono fir­mati e veri­fi­cati ma in caso di mani­po­la­zione dell’eseguibile sem­bra che l’unica azione sia scri­vere un mes­sag­gio nei log… mah. Codesign(1) sem­bra pre­ve­dere anche pos­si­bi­lità più dra­sti­che ma, in base alle note di rila­scio sem­bra che per ora non sia que­sto il caso:

Your code must be immu­ta­ble once signed. After signing, do not attempt to change exe­cu­ta­ble code (inclu­ding sym­bol tables), the Info.plist, or your program’s resource files. Do all that before signing. If you make modi­fi­ca­tions after signing, the signa­ture may be inva­lid. Programs with inva­lid signa­tu­res will be trea­ted as uni­den­ti­fied, will not gain any bene­fits from their signa­ture, and may trig­ger addi­tio­nal dia­logs from the Security system.

Dirlo per un pro­dotto uscito da meno di una set­ti­mana mi fa un po’ ridere ma che ci posso fare? Speriamo che le pros­sime ver­sioni cor­reg­gano que­ste “sviste”.

Che Kerberos venisse usato ormai da qual­che tempo nella ver­sione ser­ver di Mac OS X, lo sanno tutti; oggi que­sta infra­strut­tura di auten­ti­ca­zione viene anche usata sui client.

Secondo que­sta tech­note, l’uso di Kerberos è limi­tato solo alle con­nes­sioni via Bonjour e quindi sem­bra che non abbia nes­sun ruolo nel “Back to My Mac”.

L’ultimo sag­gio di Bruce Schneier su Wired, Gathering ‘Storm’ Superworm Poses Grave Threat to PC Nets riguarda que­sto nuovo worm – anche se in realtà, secondo Schneier, si tratta di un incro­cio fra un worm, un tro­jan e un bot – ed è vera­mente inte­res­sante, oltre che preoccupante.

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

Storm doesn’t cause any damage, or noti­cea­ble per­for­mance impact, to the hosts. Like a para­site, it needs its host to be intact and heal­thy for its own survival.

Mi fa pen­sare ad un futuro non poi molto lon­tano in cui i sistemi saranno tal­mente com­plessi da dare per scon­tato la pre­senza di forme di opportunismo/parassitismo; un po’ come le miriadi di colo­nie bat­te­ri­che che scar­roz­ziamo in giro ogni giorno.

Come molti di voi sapranno, l’avvio in sin­gle user mode, sotto Mac OS X, non richiede l’inserimento di alcuna pas­sword. In aggiunta all’uso della pas­sword sul firm­ware, pos­siamo fare in modo che venga chie­sta la pas­sword di root anche in sin­gle usare mode modi­fi­cando 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 ori­gi­nale

A Pilot on Airline Security.

Da leg­gere, per sfa­tare un sacco di miti sulla sicu­rezza negli aeroporti.