Intel, 9 anni di bug nelle CPU

I chip Core di Santa Clara prodotti dal 2008 ad oggi presentano una vulnerabilità che consentirebbe attacchi remoti. Occorre un nuovo firmware, ma trattandosi anche di sistemi datati per alcuni il fix non arriverà mai

Roma - Le piattaforme Intel dotate di funzioni di gestione remota, prodotte dal 2008 ad oggi, sono state esposte a una grave falla di sicurezza che se sfruttata consentirebbe a un attaccante di scalare i privilegi di sistema e di assumere il pieno controllo dei computer connessi alle reti vulnerabili. A renderlo noto a distanza di 9 anni è lo stesso colosso di Santa Clara, tramite una nota rilasciata dal suo Security Center. Il bug in questione è stato scoperto e riportato (CVE-2017-5689) nel mese di marzo da Maksim Malyutin, ricercatore presso Embedi.

La falla di sicurezza potrebbe affliggere tutti i chip della serie Core di Intel, da Nehalem a Kaby Lake dotati di Active Management Technology (AMT), Standard Manageability (ISM) e Small Business Technology (SBT) con firmware compresi tra le versioni 6 (per la prima generazione della famiglia Core: Nehalem) e 11.6 (per la settima generazione di Core Intel: Kaby Lake). Non impatta dunque i firmware precedenti alla 6 e successivi alla 11.6. Inoltre, il problema non sussiste per le CPU consumer, ma riguarda esclusivamente i chip dotati di tecnologia vPro. Per facilitare l'identificazione delle piattaforme vulnerabili Intel ha rilasciato una specifica guida in formato PDF.

Alcuni ricercatori affermano che la falla potrebbe essere sfruttata da remoto (via Internet e non solo in locale) esclusivamente se il servizio AMT è abilitato e fornito all'interno di una rete.
Quando configurati, AMT e ISM ascoltano automaticamente il traffico di rete: il traffico ricevuto sulle porte 16992, 16993, 16994, 16995, 623 e 664 su una macchina che utilizza AMT ha i dati inoltrati direttamente al Management Engine (ME), escludendo la CPU principale.
Secondo Matthew Garrett, Linux Kernel guru e security engineer presso Google, occorre infatti assicurarsi di aver disattivato la tecnologia Active Management Technology di Intel: "Per risolvere il problema è necessario un aggiornamento del firmware di sistema che installi un nuovo Management Engine (includendo una copia aggiornata del codice AMT). Molte delle macchine afflitte, però, non ricevono più aggiornamenti firmware e probabilmente non riceveranno mai un fix. Chiunque abiliti AMT su uno di questi dispositivi sarà vulnerabile. Tutto ciò ignorando il fatto che gli aggiornamenti firmware raramente vengono contrassegnati come critici per la sicurezza (e generalmente non vengono diffusi tramite Windows Update), pertanto anche se un aggiornamento viene reso disponibile, gli utenti non ne verranno probabilmente a conoscenza o non li installeranno".
Per altri ricercatori, invece, i requisiti per un attaccante che voglia riuscire nel suo intento da remoto sono ben più elevati. È necessario che su Windows il software Local Manageability Service (LMS) sia in esecuzione. È di questo parere HD Moore, VP Research & Development presso Atredis Partners: "Sembra che sia possibile sfruttare il bug a distanza solo se il servizio LMS è in esecuzione sul sistema interessato. Solo i server che eseguono quel servizio (rispetto ai PC desktop) con la porta raggiungibile sono esposti all'esecuzione di codice in modalità remota".
Moore afferma che tramite una ricerca su Shodan ha rilevato meno di 7.000 server con le porte di comunicazione 16992 o 16993 aperte (requisito necessario per eseguire l'attacco da remoto), ma il numero di server rappresenta una minaccia sostanziale: decine di migliaia di computer potrebbero essere connessi ad alcuni di questi host.

In definitiva, le aziende che necessitano di avere LMS e AMT abilitate nelle loro reti devono rendere l'installazione del firmware patchato una priorità assoluta. Per chi non può installare immediatamente gli aggiornamenti o nei casi in cui non siano disponibili firmware OEM aggiornati, Intel ha rilasciato una "Mitigation Guide": un set di istruzioni per risolvere temporaneamente il problema. Gli aggiornamenti firmware, infatti, anche se sviluppati da Intel, devono essere firmati crittograficamente dai vari produttori e poi distribuiti. In alcuni casi questa procedura potrebbe richiedere settimane o, come nel caso di hardware legacy (non più supportato), la soluzione potrebbe non arrivare mai.
Notizie collegate
27 Commenti alla Notizia Intel, 9 anni di bug nelle CPU
Ordina
  • per un attimo ho pensato fosse una cosa seria e nuova. poi ho letto che non c'entra la CPU propriamente detta, ma e' il solito crapware ME+virtual che Intel (e altri, stile IPMI) ficcano da anni nei computerz
    Insomma la stessa roba che la Rutkowska (e altra gente meno gnocca) massacra ciclicamente dal 2008 in avantiCon la lingua fuori
    soluzioni ce ne sarebbero ( 'linuxbios, 1999' e successive reincarnazioni varie ) ma i vendor non le hanno mai voluteCon la lingua fuori
    non+autenticato
  • Per gli utonti in ascolto: con QubeOS siete al sicuro anche da questi cosiddetti "bug"

    Un test con l'AMT di Intel:
    https://medium.com/@securitystreak/living-with-qub...



    Domanda: secondo voi Snowden se ne intende di sicurezza e di spionaggio?
    https://twitter.com/Snowden/status/781493632293605...



    Consiglio: andate dal negoziante di PC e ditegli di installare alla vostra segretaria qubeOS "in modo che girino i programmi windows".
    Al primo ransomware che evitate avete comunque risparmiato!
    non+autenticato
  • - Scritto da: bubba
    > per un attimo ho pensato fosse una cosa seria e
    > nuova. poi ho letto che non c'entra la CPU
    > propriamente detta, ma e' il solito crapware
    > ME+virtual che Intel (e altri, stile IPMI)

    beh nuova no, ma seria si

    > soluzioni ce ne sarebbero ( 'linuxbios, 1999' e
    > successive reincarnazioni varie ) ma i vendor non
    > le hanno mai volute

    la cosa paradossale e' che mi tocca leggere sul sito di coreboot che il piu' grande utilizzatore di quel firmware e' GoogleA bocca aperta

    ma non era il ciuccia-dati, spione degli spioni, secondo maxsix e compagni?

    almeno un chromebook lo puoi riflashare, affettare, maneggiare come ti pare, i pc sono sempre piu' blackbox intoccabili
    non+autenticato
  • - Scritto da: collione
    > - Scritto da: bubba
    > > per un attimo ho pensato fosse una cosa
    > seria
    > e
    > > nuova. poi ho letto che non c'entra la CPU
    > > propriamente detta, ma e' il solito crapware
    > > ME+virtual che Intel (e altri, stile IPMI)
    >
    > beh nuova no, ma seria si
    >
    > > soluzioni ce ne sarebbero ( 'linuxbios,
    > 1999'
    > e
    > > successive reincarnazioni varie ) ma i
    > vendor
    > non
    > > le hanno mai volute
    >
    > la cosa paradossale e' che mi tocca leggere sul
    > sito di coreboot che il piu' grande utilizzatore
    > di quel firmware e' Google
    >A bocca aperta

    Parassiti di codice libero, come tutti gli altri. Nonche' lobbisti che condizionano lo sviluppo di coreboot, come tutti gli altri.

    > ma non era il ciuccia-dati, spione degli spioni,
    > secondo maxsix e
    > compagni?

    Lo e', ma non ha bisogno di mettere mano sui terminali degli utenti perche' e' il piu' grosso gestore di dati personali del globo: glieli danno direttamente gli utenti, e li tiene sulle proprie macchine per poterli analizzare meglio. In compenso cede il controllo dei terminali utenti a chiunque paghi a sufficienza e non possa accedere direttamente ai dati privati degli individui.

    > almeno un chromebook lo puoi riflashare,
    > affettare, maneggiare come ti pare, i pc sono
    > sempre piu' blackbox
    > intoccabili
    non+autenticato
  • AMT&c è l'unico "hack" sistema LOM by Intel. In altri termini serve per gestire l'hw sparso per la propria infrastruttura stando comodamente seduti davanti al vosto portatile. Install&c via rete del vostro ferro, "Dépannage" di macchine con OS schiantato da remoto ecc. Es se avete n macchine da installare (un call center, un data center, ...) vi fa comodo poterlo fare comodamente dal vostro laptop non dovendo andar ad accendere, bootare/mettere in netboot e magari pure installare a mano una macchina alla volta.

    Ogni vendor di un certo spessore ha una qualche soluzione a tema (DELL ha iDRAC, IMB ha RSA, HP ha iLO, ...) poiché via software possiamo gestire l'install "automatizzata da remoto" ma abbiamo comunque bisogno di un controllo sul ferro (accensione, boot via rete ecc) e sulla configurazione di rete.

    Grossomodo questo è lo scopo dei LOM. Il problema di sicurezza (non questo in particolare ma in generale) è che questo è in genere un sistema proprietario, sviluppato da pochi, controllato da pochi, spesso non aggiornabile essendo in vario modo legato al ferro e può operare al di la del controllo dell'utente finale/dell'OS. Alcuni vendor ci stan un po' più attenti, l'Intel non è tra questi anche perché il suo core business sono le CPU non le macchine complete e il suo target è più "domestico" che altro...
    non+autenticato
  • - Scritto da: xte

    > Ogni vendor di un certo spessore ha una qualche
    > soluzione a tema (DELL ha iDRAC, IMB ha RSA, HP
    > ha iLO, ...) poiché via software possiamo gestire
    > l'install "automatizzata da remoto" ma abbiamo
    > comunque bisogno di un controllo sul ferro
    > (accensione, boot via rete ecc) e sulla
    > configurazione di
    > rete.
    >
    > Grossomodo questo è lo scopo dei LOM. Il problema
    > di sicurezza (non questo in particolare ma in
    > generale) è che questo è in genere un sistema
    > proprietario, sviluppato da pochi, controllato da
    > pochi, spesso non aggiornabile essendo in vario
    > modo legato al ferro e può operare al di la del
    > controllo dell'utente finale/dell'OS. Alcuni
    > vendor ci stan un po' più attenti, l'Intel non è
    > tra questi anche perché il suo core business sono
    > le CPU non le macchine complete e il suo target è
    > più "domestico" che
    > altro...

    che pero' sono in qualche modo soluzioni aperte, ovvero le puoi almeno rimuovere quando e come ti pare

    qui il problema e' che c'e' un tizio plenipotenziario, completamente opaco/closed, nella cpu, di cui non sappiamo niente e che non possiamo rimuovere/disabilitare ( con l'andare delle tempo hanno eliminato qualsiasi possibilita' di rimozione/spegnimento )

    capendo che la storiella dell'utilita' in ambiente enterprise e' quantomeno risibile ( almeno a fronte dell'assurda opacita' e complessita' dell'accrocchio ), hanno tirato fuori il sempreverde argomento dei poveri autori e della loro proprieta' intellettuale, che senno' non possono comprarsi la quinta megavilla nel Pacifico

    e il DRM e' diventato la nuova storia di copertura
    non+autenticato
  • ...a me risultava che la copertura fosse il caso di furto. Questo perché nella narrativa ufficiale l'AMT deve essere abilitato spontaneamente.

    Quindi il piratone ben difficilmente lo attiverà, dato che ne sarebbe lui stesso la vittima. Invece il babbeo preoccupato per i ladri potrebbe anche farlo.


    Se non erro il DRM era la copertura della versione M$ di questa truffa, ovvero il Palladium, rinominato in seguito alle polemiche.
    Non paghi delle polemiche, la schifezza l'hanno messa dentro Vista, motivo per il quale la CPU macinava sempre, in modo da evitare all'utonto di piratare: come previsto un grande "successone" sia per l'utonto medio che com'è noto ha piacere a pagare per no poter usare il PC come crede, sia per le batterie dei portatili...
    non+autenticato
  • - Scritto da: xx tt
    > ...a me risultava che la copertura fosse il caso
    > di furto. Questo perché nella narrativa ufficiale
    > l'AMT deve essere abilitato
    > spontaneamente.

    AMT si, ME no

    poi vabbe', negli anni hanno tirato fuori le scuse piu' ridicole e patetiche per farci ingoiare le backdoor made in Fort Meade

    > Se non erro il DRM era la copertura della
    > versione M$ di questa truffa, ovvero il
    > Palladium, rinominato in seguito alle
    > polemiche.

    palladium fu bastonato a sangue e il fatto di essere software lo rendeva comunque vulnerabile

    dopo il flop arrivo' il cavaliere dall'armatura scintillante ( Intel ) e ficco' un palladium-like direttamente nelle cpu
    non+autenticato
  • No guarda, qui il DRM non c'entra un tubo e non è affatto risibile: abbiamo un disperato bisogno di soluzioni LOM. Il problema di Intel è che la sua soluzione è iper-limitata al punto che in genere nessuno la usa e le altre sono proprietarie legate a ferro specifico onde per cui c'è un bel lavorio dietro per mantenerle in un ambiente eterogeneo, senza toccare il tema sicurezza.

    Ma la necessità di LOM non è una moda spinta da qualche vendor è una realtà e nulla ha a che vedere col DRM. Oggi, e non da oggi, poche persone mantengono n macchine sparse per il mondo, ma senza andar tanto lontano pensa cosa vuol dire aggiornare a mano i desktop di un'aula computers di una scuola vs farli tutti in un colpo da un portatile.
    non+autenticato
  • - Scritto da: xte
    > No guarda, qui il DRM non c'entra un tubo e non è
    > affatto risibile: abbiamo un disperato bisogno di
    > soluzioni LOM. Il problema di Intel è che la sua
    > soluzione è iper-limitata al punto che in genere
    > nessuno la usa e le altre sono proprietarie
    > legate a ferro specifico onde per cui c'è un bel
    > lavorio dietro per mantenerle in un ambiente
    > eterogeneo, senza toccare il tema
    > sicurezza.
    >
    > Ma la necessità di LOM non è una moda spinta da
    > qualche vendor è una realtà e nulla ha a che
    > vedere col DRM. Oggi, e non da oggi, poche
    > persone mantengono n macchine sparse per il
    > mondo, ma senza andar tanto lontano pensa cosa
    > vuol dire aggiornare a mano i desktop di un'aula
    > computers di una scuola vs farli tutti in un
    > colpo da un
    > portatile.


    Se è quello il problema puoi anche usare un KVM: lo colleghi alle macchine quando non c'è nessuno, poi fai accedere l'indian...ehm...la risorsa umana di turno al KVM e controllando TU quello che succede lasci che faccia quello che deve fare.

    Hai un maggior controllo rispetto a qualcosa di non ben documentato (per non dire altro) che gira sul processore.
    non+autenticato
  • Non son certo favorevole all'AMT ma considera che se i server da gestire sono in una serie di datacenter sparsi nel mondo o il call center è fisicamente in Romania mentre io sono a Sophia Antipolis bé un kvm semplice non mi basta, un kvm ip "trasparente" non è più sicuro di iDRAC, iLo, ... ed è normalmente meno gestibile, pensa per es. ad automatizzare un deploy bare-metal con Salt, con n kvm che devo fare?
    non+autenticato
  • - Scritto da: xte
    > Non son certo favorevole all'AMT ma considera che
    > se i server da gestire sono in una serie di
    > datacenter sparsi nel mondo o il call center è
    > fisicamente in Romania mentre io sono a Sophia
    > Antipolis bé un kvm semplice non mi basta, un kvm
    > ip "trasparente" non è più sicuro di iDRAC, iLo,
    > ... ed è normalmente meno gestibile, pensa per
    > es. ad automatizzare un deploy bare-metal con
    > Salt, con n kvm che devo
    > fare?

    Premetto che ero/sono ignorante del sottobosco di intrugli processi sconosciuti ed inaccessibili all'utente anche evoluto, che presiedono a basso livello al funzionamento dei computers come normalmemte conosciuto. Ho capito qualcosa da WiKi (che però non parla di LOM, acronimo di cosa?).
    Dunque mi esprimo da ignorante, dotato però di logica e buon senso, almeno spero.

    Qui tu stai parlando di disperate necessità di sistemi di LOM efficienti, come se la problematica fosse solo quella di soddisfare le comodità di pochi gestori da remoto di catene di computers per non dire servers sparsi per il mondo, accomodati davanti al proprio laptop (meglio desktop, no?), che dovrebbero poter operare liberamente in qualunque momento con pieno controllo di innumerevoli installazioni remote, come se queste non fossero presidiate da esseri dotati di intelligenza propria.

    Io la vedo diversamente: una volta che le postazioni remote, o meglio eventuali server ad esse preposti, siano switchabili in un particolare stato o modalità operativa, attivabile in loco solo quando realmente serve, che permatta accettazione di comandi da remoto in grado di far aggiornare parte o tutto del SW di base e/o applicativo (operazioni stand-by e boot compreso), con uno standard operativo pressochè comune tra le varie case produttrici, cosa altro si vuole di più?
    Ovviamenti i supergestori pochi al mondo si dovrebbero collegare, secondo accordi preventivi, solo quando le macchine target vengono messe in stato "ricettivo". Altrettando ovvio che il completamento e controllo dell'aggiornamento dovrebbe essere effettuato in loco magari off-line da esseri umani pensanti. Non tutti i Data Center sono unattended disclocati in Antartide e nessuno nello spazio o sulla Luna.

    Beh altra cosa è lasciare porta aperte a rampazzo, AMT attivo a ravanare senza motivo, computers sempre sotto rete elettrica anche dopo shutdown, orecchie sempre aperte in ricezione di comandi provenienti da chicchessia...
    Si, le PWD ed altri controaccettivi..., ma prima o poi vengono intercettati, specie se i PC target sono in ricezione continua...

    I DRM al limite c'entrano, perchè se dai potere a chi del caso di gestire a piacimento da remoto fino al punto di ricostruire o sostituire un intero S.O. + applicativi + dati a tua insaputa, altro che di backdoor totale si tratta, i DRM sono l'ultimo dei corollari conseguenti a questo visione da incubo orwelliano (che temo corrisponda ad una realtà nascosta e latente, come pavantato dal Palladium e simili amenità, 1984 ecc...).

    Ad ogni buon conto io stacco da rete elettrica (ciabatta off) i miei 5 PC dopo shutdown, non voglio sorprese malevole, per evitare le quali scopro che non basta disattivare WinUpdate (in XP non ci sono più updates e sotto 7 sono notoriamente malevole, altri Win non mi interessano), e a poco serve connettersi in rete solo quando necessario.
    E da buon ultimo, fortunatamente non uso da lustri HW Intel, per convenienza oltre che per principio.
    .
    -----------------------------------------------------------
    Modificato dall' autore il 04 maggio 2017 05.42
    -----------------------------------------------------------
  • LOM stà per Light Out Management se vuoi Wikipedia loro han scelto una variazione sul tema: "Out-of-band management"; alla fine puoi vederli come un ssh che anziché operare a livello OS opera "a livello bios" cosa che per le architetture attuali implica non una soluzione generica opensource ma una serie di soluzioni proprietarie con costi&problemi del caso.

    Normalmente nessuno lascia un lom accessibile a cani&porci, menchemeno accessibile attraverso internet (se non via ssh su una macchina in loco/VPN ecc), proprio perché son soluzioni proprietarie e intrinsecamente "poco sicure" si usano (dovrebbero usare) con religiosa attenzione...

    Quando gestisci una macchina "light out" o è da installare (iow non operativa) o ha seri problemi software (iow non operativa) non è che giochi di nascosto su qualche filesystem senza che manco l'OS se ne accorga! Quel che fai, al di la delle diverse architetture, è sostanzialmente "bootare nel bios" di una qualsiasi macchina x86 classica con la differenza che la cosa si può normalmente automatizzare, cioè puoi "modificare le impostazioni del bios" di n macchine insieme. Quella di Intel è in effetti una vulnerabilità non un modo normale di operare.

    Quanto al discorso di avere qualche bipede in loco che accende la macchina e "va nel bios" per te non è applicabile in maniera non suicidaria: il datacenter non è normalmente tuo, a meno di non chiamarsi Google, Facebook, Amazon, ... normalmente è di un'azienda e altre aziende affittano spazio e risorse al suo interno (per esempio la pippo srl va da OVH/Aruba/... e affitta 4U rack in cui piazza due suoi server 2U, paga corrente elettrica, servizio, banda ecc).

    Uno scenario d'esempio: se sei un privato o una piccola azienda facilmente compri "spazio web" ovvero chiedi a qualcuno di offrirti una directory su cui buttare dell'html/js/php/* e servirlo al mondo, magari con db&c; se hai bisogni un pelo superiori affitti un VPS ovvero una macchina virtuale/container che gira sul ferro di qualcun'altro e questo ti offre in genere un OS "preinstallato" che puoi "riportare allo stato di fabbrica" o configurare a piacere; se hai bisogni un pelo più grandi hai ad esempio macchine fisiche tue che però non puoi tenerti in casa perché non hai abbastanza banda, sicurezza di alimentazione elettrica, contro i furti ecc, allora affitti non una macchina virtuale ma uno o più armadi rack o posti in un armadio in cui metti fisicamente le tue macchine. Chi ti affitta l'armadio offre corrente, banda, garanzie di disponibilità di queste, contro i furti ecc. Ma non ti fa da babysitter. Normalmente la tua macchina per poter accedere "al bios" richiede un certa autenticazione, non è che arrivi li attacchi un portatile alla DB9 o apri monitor+tastiera da cassetto e accedi "al bios" come faresti sul tuo desktop: hai bisogno di una certa autenticazione, magari con una smartcard o magari qualcosa da remoto per far qualunque operazione, non solo a livello "OS" ma anche a livello "bios"... Ora i tuoi 3/4/5 sistemisti lavorano da casa loro o in ufficio a Milano ma i server sono fisicamente un po' ad Arezzo, un po' a Parigi e un po' in qualche posto della Svizzera/Germania o altro paese. Devi aggiornare Ubuntu alla prossima LTS o ti si schianta l'OS, niente più ssh&c. Che fai? Parti per le varie location, stacchi tutto e installi in loco? Dai le credenziali per "accedere al bios" e metterti in modalità "netboot" la macchina a uno sconosciuto del datacenter? Hai bisogno di una "seconda via" che ti permetta di accedere comunque come se fossi in loco. Ecco i LOM. Anche per dei desktops possono servire: metti un call-center in Romania con un paio di sistemisti in Italia. In loco non hai nessuno con competenze od affidabilità adeguate per fargli toccare il bios o gestire nulla sulle macchine: in genere se ci son problemi parte un corriere con il ferro pronto e il bipede in loco, magari tera parte a chiamata, si limita a collegare i cavi, telefonarti, tu da remoto accendi, controlli che sia tutto in ordine e vi salutate. Il ferro è impostato per accendersi e spegnersi da solo ad orari specifici, il case è rivettato e l'unica apertura lucchettata ha un interrutorino "di guardia" che se la apri schianta la macchina/fa suonare un'allarme/impedisce il futuro avvio lasciando i dati cifrati su disco ecc. Questa è la gestione "comune" odierna sennò nulla impedisce allo^H^H schiav^H^H^H^H^H^H sottop^H^H^H^H^H^H dipendente di rubarti ferro o magari altre cose sgradite...
    non+autenticato
  • > Non son certo favorevole all'AMT ma considera che
    > se i server da gestire sono in una serie di
    > datacenter sparsi nel mondo o il call center è
    > fisicamente in Romania mentre io sono a Sophia
    > Antipolis bé un kvm semplice non mi basta, un kvm
    > ip "trasparente" non è più sicuro di iDRAC, iLo,
    > ... ed è normalmente meno gestibile, pensa per
    > es. ad automatizzare un deploy bare-metal con
    > Salt, con n kvm che devo
    > fare?

    La sicurezza del KVM sta nel fatto che:
    1) lo accendi esclusivamente quando ti serve.
    2) essendoci vera concorrenza è più difficile che mettano backdoor appositamente
    3) puoi monitorare tutto ciò che il KVM fa sniffando a monte e a valle tutti i suoi collegamenti col server e con la rete. E quando qualche attivista becca il KVM a fare porcate...

    Col processore invece devi fidarti degli yankee e la loro legge DMCA che impone la backdoor di stato se vuoi vendere il prodotto nelle terre selvagge.

    Alla fine metti un KVM ip in ogni rack, che tanto quello funziona anche se ti si impalla la macchina.
    Quando ti serve, la risorsa umana in loco schiaccia un pulsante colorato messo lì appositamente (o si potrebbe pensare ad un tastierino numerico con codice che cambia ogni volta, se proprio non ti fidi) e il KVM parte dandoti la relativa connessione.

    Hai quindi accesso al server o meglio ai server come se fossi lì e puoi anche formattare/installare/fare test fin che vuoi.

    Se hai n macchine e 1/n tempo, come sempre, puoi replicare i comandi da inviare a tutti i KVM con un qualche batch.

    Finito l'aggiornamento come ultima cosa comandi il KVM di spegnersi fino a futura pressione del tastone colorato (o gli dai il prossimo codice numerico se ti piacciono i film di James Bond).

    Certo, ci vuole il braccino non troppo corto tale da comprare dei KVM...

    Ma con quello che può farti questo "bug" se finisce nel mercato nero, direi che è il caso di non fare troppo i genovesi.
    non+autenticato
  • C'è un problema: qualsiasi server non giocattolo ha già una soluzione LOM integrata e questa è la sola gestione possibile, in genere *non ci sono* VGA e talvolta manco USB, non puoi attaccarci un KVM... La gestione, locale o remota, la fai tramite porte DB9/RJ45 (sia seriali che ethernet, [AI]LOM, RSC, ...), normalmente con una qualche forma di autenticazione. L'unica cosa che ti da il datacenter è una rete "parallela" fisica o virtuale che sia a cui attaccarti. Essere sul posto o dall'altro capo del mondo è uguale.

    Quanto ai desktop un'infrastruttura KVM per ogni macchina d'un call-center ti costerebbe ben di più di mantenere un sistemista in loco...
    non+autenticato
  • beh, bug o non bug, è comunque da scellerati nattare su rete pubblica l'interfaccia ME di un pc/server, l'ilom, imm o qualsiasi altra interfaccia di gestione a basso livello di un server.
  • ma il nat non ti aiuta se ti entrano nella rete LAN ( e succede praticamente sempre )
    non+autenticato
  • si ok per entrare in lan comunque bisogna bucare qualcosa prima, per es un nas esposto con fantomatici servizi cloud, webcam cinesi che aprono porte a gogo con upnp ecc ecc.. ma nattare ME/AMT/kvm è come asfaltare un'autostrada direttamente verso i cazzi/servizi miei e senza casello/telepass.
    fare una vpn fa schifo?

    cmq ME di intel è sempre stata una mangement platform dei poveri con delle potenzialità ma di utilizzo contorto.
    su ibm vuoi il kvm? paghi la feature key
    con dell idrac è incluso? non saprei
    con hp mi pare che ilom sia incluso, una volta lo era.
    con sun pagavi un botto il server e l'ilom era inclusa, ora con oracle non oso immaginare
    con supermicro hai il kvm integrato e risparmi soldi ma sm stessa consiglia di non esporre l'interfaccia di management, anche li sono stati trovati molti bug di sicurezza e c'è l'applet java che rompe le balle ogni 3*2
  • - Scritto da: v8star
    > si ok per entrare in lan comunque bisogna bucare
    > qualcosa prima, per es un nas esposto con

    purtroppo non e' affatto difficile al giorno d'oggi

    i sistemi informatici sono groviere, da un lato perche' il software e' oggettivamente difficile da progettare e realizzare, dall'altro perche' c'e' la volonta' di ficcare dentro backdoor ( che prima o poi vengono sfruttate da cani e porci )
    non+autenticato
  • ...che qualcuno ha realmente attivato lo spionaggio da remoto camuffato da antifurto?
    non+autenticato
  • dopo che la backdoor viene trovata si grida al bug.
    E' sempre così. Chi l'avrebbe mai detto che questa tecnologia di controllo remoto sarebbe stata "buggata".....
    non+autenticato
  • non c'è più sordo di chi non vuol sentire:

    https://semiaccurate.com/2012/05/15/intel-small-bu.../
    non+autenticato
  • Tu sei sordo ma ci senti benissimo A bocca aperta

    La cosa più bella di quell'articolo è la data di pubblicazione. Io presumo che Intel sapeva fin dall'inizio del bug almeno per due motivi. Il primo è perché l'ha certamente introdotto di proposito. Il secondo è perchè non serve essere un ingegnere particolarmente dotato per capire il rischio di quella tecnologia e qualsiasi ingegnere che lavora a Intel aveva la capacità di notarlo fin la primo giorno e scoprire che il firmware era proprio stato buggato per consentire la backdoor che tutti si immaginavano fin dal principio. Per la serie "le coincidenze"...
    Nove anni per fixare una backdoor con exploit annesso da remoto o locale a un livello così basso fin dentro l'hardware irrilevabile dalla vittima di un attacco che perfino i prodotti Microsoft a confronto sembrano un bastione della sicurezza (per lo meno le backdoor e gli spyware di Windows 10 non funzionano se fai il boot in Linux).
    E' scandaloso alla faccia dei complotti con l'nsa. E ci scommetto che alla fine Intel non ci rimetterà niente da questo. Come se nulla fosse successo.
    non+autenticato
  • - Scritto da: ben10

    > (per lo meno le backdoor e gli spyware
    > di Windows 10 non funzionano se fai il boot
    > in Linux).

    Non c'è bisogno di ricorrere a linux, è sufficiente un qualsiasi tool di terze parti per spegnere ogni spiamento con un click.
    Alternativamente, per gli amanti del terminale, si può andare giù manualmente con una serie di sequenze di comandi che disattivano tutto.
    non+autenticato
  • - Scritto da: ben10
    > Tu sei sordo ma ci senti benissimo A bocca aperta
    >
    > La cosa più bella di quell'articolo è la data di
    > pubblicazione. Io presumo che Intel sapeva fin
    > dall'inizio del bug almeno per due motivi. Il
    > primo è perché l'ha certamente introdotto di
    > proposito. Il secondo è perchè non serve essere
    > un ingegnere particolarmente dotato per capire il
    > rischio di quella tecnologia e qualsiasi
    > ingegnere che lavora a Intel aveva la capacità di
    > notarlo fin la primo giorno e scoprire che il
    > firmware era proprio stato buggato
    >
    per consentire la backdoor che tutti
    > si immaginavano fin dal principio. Per la serie
    > "le
    > coincidenze"...
    > Nove anni per fixare una backdoor con exploit
    > annesso da remoto o locale a un livello così
    > basso fin dentro l'hardware irrilevabile dalla
    > vittima di un attacco che perfino i prodotti
    > Microsoft a confronto sembrano un bastione della
    > sicurezza (per lo meno le backdoor e gli spyware
    > di Windows 10 non funzionano se fai il boot in
    > Linux).
    > E' scandaloso alla faccia dei complotti con
    > l'nsa. E ci scommetto che alla fine Intel non ci
    > rimetterà niente da questo. Come se nulla fosse
    > successo.


    non per niente i cinesi adesso preferiscono farsi le cpu da soli (e mi sa che sono qausi tutte arm) e la stessa strada la vogliono fare i russi
    non+autenticato
  • - Scritto da: bancai

    > non per niente i cinesi adesso preferiscono farsi
    > le cpu da soli (e mi sa che sono qausi tutte arm)

    infatti i cinesi hanno comprato ARM tramite Softbank, che e' una societa' giapponese ma il cui azionariato di maggioranza e' cinese

    > e la stessa strada la vogliono fare i
    > russi

    gia' fatto e anzi sui sistemi governativi e militari hanno pure il loro sistema operativo
    non+autenticato
  • - Scritto da: bancai
    > - Scritto da: ben10
    > > Tu sei sordo ma ci senti benissimo A bocca aperta
    > >
    > > La cosa più bella di quell'articolo è la data di
    > > pubblicazione. Io presumo che Intel sapeva fin
    > > dall'inizio del bug almeno per due motivi. Il
    > > primo è perché l'ha certamente introdotto di
    > > proposito. Il secondo è perchè non serve essere
    > > un ingegnere particolarmente dotato per capire
    > il
    > > rischio di quella tecnologia e qualsiasi
    > > ingegnere che lavora a Intel aveva la capacità
    > di
    > > notarlo fin la primo giorno e scoprire che il
    > > firmware era proprio stato buggato
    > >
    per consentire la backdoor che tutti
    > > si immaginavano fin dal principio. Per la serie
    > > "le
    > > coincidenze"...
    > > Nove anni per fixare una backdoor con exploit
    > > annesso da remoto o locale a un livello così
    > > basso fin dentro l'hardware irrilevabile dalla
    > > vittima di un attacco che perfino i prodotti
    > > Microsoft a confronto sembrano un bastione della
    > > sicurezza (per lo meno le backdoor e gli spyware
    > > di Windows 10 non funzionano se fai il boot in
    > > Linux).
    > > E' scandaloso alla faccia dei complotti con
    > > l'nsa. E ci scommetto che alla fine Intel non ci
    > > rimetterà niente da questo. Come se nulla fosse
    > > successo.
    >
    >
    > non per niente i cinesi adesso preferiscono farsi
    > le cpu da soli (e mi sa che sono qausi tutte arm)
    > e la stessa strada la vogliono fare i
    > russi

    E fanno bene!

    A quando HW open finalmente anche da noi?