Разбиране на ключовете за защитата на Java - пясъчника и удостоверяване

Може би сте чували за последния недостатък в сигурността на JDK 1.1 и HotJava 1.0, който наскоро беше открит от екипа за защитено интернет програмиране в Принстънския университет (ръководен от един от авторите). Ако искате цялата история, прочетете нататък. Но в защитата на Java има нещо повече от подробностите за тази последна дупка в сигурността. Нека да разгледаме малко.

Сигурност на Java и обществено възприятие

Всички знаят, че сигурността е голяма работа за Java. Винаги, когато се открие дупка в сигурността, историята нахлува в компютърните новини (а понякога и в бизнес новините) много бързо. Може да не се изненадате да научите, че популярната преса следи comp.risks и други дискусионни групи, свързани със сигурността. Те избират истории за сигурност, за да подчертаят привидно на случаен принцип, въпреки че тъй като Java е толкова гореща в наши дни, те почти винаги отпечатват истории за защита на Java.

Проблемът е, че повечето новинарски истории въобще не обясняват добре дупките. Това може да доведе до класически проблем с „вълка на вълка“, при който хората се привикват да виждат „историята за сигурността тази седмица“ и не се обучават за реалните рискове от изпълнимото съдържание. Нещо повече, продавачите са склонни да омаловажават проблемите си със сигурността, като по този начин допълнително объркват ключовите проблеми.

Добрата новина е, че екипът за сигурност на JavaSoft сериозно се занимава с осигуряването на сигурност на Java. Лошата новина е, че по-голямата част от разработчиците и потребителите на Java могат да повярват на шумотевицата, произтичаща от събития като JavaOne, при които проблемите със сигурността не се излъчват много. Както казахме в нашата книга, Java Security: Враждебни аплети, дупки и антидоти, Sun Microsystems има много да спечели, ако ви кара да вярвате, че Java е напълно защитена. Вярно е, че доставчиците са се постарали да направят своите Java реализации възможно най-сигурни, но разработчиците не искат усилия; те искат резултати.

Тъй като уеб браузър с активиран Java позволява Java код да бъде вграден в уеб страница, изтеглен в мрежата и да се изпълнява на локална машина, сигурността е от решаващо значение. Потребителите могат да изтеглят Java аплети с изключителна лекота - понякога дори без да знаят. Това излага потребителите на Java на значителен риск.

Дизайнерите на Java са добре запознати с многото рискове, свързани с изпълнимото съдържание. За да се борят с тези рискове, те са проектирали Java специално с оглед на опасенията за сигурността. Основната цел беше да се обърне внимание на проблема със сигурността, така че наивните потребители (да речем, по-голямата част от милионите сърфисти в мрежата) да не се налага да стават експерти по сигурността, само за да преглеждат безопасно мрежата. Това е възхитителна цел.

Трите части на пясъчника на Java

Java е много мощен език за разработка. Недоверените аплети не трябва да имат достъп до цялата тази мощност. Пясъчникът на Java ограничава аплетите да извършват много дейности. Най-добрият технически документ за ограниченията на аплетите е "Ниско ниво на сигурност в Java" от Франк Йелин.

Сигурността на Java разчита на три зъба на защитата: верификатора на байт кода, Load Loader и Security Manager. Заедно тези три зъба извършват проверки за зареждане и време за изпълнение, за да ограничат достъпа до файловата система и мрежата, както и достъпа до вътрешните елементи на браузъра. Всеки от тези зъби зависи по някакъв начин от останалите. За да функционира правилно моделът на защита, всяка част трябва да си върши работата правилно.

Проверката на байтовия код :

Byte Code Verifier е първият зъб на модела за защита на Java. Когато се компилира Java програма за изход, тя се компилира до независим от платформата Java байт код. Байтовият код на Java е „проверен“, преди да може да се стартира. Тази схема за проверка има за цел да гарантира, че байтовият код, който може или не е създаден от Java компилатор, играе според правилата. В края на краищата байтовият код можеше да бъде създаден от „враждебен компилатор“, който сглоби байтов код, предназначен да срине виртуалната машина Java. Проверката на байтовия код на аплета е един от начините, при които Java автоматично проверява ненадежден външен код, преди да му бъде разрешено да се изпълнява.Проверяващият проверява байтовия код на няколко различни нива. Най-простият тест гарантира, че форматът на фрагмент от байтов код е правилен. На по-малко основно ниво към всеки фрагмент от код се прилага вградена теорема. Доказателят на теоремите помага да се уверим, че байт кодът не фалшифицира указатели, не нарушава ограниченията за достъп или обекти за достъп, използвайки неправилна информация за типа. Процесът на проверка, в съгласие с функциите за сигурност, вградени в езика чрез компилатора, помага да се установи основен набор от гаранции за сигурност.

Зареждащият клас на аплети :

Вторият зъб на защитата за защита е Java Applet Class Loader. Всички Java обекти принадлежат към класове. Устройството за зареждане на класове на аплети определя кога и как аплетът може да добавя класове към работеща Java среда. Част от работата му е да се увери, че важни части от средата за изпълнение на Java не са заменени от код, който аплетът се опитва да инсталира. Като цяло, работещата Java среда може да има активни много Load Loaders, като всеки определя своето „пространство от имена“. Пространствата с имена позволяват Java класовете да бъдат разделени на отделни "видове" според това откъде произхождат. Устройството за зареждане на класове аплети, което обикновено се доставя от доставчика на браузъра, зарежда всички аплети и класовете, към които те се позовават. Когато един аплет се зарежда в мрежата, Applet Class Loader получава двоичните данни и ги създава като нов клас.

Мениджърът по сигурността :

Третото зъбче на модела за защита на Java е Java Security Manager. Тази част от модела за сигурност ограничава начините, по които аплетът може да използва видими интерфейси. По този начин Security Manager реализира добра част от целия модел на защита. Мениджърът на сигурността е единичен модул, който може да извършва проверки по време на изпълнение на "опасни" методи. Кодът в библиотеката на Java се консултира с диспечера на сигурността, когато е на път да се направи опасна операция. Мениджърът на сигурността получава шанс да наложи вето върху операцията, като генерира изключение за сигурност (проклятието на разработчиците на Java навсякъде). Решенията, взети от Security Manager, вземат предвид кой Load Loader е заредил искащия клас. Вградените класове получават повече привилегии от класовете, които са заредени през мрежата.

Недоверен и изгонен в пясъчника

Заедно трите части на модела за сигурност на Java съставят пясъчника. Идеята е да се ограничи възможността на един аплет и да се увери, че играе според правилата. Идеята на пясъчника е привлекателна, защото има за цел да ви позволи да стартирате недоверен код на вашата машина, без да се притеснявате за това. По този начин можете да сърфирате в мрежата безнаказано, стартирайки всеки Java аплет, на който сте попаднали, без проблеми със сигурността. Е, стига пясъчникът на Java да няма дупки в сигурността.

Алтернатива на пясъчника:

Удостоверяване чрез подписване на код

ActiveX е друга високопрофилна форма на изпълнимо съдържание. Популяризиран от Microsoft, ActiveX е критикуван от специалисти по компютърна сигурност, които смятат, че подходът му към сигурността липсва. За разлика от ситуацията със защитата на Java, при която аплетът е ограничен от софтуерния контрол във видовете неща, които може да направи, ActiveX контролът няма ограничения в поведението си, след като бъде извикан. Резултатът е, че потребителите на ActiveX трябва да бъдат много внимателни, за да изпълняват само напълно надежден код. Потребителите на Java, от друга страна, имат лукса да пускат ненадежден код доста безопасно.

Подходът ActiveX разчита на цифрови подписи, един вид технология за криптиране, при която произволни двоични файлове могат да бъдат „подписани“ от разработчик или разпространител. Тъй като цифровият подпис има специални математически свойства, той е неотменим и незабравим. Това означава, че програма като вашия браузър може да провери подпис, което ви позволява да бъдете сигурни кой гарантира за кода. (Поне това е теорията. Нещата са малко по-двусмислени в реалния живот.) Още по-добре, можете да инструктирате браузъра си винаги да приема код, подписан от някоя страна, на която имате доверие, или винаги да отхвърля код, подписан от някоя страна, която вие не вярвай.

Дигиталният подпис съдържа много информация. Например, той може да ви каже, че въпреки че някои кодове се преразпределят от сайт, на който нямате доверие, той първоначално е написан от някой, на когото имате доверие. Или може да ви каже, че въпреки че кодът е написан и разпространен от някой, когото не познавате, вашият приятел е подписал кода, потвърждавайки, че е безопасен. Или може просто да ви каже кой от хилядите потребители на aol.com е написал кода.

(Вижте страничната лента за повече подробности относно цифровите подписи, включително пет ключови свойства.)

Бъдещето на изпълнимото съдържание: Напускане на пясъчника

Цифровите подписи правят ли ActiveX по-привлекателен по отношение на сигурността от Java? Ние вярваме, че не, особено в светлината на факта, че възможността за цифров подпис вече е налична в JDK 1.1.1 на Java (заедно с други подобрения в сигурността). Това означава, че в Java получавате всичко, което ActiveX прави за сигурност, плюс възможността да изпълнявате ненадежден код доста безопасно. Сигурността на Java ще бъде подобрена още по-далеч в бъдеще чрез гъвкав, фин контрол на достъпа, който според Ли Гонг, архитектът за защита на Java JavaSoft, се планира да бъде пуснат в JDK 1.2. По-добрият контрол на достъпа също ще проникне в следващия кръг браузъри, включително Netscape Communicator и MicroSoft Internet Explorer 4.0.

В съгласие с контрола на достъпа, подписването на код ще позволи на аплетите да излизат постепенно извън пясъчника за сигурност. Например, на аплет, предназначен за използване в настройка на интранет, може да бъде позволено да чете и пише в определена база данни на компанията, стига да е подписан от системния администратор. Подобна релаксация на модела за сигурност е важна за разработчиците, които се опитват да направят повече от своите аплети. Писането на код, който работи в строгите ограничения на пясъчника, е мъка. Оригиналната пясъчник е много ограничителна.

В крайна сметка на аплетите ще бъдат разрешени различни нива на доверие. Тъй като това изисква контрол на достъпа, понастоящем нюансите на доверие не са налични, въпреки че подписването на кода е. Както е в момента в JDK 1.1.1, Java аплетите са или напълно надеждни, или напълно ненадеждни. Подписан аплет, маркиран като доверен, има право да избяга напълно от пясъчника. Такъв аплет може да направи всичко и изобщо няма ограничения за сигурност.

Основният проблем с подхода на Java към сигурността е, че той е сложен. Сложните системи обикновено имат повече недостатъци от обикновените системи. Изследователите по сигурността, най-вече екипът по програмиране за сигурно интернет програми в Принстън, откриха няколко сериозни недостатъка в сигурността в ранните версии на пясъчника. Много от тези недостатъци бяха грешки при внедряването, но някои бяха грешки в спецификацията. За щастие JavaSoft, Netscape и Microsoft много бързо са отстранили подобни проблеми, когато бъдат открити. (Ясни и пълни обяснения на дупките в сигурността на Java можете да намерите в Глава 3 на нашата книга.)

Съвсем наскоро търговците на Sun (понякога наричани евангелисти) побързаха да отбележат, че не са открити нови недостатъци от доста време. Те приеха това като доказателство, че Java никога повече няма да страда от проблеми със сигурността. Те скочиха с пистолета.

Дупката за подписване на код: Java одира коляното си

Подписването на кода е сложно. Както в оригиналния модел на пясъчник, има достатъчно място за грешки при проектирането и внедряването на система за подписване на код. Скорошната дупка беше доста ясен проблем при внедряването на Classкласа на Java , както беше обяснено както на сайта на Принстън, така и на сайта за защита на JavaSoft. По-конкретно, методът Class.getsigners()връща изменяем масив от всички подписали, известни на системата. Възможно е аплет да използва неправилно тази информация. Поправката беше толкова проста, колкото връщането само на копие на масива, а не на самия масив.

Помислете за ситуация, при която разработчикът Алис не е получил никакви привилегии за сигурност в системата на уеб потребител. Всъщност, за разлика от твърдението на оригиналния JavaSoft за грешката, Алис може да бъде напълно непозната за системата. С други думи, на кода, подписан от Алиса, не се вярва повече от обичайния аплет извън улицата. Ако уеб потребителят (използващ браузъра HotJava - в момента единственият търговски продукт, който поддържа JDK 1.1.1) зареди аплет, подписан от Алиса, този аплет все още може да излезе от пясъчника, като използва дупката.

Фактът, че системата не трябва да има публичен ключ на Алиса в своята база данни, е важен. Това означава, че Алис може да бъде всеки произволен нападател, който знае как да подпише аплет с напълно произволна идентичност. Създаването на такава идентичност е лесно, както и подписването на аплет с тази самоличност. Това прави дупката наистина много сериозна.

Дупката позволява на атакуващия аплет на Алиса да промени представата на системата за това кой го е подписал. Това е особено лошо, ако на Алис не е предоставена привилегия да работи извън пясъчника, но на Боб е. Аплетът на Алис може да използва getsigners()повикването, за да промени нивото си на разрешение, за да включи всички привилегии на Боб. Аплетът на Алис може да получи максималния размер на наличните привилегии, раздадени на всеки подписващ, известен на системата.

Ако оприличите самоличността на подписите / привилегиите на палта в килера, аплетът за атака на Алиса може да опита върху всеки слой и да опита различни забранени неща, докато не открие кои от палтата са „магически“ и му позволи да получи привилегия. Ако бъде открито вълшебно палто, аплетът на Алиса може да излезе от пясъчника и да направи неща, които не бива да му се позволява. Изпробването на палта е толкова просто, колкото опит за забранено обаждане и гледане какво се случва.