Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
uzytkownikubunt napisał(-a):
Trzeba było kupić inny smartfon. Inne jakoś nie mają problemów.
Ekhmm, ja go dostałem. Poza tym, z tego co się orientuję to jest masowe działanie. W sensie niewiele smarftonów na stockowym ROMie zezwala aplikacjom na zapis/odczyt danych z kart SD. Chodzi o androida 4.4+. Więc albo trzeba na chybił trafił szukać smarftona albo wgrać alternatywny ROM i to rozwiązanie jest przede mną. Bo na tych custom ROMach są jakoś normalne moduły i nikt się nie przejmuje, że windows nie wspiera EXT4. xD
Hepita napisał(-a):
@uzytkownikubunt
Nie wiem jak z innymi wersjami Androida, ale w 4.4 google z sobie tylko znanych powodów zablokowało możliwość zapisu plików na karcie SD przez aplikacje inne niż zainstalowane systemowo. Do obejścia tylko przez roota. Nie wiem jak z innymi wersjami systemu.
Za to z blokadą odczytu się nigdy nie spotkałem...
Niby ta kwestia miała się zmienić w 5.1 chyba. Jakiś framework obmyślili by umożliwić zapis karty SD aplikacjom ale to nie działa, przynajmniej u mnie i u całej masy użytkowników, na których się natknąłem szukając rozwiązania tego problemu. Natknąłem się też na info, że Android za parę lat ma zupełnie przestać wspierać karty SD i już obecnie zachęca producentów smartfonów by porzucili sloty na karty SD, także FAT nas wszystkich wpędzi do grobu. xD
Offline
3248
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:46:41)
Offline
Serwus; à propos szyfrowania - CVE-2016-4484: Cryptsetup Initrd root Shell. Rekapitulując: "This vulnerability allows to obtain a root initramfs shell on affected systems". Wspomniana luka umożliwia kopiowanie, modyfikowanie lub zniszczenie dysku twardego, jak również skonfigurowanie ustawień sieci w taki sposób, aby skrycie wyprowadzać dane etc. Wygląda na to, że osoba atakująca, po prostu musi nacisnąć klawisz [ENTER] (w miejscu wpisania hasła, LUKS) do momentu pojawienia się powłoki, co następuje, mniej więcej, po 70. sekundach.
Pozdrawiam.
Offline
W debianie zostało to załatane:
cryptsetup (2:1.7.3-2) unstable; urgency=medium
[ Jonas Meurer ]
* debian/initramfs/cryptroot-script: sleep after max passphrase attempts.
This mitigates local brute-force attacks and addresses CVE-2016-4484.
Thanks to Ismael Ripoll for discovery and report.
- decrease $count by one in tries loop if unlocking was successful.
- warn and sleep for 60 seconds if the maximum allowed attempts of
unlocking (configured with crypttab option tries, default=3) are
reached.
— Jonas Meurer <mejo@debian.org> Mon, 07 Nov 2016 11:34:41 +0100
Sprawdziłem i faktycznie po paru próbach wywala 60 sekundowy sleep. Zaraz jeszcze dam downgrade do poprzedniej wersji i sprawdzę czy to działało w ogóle. xD
___
Faktycznie da radę uzyskać shell z rootem ale nie da rady odszyfrować żadnej partycji. W efekcie nic po takim shellu. Jedynie co to można uszkodzić kontenery zapisując je i tylko o to chodzi w tym całym problemie. Także można spać spokojnie. xD
Offline
Serwus. Tak Morfik, naprawiono ową lukę, ale dotychczas, tylko w wersji unstable, prawda? Generalnie, problem dotyczy systemu Debian/Ubuntu, nie zapominając oczywiście o dystrybucjach pochodnych etc. Według szczegółowego opisu, systemy, które wykorzystują Dracut zamiast initramfs również są podatne, vide Fedora 24 x86_64. Wygląda również na to, że ww. problem jest szczególnie poważny w środowiskach takich jak; biblioteki, bankomaty, automaty na lotnisku etc., gdzie cały proces uruchamiania się systemu chroniony jest via hasło ustawione zarówno w BIOS'ie oraz GRUB'ie.
Pozdrawiam serdecznie.
EDYCJA: stylistyka etc.
Ostatnio edytowany przez remi (2016-11-16 18:10:19)
Offline