Alfonso Maruccia

Intel, c'Ŕ una falla nei processori

Gli esperti identificano una vulnerabilitÓ nei processori a 64-bit di Santa Clara. Tutti i sistemi operativi sono a rischio, mentre Intel parla di un problema di implementazione software

Roma - Una nuova, potenzialmente pericolosa vulnerabilità è stata individuata nelle CPU Intel a 64-bit, e il rischio questa volta riguarda tutti i sistemi operativi. Ora che le patch correttive sono disponibili, lo US-CERT pubblica i dettagli del problema.

Il team statunitense per le emergenze informatiche dice in particolare che la fonte del problema è l'implementazione dell'istruzione "SYSRET" sulle CPU x86-64 di Santa Clara, una implementazione che potrebbe essere sfruttata per eseguire un attacco di tipo "privilege escalation" per eseguire codice da remoto sull'OS locale o anche dall'interno di virtual machine con ipervisore hardware.

Molteplici i sistemi operativi interessati dal problema (Windows 7, Windows Server 2008 R2, FreeBSD, SUSE Linux, Red Hat ecc. nelle loro varianti a 64-bit). Per quel che concerne Windows, Microsoft ha già pubblicato una patch correttiva con il bollettino di sicurezza MS12-042.
Intel dal canto suo, ha risposto alla pubblicazione dei dettagli sulla vulnerabilità scaricando la responsabilità sull'altrui software piuttosto che sul suo hardware: "La questione principale è che si tratta di un problema di implementazione software - dice Intel - e che i nostri processori funzionano così come descritto nelle specifiche documentate nel nostro Software Developers Manual per i 64-bit".

Alfonso Maruccia
Notizie collegate
  • TecnologiaAMD ha un bug nella CPUNon si tratta di un problema diffuso, ma sembrerebbe proprio che alcuni microprocessori di Sunnyvale abbiano un difetto congenito. In certe particolarissime condizioni lo stack fa i capricci
14 Commenti alla Notizia Intel, c'Ŕ una falla nei processori
Ordina
  • se le cpu intel fossero uguali a quelle amd non avrebbe senso comprare le cpu intel invece di quelle amd.

    semplicemente a livello software qualcuno non ha studiato e implementato bene la questione.
    se si puo' risolvere con un aggiornamento del software e' evidente che il problema e' il software
    non+autenticato
  • - Scritto da: trullo

    > se le cpu intel fossero uguali a quelle amd non
    > avrebbe senso comprare le cpu intel invece di
    > quelle
    > amd.

    Sono implementate in modo diverso (cache, disposizione dei bus, architettura delle sottounità, ecc.), ma si spera che il codeset venga implementato secondo le specifiche.

    > semplicemente a livello software qualcuno non ha
    > studiato e implementato bene la questione.

    Qualcuni di Intel, intendi.

    > se si puo' risolvere con un aggiornamento del
    > software e' evidente che il problema e' il
    > software

    Le CPU Intel possono essere aggiornate via software. Basta un tool che inietti il firmware al boot della macchina. Questo perché in realtà non implementano le istruzioni in hardware, ma sono CPU RISC che eseguono "microprogrammi" (le istruzioni CISC x86).

    Su Debian il microcode Intel è stato aggiornato qualche giorno fa.

    Bye.
    Shu
    1232
  • ottima spiegazione,
    grazie =)
    non+autenticato
  • - Scritto da: Shu

    > Su Debian il microcode Intel è stato aggiornato
    > qualche giorno
    > fa.

    e io che odiavo il microcodiceA bocca aperta

    invece si sta dimostrando utile

    mi chiedo però se venisse trovato qualche bug nel set di istruzioni risc che sta dietro il microcodice, che diavolo succederebbe

    sarebbe un gran bel colpaccio
    non+autenticato
  • - Scritto da: Shu
    > Sono implementate in modo diverso (cache,
    > disposizione dei bus, architettura delle
    > sottounità, ecc.), ma si spera che il codeset
    > venga implementato secondo le
    > specifiche.

    Quasi: http://en.wikipedia.org/wiki/X86-64#Differences_be...

    >
    > > semplicemente a livello software qualcuno non ha
    > > studiato e implementato bene la questione.
    >
    > Qualcuni di Intel, intendi.

    No, qualcuno che non ha letto le istruzioni...
    non+autenticato
  • - Scritto da: Shu
    > Le CPU Intel possono essere aggiornate via
    > software. Basta un tool che inietti il firmware
    > al boot della macchina.

    Orbene, se un virus riprogrammasse il firmware? Accidempolina!
    non+autenticato
  • - Scritto da: trullo
    > se le cpu intel fossero uguali a quelle amd non
    > avrebbe senso comprare le cpu intel invece di
    > quelle
    > amd.

    Mi spiace, non trovo un paragone calzante in grado di mostrare il livello di stupidità di questa affermazione.
    non+autenticato
  • - Scritto da: devnull
    > - Scritto da: trullo
    > > se le cpu intel fossero uguali a quelle amd
    > non
    > > avrebbe senso comprare le cpu intel invece di
    > > quelle
    > > amd.
    >
    > Mi spiace, non trovo un paragone calzante in
    > grado di mostrare il livello di stupidità di
    > questa
    > affermazione.

    solo quella?
    e questa?

    >se si puo' risolvere con un aggiornamento del software e' evidente che il >problema e' il software
    non+autenticato
  • Quando intel dice "i nostri processori funzionano così come descritto nelle specifiche documentate nel NOSTRO Software Developers Manual per i 64-bit" e' forse anche vero... ma il punto vero e' che le specs x86-64 sono standard definito da AMD, e loro hanno implementato diversamente l'opcode SYSRET in una particolare situazione... quindi claro che il comportamento anomalo si potra' gestire via sw... ma la colpa e' fondamentalmente loro.. non dei developers... che non si aspettavano questa variante nell'error handling..

    (cmq e' una "old news" di 1 settimana fa... )
    non+autenticato
  • - Scritto da: bubba
    > Quando intel dice "i nostri processori funzionano
    > così come descritto nelle specifiche documentate
    > nel NOSTRO Software Developers Manual per i
    > 64-bit" e' forse anche vero... ma il punto vero
    > e' che le specs x86-64 sono standard definito da
    > AMD, e loro hanno implementato diversamente
    > l'opcode SYSRET in una particolare situazione...
    > quindi claro che il comportamento anomalo si
    > potra' gestire via sw... ma la colpa e'
    > fondamentalmente loro.. non dei developers... che
    > non si aspettavano questa variante nell'error
    > handling..

    x86-64 è qualcosa che ha sviluppato inizialmente AMD, ma poi è stato implementato da altri in maniere anche leggermente diverse (AMD64 per AMD, EM64T per Intel e via dicendo). Esistono inoltre differenze documentate tra la versione AMD e quella Intel, per cui la colpa è dello sviluppatore che non ne ha tenuto conto. I firmware si scrivono sulla base dei Software Developers Manual, non su "quello che era una volta e non capisco perché l'hanno cambiato".

    Non raccontiamo panzane.
    non+autenticato
  • Non sono molto esperto di sistemi operativi ma si tratta forse delle stesso "bug" corretto nel 2006 nel kernel linux? (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-...).

    Se è così il fatto che sia stato corretto ben sei anni fa significa che questa news tanto news non è... e forse andrebbe pure un po' corretta
    non+autenticato
  • - Scritto da: VincenzoV
    > Non sono molto esperto di sistemi operativi ma si
    > tratta forse delle stesso "bug" corretto nel 2006
    > nel kernel linux?
    > (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
    >
    > Se è così il fatto che sia stato corretto ben sei
    > anni fa significa che questa news tanto news non
    > è... e forse andrebbe pure un po'
    > corretta

    da quello che ho capito io è così... ma non ho approfondito xche non uso arch IA64
    non+autenticato
  • Ma insomma, Intel presenta il bug e AMD no! O forse sbaglio?

    Non raccontiamoci panzane e nemmeno arrampichiamoci sugli specchi, per favore...