di  -  mercoledì 28 settembre 2011

Il prossimo anno arriverà Windows 8, ultima incarnazione del famoso sistema operativo di casa Microsoft, che porterà parecchie innovazioni, da quel che s’è visto e letto finora, ma qualcosa saltata fuori di recente ha provocato parecchi mal di pancia.

Si tratta dell’introduzione dell’avvio tramite funzionalità “Secure Boot” presente nelle schede madri moderne che fanno uso dell’UEFI al posto del vecchio BIOS che ha accompagnato i PC da 30 anni a questa parte.

Senza perdere troppo tempo in spiegazioni (un articolo esaustivo su come funziona si trova in questa pagina), sui sistemi UEFI con attiva questa modalità l’avvio di Windows 8 avverrà in maniera “sicura”, poiché verrà effettuato un controllo della firma del codice di boot, e soltanto se andrà a buon fine si proseguirà con la sua esecuzione.

Ne abbiamo già parlato diverse volte, ma l’argomento è ormai ben noto: si tratta di sfruttare le funzionalità messe a disposizione dal cosiddetto Trusted Computing, che in questo modo fa il suo ingresso “ufficiale” nel mondo dei PC.

Microsoft lo adotta nella misura in cui vuole proteggere l’esecuzione di tutto il codice fin dall’inizio, assicurandosi quindi che tutta la catena, dal reset fino all’esecuzione del suo codice di boot (e da lì a seguire), sia controllata e verificata accuratamente, senza manomissione in nessuna sua parte.

Quando Microsoft stava lavorando a Longhorn, poi commercializzato come Vista, era già all’opera su tecnologie come questa (all’epoca denominata Palladium internamente, poi rinominata in NGSCB, Next-Generation Secure Computing Base), e si pensava che sarebbe stata inserita in questo s.o., appunto.

L’erede di XP fu, stranamente, rilasciato senza alcun supporto a NGSCB, forse perché ancora immaturo, ma molto più probabilmente perché l’hardware su cui sarebbe dovuto girare era pressoché inesistente. O, magari, ben nascosto; ho, infatti, scoperto parecchi anni dopo che il mio ThinkPad R40 monta il famigerato chip “Fritz”, ma IBM ha cancellato da tempo dal suo sito ogni informazione a riguardo, probabilmente per non comprometterne le vendite (a causa della cattiva fama che si fece questa tecnologia).

Ora il cerchio è completo“. Adesso tanti dispositivi, in primis la CPU, supportano la tecnologia trusted, ivi compreso l’erede del BIOS, l’UEFI, che consente di memorizzare un insieme di chiavi certificate e utilizzarle per la validazione dei dati letti al boot, prima di lanciare il codice di inizializzazione del kernel, se l’opzione Secure Boot di cui sopra risulta attiva.

Nel caso in cui risulti inattivo, l’UEFI si comporta esattamente come il BIOS: carica il codice di boot e lo segue, senza effettuare alcun controllo (a parte uno di consistenza dei dati appena letti: un banale “checksum” per verificare se sono presenti eventuali errori).

Appare evidente come ciò comporti l’introduzione di una nuova caratteristica, che può essere fruita o meno dall’utente finale, a proprio arbitrio. Ma ciò che ha fatto storcere il naso a Matthew Garrett di Red Hat (suo è l’intervento nel link a inizio articolo ) è stata la certificazione Microsoft che impone agli OEM la presenza di questa voce nel boot e, soprattutto, che rimanga abilitata e non sia modificabile durante l’esecuzione.

Si tratta, però, di una richiesta a dir poco ovvia, poiché, diversamente, il codice di avvio potrebbe tranquillamente essere modificato da software malevolo, rompendo questa catena di responsabilità e rendendo vani tutti gli sforzi fatti per arrivare a questo stato dell’arte. Un esempio è arrivato qualche giorno fa con Mebromi, che si installa nel BIOS.

Sappiamo bene quanto in passato sia stata criticata Microsoft per non aver speso abbastanza risorse nella sicurezza dei suoi prodotti, che peraltro risultano anche i più bersagliati in quanto maggiormente diffusi (provocando danni in primis agli utenti), per cui se si presenta un’ottima opportunità per fortificarli, dovrebbe essere doveroso sfruttarla al meglio.

Questo non significa che Windows 8 richiederà necessariamente un firmware UEFI per poter girare, poiché il supporto al vecchio BIOS continua a esser presente. Semplicemente con l’UEFI gli OEM saranno tenuti e rispettare quelle indicazioni, in modo tale che gli utenti finali, spesso digiuni di informatica, possano ritrovarsi con un sistema “più sicuro” dall’accensione fino alla visualizzazione del desktop (e oltre).

In ogni caso, con la possibilità di disabilitare il Secure Boot, anche un sistema UEFI potrà continuare a lanciare s.o./software non firmati, esattamente come avviene adesso. Per cui, anche qui, non c’è alcun motivo di preoccupazione.

Viene, però, sollevata la possibilità che gli OEM possano eliminare questa possibilità. Microsoft non impone assolutamente nulla a riguardo, per cui l’operazione sarebbe a totale carico dei primi, che sono liberi di preparare e commercializzare i propri prodotti nella maniera che ritengono più opportuna per i loro affari (sarà poi il mercato a decretarne il successo o meno).

Certamente suonerebbe strano togliere di mezzo una caratteristica come questa, poiché ridurrebbe gli scenari di utilizzo del sistema. Pensiamo, ad esempio, al software per il recupero dei dati in caso di malfunzionamenti / disastri, oppure a quelli per il (ri)partizionamento dei dischi, ecc. Il campo è vasto.

Nel malaugurato caso che l’opzione non fosse più disponibile, si dovrebbe necessariamente passare da software digitalmente firmato. Anche qui, l’UEFI viene in aiuto consentendo di memorizzare più chiavi al suo interno, da utilizzare allo scopo. Oltre a quella di Microsoft potrebbero, quindi, essercene altre fornite da altri enti / aziende, che consentirebbero pertanto l’esecuzione di software con esse firmato.

Ancora una volta, non esistono imposizioni da parte di Microsoft sulla presenza o meno di altre chiavi. Gli OEM, quindi, possono memorizzarne altre nei loro firmware UEFI, come pure dare la possibilità agli utenti di aggiungerle o cancellarle (ivi comprese quelle di una black list, concetto anche questo supportato, oltre alle precedenti che fanno parte della white list).

Nel caso peggiore, quindi, sarebbe comunque possibile eseguire codice firmato, cosa che già esiste per alcune versioni di Linux. Il problema posto da Garrett riguarda il fatto che per una soluzione più generale servirebbe un boot manager firmato che consenta, poi, di lanciare una qualunque versione di Linux (o di altri s.o.).

Il candidato numero uno sarebbe ormai da tempo il diffusissimo Grub2, che però è GPL v3, ed è questo il problema maggiore su cui si sofferma il personaggio. Questa licenza è stata partorita da Richard Stallman per eliminare quello che è stato definito “tivoization” , ossia un s.o. open source e addirittura GPL (v2) che però non consentiva di eseguire codice diverso da quello firmato con apposite chiavi del produttore.

Dunque Grub2, per quanto molto completo, non è una soluzione che si può prendere in considerazione, avendo abbracciato una licenza che nasce per motivazioni diametralmente opposte e in pieno contrasto con quelle che hanno portato al Secure Boot. La versione 1 è ancora GPL v2, ma è ormai obsoleta e ci vorrebbe parecchio tempo per portarla al livello della 2. Ci sarebbe LILO, che utilizza BSD come licenza, e quindi sarebbe papabile allo scopo.

In conclusione, per l’esecuzione di s.o. diversi da Windows 8 su macchine UEFI con Secure Boot attivo le soluzioni ci sono o si possono comunque realizzare, e non si può certamente tirare in ballo la GPLv3 per puntare il dito contro questi meccanismi, perché sarebbe paradossale visto che nasce proprio per combatterli.

Come già detto altre volte in queste pagine, il futuro è certamente rappresentato da sistemi “trusted” poiché il nuovo ecosistema permette di risolvere diversi problemi di sicurezza. Si tratta, inoltre, di una tecnologia “neutra” e utilizzabile da qualunque s.o., quindi non esclusivamente da Windows, considerato che pure Linus Torvalds la vede di buon occhio e applicabile al suo Linux (che è stato, inoltre, il primo kernel a supportarla).

Al solito, l’argomento si dimostra indigesto a chi vede ormai il demonio a ogni angolo della strada, ma fortunatamente la tecnologia va avanti, e la razionalità predomina..

49 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    [D]
     scrive: 

    1- Se gli oem tolgono questo switch dai loro bios possono salutare il mercato.

    2- Microsoft crede di stare sicura con questo tipo di protezioni ma basta che guardi come si craccano allegramente vista e seven per capire che non la spunterà mai.

    3- Nella peggiore delle ipotesi ci sarà un’impennata di bios hackati sulla rete

  • # 2
    BD
     scrive: 

    Ma se viene data la possibilità alle aziende di aggiungere le loro chiavi, non è possibile che faccia lo stesso un ipotetico hacker?

  • # 3
    Herod2k
     scrive: 

    Domanda:
    ma se si rompe l’hard disk con windows 8 e l’UEFI bloccato, non posso comprarmi un’altro hard disk e installarci sopra il mio windows 8 originale comprato con il pc giusto? quindi dovrei spedirlo al produttore del pc (portatile o fisso che sia) per farglielo reinstallare… vedo controproducente per i produttori hardware disabilitare l’opzione di avvio di un bootloader non firmato no?

  • # 4
    PippoBau
     scrive: 

    My 2 cents: un passo in più verso la consumerizzazione del mercato PC, o per lo meno per quella fetta di mercato che vede il pc come un elettrodomestico-mediacenter più che come uno strumento di calcolo programmabile.
    Gli ut0nti saranno un po più al sicuro (salvo poi cliccare su tutto, perdere e cancellare i propri file, mandare mail con allegati sbagliati agli indirizzi sbagliati facendosi licenziare, dare in giro le proprie pw o scegliere le più facili da indovinare o ricondurre all’utente…) e sentiranno meno la differenza con ambienti molto più chiusi by design dei pc (smartphone, tablet).
    Gli altri si spera non abbiano troppo i bastoni tra le ruote per avere i certificati che gli servono se lavorano in un ramo in cui la cosa può essere applicabile… quasi sicuramente tra quelli che col PC ci “lavorano” ci saranno i soliti black hat che non avranno troppe difficoltà ad avere tutti i certificati che gli servono.
    Insomma, spero che il modo in cui il controllo sarà gestito da MS, assemblatori, produttori di chip, e “venditori” di certificati non sia troppo pesante per gli sviluppatori e chi al pc ci lavora, e che almeno sia efficacie a (ri)portare utenza al mercato pc.

  • # 5
    alex
     scrive: 

    @PippoBau: hai ragione, la sicurezza sarà poca, tanto ormai gli spyware girano sfacciatamente in user mode e pure su account limitati, non sentono il bisogno di occultarsi tramite metodi complicati

    in compenso avremo meno libertà di azione sulla macchina e un bel pò di rogne in più

    vorrei precisare che ms ha affermato, in un post su uno dei suoi blog, che la certificazione per windows 8 verrà data solo agli oem che bloccheranno la disabilitazione del secure boot per via programmatica

    questo vuol dire che al massimo lo si potrà fare spostando un jumper sulla scheda madre

    immaginatevi l’utonto a svolgere un’operazione del genere!!!

  • # 6
    Giulio
     scrive: 

    @alex:

    MS darà la certificazione a chi abiliterà di default Secure Boot, e non, come dici, a chi non consentirà la disattivazione.

    @D: chiunque comprerà un sistema OEM con Windows 8 (il 90% del mercato Microsoft?) probabilmente avrà Secure Boot di default, ergo non avrà bisogno di crack e affini.

    Ben venga un sistema del genere.

  • # 7
    Cesare Di Mauro (Autore del post)
     scrive: 

    Esattamente.

    @[D]: l’avevo già scritto nell’articolo, e non a caso. Ripeto: “Ora il cerchio è completo”.

    @BD: questa possibilità non è per tutti ovviamente. Un conto è se Apple, ad esempio, va a bussare alla porta di Phoenix o Award chiedendogli di inserire la sua chiave, e tutt’altra cosa è se lo facesse un pinco pallino qualsiasi.

    @Herod2k: non vedo problemi nel cambiare qualche pezzo della tua macchina. Lo si fa già adesso coi PC venduti dagli OEM.

    L’unico problema, nello specifico, sarebbe dovuto al fatto che l’hd che ti è morto conteneva anche la partizione dell’OEM per il ripristino del s.o., ma questo scenario si applicherebbe tanto col BIOS quanto con l’UEFI.

    @PippoBau: il PC è diventato un elettrodomestico da parecchi anni. Da quando, appunto, è stato possibile comprarlo per la gente comune.

    Sistemi come il Secure Boot vanno nella direzione già tracciata da anni: rendere la vita più comoda alla gente che vuole semplicemente usare il PC come fa col televisore o col telefonino.

    @alex: come spiegato nell’articolo, ciò che affermi non è corretto. La disabilitazione “programmatica” riguarda la possibilità di disabilitare il Secure Boot a livello di codice, quindi da un malware (vedi l’esempio di Mebromi). L’utente potrebbe comunque decidere di disabilitarlo manualmente (che è ben diverso da “programmaticamente”), potrà farlo dall’apposita opzione del firmware (vedi immagine allegata).

  • # 8
    ocrop
     scrive: 

    Tutti i problemi posti da questo Garrett si basano su un assunto sbagliato, ms non obbliga nessuno ad abilitare e bloccare su on il secure boot…
    http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx

    se qualche oem farà la cazz… di non renderlo disattivabile perderà quell’1% del mercato linux, che si rivolgerà ad altri produttori

    so much ado about nothing

  • # 9
    makrov
     scrive: 

    l’alternativa a grub2 potrebbe essere burg, ma nn ho idea di che licenza abbia!
    sicuramente le distro linux piu importanti avranno il loro certificato, ma distro come debian gentoo etc che hanno la loro forza nella possibilità di modificare i sorgenti e ricompilarseli non potranno mai essere certificate in questo modo (un solo certificato pubblico manderebbe tutto il sistema in panne, come per i certificati di diginotar, con la differenza che i browser aggiornano le blacklist in automatico, l’utonto nn aggiornerà mai la uefi)
    del resto gia esistono metodi per scardinare i certificati (penso al signed/unsigned sui symbian, dove bastava un ente cinese con un certificato valido gratuito per craccare qualsiasi eseguibile)
    il futuro delle aziende è sicuramente il trusted computing, ma spero che il mercato reagisca diversamente, o che gli hacker lavorino per garantirci quel minimo di libertà e per farci usare quello che compriamo come vogliamo noi utenti e non come vogliono le software house!
    trovo questi mezzucci ridicoli, un po come tutta la catena di permessi che blocca i driver su win7, per scardinare il giochino ho dovuto usare nano da linux su vgapnp.sys e adesso il vecchissimo intel 82855 funziona su win7 potendo settare la risoluzione corretta (e va anche l’accellerazione video, per quanto ridicola sia su questo chip)

  • # 10
    Giulio
     scrive: 

    Quello che conta è il bootloader, ergo non potrai riscriverti il boot loader (a meno di non disattivare quella opzione) per tutto il resto puoi ricompilare quello che più ti pare e piace.

    Il controllo viene effettuato solo ed esclusivamente sul boot loader.

  • # 11
    Marco
     scrive: 

    “so much ado about nothing”

    Quoto al 100%.

  • # 12
    Z80Fan
     scrive: 

    Secondo me il problema principale che bisognerebbe risolvere è: come fa un malware ad arrivare in una posizione di così basso livello in cui può installarsi nella flash del BIOS o nell’MBR?
    Citando l’articolo linkato dall’articolo di HW Files:
    “To gain access to the BIOS, the infection first needs to get loaded in kernel mode so that it can handle with physical memory instead of virtual memory.”
    Perchè si permette a un programma di avviare un processo in kernel mode? Che senso ha separare il sistema in livelli di privilegio se alla fine un programma (che non sia un componente del kernel) può essere caricato tranquillamente (anche se è stato avviato dall’amministratore etc.)?
    Questo è un problema strutturale del sistema operativo che va risolto in primo luogo (notare: non ho indirizzato Windows, potrebbe succedere in qualsiasi OS/kernel, mettiamo ad esempio Linux che ha i moduli caricabili; un binario proprietario prelevato da fonti non attendibili potrebbe contenere un sistema simile).

    Questo detto per il malware che viene eseguito dentro il sistema operativo.
    Ora, ovviamente si potrebbe avviare il sistema da qualche altro supporto, che a sua volta potrebbe contenere il suddetto malware. Ad esempio un utente non esperto potrebbe (pensando di essere figo) aggiornare il firmware del sistema usando una copia infetta. La prima cosa che penso, è: rendiamo il firmware più difficile da aggiornare! La flash dovrebbe essere di _default_ bloccata in scrittura, e per sbloccarla si dovrebbe agire su un jumper/switch sulla scheda madre, magari un sistema che si disattiva automaticamente al successivo reboot, o premere una combinazione di tasti all’avvio (per i portatili; mi sembra che Apple usi un sistema simile).
    Mi sembra una proposta ragionevole, anche contando che non si aggiorna tutti i giorni il bios (io nei miei sistemi non lo ho mai fatto ad esempio).

    L’ultima cosa che c’è da bloccare è la scrittura sull’MBR. Se il malware usa le chiamate del BIOS per l’interfacciamento con i dischi, è facile intercettare le scritture a determinati indirizzi (e su dei vecchi BIOS c’era tale opzione).
    Se invece il malware presume l’avvio di un completo sistema operativo che bypassa il BIOS e si interfaccia direttamente con i dischi,la situazione è un po’ più problematica, ma penso che ora stiamo entrando in delle possibilità più rare. :)
    Anche perchè, il malware deve cmq essere presente in un supporto (rimovibile), e in qualche modo deve essersi copiato e installato nell’MBR del relativo supporto; a questo punto si torna nella situazione iniziale, in cui il sistema operativo ospite non deve permettere un accesso a così basso livello.

  • # 13
    ocrop
     scrive: 

    “Questo è un problema strutturale del sistema operativo che va risolto in primo luogo”

    Gli so non saranno mai perfetti, quindi il secur boot è un layer di difesa in più, punto.

    Nel resto del messaggio proponi metodi complicatissimi quando basta per l’appunto… il secure boot! ;)
    Anche a linux farà bene… basta col fud contro ms, mi sembra di essere tornati ai tempi di vista…

  • # 14
    Marco
     scrive: 

    @Z80Fan
    Il punto è proprio quello: vorrei sapere quale utilità può avere un sistema simile quando alla fine si va ad eseguire un SO che di “trusted” non ha praticamente nulla.

    “il futuro è certamente rappresentato da sistemi “trusted””

    Allo stato attuale delle cose, sono ancora più “treacherous” che trusted.
    Verranno avviati in modalità “trusted” dei sistemi assolutamente inaffidabili. Flash Player a Acrobat Reader avranno il loro bel certificato firmato e controfirmato, e relativo bollino da esibire senza il minimo prerequisito e costose code review, per la felicità dei cracker.

    “è un layer di difesa in più”

    L’nx bit è un layer di difesa, per quanto aggirabile…
    Caricare Windows non mi sembra proprio che incrementi la sicurezza di un PC :-)))

  • # 15
    [D]
     scrive: 

    Tanto alla fine non esiste nessuna vera sicurezza, nessuna vera catena inviolabile: rimane sempre l’utente con la sua ignoranza, la sua mancanza di volontà di capire cosa sta facendo, il suo odioso ditino spastico che clicca a raffica Avanti>Avanti o il Sì di UAC senza porsi nemmeno il dubbio di cosa potrebbe succedergli. Al principio mi ero illuso che con vista e seven, i pc compromessi sarebbero scesi drasticamente poi aperto gli occhi ed ho trovato pieno di gente che riusciva a sputtanarli peggio di xp.

    Certa gente riuscirebbe fare danni perfino con il bastoncino da naso di Scrotos (il ratman di 299+1)

  • # 16
    [D]
     scrive: 

    *** Nanos, ho sbagliato a scrivere: Skrotos !

  • # 17
    Marco
     scrive: 

    Ma si non vedo il problema io… alla fine se ti crea problemi con quella distribuzione linux particolare disabiliti il secure boot e via… ;)

  • # 18
    makrov
     scrive: 

    ma il problema non sono solo le distro linux, ma l’opensource a venir penalizzato (come detto la GPL3 vorrebbe eliminare proprio questa eventualità)
    per trusted platform io nn intendo solo il boot, ma tutta la catena, UEFI verifica il certificato del bootloader e lo avvia, il bootloader verifica il certificato del kernel e lo carica, il kernel verifica i certificati dei vari programmi e li carica in runlevel0 (o chi per lui) mentre quelli non certificati solo in userspace, un po come succede per le console, anche se basta un bug nella catena o una banale leggerezza in fase di progettazione (wii e soprattutto ps3) e il tutto viene vanificato
    cmq bisogna vedere come funzionano le blacklist e le whitelist su UEFI, perchè se un virus puo inserire un proprio certificato nella whitelist i danni sono ben piu gravi che un infezione del MBR
    per evitare invece il problema del bootloader la UEFI dovrebbe essere in grado di certificare un bootloader in fase di installazione con una propria chiave unica, univoca per ogni pc, ma a quel punto gli OEM non potrebbero clonare le immagini degli HDD in serie, a meno di nn usare una chiave unica, ma qui torniamo al problema di prima.
    a breve i pc x86/Win diventeranno molto piu simili ai Mac, scopiazzando il sistema verticale apple (anche se apple non nega ai mac di montare win o linux, mentre M$ sembra intensionata a tagliare via quella misera alternativa che ci resta)

  • # 19
    homero
     scrive: 

    io sto lavarando ultimamente su un AS/400 che ormai a 15 anni di età per portarlo su architetture piu’ economiche e open surce….
    tutto quello che è scritto nell’articolo esiste già nell’as/400 di 15 anni fa…..portarlo nel mercato consumer non ha senso come non ha senso chiedere in windows seven l’autorizzazione per qualunque cosa quando sei loggato come amministratore…..
    questa tecnologia lede sicuramente al software libero….e vincola il software all’hardware in maniera decisiva cosi’come nell’as/400 i programmi in cobol sono legati strettamente all’archittura IBM power e al DB2…..solido come una roccia ma di certo non eterno….anzi….
    lo sostituirà un cluster supermicro….mi spiace ma IBM costa davvero troppo di questi tempi…..
    per quanto riguarda uefi…..i virus entreranno direttamente nell’hardware cosi’ avremo computer infetti dal boot fino alla chiusura….
    c’è da chiedersi poi se apple alla fine abbia ragione a blindare i propri sistemi……
    argomenti che non stanni in piedi per un OS che non sta in piedi….
    ho abbandonato microsoft da tempo….spero di non dover abbandonare anche linux…….debian for ever almeno per il momento….

  • # 20
    ocrop
     scrive: 

    @marco

    Accorgermi che un virus ha cambiato l’mbr io lo chiamo layer di sicurezza, grazie a secure boot la vita per gli sviluppatori di rootkit/bootkit si fa veramente

    dura… tu come lo chiameresti?@

  • # 21
    ocrop
     scrive: 

    @marco

    Accorgermi che un virus ha cambiato l’mbr io lo chiamo layer di sicurezza, grazie a secure boot la vita per gli sviluppatori di rootkit/bootkit si fa veramente

    dura… tu come lo chiameresti?

  • # 22
    ocrop
     scrive: 

    E smettetela col fud, ms supporta una caratteristica che è propria dello uefi, non la ha certo inventata lei e non cerca di costringre nessuno ad usarla per forza!
    Linux ha l’1% di share e non andrà mai oltre, pensate cose gli può fregare di sabotarlo lol
    Mi sembrate quei poveretti che parlavano di vista e palladium come il peggior male del mondo… si è visto poi che erano tutte balle…

  • # 23
    makrov
     scrive: 

    a dire il vero M$ ha attuato politiche per oslacolare linux e l’opensource, e non sono paranoie, la cosa è stata confermata da microsoft stessa http://it.wikipedia.org/wiki/Halloween_Documents

    tornando allo share l’1% si riferisce al mercato client, ma nel mercato server non c’è storia, basta dare uno sguardo su wikipedia http://en.wikipedia.org/wiki/Usage_share_of_operating_systems
    anche prendendo i dati con le molle le cifre sono impressionanti, per non parlare dei supercomputer dove ha cifre impressionanti

    linux ha uno share basso tra i client, ma il mercato sta cambiando, molti abbandonano winxp per un tablet con iOS, apple prende quote di mercato considerevoli e M$ fatica a mantenere lo share degli anni d’oro (lo share di winxp restante difficilmente verrà rimpiazato da win7 o win8-9 ma probabilmente da dispositivi completamente diversi, infatti M$ con win8 sta puntando ai tablet)

    se proprio vogliamo prendere un esempio del recente passato la sony tolse la possibilità di installare linux con un aggiornamento obbligatorio per giocare, e sappiamo bene come è andata a finire, M$ è piu furba e non andrà mai a sbandierare ai 4 venti che sta tentando di legare il piu possibile l’hardware al suo software, a me la cosa non tange piu di tanto, usando linux non sono legato a nessuna architettura hardware particolare, in special modo Wintel

  • # 24
    oipod
     scrive: 

    a me sembra solo paranoia visto che sarà tranquillamente disattivabile… scommettiamo?!?

  • # 25
    dcpr
     scrive: 

    ps: simpatico il cambio di nick a tradimento :D

  • # 26
    Marco
     scrive: 

    “grazie a secure boot la vita per gli sviluppatori di rootkit/bootkit si fa veramente dura”

    LOL, come no… le ultime parole famose :-D

  • # 27
    Cesare Di Mauro (Autore del post)
     scrive: 

    Le chiavi non possono essere inserite facilmente, altrimenti verrebbe meno la sicurezza. Qualunque cambiamento al firmware UEFI, dal suo stesso codice fino alle chiavi da inserire o cancellare, è basato sul controllo della firma di ciò che si vuole cambiare.

    @Marco: “treacherous” è una parola assai cara al grande ingannatore che ha ideato il software diversamente libero. Come Grub2, che è talmente libero da non permetterti di utilizzarlo su una piattaforma trusted. :D

    Riguardo a Flash e Acrobat Reader, stiamo parlando di applicazioni, che non avranno i privilegi per modificare parti critiche del sistema (kernel, driver, MBR, e firmware UEFI, per intenderci).

    Infine sui rootkit, è oggettivo che attualmente sia più facile per loro installarsi. Com’è anche vero che sui sistemi trusted ciò sarà di gran lunga più difficile, visto che non sarà sufficiente riuscire a ottenere i privilegi di root per cambiare parte della catena trusted, se il codice e/o i dati della modifica non saranno a loro volta firmati digitalmente.

    @makrov: non è l’open source a venire penalizzato, e non vedo come si potrebbe. Intanto il problema riguarda il boot loader e non è senza soluzioni, come già discusso. Ciò che avviene DOPO l’avvio del boot loader non è più di dominio dell’UEFI, e quindi potresti tranquillamente far partire anche una micro distro Linux che esegue rm -rf / come primo (e unico) comando…

    Riguardo alle protezioni scardinate su Wii e PS3, è vero; nulla da dire in merito. Quando sarà impossibile disassemblare ed eseguire con un debugger il codice se non si è il proprio creatore, i cracker avranno non pochi grattacapi (e ci sarà finalmente una separazione netta fra codice chiuso e aperto, come già discusso in un precedente articolo).

    I server non soffrono delle problematiche di cui stiamo discutendo qui, perché sono progettati appositamente. Anzi, potrebbero fare già uso di soluzioni come il Secure Boot, magari con distro Linux firmate digitalmente.

    Infine, anche se esci dal binomio Winintel, non credere che cambi chissà cosa. Intanto Windows sta approdando sugli ARM proprio con 8. Inoltre anche ARM fa parte del consorzio TCG, e già da anni i suoi processori “di targa”, presenti su smartphone, tablet, et similia, ne implementano le tecnologie trusted.

    @homero: il mercato dà ragione ad Apple e a Microsoft. Tanto basta.

    Riguardo al software diversamente libero, vedi sopra.

    @dcpr: “Accà nisciuno è fesso”. Risparmiati questi giochetti, perché la prossima volta non mi limiterò a cambiarti il nick; uomo avvisato.

  • # 28
    Marco
     scrive: 

    “Riguardo a Flash e Acrobat Reader, stiamo parlando di applicazioni, che non avranno i privilegi per modificare parte critichi del sistema”

    Privilege escalation non ti dice niente? :-D

    Quanto ai rootkit, già ora la maggior parte si installa a runtime e proprio sfruttando buchi di sicurezza che Windows (e Linux, e molti altri) mette a disposizione con inverosimile profusione.
    Anzi, si tratta già di un passo obbligato se non si vuole essere individuati da sistemi di controllo dell’integrità dei binari tipo afick et similia (concetto non dissimile da quello in topic in effetti).
    Ovviamente il binario del kernel su disco e relativa fingerprint non vengono toccate, e UEFI non inibirà di certo l’esecuzione di un piccolo binario dalla user startup di un utente qualunque (se la persistenza fosse un requisito).

    BTW, non sono affatto contrario a UEFI, ma nemmeno sono convinto che porti con se tutti quei benefici che vengono sbandierati.
    Tanta fuffa, da tutte le parti, e anche malizia: se le aziende volessero veramente realizzare un sistema sicuro, dovrebbero cominciare a mettere le mani da tutt’altra parte, perché una firma di garanzia su un kernel bacato non risolve granché.

  • # 29
    Cesare Di Mauro (Autore del post)
     scrive: 

    E’ sempre meglio di un sistema senza alcuna protezione hardware.

    Riguardo alla problematica di cui sopra, anche a runtime non puoi modificare alcunché di codice e dati marcati come trusted e firmati digitalmente. Potresti diventare root con una priviledge escalation, ma i danni che potresti fare sarebbero comunque limitati.

  • # 30
    Pluto
     scrive: 

    Scusate la domanda, ho riletto l’articolo due volte, ma non ho capito se potrò o meno installare Linux sul mio PC semplicemente disabilitando una voce nella configurazione del BIOS oppure se pre-configurare il PC con una crack per installare il mio sistema operativo preferito.

  • # 31
    Marco
     scrive: 

    “E’ sempre meglio di un sistema senza alcuna protezione hardware”

    Ancora, secure boot, a discapito del nome, non da alcuna indicazione sulla sicurezza: fornisce solo alcune parziali garanzie sul fatto che parte del codice che è in esecuzione corrisponde a quello fornito/firmato dal produttore. Fine.

    “Riguardo alla problematica di cui sopra, anche a runtime non puoi modificare alcunché di codice e dati marcati come trusted e firmati digitalmente.”

    Non è vero. Secure boot, come dice il nome, si occupa solamente del processo di inizializzazione. Al limite interverranno altri meccanismi, anche se non mi risultano meccanismi di sanity check per l’immagine in RAM di processi in esecuzione da parte di UEFI.

    Secondo, non mi interessa modificare codice trusted se questo è bacato: mi interessa solamente sfruttarne le vulnerabilità ;-)

  • # 32
    Davide Rao
     scrive: 

    Se nel futuro prossimo dovesse diventare impossibbile far girare unsigned code sul proprio “Personal Computer” diventerebbe discutibile anche la dicitura “Personal”. Comunque MS ci sta tentando senza successo dalla xbox ma gli hacker trovano sempre una strada per eseguire codice arbitrario e lo hanno fatto anche sulle ultime versioni della xbox360 (anche quelle post agosto 2009): http://www.free60.org/Reset_Glitch_Hack
    La cosa interessante e che il reset glitch hack sfrutta una vulnerabilita hardware. MS dovra commissionare un nuovo processore per fissare questa vulnerabilita’ :-D
    Tra un po vedremmo apparire sulle nostre console: “E’ disponibile un nuovo processore per la tua console: questo gioco non puo’ essere eseguito se non aggiorni il tuo processore !” ROLF

  • # 33
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non sarei così sicuro sul sempre. Certo, l’hack della 360 è qualcosa di incredibile: bisogna essere dei geni per pensare a roba del genere.

    Di questo Microsoft ne farà tesoro per la CPU della prossima console. Non credo che gliene freghi qualcosa ormai di cambiare il progetto di quella attuale. ;)

    Riguardo al “personal”, beh, è per uso personale. Non c’entra il tipo di codice che ci gira. :P

    @Marco: è vero, sono andato troppo avanti. :)

    Il Secure Boot da solo non serve a niente, se poi il codice eseguito dopo non fa uso di altri meccanismi di protezione.

    Ma fra avere questa funzionalità e non averla, è sempre meglio la prima. Qualcuno, prima o poi, troverà il modo di sfruttarla. ;)

  • # 34
    ocrop
     scrive: 

    @marco

    quindi secondo te, dato che windows è cmq vulnerabile aggiungere layer di protezione è inutile… i fatti ti danno torto

    http://www.winrumors.com/windows-7-malware-infection-rate-significantly-lower-than-windows-xp/

    come puoi vedere le infezioni in vista prima e in 7 ancora di puù sono calate drasticamente, e con windows 8 si avvicineranno ancora di più allo zero ;)

  • # 35
    Marco
     scrive: 

    @ocrop
    Non ho mai detto che è inutile, ma rifletti un poco: se UEFI Secure boot fosse stato abilitato dai tempi di XP, cosa sarebbe cambiato in quel grafico che hai linkato?

    Che MS ultimamente (da XP SP2 e Windows 2003) si sia impegnata molto di più sul fronte della sicurezza non l’ho mai negato ed è un dato di fatto: dal famoso switch /GS, al DEP, al resource protection e via dicendo. Anzi, secondo me ha superato una distribuzione di linux media, pur mantenendo una eccellente usabilità.

  • # 36
    Marco
     scrive: 

    @Cesare
    “Certo, l’hack della 360 è qualcosa di incredibile: bisogna essere dei geni per pensare a roba del genere.”

    L’ho visto adesso… veramente incredibile :-O

  • # 37
    ocrop
     scrive: 

    se fosse stato implementato su xp, senza tutte le altre difese che hai citato e altre ancora come l’hardening dei servizi ecc… probabilmente nulla, ma assieme a tutte le altre difese compreso il più che buono antivirus mse installato di default, che spero resti attivo anche in caso di windows con licenze irregolari, vedrai che le infezioni caleranno drasticamente ;)
    il secure boot ha solo vantaggi e nessuno svantaggio, magari lo aggireranno, ma non penso sarà così facile
    le app metro poi sono scaricabili solo dallo store che sarà ipercontrollato e girano obbligatoriamente in sandbox

  • # 38
    Davide Rao
     scrive: 

    Cesare: Un personal che non ti consente di far girare codice arbitrario non e’ + un personal. Sino a che rimane un opzione a bios che si puo’ disattivare e un conto, se MS invece ti costringe ad attivarlo sarebbe una seccatura, se diventasse uno standard non disattivabile serebbe ben altra cosa.

  • # 39
    parappa
     scrive: 

    Non mi risulta ms produca hardware, quindi non vedo come possa costringere qualcuno a renderlo non disattivabile

    http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx

  • # 40
    Cesare Di Mauro (Autore del post)
     scrive: 

    Esattamente. Non è un problema di Microsoft, ma degli OEM.

    @Davide: non possiamo cambiare le definizioni a proprio piacimento.

    A personal computer (PC) is any general-purpose computer whose size, capabilities, and original sales price make it useful for individuals, and which is intended to be operated directly by an end-user with no intervening computer operator.

    ;)

  • # 41
    Marco
     scrive: 

    @Cesare, Davide
    “is any general-purpose”

    E’ proprio qui il punto: quando è che un computer non è più “general-purpose”?
    IMHO, quando non è più adatto a soddisfare una mia particolare esigenza, che in un caso specifico potrebbe essere quella di eseguire codice non firmato.
    E la discussione potrebbe andare avanti molto a lungo ;-)

  • # 42
    parappa
     scrive: 

    fate i seri, il tempo degli accordi per tagliare le gambe alla concorrenza è finito da un bel pò…
    primo perchè la concorrenza ormai, purtroppo, è riuscita ad eliminarla abbondantemente
    secondo perchè l’antitrust è li pronto a farle il culo alla prima occasione, quindi meno pippe mentali e vivete sereni

  • # 43
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Marco: quello è un dettaglio. Ciò che è importa è la “qualità”, ossia riuscire ad assolvere a determinati compiti che ci aiutano.

    Comunque sì, sono discussioni che non finirebbero mai. :P

  • # 44
    makrov
     scrive: 

    matthew garrett, sviluppatore di red hat sull’argomento http://mjg59.livejournal.com/
    espone tutti i dubbi che questo secure boot comporta, soprattutto riguardo la certificazione “windows 8″ e l’inesistenza di un ente che gestisca i certificati UEFI, e questo da utilizzatore di linux non mi va affatto giu!
    dato il putiferio che la rimozione dell’opzione OtherOS su ps3 ha scatenato spero che succeda lo stesso riguardo il secure boot, sperando in firmware crakkati/cucinati/virtualizzati così da poter gestire con autonomia questa nuova feature “antimalware” e installare ubuntu/debian dove ritengo piu opportuno! (cioè ogni pc che acquisto)

  • # 45
    Cesare Di Mauro (Autore del post)
     scrive: 

    Quel link l’avevo riportato proprio all’inizio dell’articolo, e l’argomento è stato sufficientemente sviscerato, anche nei commenti.

  • # 46
    markit
     scrive: 

    “ha abbracciato una licenza che nasce per motivazioni diametralmente opposte e in pieno contrasto con quelle che hanno portato al Secure Boot”
    Parole sante! La GPL3 nasce per garantire la libertà degli utenti, il “trusted computer”, o “treacerous computer” (computer traditore) nasce per il motivo opposto, il controllo totale dell’utente da parte del computer.
    “Secure” è “sicuro” solo per chi vuole tenere l’utente in pugno. Possibile che se la sicurezza sta tanto a cuore a M$, siamo nel 2011 e ancora Windows è un colabrodo che nessuno oserebbe far andare senza un antivirus, da aggiornare giornalmente, e che non copre certo il 100% dei rischi ma una percentuale molto più bassa?
    Possibile che quando compro un PC mi ritrovi questa zozzeria preinstallata quasi sempre, e procedure impraticabili per riavere i soldi che mi hanno preventivamente e INDEBITAMENTE sottratto visto che non accetto la licenza e ci installo qualcosa di rispettoso della mia libertà, GNU/Linux?
    Possibile che uno strumento meraviglioso di libertà si sia trasformato in un tramite per il controllo e la coercizione, con utenti felici e giulivi di essere consumatori passivi e pronti a creare flame per difendere i propri carcerieri?

  • # 47
    Cesare Di Mauro (Autore del post)
     scrive: 

    Mi sembra di sentire Stallman… Nemmeno rispondo nel merito, visto che in queste pagine ne abbiamo già ampiamente parlato.

  • # 48
    Marco
     scrive: 

    Io mi permetto invece di aggiungere che livelli di integralismo come quelli di markit non solo non aggiungono nulla ma sono pure controproducenti alle “cause” del software libero che in buona parte condivido.

  • # 49
    Cesare Di Mauro (Autore del post)
     scrive: 

    Nemmeno se ne rendono conto, col lavaggio del cervello che hanno subito: sembrano usciti tutti dalla stessa catena di montaggio, ripetendo sempre le stesse cose sugli stessi argomenti, come se ciò contribuisse a renderli veri.

    P.S. Io sono a favore del software in generale: uso quello che mi fa più comodo. ;)

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.