Link alla notizia: https://www.hwupgrade.it/news/sicurezza-software/il-codice-sorgente-del-bios-uefi-delle-cpu-alder-lake-finisce-sul-web-intel-minimizza_110839.html

Il codice sorgente del BIOS UEFI delle CPU Alder Lake è finito sul web, ponendo un possibile problema di sicurezza per i sistemi con CPU Core di 12a generazione. Intel, in una risposta ufficiale, minimizza l'accaduto mentre la comunità dei ricercatori s'interroga.

Click sul link per visualizzare la notizia.

Ma si, che sarà mai ! :O

la cosa che piu' inorridisce e' che in Intel ancora utilizzino SVN...

forse ha ragione intel! se fosse grave non esisterebbe l'open source.

la cosa che piu' inorridisce e' che in Intel ancora utilizzino SVN...

cazz non c'avevo fatto caso, ora per colpa tua sono in iperventilazione per l'ansia

Alla fine, meglio .... codice sorgente si maggior rischio di Marware, ma per la scena significa anche Migliore possibilità di far sopravvivere le MOBO dopo i due anni di MORTE PROGRAMMATA (Asus.... sto attendendo ancora la Patch del Microkernel).

forse ha ragione intel! se fosse grave non esisterebbe l'open source.
Non è la stessa cosa...
L'open source è in genere caratterizzato da "trova il bug, sistemalo, aggiorna il software".
Il Bios, da "questo hai, e questo ti tieni, bug o no"...

Non è la stessa cosa...
L'open source è in genere caratterizzato da "trova il bug, sistemalo, aggiorna il software".
Il Bios, da "questo hai, e questo ti tieni, bug o no"...

guarda che quando si parla di ROM non è più ROM per davvero da tipo il 1988 :D

bios / uefi / firmware più in generale ovviamente sono aggiornabili

il problema di sicurezza qui se caso è un altro
se è un sw già lungamente testato / fixato con le best practices del settore, insomma hai fatto le cose per bene, non ha problemi se il codice viene diffuso;
se invece hai parzialmente / completamente fatto affidamento alla security through obscurity allora si, c'è un problema serio

[...]
se è un sw già lungamente testato / fixato con le best practices del settore, insomma hai fatto le cose per bene, non ha problemi se il codice viene diffuso;
[...]
vero, ma nel caso specifico, quanto a best practices beh beh.... questi hanno messo una chiave privata nel VCS! :doh:
e lì non ci sono santi, Intel Boot Guard rischia di diventare untrusted per tutti

guarda che quando si parla di ROM non è più ROM per davvero da tipo il 1988 :D

bios / uefi / firmware più in generale ovviamente sono aggiornabili

il problema di sicurezza qui se caso è un altro
se è un sw già lungamente testato / fixato con le best practices del settore, insomma hai fatto le cose per bene, non ha problemi se il codice viene diffuso;
se invece hai parzialmente / completamente fatto affidamento alla security through obscurity allora si, c'è un problema serio

Non intendevo che non è aggiornabile a causa della ROM...
Intendevo che, nella maggior parte dei casi, i produttori di hardware non rilasciano aggiornamenti del BIOS. Compri un dispositivo con quel BIOS, e ti tieni quel BIOS a vita, perché non vengono rilasciati aggiornamenti...

E nonostante non abbiano fatto affidamento alla security through obscurity, si tratta comunque di un codice che è stato finora sotto gli occhi di pochi esperti. Nel momento in cui finisce sotto gli occhi di molti altri esperti, qualche vulnerabilità probabilmente salta fuori. E quelle vulnerabilità te le tieni, se i produttori non rilasciano poi aggiornamenti...

ma secondo alcuni ricercatori - come riportato da Bleeping Computer - questo furto di codice potrebbe facilitare la vita dei malintenzionati a rintracciare falle e fare persino del reverse engineering.

Non sono un informatico e mi chiedo: che bisogno c'è di fare reverse engineering quando si hanno i sorgenti a disposizione?

forse intendevano il reverse engineering del hardware

la cosa che piu' inorridisce e' che in Intel ancora utilizzino SVN...

Quella è la pagina di github. Può anche darsi che abbiano importato su github un repository originario svn.

Se era un progetto open source tutti sarebbero stati felici del codice pubblico

Quella è la pagina di github. Può anche darsi che abbiano importato su github un repository originario svn.

Lo so che e' github, ma vedo la cartella .svn, quindi e' un repository svn caricato paro paro su github... E sinceramente ho i miei dubbi che chi abbia preso il codice l'abbia versionato prima in SVN per poi caricarlo su github, e' molto piu' probabile che quella cartella fosse presente fin dall'origine...

Non sono un informatico e mi chiedo: che bisogno c'è di fare reverse engineering quando si hanno i sorgenti a disposizione?

Perche' avere i sorgenti non significa per forza avere il codice sorgente... Ad esempio se vedi il kernel linux, alcuni driver sono si' nel repository del kernel, ma sottoforma di blob binari, proprio perche' non vogliono rendere noto il codice sorgente (ad esempio questo driver (https://git.kernel.org/pub/scm/linux/kernel/git/tglx/apic.git/tree/firmware/atmsar11.HEX)). Quindi anche in caso di software rilasciato e' possibile avere delle parti binarie precompilate che devono essere sottoposte a reverse engineering per capire bene come funzionano.

Perche' avere i sorgenti non significa per forza avere il codice sorgente... Ad esempio se vedi il kernel linux, alcuni driver sono si' nel repository del kernel, ma sottoforma di blob binari, proprio perche' non vogliono rendere noto il codice sorgente (ad esempio questo driver (https://git.kernel.org/pub/scm/linux/kernel/git/tglx/apic.git/tree/firmware/atmsar11.HEX)). Quindi anche in caso di software rilasciato e' possibile avere delle parti binarie precompilate che devono essere sottoposte a reverse engineering per capire bene come funzionano.

Scusami ma non ti seguo (di sicuro è un problema mio)

Nell'articolo è scritto Il codice sorgente del BIOS UEFI delle CPU Alder Lake è finito sul webSignifica che non sono i sorgenti ma blob binari?
O forse quando scrivi anche in caso di software rilasciato e' possibile avere delle parti binarie precompilatesignifica che all'interno dei sorgenti ci sono parti già compilate? (Immagino che il compilatore saprà che quelle parti sono da saltare in fase di compilazione.) Oppure sono sorgenti offuscati?
Scusa la pesantezza ma, anche se non sono informatico, certe cose mi piacerebbe capirle, se riesco...

vero, ma nel caso specifico, quanto a best practices beh beh.... questi hanno messo una chiave privata nel VCS! :doh:

si ecco :muro:

la cosa che mi stupisce è che cmq un tot di best practices le dovresti seguire per essere compliant per le varie certificazioni che sicuramente Intel ha

per lavoro stiamo rendendo compliant iso 27001 un sw utilizzato da un cliente (che comunque è una piccola azienda), poi vado sul sito della banca e se sbagli la login ti dice se è perché l'utente non esiste o la pass è sbagliata (cioè il motivo, esponendo perciò se esiste o non esiste il dato account), io boh

Perche' avere i sorgenti non significa per forza avere il codice sorgente... Ad esempio se vedi il kernel linux, alcuni driver sono si' nel repository del kernel, ma sottoforma di blob binari, proprio perche' non vogliono rendere noto il codice sorgente (ad esempio questo driver (https://git.kernel.org/pub/scm/linux/kernel/git/tglx/apic.git/tree/firmware/atmsar11.HEX)). Quindi anche in caso di software rilasciato e' possibile avere delle parti binarie precompilate che devono essere sottoposte a reverse engineering per capire bene come funzionano.

Non solo, visto che roba tipo il BIOS UEFI non la si riscrive da zero per ogni cpu, dando un occhiata alle strutture dati, al codice sorgente ed al codice binario generato compilandolo per Alder Lake, si ricavano informazioni utili per fare molto più rapidamente il reverse engineering del firmware di cpu precedenti e successive.