1. Безпека комп'ютера багато в чому залежить від досконалості встановленої на ньому операційної системи....
2. АРХІТЕКТУРНІ КОНЦЕПЦІЇ
3. зведена ТАБЛИЦЯ

Безпека комп'ютера багато в чому залежить від досконалості встановленої на ньому операційної системи. Максимально досяжна захищеність вузла як такого ніколи не перевершує ступеня захищеності самої ОС.

Oтнюдь не тільки консерватори вважають, що поширення електронно-обчислювальних машин привнесло більше проблем, ніж їх вирішило. Людство ні морально, ні етично, ні психологічно виявилося не готове до що відкрилися, і комп'ютерні технології часто виявляються в руках людей, чиї устремління спрямовані лише на руйнування. Якщо до появи Internet вірусна загроза в основному зводилася до проблеми «брудних рук» і безладного копіювання ПО, то тепер ситуація суттєво змінилася, про що свідчить, зокрема, недавня епідемія Helkern.

Здавалося б, користувачеві досить просто взяти найбільш захищену з представлених на ринку ОС. Однак як дізнатися, яку саме? Подібного тестування ще ніхто не проводив, та й навряд чи воно взагалі можливо. Доступний матеріал носить суб'єктивний і поверхневий характер і спирається у своїх оцінках на непринципові недоліки конкретних реалізацій ОС, велика частина яких давним-давно виправлена ​​з появою чергової латки.

До того ж дуже важко вибрати адекватні критерії захищеності - кількість зафіксованих зломів ОС і виявлених «дірок» саме по собі ще ні про що не говорить: по-перше, точної статистики немає і не може бути в принципі (по-справжньому успішні зломи, як правило, не реєструються і не афішуються), а по-друге, дані такого роду відображають не захищеність, а поширеність тих чи інших систем і інтерес до них з боку хакерів (попросту кажучи, моду).

Тому ми вирішили абстрагуватися від особливостей конкретних реалізацій і порівняти потенційну концептуальну вразливість операційних систем сімейств NT і UNIX. (Щоб уникнути багатослів'я під «NT», якщо тільки явно не зазначено інше, тут і далі буде матися на увазі все NT-подібні системи: сама Windows NT, Windows 2000 і Windows XP.) Що таке «потенційна концептуальна вразливість»? Це властивість архітектури системи, яке за певних обставин може призвести до зниження ступеня її захищеності, причому воно настільки тісно пов'язане з системою, що без серйозного «хірургічного» втручання в архітектуру ядра його не змінити. Зокрема, за інших рівних умов менш складна система вважається більш захищеною і, відповідно, навпаки.

Звичайно, багато що залежить від професіоналізму розробників, якості перевірки і т. Д. Однак всі ці обставини практично не піддаються об'єктивному обліку, тому краще їх взагалі виключити з розгляду, ніж враховувати неправильно (той факт, що Linux тестують мільйони людей по всьому світу, мало що змінює - адже вся справа в тому, наскільки професійно проводиться тестування).

ФІЛОСОФСЬКІ КОНЦЕПЦІЇ

Відкритий код проти дизассемблера. За визначенням Іллі Медведовского, атака на комп'ютерну систему - це дії, що робляться зловмисником, яке полягає в пошуку і використанні тієї або іншої уразливості. Методик пошуку вразливостей існує безліч, але нас цікавлять не конкретні реалізації, а принципові підходи. Всі методики можна розділити на дві полярні категорії - сліпий і цілеспрямований пошук.

Перший розглядає механізм захисту як чорний ящик з входом і виходом. Планомірно перебираючи всілякі вхідні значення, зловмисник намагається виявити ті з них, введення яких порушив би нормальну роботу захисного механізму або послабив би ступінь захисту. Ця надзвичайно проста і інтелектуально невибаглива стратегія злому вельми популярна в колах початківців хакерів. Втім, після ... дцять за рахунком спроби терпіння вичерпується, і ейфорія раптово проходить. Звичайно, час від часу деяким особливо везучим щасливчикам все-таки вдається проникнути то в одну, то в іншу захищену систему, але особливої ​​небезпеки такі атаки, як правило, не представляють.

Будь цілеспрямований злом починається з вивчення атакується об'єкта. Захисний же механізм, принцип дії якого невідомий, може бути зламаний тільки грубою силою. Отже, за інших рівних умов міцність оборони обернено пропорційна легкості аналізу коду системи, що визначається в першу чергу доступністю вихідних текстів захисного механізму!

Більшість систем UNIX поставляється разом з вихідними текстами, в той час як вихідні тексти NT невідомі, а аналіз дізассемблерних лістингів не тільки надзвичайно трудомісткий і стомлює сам по собі, але ще і вимагає неабиякої професійної підготовки, якої можуть похвалитися далеко не всі. Додамо, що підсистема захисту NT значно складніше аналогічної підсистеми багатьох систем UNIX і вельми поверхнево документована, ніж та відлякує багатьох потенційних зловмисників.

Як наслідок, кількість вразливостей, виявлених в NT за весь час її існування (причому найчастіше випадково), можна перерахувати по пальцях. В UNIX ж, навпаки, «дірки» виявляються постійно. З іншого боку...

Малотиражні проти багатотиражних. ... з іншого боку, ступінь небезпеки «дірки» залежить не стільки від її «лінійних розмірів», скільки від поширеності операційної системи. Завдяки величезній кількості клонів, UNIX в цьому відношенні виявляється в досить виграшному положенні (з точки зору безпеки). До того ж постійно листуємося, та й просто альтернативні, ядра навіть одну-єдину систему розмножують до цілого сімейства, завдяки чому уразливість, виявлена ​​в одній версії ядра, часто недійсна для всіх інших.

В результаті хакер, який знайшов «дірку» в UNIX, потенційно здатний нанести набагато меншої шкоди, ніж якби помилка аналогічного характеру була виявлена ​​в NT (через нечисленність своїх різновидів кожна окремо взята версія NT встановлена ​​на значно більшій кількості машин, ніж UNIX). Саме тому NT все-таки зламують або, у всякому разі, намагаються це зробити. Спокуса настільки великий, що хакерів не зупиняють ні відсутність вихідних текстів, ні трудомісткість аналізу. До того ж ядро ​​NT перестав переписується щодня, і практично всі незахищені місця, виявлені в NT 4.0, залишаються актуальними і в Windows 2000, а то і в Windows XP. (Детальніше про це розповідається в книзі Кріса Касперски «Техніка мережних атак».)

Навпаки, якщо якась операційна система встановлена ​​на лічених комп'ютерах, то навряд чи хто-небудь стане витрачати сили на злом лише з любові до мистецтва без вагомого стимулу для її вивчення. Мало поширені операційні системи практично повністю залишаються без уваги з боку фахівців з інформаційної безпеки, внаслідок чого часто містять велику кількість тривіальних і легко виявляються помилок. Проте встановлення такої системи автоматично відсікає велику армію «хакерів» - тих, хто користується для атак чужими експлойтів. А щоб уберегтися від дій професіонала, необхідно створити другий рівень захисту - вузол з перевіреною часом і ретельно випробуваною фахівцями операційною системою.

До речі, непогана ідея: на передній план оборони відрізати який-небудь «рідкоземельні» клон UNIX, а на наступний - NT. Більшість хакерів, як показує практика, спеціалізуються на одній операційній системі і лише у виняткових випадках - на двох відразу.

Складність коду. Трудомісткість налагодження та тестування комп'ютерних програм стрімко зростає зі збільшенням їх складності. Починаючи з деякого рівня, витрати на ретельну доведення програми поступово переважують сукупний дохід від її продажу, через що розробники змушені обмежитися лише поверхневим тестуванням (якщо програма не зупинилася під час запуску, то це вже добре).

Сучасні операційні системи давним-давно минули подібний рубіж, і ніяка з них не застрахована від помилок. З імовірністю, близькою до одиниці, можна стверджувати, що критичні помилки присутні в кожній ОС загального призначення, і тому будь-який вузол в мережі може бути зламаний - це всього лише питання часу і зусиль.

Тим часом помилки вкрай неоднорідні за своєю природою: одні, що називається, лежать на поверхні і виявляються навіть автоматизованими засобами контролю якості коду; інші ж, навпаки, зариті так глибоко, що знайти їх можна тільки випадково. Фундаментальна проблема налагодження полягає в тому, що навіть сама незначна модифікація програмного коду чревата появою каскаду помилок, причому часом вони виникають в найнесподіваніших місцях. І тому внесення будь-яких було змін в операційну систему і / або в супутні їй додатку повинно супроводжуватися повним циклом повторного тестування. Але ж вичерпне тестування, як вже було показано вище, провести неможливо!

Надмірна складність NT укупі з величезною кількістю змін, що вносяться до код кожної нової версії, власне і пояснює низьку якість її тестування. Незважаючи на всі зусилля, що вживаються Microsoft, вразливість NT закладена вже в самій політиці її розвитку, а тому є принципово непереборний, т. Е. Фундаментальної.

Більшість систем UNIX, навпаки, досить компактно і містить мінімум необхідних для функціонування системи компонентів (або, у всякому разі, їх можна «урізати» до такого стану). До того ж їх повільне, еволюційний (а не революційний, як у NT) розвиток аж ніяк не сприяє появі грубих, легко виявляються помилок, якими так славиться NT.

Засіб віддаленого доступу. Одне з концептуальних відмінностей філософії NT від UNIX полягає в тому, що в UNIX не робиться ніяких відмінностей між локальним і віддаленим доступом до машини. В NT ж, навпаки, лише деякі дії можуть бути виконані віддалено, а для повноцінного управління сервером адміністратору необхідний фізичний доступ до нього. Взагалі ж, в NT дуже небагато можна зробити за допомогою віддаленого доступу (правда, починаючи з Windows 2000 все-таки з'явилися більш-менш досконалі механізми віддаленого управління).

Ніхто не сперечається - управляти сервером на відстані дуже зручно, але давайте задумаємося, наскільки це безпечно? На жаль, ніяке зручність не проходить даром! Що комфортно адмініструвати, то комфортно і атакувати!

Проте не варто впадати в крайнощі і повністю відмовлятися від можливості віддаленого адміністрування. Звичайно, категорично заборонивши віддалений доступ, ви в значній мірі підсилите захищеність свого сервера, але ... будете змушені постійно перебувати безпосередньо поруч з ним. До того ж проникнути на атакується машину можна через будь-який встановлений на ній сервіс (скажімо, Web) і тому вкрай небажано позбавляти себе всіх засобів дистанційного моніторингу та управління сервером.

Словом, віддалене управління - палиця з двома кінцями: з одного боку, воно послаблює захищеність вузла, а з іншого - сприяє оперативному виявленню і нейтралізації зловмисників. Разом з тим, в відповідальних випадках від віддаленого управління все ж краще зовсім відмовитися, особливо при наявності можливості організувати цілодобове чергування оператора.

Комплектність штатної поставки. Комплект штатної поставки переважної більшості UNIX включає в себе величезну кількість різноманітних програм - від іграшок до компіляторів і інтерпретаторів. А чим більше додатків встановлено на машині, тим вище ймовірність утворення «дірок» в системі безпеки! Наявність компіляторів (інтерпретаторів) на атакується машині значно спрощує злом, оскільки, по-перше, створює умови для перенесення експлойтів, по-друге, дозволяє автоматизувати атаку і, по-третє, надає доступ до функцій і сервісів, недоступним з командної оболонки.

Операційні системи сімейства NT укомплектовані дуже скромним набором утиліт, а тому виглядають більш захищеними. Втім, це непринципове відмінність: грамотний адміністратор неодмінно видалить з UNIX все зайве.

АРХІТЕКТУРНІ КОНЦЕПЦІЇ

Механізми аутентифікації. Механізми аутентифікації користувачів (попросту кажучи, алгоритми перевірки правильності пароля) і в UNIX, і в NT грунтуються на практично ідентичних принципах, а саме: еталонний пароль ніде не зберігається, натомість, використовується його хеш (іншими словами, контрольна сума). Після введення пароля операційна система хешірует його відповідно до тих чи інших алгоритмом і порівнює отриманий результат з хеш-сумою еталонного пароля, що зберігається в спеціальній базі паролів. Така схема (при відсутності помилок реалізації, звичайно) гарантує, що, навіть отримавши доступ до бази, зловмисник все одно не зможе проникнути в систему інакше, ніж методом перебору. Втім, якщо спуститися з небес ідеалізованих математичних концепцій на грішну землю, то виникає питання, а чи варто було город городити? Зокрема, в більшості систем UNIX вводиться пароль відкритим текстом передається по мережі і, при наявності хоча б одного вразливого вузла в ланцюжку передачі, може бути перехоплений. В NT же відкритий пароль ніколи не передається (ну, хіба що через недогляд адміністратора), а схема аутентифікації стійка до перехоплення трафіку.

Разом з тим, розробники NT вкрай недбало поставилися до захисту бази паролів. Зокрема, резервні копії бази паролів за замовчуванням зберігаються в загальнодоступних каталогах.

На перший погляд здається, що ніякої проблеми взагалі немає, так як доступ до бази є лише у системи, адміністраторів і обмеженого числа спеціально призначених користувачів. У чому ж небезпека? Адже паролів в файлі паролів немає, а «звернення» хеша методом перебору займає надто багато часу. Однак обсяг жорстких дисків сьогодні зріс настільки, що хакер може заздалегідь зберегти хеши всіх перебираються паролів. І неважливо, скільки часу це займе - місяць, рік або більше. У зломщика з'явиться можливість практично миттєво відновити пароль по його хешу - була б тільки база паролів в руках! Мало того, алгоритм аутентифікації не використовує прив'язки (salt), і хеші однакових паролів в NT завжди буде збігатися, тим самим злом зазнає суттєвого спрощення! Втім, від атак даного типу прив'язка все одно не рятує.

Підвищення рівня привілеїв. Модель і механізм привілеїв користувачів - найбільш вразливе (за статистикою) ланка підсистеми безпеки будь-якої багатокористувацької ОС. У загальному випадку до неї ставляться такі вимоги:

• а) достатня гнучкість, зручність і інтуїтивна ясність, в іншому випадку помилки адміністрування неминучі;
  
• б) механізми контролю прав доступу повинні не тільки гарантувати неможливість несанкціонованого підвищення рівня своїх привілеїв, а й бути максимально стійкими до помилок програмування;
  
• в) і сама система, і що працюють в ній користувачі зобов'язані обходитися мінімально необхідним рівнем привілеїв.

Перераховані вище вимоги не виконуються ні в одній ОС масового призначення, а тому всі вони в тій чи іншій мірі свідомо уразливі. Тим часом ступінь захищеності систем UNIX і NT різна.

Модель привілеїв, що застосовується в більшості програм UNIX, є однорівневої і допускає існування лише двох типів користувачів: звичайні і привілейований користувач (він же root, або адміністратор). В NT ж, навпаки, використовується ієрархічна схема, крім root в ній є ще один привілейований користувач - система. На відміну від UNIX, кожен користувач отримує мінімум необхідних йому прав і ніколи не підвищує рівень своїх привілеїв без особливої ​​потреби. Широко поширена помилка, що правильне адміністрування UNIX дозволяє домогтися точно такого ж розподілу прав доступу, нехай ціною більшого часу і зусиль. Насправді це не так.

Відсутність в UNIX такого користувача, як система, виробляти до неможлівості Виконання цілого ряду Дій інакше, чем Шляхом Тимчасова Підвищення прівілеїв потокової програму до root. Взяти хоча б класичну задачу Зміни пароля. Користувачі могут (і повінні!) Періодічно міняті свои паролі. В UNIX (як, втім, и в NT) всі паролі зберігаються в одному файлі, причому модель прівілеїв НЕ дозволяє прізначаті різнім частина файлу Різні права доступу. Альо ж має користувач якось Изменить свой пароль? В UNIX це завдання вірішується так: утіліті, відповідальної за зміну пароля, прісвоюється Спеціальний атрибут, что дозволяє їй отрімуваті права root. Якби описів Механізм вікорістовувався только при операціях з паролями, то Великої біди в цьом НЕ Було б. Насправді ж, такий атрибут необхідній дуже Великій кількості Додатків, зокрема серверів Web и Електронної пошта. Задумайтесь, що станеться, якщо в одній з програм, що виконуються з найвищими привілеями, виявиться помилка, в результаті якої управління може тим чи іншим способом перехопити хакерський код? Але ж такі помилки сиплються з програм UNIX як з рогу достатку!

Зовсім інша ситуація в середовищі NT. Непривілейованих користувачам тільки у виняткових випадках потрібно підвищувати свої права до рівня адміністратора, а весь інший час вони користуються API-функціями операційної системи, при цьому потенційно небезпечні дії виконуються засобами самої ОС. Навіть якщо в одному з таких додатків буде допущена помилка і хакер захопить управління, то він успадкує мінімальні права і заподіє системі найменшу шкоду.

Таким чином, NT стійка до помилок програмування, а UNIX надзвичайно чутлива до них.

Загроза переповнення буфера. Переповнення буфера - найпоширеніша і в той же час найбільш підступна помилка. Коротко пояснимо її суть: якщо розмір виділеного програмістом буфера раптом виявиться недостатнім для вміщення всіх копіюються в нього даних, то не разом в буфер дані зруйнують (а точніше, замінять собою) вміст пам'яті за кінцем буфера. Залежно від ситуації за кінцем буфера можуть перебувати:

• а) інші буфери і змінні програми;
• б) службові дані, зокрема адреса повернення з функції;
• в) виконуваний код;
• г) незайнята або
• д) відсутня сторінка пам'яті.

Найбільшу небезпеку становлять пункти б) та в), так як вони можуть призвести до повним захопленням контролю над вразливою програмою. Пункт д) менше підступний і в гіршому випадку призводить до реалізації атаки по типу «відмова в обслуговуванні» (при зверненні до відсутньої сторінці пам'яті процесор видає виключення, що приводить до аварійного завершення уразливого додатки). Загроза від пункту а) в значній мірі залежить від роду і призначення змінних, що знаходяться за кінцем переповненого буфера.

Для повноцінного захоплення управління хакер повинен мати можливість виконувати на віддаленій машині власний код, зазвичай передається безпосередньо через переповнені буфер. Залежно від розташування уразливого буфера і «характеру» операційної системи, виконання переданого їм коду може бути як дозволено, так і заборонено.

Обидві розглянуті системи потенційно допускають можливість здійснення пунктів а), б), г) і д), виключаючи лише єдиний з них - пункт в). Отже, вони в рівній мірі схильні загрозу переповнення буфера. Крім того, і та, і інша мають виконуваний стек (т. Е. Дозволяють виконання коду в стеці і забороняють його виконання в сегменті даних). А це означає, що переповнення буферів, де знаходяться автоматичні (т. Е. Стекові) змінні, таїть загрозу повного захоплення управління над вразливою програмою. Правда, для деяких UNIX існують латки, позбавляють стек права виконання, але сфера їх застосування досить обмежена (виконуваний стек необхідний безлічі цілком легальних програм, зокрема компіляторам).

Найсумніше, що і UNIX, і NT написані на Сі - мовою програмування, який не підтримує автоматичний контроль кордонів масиву і тому схильний до помилок переповнення.

Доступ до чужого адресного простору. З захистом адресного простору процесора пов'язана величезна кількість непорозумінь, та й просте нерозуміння самої філософії захисту. Часто беруть до уваги, що мова йде, в першу чергу, про запобігання ненавмисного доступу, т. Е. Неполадки в одному процесі не повинні впливати на інші виконуються процеси.

Повноцінного захисту від навмисного доступу в чуже адресний простір ні в UNIX, ні в NT насправді не передбачено. Власне, UNIX взагалі не представляє ніяких коштів такої взаємодії, крім хіба що розділяються (т. Е. Спільно використовуваних) областей пам'яті, але це зовсім не те. NT ж забезпечує дуже гнучкий контроль доступу до адресного простору процесорів, але значно програє UNIX щодо безпеки. І ось чому:

• а) в NT доступ в чуже адресний простір за замовчуванням дозволено всім, навіть гостю, і, якщо якийсь процес (точніше, його власник) не хоче, щоб в нього проникали, він зобов'язаний заявити про це явно;
• б) в UNIX необхідно, щоб налагоджувати процес не тільки дав згоду на свою налагодження, але і виконав деякі дії, причому налагодження вже виконуються процесів заборонена! NT же безперешкодно дозволяє налагоджувати активні процеси і ініціювати налагодження нових, природно, з успадкуванням всіх привілеїв процесу-відладчика (т. Е. В загальному випадку налагодження більш привілейованих процесів з менш привілейованих неможлива).

Коротко кажучи, NT надає вельми привільні умови для існування вірусів Stealth, клавіатурних «шпигунів» і всіх інших порушників спокою системи.

Межпроцессорной комунікації. Процеси повинні обмінюватися даними - це безперечно, в іншому випадку така система нікому не потрібна. З іншого боку, наявність яких би то ні було коштів взаємодії між процесами потенційно дозволяє атакуючому згубно впливати на чужій процес. Отже, кожен з сполучених процесів повинен мати можливість:

• а) самостійно вирішувати, з ким йому здійснювати обмін;
• б) вміти визначати справжність процесів відправників і процесів одержувачів;
• в) контролювати цілісність переданих / прийнятих даних;
• г) створювати захищений канал зв'язку, стійкий до перехоплення трафіку.

Різноманіття засобів взаємодії між процесами, які підтримуються сучасними операційними системами, надзвичайно ускладнює відповідь на питання, якою мірою виконуються перераховані вище вимоги на практиці? Обмежені обсягом журнальної статті, ми розглянемо лише три найбільш популярних кошти межпроцессорного взаємодії: канали, сокети і повідомлення.

Неіменовані канали дозволяють пов'язувати лише родинні процеси і тому повністю відповідають умові пункту а). Навіть якщо сторонній процес якимось чином ухитриться отримати дескриптор неіменованого каналу не спорідненого йому процесу, то він (дескриптор) поза контекстом свого процесу втрачає всякий змив, і нічого шкідливого з його допомогою зловмисник зробити не зможе. Якщо ж останній проникне в родинний процес і спробує, скажімо, завалити свого сусіда потоком інформаційного сміття, то ... нічого не станеться. Коли процес-читач вже не зможе «переробляти» надсилали дані, система автоматично припинить передачу, не даючи атакується процесу «захлинутися». Причому жертва вільна сама вирішувати, як вчинити: наприклад, вона може просто закрити канал.

Іменовані канали доступні всім процесам в системі, а в NT і тим процесам, які виконуються на інших вузлах мережі. Природно, для відкриття іменованого каналу необхідні відповідні привілеї, але ось сформувати новий іменований канал можна і без таких привілеїв, причому в NT немає легальних способів визначення «авторства» творця того чи іншого каналу! З огляду на, що іменовані канали активно використовуються системою для передачі зашифрованих паролів і віддаленого управління реєстром, загроза застосування підроблених каналів вже не здасться незначною.

Частково проблема вирішується установкою відповідного пакета оновлень (зокрема, Service Pack 2 для Windows 2000). Однак дана латка запобігає появі підробленого примірника вже існуючого іменованого каналу. Тим часом можливість створити підроблений канал «з нуля», як і раніше залишається, а механізмів ідентифікації винуватців того, що сталося в Win32 API як не було, так і немає.

Локальний характер іменованих каналів в UNIX виявляється одночасно і сильною, і слабкою її стороною. Але відсутність віддаленого доступу до каналів - ще не привід розслаблятися, адже створити підроблений канал може навіть користувач зі статусом гостя, що в ряді випадків забезпечує йому успішну атаку більш привілейованих процесів.

Іменовані канали мають ще один серйозний недолік: обробка кожного нового підключення вимагає якоїсь кількості системних ресурсів, а максимальне число створюваних екземплярів каналу зазвичай не обмежена. Виплоджуючи все нові і нові екземпляри, зловмисник займе всі ресурси, і система рано чи пізно зупиниться. Навіть якщо максимальну кількість екземплярів було заздалегідь обмежена, результат буде той же самий. Захопивши все вільні канали, зловмисник порушить нормальну роботу інших легальних процесів. Система, правда, не впаде, але користі від цього буде небагато ... Вирішити проблему допоможе введення квот з клієнтської (а не серверної!) Сторони, але, по-перше, не зовсім ясно, як їх реалізувати в мережевому середовищі, а, по-друге, клієнтську захист завжди легко обійти.

Сокети, що використовуються в основному при міжвузлових взаємодіях між процесами (хоча в UNIX вони широко застосовуються і для локального обміну даними), катастрофічно не захищені перед спробою захоплення всіх вільних ресурсів, і величезна кількість атак flooding - найкраще тому підтвердження. До речі, наявність «неформатованих» (raw) сокетов в UNIX робить її «платформою № 1» для будь-якого мало-мальськи серйозного нападу TCP / IP.

Системи сімейства NT довгий час взагалі не дозволяли «вручну» формувати мережеві пакети, і тому атаки, на зразок Land, Teardrop і Bonk, здійснити з їх допомогою було неможливо (правда, це ще не означає, що NT більш стійка!). Чи не даним чи обставиною викликана патологічна любов більшості хакерів до UNIX? Правда, сьогодні не складає труднощів знайти драйвер NDIS до NT для роботи з пакетами TCP / IP на низькому рівні, так що репутація UNIX як основної платформи для злому в недалекому майбутньому може похитнутися.

Нарешті, ще один тип неавторизованого межпроцессорного взаємодії представляють повідомлення. В NT будь-який процес, незалежно від рівня своїх привілеїв, може послати повідомлення вікну іншого процесу (в тому числі і більш привілейованого!), Причому встановити відправника повідомлення не можна! Якщо на машині відкрито вікно якогось привілейованого додатки (а така можливість у нас є), то, знаючи дескриптор цікавить його елемента управління (кнопки, пункту меню, рядка редагування), зловмисник може емулювати введення користувача! Привілейований процес все зробить сам, так нічого і не запідозривши. Як бачимо, запускати засоби адміністрування безпечно лише на свідомо «стерильної» машині (по мережі повідомлення не передаються, точніше, не передаються в штатній конфігурації NT, але ряд утиліт віддаленого управління системою дозволяє обмінюватися ними і по мережі).

Гучна «діра», коли код оболонки передається в рядок редагування привілейованого процесу з подальшою установкою таймера для виконання цього коду в адресному просторі і з привілеями атакується процесу, в даний час, за запевненням Microsoft, вже усунена. Повністю ж відмовитися від нього (або захистити) межпроцессорную розсилку повідомлень неможливо, оскільки це один з компонентів філософії віконної підсистеми Windows, і будь-які спроби внесення яких би то не було обмежень не забаряться привести до проблем сумісності і до непрацездатності великої кількості прикладних програм.

Віконна підсистема UNIX хороша тим, що не є невід'ємною частиною системи, при бажанні від неї можна відмовитися, обмежившись надійним і безпечним текстовим режимом. Обмін повідомленнями в графічних оболонках UNIX зазвичай здійснюється за протоколами TCP / IP, вікна і елементи управління одного процесу виявляються захищеними від зазіхань усіх інших (якщо, звичайно, сам процес-власник цього не захоче).

Отже, міжпроцесорний обмін і в UNIX, і в NT реалізований дуже погано і тому небезпечний. Адекватні засоби захисту від розглянутих вище атак ні в близькому, ні в далекому майбутньому, мабуть, не з'являться - адже «собака зарита» на рівні базових концепцій і філософії тієї й іншої системи. А філософію черговий заплатити не поміняєш.

зведена ТАБЛИЦЯ

Так яка ж система надійніше? В ідеалі, звичайно, варто було б присвоїти кожній характеристиці свій «вага» і порахувати «окуляри» обох систем. Однак «вага» - поняття суб'єктивне, і нам нічого не варто було б налаштувати вимірювальну шкалу так, щоб більш надійної виявилася наша улюблена система. Підтасовування може відбуватися підсвідомо, а тому у вільній таблиці, наведеної вище, ніякі вагові категорії взагалі не використовуються.

Не варто також забувати, що оцінка безпеки системи дуже чутлива до кількості і виду порівнюваних характеристик. Виключаючи одні або додаючи інші, ми можемо значно змінити кінцевий результат. Так що не варто вважати наше порівняння істиною в останній інстанції ...

Якість і повнота документації Документована поверхнево Документована досить докладно Доступність вихідних текстів Вихідні тексти недоступні Вихідні тексти доступні Складність аналізу Висока Помірна Поширеність Вельми обмежена кількість представників NT, причому спостерігається яскраво виражена спадкоємність вразливостей від одних версій системи до інших Величезна кількість різноманітних клонів, причому помилки однієї версії системи часто відсутні в інших Складність коду Код изл шне складний Код гранично простий Підтримка віддаленого адміністрування Часткова Повноцінна Комплектність штатної поставки Мінімум необхідних додатків Величезна кількість додатків, в тому числі і непротестованих Механізми аутентифікації Стійкість до перехоплення паролів Передача пароля у відкритому вигляді Використання прив'язки Чи не використовує Використовує Виконання привілейованих операцій Операції виконуються операційною системою Операції виконуються самим додатком з тимчасовим підвищенням привілеїв Модель користув ялин Ієрархічна Одноуровневая Захист від переповнення буфера Відсутня, причому сама ОС написана на мові, що провокує такі помилки Відсутня, причому сама ОС написана на мові, що провокує такі помилки Можливість доступу в адресний простір чужого процесу Дозволена за замовчуванням Відсутня Можливість налагодження процесів Дозволена за замовчуванням Пов'язана з рядом обмежень Можливість налагодження активних процесів При наявності відповідних привілеїв Відсутня Віддалений доступ до іменованих каналів Так Ні Провадження у помилкових іменованих каналів Так, причому можна створити і канал, і навіть підроблений екземпляр вже відкритого каналу Так, можна створити лише підроблений канал Захист іменованих каналів від небажаних підключень Відсутня Відсутня Захист сокетов від небажаних підключень Відсутній Відсутній Можливість емуляції введення в більш привілейований процес Є Відсутня

Кріс Касперски - незалежний експерт в області комп'ютерної безпеки. З ним можна зв'язати за адресою: [email protected] .