K\u00ebrkuesit p\u00ebr sigurin\u00eb nga kompania Binarly identifikuan nj\u00eb mund\u00ebsi p\u00ebr t\u00eb anashkaluar modalitetin e ngarkimit t\u00eb verifikuar UEFI Secure Boot n\u00eb m\u00eb shum\u00eb se 800 produkte q\u00eb jan\u00eb l\u00ebshuar nga kompanit\u00eb Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo dhe Supermicro. Problemi mori emrin kodor PKfail dhe lidhet me p\u00ebrdorimin n\u00eb firmware t\u00eb nj\u00eb \u00e7el\u00ebsi platforme (PK, Platform Key) t\u00eb pabesuesh\u00ebm, t\u00eb gjeneruar nga kompania AMI (American Megatrends International) dhe d\u00ebrguar si nj\u00eb shembull prove. Firmware m\u00eb t\u00eb vjetra q\u00eb p\u00ebrdorin \u00e7el\u00ebsin e testit jan\u00eb l\u00ebshuar n\u00eb vitin 2012, nd\u00ebrsa m\u00eb t\u00eb rejat jan\u00eb datuar n\u00eb qershor 2024. Sipas t\u00eb dh\u00ebnave nga k\u00ebrkuesit, mbi 10% e t\u00eb gjitha firmware t\u00eb verifikuara jan\u00eb prekur nga ky problem. <\/p>\n
N\u00eb parametrat e \u00e7el\u00ebsit ishte e sh\u00ebnuar se ai nuk \u00ebsht\u00eb i besuesh\u00ebm dhe nuk duhet t\u00eb dor\u00ebzohet n\u00eb produktet e tyre. Ishte n\u00ebnkuptuar se ky \u00e7el\u00ebs prove duhet t\u00eb z\u00ebvend\u00ebsohej me nj\u00eb \u00e7el\u00ebs t\u00eb vetin, por prodhuesit nuk e mor\u00ebn parasysh paralajm\u00ebrimin dhe p\u00ebrdor\u00ebn n\u00eb firmware t\u00eb fundit nj\u00eb \u00e7el\u00ebs t\u00eb zakonsh\u00ebm t\u00eb d\u00ebrguar p\u00ebr t\u00eb gjith\u00eb partner\u00ebt dhe klient\u00ebt e kompani AMI. <\/p>\n
Pjesa e mbyllur e \u00e7el\u00ebsit t\u00eb testit AMI, e nevojshme p\u00ebr krijimin e n\u00ebnshkrimeve digjitale, u b\u00eb publike pas nj\u00eb shp\u00ebrthimi informacioni nga nj\u00eb nga prodhuesit e pajisjeve, nj\u00eb punonj\u00ebs i t\u00eb cilit aksidentalisht postoi n\u00eb nj\u00eb depo publike n\u00eb GitHub kodin, i cili p\u00ebrmbante k\u00ebt\u00eb \u00e7el\u00ebs. \u00c7el\u00ebsi i mbyllur u vendos n\u00eb nj\u00eb skedar t\u00eb enkriptuar, gjat\u00eb enkriptimit t\u00eb t\u00eb cilit u p\u00ebrdor nj\u00eb fjal\u00ebkalim i thjesht\u00eb 4-shifror, i cili u gjet leht\u00ebsisht me metod\u00ebn e prov\u00ebs s\u00eb mundimeve. <\/p>\n
\u00c7el\u00ebsi i platform\u00ebs p\u00ebrdoret si rr\u00ebnja e besimit p\u00ebr t\u00eb certifikuar DB-t\u00eb me \u00e7el\u00ebsa p\u00ebr Secure Boot. Marrja e pjes\u00ebs private t\u00eb \u00e7el\u00ebsit t\u00eb platform\u00ebs \u00e7on n\u00eb komprometimin e t\u00ebr\u00eb zinxhirit t\u00eb besimit, i angazhuar n\u00eb verifikimin e vlefshm\u00ebris\u00eb s\u00eb komponent\u00ebve t\u00eb sistemit t\u00eb ngarkes\u00ebs \u2014 duke ditur \u00e7el\u00ebsin e platform\u00ebs mund t\u00eb anashkalohet mbrojtja e Secure Boot dhe t\u00eb organizohet nj\u00ebsia e ngarkes\u00ebs me komponent\u00ebt e vet duke manipuluar \u00e7el\u00ebsin KEK (Key Exchange Key) dhe databazat \u00abdb\u00bb (Signature Database) dhe \u00abdbx\u00bb (Forbidden Signature Database). KEK p\u00ebrgjigjet p\u00ebr krijimin e zinxhirit t\u00eb besimit midis firmware dhe sistemit operativ, \u00abdb\u00bb p\u00ebrmban certifikatat dhe n\u00ebnshkrimet p\u00ebr ngarkuesin dhe komponent\u00ebt e pal\u00ebve t\u00eb treta UEFI, nd\u00ebrsa \u00abdbx\u00bb p\u00ebrfshin n\u00ebnshkrimet e t\u00ebrhequra t\u00eb komponent\u00ebve t\u00eb njohur keqdash\u00ebs. <\/p>\n
P\u00ebr t\u00eb kryer nj\u00eb sulm, mjafton t\u00eb gjeneroni \u00e7el\u00ebsa dhe certifikata t\u00eb reja p\u00ebr KEK dhe db, dhe m\u00eb pas t\u00eb p\u00ebrdorni \u00e7el\u00ebsin e platform\u00ebs testues q\u00eb ka ardhur n\u00eb dispozicion publik p\u00ebr t\u00eb ngarkuar n\u00eb firmware-n UEFI certifikat\u00ebn e krijuar KEK. Pasi t\u00eb ngarkohet n\u00eb firmware, certifikata KEK mund t\u00eb p\u00ebrdoret me \u00e7el\u00ebsin e saj privat p\u00ebr t\u00eb ngarkuar nj\u00eb certifikat\u00eb t\u00eb re n\u00eb databaz\u00ebn db. Pas ngarkimit t\u00eb certifikat\u00ebs db, \u00e7el\u00ebsi i saj privat mund t\u00eb p\u00ebrdoret p\u00ebr t\u00eb certifikuar komponent\u00ebt EFI q\u00eb ngarkohen. openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj '\/CN=BRLY KEK\/' -out KEK.crt openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj '\/CN=BRLY db\/' -out db.crt efi-updatevar -a -c KEK.crt -k PK.key KEK efi-updatevar -a -c db.crt -k KEK.key db sbsign --key db.key --cert db.crt --output rogue.efi.signed rogue.efi <\/p>\n
P\u00ebr t\u00eb verifikuar sakt\u00ebsin\u00eb e \u00e7el\u00ebsit t\u00eb platform\u00ebs, mjafton t\u00eb ekzekutoni mjetin \u00abefi-readvar -v PK\u00bb nga paketa efitools dhe t\u00eb siguroheni q\u00eb \u00e7el\u00ebsi i platform\u00ebs nuk \u00ebsht\u00eb testues: efi-readvar -v PK Variable PK, length 862 PK: Lista 0, tipi X509 N\u00ebnshkrimi 0, madh\u00ebsia 834, pronari 26dc4851-195f-4ae1-9a19-fbf883bbb35e Subjekti: CN=DO NOT TRUST \u2014 AMI Test PK S issuer: CN=DO NOT TRUST \u2014 AMI Test PK
![\"Luaj](\"https:\/\/img.youtube.com\/vi\/CveWt3gFQTE\/hqdefault.jpg\")
\r\n