Сообщение Re[25]: [UPD2] Безопасность ОС. Можно ли решить кардинально от 08.10.2014 16:31
Изменено 08.10.2014 16:55 ononim
S>>>Велком — рассказывайте, какие операции вы собираетесь поддерживать, и как получается итоговая разметка.
O>>Любая операция принимает на вход некие данные, делает над ними некие вычисления, результат которых зависит от самой операции и от входных данных. В результате операции появляются новые данные. Причем совершенно независимо от того что там за операция — imul, xor или SSEэшное перемножение векторов, 'принадлежность' информации которая получается в ее результате однозначно определяется как объединение принадлежностей информации принимаемой на вход (всех операндов, включая регистры и IO порты) и самой операции.
M>В примере перечислено то, что покроет 95% случаев. А вот специальные 5% инструкций доставят 95% проблем. И эти 5% — условные переходы. Вот как вы собираетесь размечать результат инструкции условного перехода? Все данные после перехода будут помечены тегом данных, которые использовались в условии? А не учитывать условные переходы нельзя, иначе можно создавать информацию из воздуха.
M>
Отличный вопрос, пожалей второй адекватный вопрос за всю историю ветки
Я пожалуй над ним подумаю и отвечу как нить потом, если чтонить придумаю. Ну или посыплю голову пеплом А сейчас времени мало.
UPD1: посетил определенные места и таки кое что придумал. В гипотетической архитектуре не будет условных переходов
Зато будут условные call'ы и чтонибудь 
UPD2: с условными переходами я погорячился. Их можно оставить. И они правда будут накладывать теги на весь execution flow до.. возврата из обычного call'а, в котором находится текущий контекст. Т.о. на call'ы будет накладываться семантика ограничения скопа тегов порожденных условными переходами. Ну и само собой надо както будет сделать невозможным фокусы а-ля push/ret'а. Например — путем разделения стека переменных и стека адресов возврата. Это не единственное возможное решение, но его существования доказывает возможность решения вообще
M>Вот так на условных переходах теги теряются. Так что нужно бы все условные переходы трейсить и навешивать теги от условия перехода. Чую, так просто от этого не отделаться будет. Расползутся теги от условного перехода по всему приложению. Вот посмотрит браузер на clipping area для вывода чего-нибудь со странички банка, и все, на всем UI-выводе будет висеть тег этого банка. Даже после того, как я закрыл все окна от него.
Почему на всем UI выводе? Если говорим об экране — это лишь кусок видеопамяти, которая по сути ничем не отличается от физической памяти, кроме того что ее содержимое видно юзеру практически как есть Потому — просто эта память должна тегироваться как и обычная, а не обзываться "всем UI выводом".
M>Еще интересные темы с межпроцессным взаимодействием. Как тегируется новый процесс?
Сущность 'процесс' ортогональна тегированию. Вкратце — советую вам в этом контексте про процессы забыть. Но если уж не забывать, то изначально процесс — это прочитанные в память файлы (они, конечно же, тоже тегируются). Вот как была протегирована информация в файлах — так она и будет протегирована в процессе. Само собой АП процесс — не рассматривается как одна единственная сущность. А любая передача данных между процессами в плане передачи тегов должна быть эквивалентна прямому копированию данных в пределах одного процесса. Поэтому разделение на процессы совершенно не добавляет ничего в плане защиты данных от угона, а может использоваться только как мера локализации непреднамеренных повреждений памяти.
O>>Теперь попробуйте придумать вектор атаки, которая это обойдет.
M>Запросто. И даже теги на IP (instruction pointer) нам не помешают. Будем неторопясь сливать данные в свой "хакерский" домен. Отсутствие информации тоже может быть использовано в качестве информации!
M>
M>Вот вам и вектор. Каждый читатель получает информацию из "хакерских данных". Если вдруг он прочитал данные с банковским тегом, он просто умирает (ничего никуда не сигналя!). Так как другие читатели знают протокол обмена, они могут восстановить "ошибки протокола" (т.е. не вышедших на связь в нужное время читателей).
M>Немного черной магии и данные извлекаются из "отсутствия данных". Чтобы с этим бороться, нужно либо анализировать как-то program flow и возможные affected vairables. Либо радостно развешивать теги на все псевдоглобальное, включая thread.sleep, сетевые взаимодействия и прочие источники, которые могут быть использованы для кражи данных. Но даже там я реализую sleep через большой цикл. И буду с интервалом ридеров пускать, а не ждать в самом ридере.
Код не разбирал, не очень есть время на это сейчас, отвечу по изложенному тексту.
Теги навешиваются на все, на самом низком уровне Прыгая по дереву абстракций вверх — от них не спрячешься. Статус процесса — это тоже переменная в памяти, и если ее вычисленное значение зависело от некоторых данных — на нем будет тот же тег.
M>Что-то мне кажется, что попытки бороться со всем этим приведут к решению "ставим теги на процесс". А это уже совсем не так интересно. Плюс результат будет похож на то, что уже есть сейчас. Всякие apparmor и прочие ограничители прав приложений (т.е. не только файловый доступ, а еще сокеты, системные ресурсы и т.п.).
Вообще моя предполагаемая архитектура если она имплементиться в хардваре — должна тегировать физическую память. Вообще всю, каждый байтик должен быть учтен. Причем память — это и ОЗУ, и диск, и регистры процессора. Да, на х86 это все накладывать будет накладно — я не спорю, потому и писал что тот проект — был лишь прототипом. Да и смысла нет — подобная модель при ее полноценной реализации (а не как большинство секурити продуктов на рынке, которые влегкую смогут обойти сами их разработчики) не оставит места для совместимости с любыми из существующих приложений.
А если его реализовывать софтварно — то только на сингулярити-образных ОС, в которых кстати уже настолько развитый контроль на памятью что там процессы и так работают в едином АП.
O>>Любая операция принимает на вход некие данные, делает над ними некие вычисления, результат которых зависит от самой операции и от входных данных. В результате операции появляются новые данные. Причем совершенно независимо от того что там за операция — imul, xor или SSEэшное перемножение векторов, 'принадлежность' информации которая получается в ее результате однозначно определяется как объединение принадлежностей информации принимаемой на вход (всех операндов, включая регистры и IO порты) и самой операции.
M>В примере перечислено то, что покроет 95% случаев. А вот специальные 5% инструкций доставят 95% проблем. И эти 5% — условные переходы. Вот как вы собираетесь размечать результат инструкции условного перехода? Все данные после перехода будут помечены тегом данных, которые использовались в условии? А не учитывать условные переходы нельзя, иначе можно создавать информацию из воздуха.
M>
M>var bankBits = bankData.asLongNumber(); //банковые данные
M>var myData = 0; //хакерские данные.
M>for (var i = 0; i < 10000; i++) {
M> if (bankBits % 2 == 0)
M> myData = myData * 2; //только хакерские данные
M> else
M> myData = myData * 2 + 1; //тоже хакерские данные
M> // Чисто банковские данные. Или нет? Хотя не важно.
M> bankBits /= 2;
M>}
M>myData.reverseBits();
M>Отличный вопрос, пожалей второй адекватный вопрос за всю историю ветки
Я пожалуй над ним подумаю и отвечу как нить потом, если чтонить придумаю. Ну или посыплю голову пеплом А сейчас времени мало.UPD1: посетил определенные места и таки кое что придумал. В гипотетической архитектуре не будет условных переходов
Зато будут условные call'ы и чтонибудь UPD2: с условными переходами я погорячился. Их можно оставить. И они правда будут накладывать теги на весь execution flow до.. возврата из обычного call'а, в котором находится текущий контекст. Т.о. на call'ы будет накладываться семантика ограничения скопа тегов порожденных условными переходами. Ну и само собой надо както будет сделать невозможным фокусы а-ля push/ret'а. Например — путем разделения стека переменных и стека адресов возврата. Это не единственное возможное решение, но его существования доказывает возможность решения вообще
M>Вот так на условных переходах теги теряются. Так что нужно бы все условные переходы трейсить и навешивать теги от условия перехода. Чую, так просто от этого не отделаться будет. Расползутся теги от условного перехода по всему приложению. Вот посмотрит браузер на clipping area для вывода чего-нибудь со странички банка, и все, на всем UI-выводе будет висеть тег этого банка. Даже после того, как я закрыл все окна от него.
Почему на всем UI выводе? Если говорим об экране — это лишь кусок видеопамяти, которая по сути ничем не отличается от физической памяти, кроме того что ее содержимое видно юзеру практически как есть
Потому — просто эта память должна тегироваться как и обычная, а не обзываться "всем UI выводом".M>Еще интересные темы с межпроцессным взаимодействием. Как тегируется новый процесс?
Сущность 'процесс' ортогональна тегированию. Вкратце — советую вам в этом контексте про процессы забыть. Но если уж не забывать, то изначально процесс — это прочитанные в память файлы (они, конечно же, тоже тегируются). Вот как была протегирована информация в файлах — так она и будет протегирована в процессе. Само собой АП процесс — не рассматривается как одна единственная сущность. А любая передача данных между процессами в плане передачи тегов должна быть эквивалентна прямому копированию данных в пределах одного процесса. Поэтому разделение на процессы совершенно не добавляет ничего в плане защиты данных от угона, а может использоваться только как мера локализации непреднамеренных повреждений памяти.
O>>Теперь попробуйте придумать вектор атаки, которая это обойдет.
M>Запросто. И даже теги на IP (instruction pointer) нам не помешают. Будем неторопясь сливать данные в свой "хакерский" домен. Отсутствие информации тоже может быть использовано в качестве информации!
M>
M>M>Вот вам и вектор. Каждый читатель получает информацию из "хакерских данных". Если вдруг он прочитал данные с банковским тегом, он просто умирает (ничего никуда не сигналя!). Так как другие читатели знают протокол обмена, они могут восстановить "ошибки протокола" (т.е. не вышедших на связь в нужное время читателей).
M>Немного черной магии и данные извлекаются из "отсутствия данных". Чтобы с этим бороться, нужно либо анализировать как-то program flow и возможные affected vairables. Либо радостно развешивать теги на все псевдоглобальное, включая thread.sleep, сетевые взаимодействия и прочие источники, которые могут быть использованы для кражи данных. Но даже там я реализую sleep через большой цикл. И буду с интервалом ридеров пускать, а не ждать в самом ридере.
Код не разбирал, не очень есть время на это сейчас, отвечу по изложенному тексту.
Теги навешиваются на все, на самом низком уровне
Прыгая по дереву абстракций вверх — от них не спрячешься. Статус процесса — это тоже переменная в памяти, и если ее вычисленное значение зависело от некоторых данных — на нем будет тот же тег.M>Что-то мне кажется, что попытки бороться со всем этим приведут к решению "ставим теги на процесс". А это уже совсем не так интересно. Плюс результат будет похож на то, что уже есть сейчас. Всякие apparmor и прочие ограничители прав приложений (т.е. не только файловый доступ, а еще сокеты, системные ресурсы и т.п.).
Вообще моя предполагаемая архитектура если она имплементиться в хардваре — должна тегировать физическую память. Вообще всю, каждый байтик должен быть учтен. Причем память — это и ОЗУ, и диск, и регистры процессора.
Да, на х86 это все накладывать будет накладно — я не спорю, потому и писал что тот проект — был лишь прототипом. Да и смысла нет — подобная модель при ее полноценной реализации (а не как большинство секурити продуктов на рынке, которые влегкую смогут обойти сами их разработчики) не оставит места для совместимости с любыми из существующих приложений.А если его реализовывать софтварно — то только на сингулярити-образных ОС, в которых кстати уже настолько развитый контроль на памятью что там процессы и так работают в едином АП.
S>>>Велком — рассказывайте, какие операции вы собираетесь поддерживать, и как получается итоговая разметка.
O>>Любая операция принимает на вход некие данные, делает над ними некие вычисления, результат которых зависит от самой операции и от входных данных. В результате операции появляются новые данные. Причем совершенно независимо от того что там за операция — imul, xor или SSEэшное перемножение векторов, 'принадлежность' информации которая получается в ее результате однозначно определяется как объединение принадлежностей информации принимаемой на вход (всех операндов, включая регистры и IO порты) и самой операции.
M>В примере перечислено то, что покроет 95% случаев. А вот специальные 5% инструкций доставят 95% проблем. И эти 5% — условные переходы. Вот как вы собираетесь размечать результат инструкции условного перехода? Все данные после перехода будут помечены тегом данных, которые использовались в условии? А не учитывать условные переходы нельзя, иначе можно создавать информацию из воздуха.
M>
Отличный вопрос, пожалей второй адекватный вопрос за всю историю ветки Я пожалуй над ним подумаю и отвечу как нить потом, если чтонить придумаю. Ну или посыплю голову пеплом А сейчас времени мало.
UPD1: посетил определенные места и таки кое что придумал. В гипотетической архитектуре не будет условных переходов Зато будут условные call'ы и чтонибудь
UPD2: с условными переходами я погорячился. Их можно оставить. И они правда будут накладывать теги на весь execution flow до.. возврата из обычного call'а, в котором находится текущий контекст. Т.о. на call'ы будет накладываться семантика ограничения скопа тегов порожденных условными переходами. Ну и само собой надо както будет сделать невозможным фокусы а-ля push/ret'а. Например — путем разделения стека переменных и стека адресов возврата. Это не единственное возможное решение, но его существование доказывает возможность решения вообще
M>Вот так на условных переходах теги теряются. Так что нужно бы все условные переходы трейсить и навешивать теги от условия перехода. Чую, так просто от этого не отделаться будет. Расползутся теги от условного перехода по всему приложению. Вот посмотрит браузер на clipping area для вывода чего-нибудь со странички банка, и все, на всем UI-выводе будет висеть тег этого банка. Даже после того, как я закрыл все окна от него.
Почему на всем UI выводе? Если говорим об экране — это лишь кусок видеопамяти, которая по сути ничем не отличается от физической памяти, кроме того что ее содержимое видно юзеру практически как есть Потому — просто эта память должна тегироваться как и обычная, а не обзываться "всем UI выводом".
M>Еще интересные темы с межпроцессным взаимодействием. Как тегируется новый процесс?
Сущность 'процесс' ортогональна тегированию. Вкратце — советую вам в этом контексте про процессы забыть. Но если уж не забывать, то изначально процесс — это прочитанные в память файлы (они, конечно же, тоже тегируются). Вот как была протегирована информация в файлах — так она и будет протегирована в процессе. Само собой АП процесс — не рассматривается как одна единственная сущность. А любая передача данных между процессами в плане передачи тегов должна быть эквивалентна прямому копированию данных в пределах одного процесса. Поэтому разделение на процессы совершенно не добавляет ничего в плане защиты данных от угона, а может использоваться только как мера локализации непреднамеренных повреждений памяти.
O>>Теперь попробуйте придумать вектор атаки, которая это обойдет.
M>Запросто. И даже теги на IP (instruction pointer) нам не помешают. Будем неторопясь сливать данные в свой "хакерский" домен. Отсутствие информации тоже может быть использовано в качестве информации!
M>
M>Вот вам и вектор. Каждый читатель получает информацию из "хакерских данных". Если вдруг он прочитал данные с банковским тегом, он просто умирает (ничего никуда не сигналя!). Так как другие читатели знают протокол обмена, они могут восстановить "ошибки протокола" (т.е. не вышедших на связь в нужное время читателей).
M>Немного черной магии и данные извлекаются из "отсутствия данных". Чтобы с этим бороться, нужно либо анализировать как-то program flow и возможные affected vairables. Либо радостно развешивать теги на все псевдоглобальное, включая thread.sleep, сетевые взаимодействия и прочие источники, которые могут быть использованы для кражи данных. Но даже там я реализую sleep через большой цикл. И буду с интервалом ридеров пускать, а не ждать в самом ридере.
Код не разбирал, не очень есть время на это сейчас, отвечу по изложенному тексту.
Теги навешиваются на все, на самом низком уровне Прыгая по дереву абстракций вверх — от них не спрячешься. Статус процесса — это тоже переменная в памяти, и если ее вычисленное значение зависело от некоторых данных — на нем будет тот же тег.
M>Что-то мне кажется, что попытки бороться со всем этим приведут к решению "ставим теги на процесс". А это уже совсем не так интересно. Плюс результат будет похож на то, что уже есть сейчас. Всякие apparmor и прочие ограничители прав приложений (т.е. не только файловый доступ, а еще сокеты, системные ресурсы и т.п.).
Вообще моя предполагаемая архитектура если она имплементиться в хардваре — должна тегировать физическую память. Вообще всю, каждый байтик должен быть учтен. Причем память — это и ОЗУ, и диск, и регистры процессора. Да, на х86 это все накладывать будет накладно — я не спорю, потому и писал что тот проект — был лишь прототипом. Да и смысла нет — подобная модель при ее полноценной реализации (а не как большинство секурити продуктов на рынке, которые влегкую смогут обойти сами их разработчики) не оставит места для совместимости с любыми из существующих приложений.
А если его реализовывать софтварно — то только на сингулярити-образных ОС, в которых кстати уже настолько развитый контроль на памятью что там процессы и так работают в едином АП.
O>>Любая операция принимает на вход некие данные, делает над ними некие вычисления, результат которых зависит от самой операции и от входных данных. В результате операции появляются новые данные. Причем совершенно независимо от того что там за операция — imul, xor или SSEэшное перемножение векторов, 'принадлежность' информации которая получается в ее результате однозначно определяется как объединение принадлежностей информации принимаемой на вход (всех операндов, включая регистры и IO порты) и самой операции.
M>В примере перечислено то, что покроет 95% случаев. А вот специальные 5% инструкций доставят 95% проблем. И эти 5% — условные переходы. Вот как вы собираетесь размечать результат инструкции условного перехода? Все данные после перехода будут помечены тегом данных, которые использовались в условии? А не учитывать условные переходы нельзя, иначе можно создавать информацию из воздуха.
M>
M>var bankBits = bankData.asLongNumber(); //банковые данные
M>var myData = 0; //хакерские данные.
M>for (var i = 0; i < 10000; i++) {
M> if (bankBits % 2 == 0)
M> myData = myData * 2; //только хакерские данные
M> else
M> myData = myData * 2 + 1; //тоже хакерские данные
M> // Чисто банковские данные. Или нет? Хотя не важно.
M> bankBits /= 2;
M>}
M>myData.reverseBits();
M>Отличный вопрос, пожалей второй адекватный вопрос за всю историю ветки
Я пожалуй над ним подумаю и отвечу как нить потом, если чтонить придумаю. Ну или посыплю голову пеплом А сейчас времени мало.UPD1: посетил определенные места и таки кое что придумал. В гипотетической архитектуре не будет условных переходов
Зато будут условные call'ы и чтонибудь UPD2: с условными переходами я погорячился. Их можно оставить. И они правда будут накладывать теги на весь execution flow до.. возврата из обычного call'а, в котором находится текущий контекст. Т.о. на call'ы будет накладываться семантика ограничения скопа тегов порожденных условными переходами. Ну и само собой надо както будет сделать невозможным фокусы а-ля push/ret'а. Например — путем разделения стека переменных и стека адресов возврата. Это не единственное возможное решение, но его существование доказывает возможность решения вообще
M>Вот так на условных переходах теги теряются. Так что нужно бы все условные переходы трейсить и навешивать теги от условия перехода. Чую, так просто от этого не отделаться будет. Расползутся теги от условного перехода по всему приложению. Вот посмотрит браузер на clipping area для вывода чего-нибудь со странички банка, и все, на всем UI-выводе будет висеть тег этого банка. Даже после того, как я закрыл все окна от него.
Почему на всем UI выводе? Если говорим об экране — это лишь кусок видеопамяти, которая по сути ничем не отличается от физической памяти, кроме того что ее содержимое видно юзеру практически как есть
Потому — просто эта память должна тегироваться как и обычная, а не обзываться "всем UI выводом".M>Еще интересные темы с межпроцессным взаимодействием. Как тегируется новый процесс?
Сущность 'процесс' ортогональна тегированию. Вкратце — советую вам в этом контексте про процессы забыть. Но если уж не забывать, то изначально процесс — это прочитанные в память файлы (они, конечно же, тоже тегируются). Вот как была протегирована информация в файлах — так она и будет протегирована в процессе. Само собой АП процесс — не рассматривается как одна единственная сущность. А любая передача данных между процессами в плане передачи тегов должна быть эквивалентна прямому копированию данных в пределах одного процесса. Поэтому разделение на процессы совершенно не добавляет ничего в плане защиты данных от угона, а может использоваться только как мера локализации непреднамеренных повреждений памяти.
O>>Теперь попробуйте придумать вектор атаки, которая это обойдет.
M>Запросто. И даже теги на IP (instruction pointer) нам не помешают. Будем неторопясь сливать данные в свой "хакерский" домен. Отсутствие информации тоже может быть использовано в качестве информации!
M>
M>M>Вот вам и вектор. Каждый читатель получает информацию из "хакерских данных". Если вдруг он прочитал данные с банковским тегом, он просто умирает (ничего никуда не сигналя!). Так как другие читатели знают протокол обмена, они могут восстановить "ошибки протокола" (т.е. не вышедших на связь в нужное время читателей).
M>Немного черной магии и данные извлекаются из "отсутствия данных". Чтобы с этим бороться, нужно либо анализировать как-то program flow и возможные affected vairables. Либо радостно развешивать теги на все псевдоглобальное, включая thread.sleep, сетевые взаимодействия и прочие источники, которые могут быть использованы для кражи данных. Но даже там я реализую sleep через большой цикл. И буду с интервалом ридеров пускать, а не ждать в самом ридере.
Код не разбирал, не очень есть время на это сейчас, отвечу по изложенному тексту.
Теги навешиваются на все, на самом низком уровне
Прыгая по дереву абстракций вверх — от них не спрячешься. Статус процесса — это тоже переменная в памяти, и если ее вычисленное значение зависело от некоторых данных — на нем будет тот же тег.M>Что-то мне кажется, что попытки бороться со всем этим приведут к решению "ставим теги на процесс". А это уже совсем не так интересно. Плюс результат будет похож на то, что уже есть сейчас. Всякие apparmor и прочие ограничители прав приложений (т.е. не только файловый доступ, а еще сокеты, системные ресурсы и т.п.).
Вообще моя предполагаемая архитектура если она имплементиться в хардваре — должна тегировать физическую память. Вообще всю, каждый байтик должен быть учтен. Причем память — это и ОЗУ, и диск, и регистры процессора.
Да, на х86 это все накладывать будет накладно — я не спорю, потому и писал что тот проект — был лишь прототипом. Да и смысла нет — подобная модель при ее полноценной реализации (а не как большинство секурити продуктов на рынке, которые влегкую смогут обойти сами их разработчики) не оставит места для совместимости с любыми из существующих приложений.А если его реализовывать софтварно — то только на сингулярити-образных ОС, в которых кстати уже настолько развитый контроль на памятью что там процессы и так работают в едином АП.