Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, Mr. None, Вы писали:

MN>>Такой код не модифицируем, если
MN>>1) ОС не содержит ошибок и правильно использует предоставляемые аппаратные ресурсы, как-то: 4 кольца защиты процессора, защита памяти с исполняемыми данными от модификации, стека и динамической памяти от исполнения;

GN>ОС уже есть и приходится с ней жить.

Vista — все 4 кольца защиты. Unix`ы семейства S5R4 — все 4 кольца защиты. Ещё вопросы есть? Осталось исправить ошибки, после 2-ого сервис пака, я уверен, висту чёрта в 2 прошибёшь... Так — изредка. Если уж w2k стала стабильной при всех её недостатках.


MN>>2) пользователь придерживается элементарной гигиены — не ходить в сеть под админом...

GN>Можно бы ответить аналогично — кто цепляет малвару под админом, у того руки не оттуда растут. И вообще, меня удивляет подобная позиция профессионалов. Клиент всегда прав.

Если он чётко следует инструкциям и руководствам — мы же с вами в реальном мире живём, где правят продажи, а не оголтелый фанатизм и альтруизм.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, Mr. None, Вы писали:

MN>>А кто будет компилировать этот код just in time? JIT компилятор, а он будет каким, тоже компилироваться just in time?

GN>Нет, он будет поставляться (подписанным ЭЦП) производителем ОС на немодифицируемом носителе.

А ЭЦП ты будешь проверять вручную .


MN>> А кто будет компилировать его? (И вообще — на каком компиляторе был скомпилирован первый компилятор?) В конце концов получис нативный бинарный компилятор с постоянными адресами, который будет компилировать нечто на раннем этапе загрузки системы и малвары будут атаковать его ... Короче в хумор!!!!

GN>Можно увидеть подробный сценарий атаки компилятора? посмеёмся в месте.

Давай. MS не так давно заявила, что Vista будет последней операционной системой распространяемой традиционным спомобом, посредством продажи на дисках в коробочках. Последующие ОС будут, скорее всего, распространятся отдельными модулями посредством скачивания с их сайта и последующей авторизацией покупаемым ключом. А вы "немодифицируемый носитель"...

>>Vista — все 4 кольца защиты.

Где про это можно почитать?

Здравствуйте, Gabryael, Вы писали:

>>>Vista — все 4 кольца защиты.

G>Где про это можно почитать?

К сожалению толком нигде . Изначально Майкрософт заявляла, что будут все 4 кольца защиты в 64-битной версии ОС. Но потом тишина. Одни источники утверждают, что это так другие, что нет. Достоверного подтверждения или опровержения я так и не нашёл. Так что моё заявление, можно сказать, не вполне подтверждённое. В любом случае ждём Longhorn`а...

Здравствуйте, Arioch, Вы писали:

A>>>или отправляет в сеть своему хозяину данные пользователя в виле файла.
GN>>Она не сможет это сделать при установленном фаерволле.
A>Файрвол выключеН, поскольку ОС не смогла его защитить от малвары. http://bash.org.ru/quote.php?num=211190

A>>>JVM/CLR тут никаким боком, млаваре внедряться никуда не надо, если речь идет о безопасности данных пользователя — то проще их взять как файл не внедряясь в программы.
GN>>Поэтому малвара пропатчит ядро и выйдет в сеть в обход фаерволла.
A>Так чем JVM/CLR помодет в защите безопасности ?
Если запретить исполнение неуправляемого кода, то всё, что делает скачанный из недобросовестного источника код, будет проходить через CAS. В итоге, манипуляции с чужими данными будут посланы в лес. Манипуляции с OS, в том числе и c JVM/CLR будут посланы в лес. Ну и так далее.
Единственная остающаяся дыра в CAS — это программы, маскирующие нелегальное поведение под легальное. К примеру, бэкапилка с автоапдейтом. Как бэкап она имеет право читать всё, и пользователь это подтвердит, а для автоапдейта ей нужен доступ к родному серверу. То, что при "автоапдейте" программка будет сливать на сервер данные "забэкапленных" кредиток, обнаружится значительно позже.
Тем не менее, как минимум будут отслежены
— хождения "не туда" (что, впрочем, уже сейчас мониторится фаерволлами)
— попытки манипулировать чем не надо (например, тем же фаерволлом).

Для неуправляемого кода ничего полезного сделать все равно нельзя. Это аксиома. Как только пользователь под привилегиями администратора запустил неуправляемый код, никакая защита не сработает (кроме заранее запущенного антивируса, который вовремя предотвратит запуск злонамеренного кода, умея его обнаруживать).
Полиморфное ядро не слишком поможет. На первое время — да. А потом кто-то поумнее напишет анализатор ядра, который посканирует код и найдет точки входа. Все, что спрятал пингвин, завсегда найдет буревестник. У него — всё время мира и полные права администратора в user mode. После этого можно будет сгенерировать соответствущий руткит, который активизируется сразу после перезагрузки (а то и до неё). Лично видел вполне легальный инсталлер, который отключал ворнинги винды по поводу неподписанных драйверов на время инсталляции. А если бы острым, а если бы в глаз?

A>>>Невозможность перехвата будут обеспечивтаь механизмы ОС, которые "неспособны противостоять атакам" как написано выше.
A>>>Иными словами, неворзможность перехвата обеспечить нельзя — проблему курицы и яйца.
GN>>Для того, что бы перехватить некоторую функцию, необходим её адрес. Нет адреса — перехват невозможен.
A>Reflection, однако. Берем у VM и запрашиваем замену стандартной функции нa свою
CAS не даст нам это сделать. В том, естественно, случае, если мы не запустили неуправляемый код. Потому что неуправляемый код банально поправит настройки CAS и всего чего душеньке угодно.

Sinclair wrote:
> CAS не даст нам это сделать. В том, естественно, случае, если мы не
> запустили неуправляемый код. Потому что неуправляемый код банально
> поправит настройки CAS и всего чего душеньке угодно.
Кстати, я уже пару раз говорил, что никто не мешает использовать CAS для
unmanaged-кода.

Например, http://coyotos.org/ фактически так и делает — там используется
система "capabilities". Каждый "capability" — это по-сути handle для
какого-то ресурса, его нельзя создать без участия ядра. Грубо говоря, у
тебя unmanaged-программа ничего не сможет сделать с ядром, если у нее не
будет хэндла на доступ к нему.

Здравствуйте, Sinclair, Вы писали:

S>Для неуправляемого кода ничего полезного сделать все равно нельзя. Это аксиома. Как только пользователь под привилегиями администратора запустил неуправляемый код, никакая защита не сработает (кроме заранее запущенного антивируса, который вовремя предотвратит запуск злонамеренного кода, умея его обнаруживать).

Очень авторитетные товарищи имеют прямо противроположное мнение:

http://citforum.ru/operating_systems/reliable_os/

Здравствуйте, Mr. None, Вы писали:

MN>А ЭЦП ты будешь проверять вручную .

Да. А что? Эта проверка будет происходить на стадии инсталляции или загрузки, то есть до запуска зловредного кода.

MN>MS не так давно заявила, что Vista будет последней операционной системой распространяемой традиционным спомобом, посредством продажи на дисках в коробочках. Последующие ОС будут, скорее всего, распространятся отдельными модулями посредством скачивания с их сайта и последующей авторизацией покупаемым ключом. А вы "немодифицируемый носитель"...

Я просил сценарий атаки, а не размышления о поставках ОС.

Здравствуйте, Mr. None, Вы писали:

MN>Vista — все 4 кольца защиты.

Речь о Toyota Vista что ли?

MN> Unix`ы семейства S5R4 — все 4 кольца защиты.

Рад за них, но есть еще и массовая ОС, а не только Неуловый Джо.

MN> Ещё вопросы есть?

Да. И зачем же MS реализовали PatchGuard?

MN>Если он чётко следует инструкциям и руководствам — мы же с вами в реальном мире живём, где правят продажи, а не оголтелый фанатизм и альтруизм.

А я о продажах и говорю, клиент хочет ПО для спокойной работы, а не для постоянного ввода паролей и подтверждений

Здравствуйте, Sinclair, Вы писали:

S>Полиморфное ядро не слишком поможет. На первое время — да. А потом кто-то поумнее напишет анализатор ядра, который посканирует код и найдет точки входа.

А как приблизительно будет выглядеть такой анализатор? Есть мнения, что это NP-полная задача.

Здравствуйте, Cyberax, Вы писали:

C>Кстати, я уже пару раз говорил, что никто не мешает использовать CAS для
C>unmanaged-кода.
Гм. Никаких шансов реализовать CAS для неуправляемого кода нет. Грубо говоря, мне достаточно подпатчить собственный стек, чтобы получить любые требуемые привилегии. А потом подпатчить его обратно.
В том-то и дело, что управляемая среда банально не дает коду вылезти из песочницы.

Здравствуйте, FR, Вы писали:

FR>http://citforum.ru/operating_systems/reliable_os/
Гм. Авторитетные товарищи занимаются в основном улучшением ситуации с взаимопроникновением драйверов. Действительно, некоторые аспекты безопасности системы можно улучшить благодаря изоляции драйверов, хотя до полной безопасности еще далеко. Позволю себе напомнить, что подавляющее большинство вредоносного софта сейчас исполняется в user mode и зачастую не требует даже администраторских привилегий для того, чтобы пошалить.

Всё это связано с отсутствием контроля за тем, какой именно код исполняется неуправляемым приложением. Я, честно говоря, не вижу проблемы для приложения, выполняемого в юзермоде под правами администратора взять и, к примеру, "починить" реестр или файловую систему так, чтобы обеспечить перехват системных функций после следующей перезагрузки.
Ну вот выделили мы всё, что можно, из ядра. И что? Как это поможет предотвратить вклинивание или замену драйвера файлухи на свой, который будет видеть всё, кроме вируса?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, FR, Вы писали:

FR>>http://citforum.ru/operating_systems/reliable_os/
S>Гм. Авторитетные товарищи занимаются в основном улучшением ситуации с взаимопроникновением драйверов. Действительно, некоторые аспекты безопасности системы можно улучшить благодаря изоляции драйверов, хотя до полной безопасности еще далеко. Позволю себе напомнить, что подавляющее большинство вредоносного софта сейчас исполняется в user mode и зачастую не требует даже администраторских привилегий для того, чтобы пошалить.

Ты прочитай до конца статью там есть и про защиту в user mode.

S>Всё это связано с отсутствием контроля за тем, какой именно код исполняется неуправляемым приложением. Я, честно говоря, не вижу проблемы для приложения, выполняемого в юзермоде под правами администратора взять и, к примеру, "починить" реестр или файловую систему так, чтобы обеспечить перехват системных функций после следующей перезагрузки.

По моему ничего не выйдет. Обычные приложения имеют очень мало прав в этой системе.

S>Ну вот выделили мы всё, что можно, из ядра. И что? Как это поможет предотвратить вклинивание или замену драйвера файлухи на свой, который будет видеть всё, кроме вируса?

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

Здравствуйте, FR, Вы писали:

FR>Ты прочитай до конца статью там есть и про защиту в user mode.
Прочитал. Не нашел. Везде только детский лепет про "наша система не предназначена для защиты от злонамеренного кода, зато помогает добропорядочным драйверам восстановиться при сбое". Да, есть упоминания про то, как контролируется IPC, но нет никакого упоминания про то, каким образом настраиваются эти политики.
Поэтому нет никакой гарантии того, что все сработает как надо. Вот у них там упоминается про инициализацию векторов защиты портов из файлухи. В будушем они обещают это починить и получать информацию из BIOS, но пока что вирус может тупо переписать файл (а права иметь запись в файлуху будут у очень большого количества приложений), и поправить привилегии.

То, что предлагают эти парни — средство повышения отказоустойчивости, а не безопасности. Предлагается что-то вроде CAS, только очень грубое; на уровне процесса. Я на 100% уверен, что реализовать полномасштабную проверку в ядре — невозможно. Можно только несколько затруднить взлом такой системы. Против пользователя с административными привилегиями все эти меры не дадут никакого результата.

FR>По моему ничего не выйдет. Обычные приложения имеют очень мало прав в этой системе.
Да ну, не смеши меня.
S>>Ну вот выделили мы всё, что можно, из ядра. И что? Как это поможет предотвратить вклинивание или замену драйвера файлухи на свой, который будет видеть всё, кроме вируса?
FR>Вкливание вообще не возможно, пользовательские приложения вообще не могут получить доступ к памяти других процессов.
Ха-ха. Просто в этой системе вклинивание не будет требовать доступа к памяти. Зачем?
FR>Для замены драйвера придется его ручками устанавливать.
Что значит "ручками"? Если админ может подергать за ручки, то же самое может сделать и червь под его правами. Он точно так же пропишет себя как драйвер файлухи, и всё заработает как ему надо.

Sinclair wrote:
> C>Кстати, я уже пару раз говорил, что никто не мешает использовать CAS для
> C>unmanaged-кода.
> Гм. Никаких шансов реализовать CAS для неуправляемого кода нет. Грубо
> говоря, мне достаточно подпатчить собственный стек, чтобы получить любые
> требуемые привилегии. А потом подпатчить его обратно.
Как? Еще раз напомню — с важными ресурсами ты работаешь через
специальные handle'ы. Сам создать или изменить ты их не можешь. А что ты
там со своим стеком делаешь — это твое личное дело.

Собственно, CASы для неуправляемого кода уже делались, причем вполне
успешно — http://en.wikipedia.org/wiki/Plessey_250

Здравствуйте, Cyberax, Вы писали:

C>Sinclair wrote:
>> C>Кстати, я уже пару раз говорил, что никто не мешает использовать CAS для
>> C>unmanaged-кода.
>> Гм. Никаких шансов реализовать CAS для неуправляемого кода нет. Грубо
>> говоря, мне достаточно подпатчить собственный стек, чтобы получить любые
>> требуемые привилегии. А потом подпатчить его обратно.
C>Как? Еще раз напомню — с важными ресурсами ты работаешь через
C>специальные handle'ы. Сам создать или изменить ты их не можешь.
Ок, откуда я получаю такой хэндл? Правильно, я делаю системный вызов. Например, CreateFile("C:\boot.ini"). Как система проверяет, что мне можно этот вызов делать? Система привилегий пользователя тупо сравнивает ACL с моим списком групп. Система CAS должна посмотреть в стек, чтобы понять, что за код делает такой вызов. В управляемой среде это так; именно поэтому я могу запретить стороннему приложению открывать файлы напрямую, но разрешить через специальный SandBox API. Так вот: в неуправляемом коде стек ты не проверишь. Потому, что я могу его "починить".
C>Собственно, CASы для неуправляемого кода уже делались, причем вполне
C>успешно — http://en.wikipedia.org/wiki/Plessey_250
Гм. Я так понял, у парней было аппаратное решение. Т.е. что-то вроде управляемой среды на реальной машине, а не на виртуальной.

Sinclair wrote:
> именно поэтому я могу запретить стороннему приложению открывать файлы
> напрямую, но разрешить через специальный SandBox API. Так вот: в
> неуправляемом коде стек ты не проверишь. Потому, что я могу его "починить".
Размести этот Sandbox API в отдельном процессе со специальными
привиллегиями — тогда проверка привиллегий вызывающего будет надежной.
Еще раз, проблема CAS уже успешно решалась для нативного кода.

> C>Собственно, CASы для неуправляемого кода уже делались, причем вполне
> C>успешно — http://en.wikipedia.org/wiki/Plessey_250
> Гм. Я так понял, у парней было аппаратное решение. Т.е. что-то вроде
> управляемой среды на реальной машине, а не на виртуальной.
Такое можно и сейчас сделать на x86 — просто оно будет медленнее
работать (потребуется делить код на процессы).