За семью замками. Обзор security-новшеств Android 5.0

Историческая справка

Для Google безопас­ность Android всег­да игра­ла далеко не пос­леднюю роль. С самых пер­вых вер­сий Android был снаб­жен набором мощ­ных средств защиты, сре­ди которых мож­но отме­тить сан­дбок­синг при­ложе­ний, сис­тему раз­гра­ниче­ния пол­номочий, еди­ный RPC-механизм для всех при­ложе­ний и сис­темы (Binder), язык прог­рамми­рова­ния с про­вер­кой гра­ниц буферов, кон­тро­лиру­емую сре­ду исполне­ния (dalvik) и, конеч­но же, пов­семес­тное исполь­зование циф­ровых под­писей (в том чис­ле для исполня­емо­го кода).

С каж­дым новым релизом механиз­мы безопас­ности дораба­тыва­лись и рас­ширялись. Сна­чала Google занялась проб­лемами перепол­нения буфера и интегри­рова­ла наработ­ки про­екта OpenBSD в свою сис­темную биб­лиоте­ку Bionic (реали­зации фун­кций dmalloc и calloc, Android 1.5), затем добави­ла под­дер­жку бита No eXecute (NX) в 2.3, модифи­циро­вала сис­тему сбор­ки исходни­ков для под­дер­жки опций ком­пилято­ра -fstack-protector и Wformat-security -Werror=format-security (защита от сры­ва сте­ка и оши­бок фор­матиро­вания строк).

В вер­сии 3.0 появи­лась встро­енная фун­кция шиф­рования всех поль­зователь­ских дан­ных, осно­ван­ная на про­верен­ном годами и сот­нями тысяч поль­зовате­лей модуле Linux-ядра dm-crypt. В Android 4.0 — так дав­но ожи­даемый в кор­поратив­ном сек­торе API KeyChain, поз­воля­ющий уста­нав­ливать в сис­тему и исполь­зовать сто­рон­ние циф­ровые сер­тифика­ты. В 4.1 была интегри­рова­на фун­кция шиф­рования уста­нов­ленных при­ложе­ний (в пер­вую оче­редь для защиты от копиро­вания) и под­дер­жка хар­двар­ного шиф­рования с помощью HAL-биб­лиоте­ки keymaster (в зависи­мос­ти от про­изво­дите­ля она может исполь­зовать тот или иной механизм шиф­рования, нап­ример M-Shield в чипах серии OMAP4, на котором базиро­вал­ся Galaxy Nexus).

В фев­рале 2012 года Google перек­лючилась на борь­бу с вируса­ми и соз­дала сер­вис онлайн‑про­вер­ки при­ложе­ний Bouncer, который запус­кал каж­дое пуб­лику­емое в Google Play при­ложе­ние в эму­лято­ре и про­гонял через мно­гочис­ленные тес­ты, выяв­ляя подоз­ритель­ное поведе­ние. В нояб­ре того же года был запущен сер­вис онлайн‑про­вер­ки соф­та на вирусы пря­мо на устрой­стве поль­зовате­ля. Изна­чаль­но он работал толь­ко на 4.2, но к июлю 2013-го был интегри­рован в пакет Google Services и стал дос­тупен для всех устрой­ств от 2.3 и выше. Начиная с апре­ля 2014-го про­вер­ка выпол­няет­ся не толь­ко на эта­пе уста­нов­ки при­ложе­ния, но и пери­оди­чес­ки для все­го уста­нов­ленно­го соф­та. Для борь­бы с SMS-тро­яна­ми в Android 4.2 была интегри­рова­на фун­кция при­нуди­тель­ного под­твержде­ния отправ­ки СМС на корот­кие номера.

Дру­гим нов­шес­твом Android 4.2 ста­ла интегра­ция в ОС под­систе­мы ман­датно­го кон­тро­ля дос­тупа SELinux, которая изна­чаль­но работа­ла исклю­читель­но в «раз­реша­ющем режиме» (permissive mode), а в 4.4 была переве­дена в режим enforcing, но с исполь­зовани­ем все­го нес­коль­ких кон­тек­стов безопас­ности для низ­коуров­невых ком­понен­тов сис­темы, что не слиш­ком повыша­ло защищен­ность. В качес­тве допол­нитель­ной меры в 4.3 был зап­рещен запуск SETUID-бинар­ников из катало­га /system и задей­ство­вана сис­тема пол­номочий (capabilities) ядра Linux для сис­темных ком­понен­тов.

В целом за шесть лет раз­вития Android Google про­дела­ла серь­езную работу по улуч­шению общей безопас­ности сис­темы, не ска­тив­шись при этом до уров­ня Apple с ее методом тоталь­ной бло­киров­ки все­го и вся. Опе­раци­онка оста­лась гиб­кой, пол­ностью под­чинен­ной поль­зовате­лю, но при этом дос­таточ­но безопас­ной для того, что­бы не воз­никало необ­ходимос­ти уста­нов­ки анти­виру­сов и «вклю­чения режима парано­ика».

Тем не менее ока­залось, что пла­ны Google прос­тира­ются гораз­до даль­ше того, что уже сде­лано. Android 5.0 вклю­чает в себя столь­ко security specific нов­шеств, что даль­ше, кажет­ся, уже некуда. Но нач­нем с двух глав­ных геро­ев новос­тей: шиф­рования, которое зас­тавля­ет девай­сы тор­мозить пос­ле обновле­ния до 5.0, и SELinux, который лома­ет root.

Шифрование по умолчанию

В оче­ред­ной раз сле­дуя нога в ногу за Apple, «кор­порация доб­ра» внед­ряет в Android фун­кци­ональ­ность, которая сов­сем недав­но появи­лась в iOS. На этот раз речь идет о шиф­ровании све­жекуп­ленно­го устрой­ства — начиная с Lollipop, все поль­зователь­ские нас­трой­ки и дан­ные в катало­ге /data, а вмес­те с ними и внут­ренняя (эму­лиру­емая) кар­та памяти будут шиф­ровать­ся в режиме реаль­ного вре­мени без ведома поль­зовате­ля.

На прак­тике это озна­чает толь­ко то, что та самая фун­кция шиф­рования из 3.0 теперь будет вклю­чена по умол­чанию, но с дву­мя важ­ными ого­вор­ками:

• для защиты клю­ча шиф­рования (Master Key) будет исполь­зован слу­чай­но сге­нери­рован­ный ключ вмес­то клю­ча, получен­ного из PIN-кода экра­на бло­киров­ки;
• этот слу­чай­ный ключ (Key Encryption Key, KEK) теперь может хра­нить­ся в области памяти, защищен­ной с помощью реали­зован­ного в про­цес­соре механиз­ма Trusted Execution Environment (TEE), такого, нап­ример, как Qualcomm Secure Execution Environment.

Дру­гими сло­вами, воз­можность рас­шифров­ки дан­ных теперь дос­тупна толь­ко одно­му неболь­шому ком­понен­ту ОС, а имен­но HAL-биб­лиоте­ке masterkey, работа­ющей с TEE. Ни поль­зователь, ни дру­гие час­ти сис­темы не смо­гут получить ключ шиф­рования в ее обход, так же как это не получит­ся сде­лать челове­ку, который попыта­ется снять дамп памяти нап­рямую с чипов NAND.

С дру­гой сто­роны, шиф­рование никак не защитит устрой­ство в том слу­чае, если юзер не уста­новит на экран бло­киров­ки PIN-код или не вос­поль­зует­ся фун­кци­ей Smart Lock (о ней мы погово­рим поз­же). Поэто­му заяв­ления Google о том, что они сде­лали апри­ори секь­юрную опе­раци­онку, которая не пот­ребу­ет лиш­них телод­вижений от поль­зовате­ля, как минимум лукавс­тво.

Во всем осталь­ном реали­зация шиф­рования оста­лась на преж­нем уров­не. Это поб­лочное шиф­рование раз­дела /data с помощью модуля dm-crypt и алго­рит­ма AES-128 в режиме CBC с задей­ство­вани­ем фун­кции ESSIV:SHA256 для получе­ния век­торов ини­циали­зации (IV). Сам ключ шиф­рования защищен с помощью KEK-клю­ча, который может быть или получен из PIN-кода с помощью про­гон­ки через фун­кцию script, или сге­нери­рован слу­чай­ным обра­зом и сох­ранен в TEE. При этом, если юзер купит смар­тфон на базе Android 5.0 с акти­виро­ван­ным по умол­чанию шиф­ровани­ем и затем уста­новит PIN-код, пос­ледний так­же будет исполь­зован для генера­ции KEK.

Фун­кция script для получе­ния клю­ча из PIN-кода исполь­зует­ся начиная с Android 4.4 и заменя­ет при­меняв­ший­ся ранее алго­ритм PBKDF2. Пос­ледний ока­зал­ся уяз­вимым для под­бора на GPU (6-знач­ный циф­ровой PIN за 10 с, 6-знач­ный зна­ковый — 4 ч с помощью hashcat), тог­да как script, по заяв­лению соз­дателей, уве­личи­вает вре­мя под­бора при­мер­но в 20 000 раз и вооб­ще не под­ходит для GPU по при­чине высоких тре­бова­ний к памяти.

В зак­лючение хочу ска­зать, что шиф­рование будет акти­виро­вано толь­ко для устрой­ств, изна­чаль­но осно­ван­ных на Android 5.0. Уже сущес­тву­ющие девай­сы, получив­шие обновле­ние по воз­духу, оста­нут­ся незашиф­рован­ными.

SEAndroid

Тех­нология SELinux, раз­работан­ная Агентством наци­ональ­ной безопас­ности США, уже дав­но исполь­зует­ся во мно­гих кор­поратив­ных и нас­толь­ных дис­три­бути­вах для защиты от самых раз­ных видов атак. Одно из основных при­мене­ний SELinux — это огра­ниче­ние при­ложе­ниям дос­тупа к ресур­сам ОС и дан­ным дру­гих при­ложе­ний. С помощью SELinux мож­но, нап­ример, сде­лать так, что­бы сер­вер Apache имел дос­туп толь­ко к опре­делен­ным фай­лам и диапа­зону пор­тов, не мог запус­кать бинар­ники помимо заранее ого­ворен­ных и имел огра­ничен­ный дос­туп к сис­темным вызовам. По сути, SELinux запира­ет при­ложе­ние в песоч­ницу, серь­езно огра­ничи­вая воз­можнос­ти того, кто смо­жет его взло­мать.

Вско­ре пос­ле появ­ления на свет Android раз­работ­чики SELinux начали про­ект SEAndroid с целью перенес­ти сис­тему в мобиль­ную опе­раци­онку и раз­работать ряд SELinux-пра­вил для защиты ее ком­понен­тов. Начиная с вер­сии 4.2, наработ­ки это­го про­екта вхо­дят в сос­тав Android, но на пер­вых порах (вер­сия 4.2–4.3) исполь­зуют­ся исклю­читель­но для сбо­ра информа­ции о поведе­нии ком­понен­тов сис­темы (с целью пос­леду­юще­го сос­тавле­ния пра­вил). В вер­сии 4.4 Google переве­ла сис­тему в активный режим, но с мяг­кими огра­ниче­ниями для нес­коль­ких сис­темных демонов (installd, netd, vold и zygote). На пол­ную же катуш­ку SELinux зарабо­тал толь­ко в 5.0.

В Android 5.0 пре­дус­мотре­но более 60 доменов SELinux (про­ще говоря — пра­вил огра­ниче­ний) поч­ти для каж­дого сис­темно­го ком­понен­та, начиная от пер­вично­го про­цес­са init и закан­чивая поль­зователь­ски­ми при­ложе­ниями. На прак­тике это озна­чает, что мно­гие век­торы атак на Android, которые в прош­лом исполь­зовались как самими юзе­рами для получе­ния root, так и раз­ного рода мал­варью, более не акту­аль­ны.

Так, уяз­вимость CVE-2011-1823, имев­шая мес­то во всех вер­сиях Android до 2.3.4 и поз­воля­ющая выз­вать memory corruption в демоне vold, а далее передать управле­ние шел­лу с пра­вами root (экс­плойт Gingerbreak), не мог­ла бы быть исполь­зована, будь она най­дена в 5.0 — здесь, сог­ласно пра­вилам SELinux, vold не име­ет пра­ва запус­кать дру­гие бинар­ники. То же самое спра­вед­ливо и в отно­шении уяз­вимос­ти CVE-2014-3100 в Android 4.3, поз­воля­ющей выз­вать перепол­нение буфера в демоне keystore, и 70% дру­гих уяз­вимос­тей.

SELinux зна­читель­но сни­жает риск того, что устрой­ством зав­ладе­ют через экс­плу­ата­цию уяз­вимос­тей в низ­коуров­невых ком­понен­тах сис­темы (мно­гочис­ленных написан­ных на С и С++ демонах, исполня­емых от име­ни root), но в то же вре­мя зат­рудня­ет получе­ние root, так ска­зать, «для себя». Более того, отны­не пра­ва root сами по себе не гаран­тиру­ют пол­ного кон­тро­ля над сис­темой, так как для SELinux нет раз­ницы меж­ду обыч­ным юзе­ром и супер­поль­зовате­лем.

К счастью, это огра­ниче­ние доволь­но лег­ко обой­ти, если зас­тавить при­ложе­ния с под­дер­жкой root выпол­нять при­виле­гиро­ван­ные дей­ствия в неог­раничен­ном SELinux-кон­тек­сте init. Такая фун­кци­ональ­ность реали­зова­на в SuperSU начиная с вер­сии 2.23 (пос­редс­твом прок­си, который запус­кает­ся на ран­нем эта­пе заг­рузки, работа­ет кон­тек­сте init и исполня­ет коман­ды, при­нятые от бинар­ника su). Одна­ко для его уста­нов­ки нужен кас­томный recovery, который, в свою оче­редь, может быть уста­нов­лен либо пос­ле «получе­ния пол­ноцен­ного root» на устрой­стве (проб­лема курицы и яйца), либо пос­ле раз­бло­киров­ки заг­рузчи­ка.

Так­же сто­ит иметь в виду, что SELinux не обя­затель­но будет вклю­чен в тво­ем устрой­стве, тем более если речь идет о девай­се, который изна­чаль­но пос­тавлял­ся с более ран­ней вер­сией Android.

Гостевой режим

Мно­гополь­зователь­ский режим в Android появил­ся еще в вер­сии 4.2, но на про­тяже­нии раз­вития чет­вертой вет­ки ОС оста­вал­ся дос­тупен толь­ко для план­шетов (с воз­можностью вклю­чения на смар­тфо­не с помощью хаков, нап­ример при­ложе­ния 4.2 Multiple User Enabler). В 4.3 в его реали­зации появи­лась фун­кция огра­ниче­ния юзе­ров в пол­номочи­ях, что мож­но было исполь­зовать для зап­рета звон­ков, СМС и дру­гих воз­можнос­тей девай­са.

В Lollipop мно­гополь­зователь­ский режим рас­простра­нил­ся так­же и на смар­тфо­ны, при­чем с нес­коль­кими весь­ма инте­рес­ными доработ­ками. Пер­вая из них — это так называ­емый гос­тевой режим, спе­циаль­ный поль­зователь­ский про­филь, который само­унич­тожа­ется пос­ле воз­вра­щения к основно­му или любому дру­гому про­филю. По сути, это быс­трый и прос­той спо­соб получить дос­туп к чис­той ОС, нап­ример для того, что­бы «дать поз­вонить» или про­вес­ти экспе­римент.

Вто­рое нов­шес­тво — это screen pinning, фун­кция, не отно­сяща­яся нап­рямую к мно­гополь­зователь­ско­му режиму, но прес­леду­ющая ту же цель. Она поз­воля­ет заб­локиро­вать экран на одном при­ложе­нии без воз­можнос­ти получить дос­туп к домаш­нему экра­ну, «штор­ке» и дру­гой фун­кци­ональ­нос­ти ОС. Фун­кция акти­виру­ется в раз­деле «Безопас­ность» в нас­трой­ках, далее необ­ходимо запус­тить нуж­ное при­ложе­ние, нажать кноп­ку перек­лючения меж­ду при­ложе­ниями и тап­нуть по знач­ку в ниж­ней пра­вой час­ти превью.

Для выхода из режима screen pinning дос­таточ­но одну‑две секун­ды удер­живать ту же кноп­ку перек­лючения меж­ду при­ложе­ниями. Одна­ко устрой­ство мож­но защитить, если уста­новить PIN-код или гра­фичес­кий ключ на экран бло­киров­ки и отме­тить соот­ветс­тву­ющую галоч­ку при зак­репле­нии при­ложе­ния на экра­не. В этом слу­чае юзер не смо­жет получить дос­туп к ОС без вво­да PIN’а или клю­ча.

Спра­вед­ливос­ти ради сто­ит отме­тить, что подоб­ная фун­кци­ональ­ность, вклю­чая гос­тевые акка­унты и бло­киров­ку на при­ложе­нии, уже сущес­тво­вали во мно­гих дос­тупных в мар­кете при­ложе­ниях, одна­ко 99% из них исполь­зовали кон­цепцию «рабочий стол внут­ри при­ложе­ния», то есть, по сути, вооб­ще не изо­лиро­вали поль­зователь­ские акка­унты от основной сис­темы. Более прод­винутая тех­нология вхо­дит в сос­тав сис­темы безопас­ности Samsung Knox. Она поз­воля­ет запус­тить чис­тую ОС рядом с основной и пол­ностью отре­зать сис­темы друг от дру­га, но дос­тупна толь­ко в смар­тфо­нах и план­шетах соот­ветс­тву­ющей мар­ки.

Smart Lock

Поль­зовате­ли не любят PIN-коды и гра­фичес­кие клю­чи, и Google отлично это понима­ет. Поэто­му еще одним нов­шес­твом 5.0 ста­ла фун­кция Smart Lock, поз­воля­ющая сох­ранить безопас­ность смар­тфо­на и дан­ных, не утом­ляя себя вво­дом цифр или рисова­нием на экра­не слож­ных иерог­лифов. Это еще один шаг Google в сто­рону «защищен­ного по умол­чанию смар­тфо­на», о котором мы говори­ли в раз­деле про шиф­рование.

Од­нако в этот раз все нам­ного про­ще. Smart Lock — это не что иное, как воз­можность авто­мати­чес­кого отклю­чения защиты экра­на бло­киров­ки пос­ле под­клю­чения к одно­му из Bluetooth-устрой­ств (умные часы, авто­маг­нитола, TV Box), касания смар­тфо­ном NFC-мет­ки или на осно­ве мес­тополо­жения. Фак­тичес­ки это офи­циаль­ная реали­зация фун­кций, которые уже нес­коль­ко лет дос­тупны в сто­рон­них при­ложе­ниях, про­шив­ках от про­изво­дите­лей (моторо­лов­ский Trusted Bluetooth, нап­ример), Tasker, при­ложе­ниях для Pebble и дру­гих умных часов (при­ложе­ние SWApp Link).

Те­перь фун­кци­ональ­ность этих при­ложе­ний дос­тупна в самой про­шив­ке, а все, что оста­ется сде­лать юзе­ру, — это уста­новить на экран бло­киров­ки PIN-код или ключ, акти­виро­вать Smart Lock в нас­трой­ках безопас­ности (раз­дел Trusted Agents) и добавить доверен­ные Bluetooth-устрой­ства, NFC-теги или мес­та.

Фун­кция раз­бло­киров­ки по сним­ку лица теперь тоже часть Smart Lock. При­чем отны­не она не толь­ко вклю­чает­ся на экра­не бло­киров­ки, но и пос­тоян­но сле­дит за юзе­ром и бло­киру­ет устрой­ство, если лицо изме­нилось. Дру­гими сло­вами, сто­ит вору, вых­ватив­шему смар­тфон из рук вла­дель­ца, взгля­нуть на экран, как смар­тфон сра­зу заб­локиру­ется.

Обновляемый WebView

С пер­вых вер­сий Android вклю­чал в себя ком­понент WebView на базе WebKit, поз­воля­ющий сто­рон­ним при­ложе­ниям исполь­зовать HTML/JS-дви­жок для отоб­ражения кон­тента. На нем же базиро­валось боль­шинс­тво сто­рон­них бра­узе­ров. В KitKat WebView был серь­езно модер­низиро­ван и заменен на дви­жок из про­екта Chromium (вер­сии 33 в Android 4.4.3), что поз­волило раз­работ­чикам получить дос­туп к пос­ледним наработ­кам Google в области отоб­ражения веб‑кон­тента.

На­чиная с Lollipop, WebView не прос­то базиру­ется на Chromium, но и уме­ет обновлять­ся через Google Play (в авто­мати­чес­ком режиме, незамет­но для юзе­ра). Это зна­чит, что незави­симо от исполь­зуемой вер­сии Android раз­работ­чики при­ложе­ний теперь всег­да будут иметь дело с пос­ледней вер­сией HTML/JS-движ­ка, вклю­чающей все пос­ледние новов­ведения. Но что более важ­но, Google теперь смо­жет зак­рывать уяз­вимос­ти в движ­ке так же быс­тро, как уяз­вимос­ти в Google Chrome для Android. Все, что пот­ребу­ется от юзе­ра, — это под­клю­чен­ный к интерне­ту смар­тфон с Android 5.0 или выше.

Kill Switch

В августе 2013 года Google запус­тила веб‑сер­вис Android Device Manager, с помощью которо­го мы получи­ли воз­можность сбро­са до завод­ских нас­тро­ек или уда­лен­ной бло­киров­ки смар­тфо­на. В качес­тве кли­ент­ской час­ти на смар­тфо­не сер­вис исполь­зовал обновля­емый через Google Play ком­понент Google Services, поэто­му фун­кция ста­ла дос­тупна для любых устрой­ств, начиная с Android 2.3.

На­чиная с Android 5.0, сер­вис так­же вклю­чает в себя фун­кцию Factory Reset Protection. Пос­ле ее акти­вации воз­можность сбро­са до завод­ских нас­тро­ек будет заб­локиро­вана паролем, что, по мне­нию Google, будет пре­пятс­тво­вать пол­ноцен­ному исполь­зованию смар­тфо­на или его про­даже. Ведь однажды при­вязан­ный к акка­унту Google смар­тфон уже не может быть отвя­зан без сбро­са нас­тро­ек.

Все логич­но, но фун­кция боль­ше напоми­нает игрушку, чем серь­езный метод борь­бы с кра­жами. В кон­це кон­цов, раз­бло­киров­ка заг­рузчи­ка и пра­ва root решат все воп­росы воз­вра­щения смар­тфо­на к завод­ско­му сос­тоянию.

Другие улучшения

• Ин­тегра­ция с ChromeOS. Брат­ская ОС уже научи­лась получать уве­дом­ления от Android и запус­кать Android-при­ложе­ния, а теперь она уме­ет авто­мати­чес­ки впус­кать юзе­ра, если рядом находит­ся его телефон (эта­кий Smart Lock наобо­рот).
• Улуч­шения в под­дер­жке HTTPS и TLS/SSL. В Android 5.0 теперь вклю­чена под­дер­жка TLSv1.1 и TLSv1.2. При сог­ласова­нии клю­чей по воз­можнос­ти исполь­зует­ся опция Forward Secrecy. Добав­лена под­дер­жка алго­рит­ма AES-GCM, а ущер­бные в пла­не безопас­ности алго­рит­мы шиф­рования/хеширо­вания (MD5, 3DES) отклю­чены.
• PIE вез­де. Android теперь явно тре­бует, что­бы все натив­ные бинар­ники были ском­пилиро­ваны с под­дер­жкой PIE (Position-Independent Executables).
• Рас­ширен­ная под­дер­жка FORTIFY_SOURCE. Такие фун­кции, как stpcpy(), stpncpy(), read(), recvfrom(), FD_CLR(), FD_SET() и FD_ISSET(), теперь так­же защище­ны с помощью механиз­ма FORTIFY_SOURCE ком­пилято­ра GCC (защита от сры­ва сте­ка). Началь­ная под­дер­жка FORTIFY_SOURCE появи­лась еще в Android 4.2.

Вместо выводов

Google не толь­ко сде­лала Android 5.0 таким, каким его хотят видеть поль­зовате­ли и про­изво­дите­ли смар­тфо­нов, но и при­ложи­ла все уси­лия для того, что­бы решить две основные проб­лемы безопас­ности: убе­речь смар­тфон от пос­торон­них глаз и защитить от уяз­вимос­ти к ата­кам, нап­равлен­ным на получе­ние прав root. Эффектив­ны ли эти улуч­шения, покажет вре­мя, но уже сей­час мож­но точ­но ска­зать, что Lollipop — это самая защищен­ная вер­сия Android из всех.