A macOS High Sierra felfedi a titkosított APFS kötetek jelszavát jelszóemlékeztetőként (clear text)

 ( trey | 2017. október 6., péntek - 13:56 )

Egy rút bug található a macOS High Sierra-ban, aminek következtében az felfedi a titkosított APFS kötetek jelszavát plain text módon:

Matheus Mariano, brazil szoftverfejlesztő fedezte fel, hogy a High Sierra a jelszóemlékeztetőben a korábban a titkosításhoz használt jelszót jeleníti meg... Az Apple által kiadott High Sierra update nem javítja a már meglevő problémát. Az Apple egy útmutatót tett közzé a baki "kijavítására": If macOS High Sierra shows your password instead of the password hint for an encrypted APFS volume

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

#legendaryapplequality #nekemnincsidomlinuxonhulyesegeketjavítaniazertmacezek #nemkellselfsupport

és egyéb ordas baromságok.

--
trey @ gépház

hehehe :D

Ez fícsör, a legtöbb r=1 júzer ilyen jelszó emlékeztetőről álmodik, ha már a hülye szoftver fejlesztők mindenféle jelszavakkal nehezítik az életüket.

:-)

Nem r=1 user!
Hanem a=1 azaz apple=1 user :-)

Jelszó-emlékeztetőt meg az kérjen aki elfelejtette, nem az aki sohasem tudta és akkor nincsen baj! :)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

> Click Erase.

Ha nem lenne Mac a családban, még röhögnék is.

Nem hiszem el, hogy magártól ennyire hülye az apple qm. Olyan hibák csúsznak ki termékként, hogy az nem lehet véletlen főleg nem egy olyan cégnél akinek végtelen erőforrása van.

Ahhoz kepest hogy milyen sok penzuk van, joval kevesebbet fizetnek a fejlesztoiknek, mint ugyanabban a varosban egy atlagos startup.

"Majd jobban mutat a CV-dben" - a kereslet meg a kinalat meg le van szarva munkaero keresese eseten.

Majd az új munkakörnyezetben hatékonyabbak lesznek! Ahogy hallottam, a dolgozóknak kifejezetten "tetszik" az új open air munkakörnyezet...

--
trey @ gépház

Vegulis ez nem is hiba, mert eleg hatekony hintet ad a jelszora :D

Hét végül is, eszedbe jut róla a jelszó? Igen. Akkor jó jelszó-emlékeztető. :D

Túl sok binuz kóderpistike került az aplihoz.

A C kodban behivott Perl kodnal anno tenyleg ez volt az erzesem :)

Elso problemam ,hogy miert tudja a jelszot?

Mert megadtad neki. 2017-ben tanuld meg végre, hogy amit megadsz ezeknek, az már az övék! :)

Valoszinuleg itt a jelszo field adatait mentette bele a hintbe is. Veletlen.

Ami ugy tortent hogy...

Hogyan lehet veletlenul kiolvasni valahonnan egy jelszot amit le se kene tarolnia csak a hasht vagy ha megis akkor is titkositva?

Na jó, de hogyan készül a hash?

Betesszük a jelszót a változóba, készítünk hash-t, tároljuk, aztán tároljuk a változóból a hintbe ;-)

Valoszinuleg nem a visszaolvasaskor van a hiba, hanem mar a beiraskor, amikor a jelszo meg ismert, bekerult a hintbe is. Ez egy programozoi eliras, ami belefer. A gondd, hogy ez valahogy az egesz qa-n atment. Senkinek nem tunt fel.

-
Kiterjesztések írása Go nyelvi környezetben

passwordHint = txtHint.Text;
helyett gondolom valami olyasmit sikerült írni, hogy
passwordHint = txtPassword.Text;

elég gáz így is, ellopni sem kell :)

nem tudok spanyolul.

--
GPLv3-as hozzászólás.

Mihez kéne spanyolul tudnod?

Gondolom a portugál videohoz.

--
trey @ gépház

Más forras is megerositette? Kiprobalta mar valaki? Megtalaltatok mashol is az ellenorzest?

Nagyon erdekes az ugy.

Ittál?

--
trey @ gépház

Nem, nem. Ne erts felre, egyszeruen mar nem tudom elhinni, hogy milyen hibak kerulnek be apple szoftverekbe. Csak ennyi. Veletlenul senki nem ilyen hulye.

Arra kérdeztem, hogy "Más forras is megerositette?". Az Apple maga erősítette meg, hiszen javítást és útmutatót adott ki hozzá. Miért kellene ezt másnak még megerősítenie?

--
trey @ gépház

Egy szavukat se lehet hinni :-D

Megnéztem a videót, elhűltem, majd gyorsan kipróbáltam, de nálan nem jött elő.
Biztos, ami tuti, azért felraktam a kiegészítő javítást. Még a végén tényleg megtudom, mi volt tegnap a jelszavam :)

--
Kinek nem inge, ne vegye gatyára

Apfs-ed van? Hfs+-t nem erinti

a High Sierra upgrade atkonvertalta a system disket APFS-re.

Nem, csak az SSD-knél teszi ezt.

--
Kinek nem inge, ne vegye gatyára

„Egy rút bug található…”
Bug egy fenét. Nagyon durva koncepciós hiba. Eleve a titkosítás alapszabálya, hogy a jelszót nem tárolják titkosítatlanul sehol sem. Különben semmi értelme titkosítani bármit is. Persze értem én, hogy ez baj sok 1.0-ás felhasználónak, mert ha elfelejti a jelszót, akkor bukó van az adatoknak (és nyilván ők az a kategória, akik biztonsági mentést sem tartanak), de el kell dönteniük, hogy kényelmet vagy biztonságot akarnak.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Amint az feljebb már írták, illetve a decompile-olt kódrészlet is alátámasztja, a hiba a jelszó és jelszó-emlékeztetőt megadó GUI ablakban van. Ez kb az utolsó hely, ahol a jelszónak még szükségszerű plaintext formában meglennie. Normális körülmények között tényleg nem tárolódna le, ez valóban egy elírás-jellegű bugnak néz ki. Ez megmagyarázza azt is, miért nem érinti azokat, akinek HFS+-ról lett konvertálva APFS-re a kötete.
---
Régóta vágyok én, az androidok mezonkincsére már!

Úgy látszik, hogy nem voltam világos. Sem jelszónak, sem emlékeztetőnek nem lenne szabad eltárolva lennie titkosítatlan formában. Emiatt eleve nem lenen szabad léteznie jelszó-emlékeztető mezőnek. Onnantól hogy el vannak ezek tárolva plain textben, onnantól megette a fene, hogy GUI bug miatt megjelenik-e a rossz mezőben a jelszó az emlékeztető helyett, vagy nem, mert lemezképet készítve bárki számára olvasható lesz, emiatt ez a fajta titkosítás nem ér semmit, csak teljesen technikai analfabéták ellen.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Hol olvastad, hogy el van tarolva a plain text jelszo es azt adja vissza a gui? Amikor beirod a jelszavat, akkor az plain text. Na akkor irtak be a jelszavat veletlen a hintbe. A jelszot cryptaltak es beleirtak a kotetbe, es melle irtak a jelszo emlekeztetot (amit nyilvan plain text vissza kell tudni adni a usernek), csak ez esetben elnezte a programozo, es a hintbe betette a jelszavat. Szoval nem az a baj, hogy egy GUI hiba miatt kiolvastak a tarolt jelszavat plain text formatumban.

"sem emlékeztetőnek nem lenne szabad eltárolva lennie titkosítatlan formában" ezt kifejtened bovebben, hogy milyen formaban titkositanad a jelszo emlekeztetot, amit vissza kell adni plain text formatumban anelkul, hogy a user begepelne egy jelszavat (mert ugye az emlekeztetot nem vedheted jelszoval, akkor viszont vagy generalnod kell egy jelszavat, amit melle raksz es semmi ertelme, vagy egy kozos titkos jelszot hasznalsz, aminek megint semmi ertelme)

"mert lemezképet készítve bárki számára olvasható lesz" igen ez tortent, mert rosszul lett a lemezkere irva az emlekezteto.

"emiatt ez a fajta titkosítás nem ér semmit" pontosan mi a baj ezzel a titkositassal (mar amikor nem irja el a programozo)? Fog egy jelszavat, azt egyiranyuan cryptalja, es letarol egy plain text emlekeztetot, ami nem lehet a jelszo? Persze az emberi hulyesegtol nem ved, de az ellenen semmi sem ved :) Ertem en, hogy security leak a jelszo emlekezteto, mert az alapjan kitalahato a jelszo, ha mondjuk ismernek teged vagy social engineeringgel. Viszont egy kotet titkositasanal nincs jelszoemlekezteto email, mint a weben. Itt vagy tudod a jelszavad vagy nem fersz az adatokhaz hozza. Szoval a korulmenyekhez kepest egy elfogadhato kompromisszum, marmint elfogadhatobb, mint hogy userek szazazrei veszitik el az adataikat, mert nem emlekeznek a jelszora, amit egy evvel azelott megadtak. Ha mar itt jarunk egy lapra felirni, es eltenni a szekrenybe sem biztonsagosabb. Es utoljara, rohadtul nem kotelezo mezo, szoval akinek nem fer bele ez a sec leak, az ne irjon oda semmit :D

-
Kiterjesztések írása Go nyelvi környezetben

Így már világos. Viszont még így sem szabadna emlékeztetőnek lennie, mert a titkosítást rettentően elgyengíti, támpontot ad bárkinek a visszafejtéshez. Egyébként pont ezért nem népszerű a titkosítás sok felhasználónál, nem elég kényelmes nekik, meg komplikált, meg nincs meg bennük a fegyelem, és csak elfelejtik a jelszót, meg kizárják magukat az adataikból. Aki csak egyszerű védelmet akar, állítson be BIOS jelszót, vagy valami hasonló primitív megoldást, az informatikailag analfabéták ellen az is véd, ha viszont megbízható titkosítás kell, akkor vállalni kell az ezzel járó kényelmetlenséget, nincs hint, nincs backdoor vészesetre.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

"Aki csak egyszerű védelmet akar, állítson be BIOS jelszót" az nem ved az ellen ha kiszerelik a merevlemezt, amit egy mezei user is meg tud csinalni, ha mas nem hat kalapaccsal. "ha viszont megbízható titkosítás kell" csakhogy az IT biztonsag nem ilyen fekete meg feher. Attol fugg mit akasz vedeni, vagyis mennyit er az amit vedeni akasz. Ha megbizhato biztonsag kell ne allits be emlekeztetot, vagy jobbat mondok szandekosan vezesd felre a tamadot az emlekeztetovel. Mindig azt kell szem elott tartani, hogy tobb erofeszites legyen feltorni, mint az adat erteke, ami a vedelem mogott van. A felhasznalonak kell tudnia eldonteni, de ha egyaltalan nincs emlekeztetore lehetoseg, akkor az egy dolgot fog eredmenyezni, hogy csak a HC arcok fognak titkositani, mert mindenki mas el fog retteni a dologtol. Es amugy a semminel meg az is biztonsagosabb, hogy a szuletiesi datum a jelszo, es az az emlekezteto, hogy "amikor szulettem", mert a szuletesi datumot is le lehet irni 20 felekeppen, meg az sem biztos, hogy aki kilopja a kocsibol a laptopod tudni fogja, hogy mikor szulettel. Fokozatok vannak, es nem csak a tokeletes vedelem letezik, es nem csak a tokeletes vedelemnek van ertelme, hanem a koztes dolgoknak is. Viszont egy ilyen offline titkositas eseten nem nagyon valogathatsza lehetosegek kozul, ha nem csak a 0 es 1-es tipusu titkositas hivoket akarod kiszolgalni.

-
Kiterjesztések írása Go nyelvi környezetben

A jelszónak valóban nem szabad plaintextben tárolva lenni, de az emlékeztetőnek igen (most ne vesszünk össze azon, hogy hülyeség-e a jelszóemlékeztető - én sem élek ilyenekkel). Az emlékeztető hint elég nehezen mutatható meg a usernek, ha csak titkosítva van meg.

Ez ellen a hibafajta ellen egyébként persze lehetne rendszerszinten védekezni, de a teljes rendszeren elég szigorúan végigvitt secure coding megoldások kellenek hozzá. Kezdve azzal, hogy a külön boxing típus van bevezetve a secret adatokra, nincs implicit typecast a becsomagolt alaptípus megfelelőjére, csak valami yesReallyRevealTheSecretRightHere() metódussal szedhető ki belőle. Esetleg meg is kell annotálnod a függvényt, ami ilyet hív, hogy a fordító/code analyzer átengedje, külön code review-t kap ahol security-hez értő ember is ránéz, hogy tényleg indokolt-e és nincs-e benne valami - átlag kóder számára nem túl nyilvánvaló - hiba. A GUI password widget csak a secret típust adja vissza. Aztán tovább lehet vinni, hogy a secret típusú változó eldobásakor explicit kinullázódik a memóriaterület, managed nyelv esetén ne legyen rá lazy garbage collection, hanem a referencia számláló 0-ra futásakor azonnal nullázzon. Esetleg a memóriában tényleg titkosítva legyen az adat, nyilván a kulcs is benne van a process teljes memóriaképében, de pl buffer overflow hibáknál nagyon kis valószínűséggel kerül ki egyszerre a kulcs és egy védett adat.

Na ez az, amit legfeljebb valami egészen különleges biztonságkritikus projektben csinálnak meg, de máshol nem. Vagy még ott sem (lásd OpenSSL).
---
Régóta vágyok én, az androidok mezonkincsére már!

Én egyébként ezt a jelszó-emlékeztető dolgot sem értem teljesen! Ez mire is való? Nyilván a c8559c3c9cfb42131794b7d8009230403b9b454c típusú jelszavakra nincs emlékeztető, de akkor mire? Az első macskám neve? Ilyen infónak biztos minden hekker örül...

A legjobb, amikor választanod kell listából olyan nyilvánvaló személyes kérdéseket, amelyekre a válaszokat még a Facebook előtt is legalább 20-30 ember tudott rólad.

Ki mondta, hogy a kedvenc háziállatom nevére a kedvenc háziállatom nevét kell beírnom? Lehet valami teljesen más is, csak meg kell jegyezni. Oh wait.

De akkor szükség lenne még egy jelszóemlékeztető emlékeztető blokkra is! :)

Nekem a kedvenc agybaszásom, amikor kötelező ki is tölteni, mivel én a fentebb említett típusú jelszavakat használom, így nehéz bármilyen értelmes emlékeztetőt beírni. Hacsak be nem írom emlékeztetőnek magát a jelszót :-)

Látod, és ha így teszel, utána te is készíthetnél kis videót, hogy a jelszóemlékeztető a jelszavadat írja ki, és ez már milyen!

Én ilyen esetekben „nincs emlékeztető”, „no hint”, „addig állj fél lábon”, stb. adok meg hintnek. Ha biztonsági kérdést erőltetnek, arra is ilyesmit adok meg, válasznak meg valami random karakterláncot. A legrosszabb az, mikor fix listából enged csak security questiont választani, pl. a Yahoo esetén ilyeneket, hogy „Name of your first pet” meg hasonló ökörségeket, akkor kiválasztok egyet (pl. nem volt soha háziállatom), és arra is valami értelmetlen karakterhalmazt zongorázok be. Az ilyen csak online accountoknál van.

Titkosításnál nincs, jelszavakra KeePass X2-őt, egyéb adatokra LUKS-ot vagy hardveres ATA-jelszót használok (utóbbit, ha a gép és a meghajtó támogatja) egész lemezes titkosításként (adatok, OS is titkosítva van). Ezekre nincs hint, nincs backdoor. ATA jelszónál is figyelek, hogy a master és user password egybeessen, nehogy gyárilag generált legyen a master password (bár ha azt megszerzi valaki, akkor sem fér hozzá az adatokhoz, csak a meghajtót tudja nullázni az adatok törlésével). Ezek alól nincs kibúvó, ha elfelejteném a jelszót, akkor bukó az adatoknak, vagyis van biztonsági mentésem, de az is egész lemezes LUKS-titkosítással (AES-256 XTS). Pedig semmi olyan rendkívüli rejtegetni valóm nincs, szokásos magánéletbeli dolgok (letöltések, dokumentumok), de mivel régen aktívan torrenteztem, ezért jobbnak láttam óvintézkedéseket tenni, azóta már visszaszorult a torrentezés, de a titkosítást tovább használom, ha már egyszer támogatott, meg be van állítva. Szoftveresen régi gépen sem sokat lassít, még annyira sem mint az NTFS-3G használata pl., mióta meg a procik meg a HDD-k/SSD-k támogatják a hardveres AES-t, azóta meg 0 teljesítményvesztés árán kaphat biztonságot az ember. Legalább ha a gép rossz kezekbe kerül, akkor legalább az adataim hozzáférhetetlenek lesznek. Egyedül az zavar, hogy az Android szarul áll titkosítás terén, és nem tudok olyan ütőképes megoldásról, amivel biztonságosan le lehetne titkosítani az egész rendszert meg a dokumentumokat a telefonomon.

Az ATA jelszónak van még egy olyan hátránya, hogy ahány gyártó, annyi implementáció, ezért nem tudni nincs-e benne backdoor, meg SSD-nél a TRIM működése is lehetővé teszi a vízjel-támadást a nem használt adatterületek felfedésével. A LUKS-nál garantált, hogy nincs benne semmi fogódzó egyik titkosszolgálatnak vagy hárombetűs ügynökségnek sem. A Windows Bitlocker és a MacOS titkosítását (az ilyen hírek miatt, mint ez is) nem tartom megbízhatónak egyáltalán, csak teljesen hamis biztonságérzet megteremtésére jók.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

A biztonsági kérdésekkel azért vigyázz, mert sokszor van olyan, hogy azt csak akkor kérdezik, amikor elfelejtetted / valamiért nem működik a jelszavad, és új jelszót akarsz generáltatni.
Ha ilyenkor megkérdeznék, hogy mi volt a kutyád neve és nem emlékszel a random karakterekre, akkor megakad a folyamat és maradsz kizárva.
Szóval a random karaktereket érdemes felírni valahová biztonságosan.