Сообщение Re[3]: Единое адрессное пространство от 21.08.2019 17:15
Изменено 21.08.2019 17:18 IID
Re[3]: Единое адрессное пространство
Здравствуйте, Эйнсток Файр, Вы писали:
B>>> можно передавать между процессами указатели напрямую
IID>> Для этого указатель должен быть подписан выдающей стороной. Иначе ДЫРИЩА в безопасности.
ЭФ>Непонятно почему дырища, и как там может образоваться man-in-the-middle, когда прикладная программа вызывает ядро и обрабатывает из ядра коллбэки.
причём тут MITM
Я о соседних с тобой процессах. Чтобы было понятнее — менее привелегированных. Или содержащих "вкусные" данные (тут вообще полный швах, очевидно).
Представь, у тебя в программе нашли баг (переполнение буфера на стеке, использование уже удалённого объекта, и т.д.)
Причиной бага может быть незначительный дефект в синхронизации. Который даст буквально сотню машинных тактов. Этого может оказаться (и оказывалось) достаточно.
Итак.
Злоумышленник может передать управление на произвольный адрес.
Что ему ещё надо ?
Ему надо как-то разместить в атакуемом приложении полезную нагрузку и запустить её.
Полезная нагрузка не может быть кодом года эдак с 2006, когда началась более-менее массовая поддержка жезелом NoneXecutable бита в MMU.
Значит полезная нагрузка это данные.
Т.е. злоумышленнику надо
— как-то разместить данные в твоей программе. В случае переполнения буфера — его можно сразу переполнить нужными данными. Но как понять где их адрес ?
— передать управление на уже имеющийся в программе код, инициировав ROP/JOP/FOP.
В классическом случае злоумышленнику мешают:
— изоляция адресного пространства
— ASLR
— Heap Randomization
В твоём варианте злоумышленнику не мешает НИЧЕГО.
Даже древние "черви Морриса" смогут обрести новое дыхание, которое им перекрыли стековыми канарейками в конце 90х.
!!!КСТАТИ!!!
1) как предполагается защищаться от изменения writable данных ? Злоумышленник находит такой блок (АП-то общее!), и повреждает его, провоцируя твою программу начать исполнение вредоносного кода.
2) как предполагается защищаться от изменения прочих данных ? Я отдал тебе ReadOnly буфер на парсинг, и продолжаю его менять. Классическое TICTOE ведь, на котором были сломаны защиты миллионов устройств.
3) что будет если злоумышленник передаст управление из атакованной программы НА СЕБЯ ?
По п.3: именно так работали ядерные эксплоиты где-то до 2010-2013 года. Передавая управление на полезную нагрузку в юзермод — при этом юзерский код исполнялся с уровнем привилегий ядра ОС.
Разрабочикам процессоров ПРИШЛОСЬ сделать SMEP/PXN, а затем и SMAP/PAN. Что резко и сильно усложнило эксплуатацию уязвимостей в ядре.
Т.е. даже ПРОСТО ЧИТАТЬ память это ОПАСНО. Даже для читателя. Понимаешь ?
B>> может какието хипстеры из какогото стремного АРМ уже такое сделали?
ЭФ>Я читал, что такое было реализовно в TempleOS
Ага, которая падает по каждому чиху.
А почему не MS-DOS кстати ? Там было ровно то же самое.
B>>> можно передавать между процессами указатели напрямую
IID>> Для этого указатель должен быть подписан выдающей стороной. Иначе ДЫРИЩА в безопасности.
ЭФ>Непонятно почему дырища, и как там может образоваться man-in-the-middle, когда прикладная программа вызывает ядро и обрабатывает из ядра коллбэки.
причём тут MITM
Я о соседних с тобой процессах. Чтобы было понятнее — менее привелегированных. Или содержащих "вкусные" данные (тут вообще полный швах, очевидно).
Представь, у тебя в программе нашли баг (переполнение буфера на стеке, использование уже удалённого объекта, и т.д.)
Причиной бага может быть незначительный дефект в синхронизации. Который даст буквально сотню машинных тактов. Этого может оказаться (и оказывалось) достаточно.
Итак.
Злоумышленник может передать управление на произвольный адрес.
Что ему ещё надо ?
Ему надо как-то разместить в атакуемом приложении полезную нагрузку и запустить её.
Полезная нагрузка не может быть кодом года эдак с 2006, когда началась более-менее массовая поддержка жезелом NoneXecutable бита в MMU.
Значит полезная нагрузка это данные.
Т.е. злоумышленнику надо
— как-то разместить данные в твоей программе. В случае переполнения буфера — его можно сразу переполнить нужными данными. Но как понять где их адрес ?
— передать управление на уже имеющийся в программе код, инициировав ROP/JOP/FOP.
В классическом случае злоумышленнику мешают:
— изоляция адресного пространства
— ASLR
— Heap Randomization
В твоём варианте злоумышленнику не мешает НИЧЕГО.
Даже древние "черви Морриса" смогут обрести новое дыхание, которое им перекрыли стековыми канарейками в конце 90х.
!!!КСТАТИ!!!
1) как предполагается защищаться от изменения writable данных ? Злоумышленник находит такой блок (АП-то общее!), и повреждает его, провоцируя твою программу начать исполнение вредоносного кода.
2) как предполагается защищаться от изменения прочих данных ? Я отдал тебе ReadOnly буфер на парсинг, и продолжаю его менять. Классическое TICTOE ведь, на котором были сломаны защиты миллионов устройств.
3) что будет если злоумышленник передаст управление из атакованной программы НА СЕБЯ ?
По п.3: именно так работали ядерные эксплоиты где-то до 2010-2013 года. Передавая управление на полезную нагрузку в юзермод — при этом юзерский код исполнялся с уровнем привилегий ядра ОС.
Разрабочикам процессоров ПРИШЛОСЬ сделать SMEP/PXN, а затем и SMAP/PAN. Что резко и сильно усложнило эксплуатацию уязвимостей в ядре.
Т.е. даже ПРОСТО ЧИТАТЬ память это ОПАСНО. Даже для читателя. Понимаешь ?
B>> может какието хипстеры из какогото стремного АРМ уже такое сделали?
ЭФ>Я читал, что такое было реализовно в TempleOS
Ага, которая падает по каждому чиху.
А почему не MS-DOS кстати ? Там было ровно то же самое.
Re[3]: Единое адрессное пространство
Здравствуйте, Эйнсток Файр, Вы писали:
B>>> можно передавать между процессами указатели напрямую
IID>> Для этого указатель должен быть подписан выдающей стороной. Иначе ДЫРИЩА в безопасности.
ЭФ>Непонятно почему дырища, и как там может образоваться man-in-the-middle, когда прикладная программа вызывает ядро и обрабатывает из ядра коллбэки.
причём тут MITM
Я о соседних с тобой процессах. Чтобы было понятнее — менее привелегированных. Или содержащих "вкусные" данные (тут вообще полный швах, очевидно).
Представь, у тебя в программе нашли баг (переполнение буфера на стеке, использование уже удалённого объекта, и т.д.)
Причиной бага может быть незначительный дефект в синхронизации. Который даст буквально сотню машинных тактов. Этого может оказаться (и оказывалось) достаточно.
Итак.
Злоумышленник может передать управление на произвольный адрес.
Что ему ещё надо ?
Ему надо как-то разместить в атакуемом приложении полезную нагрузку и запустить её.
Полезная нагрузка не может быть кодом года эдак с 2006, когда началась более-менее массовая поддержка жезелом NoneXecutable бита в MMU.
Значит полезная нагрузка это данные.
Т.е. злоумышленнику надо
— как-то разместить данные в твоей программе. В случае переполнения буфера — его можно сразу переполнить нужными данными. Но как понять где их адрес ?
— передать управление на уже имеющийся в программе код, инициировав ROP/JOP/FOP. Но как найти адрес твоего (и системного кода) ?
В классическом случае злоумышленнику мешают:
— изоляция адресного пространства
— ASLR
— Heap Randomization
В твоём варианте злоумышленнику не мешает НИЧЕГО.
Даже древние "черви Морриса" смогут обрести новое дыхание, которое им перекрыли стековыми канарейками в конце 90х.
!!!КСТАТИ!!!
1) как предполагается защищаться от изменения writable данных ? Злоумышленник находит такой блок (АП-то общее!), и повреждает его, провоцируя твою программу начать исполнение вредоносного кода.
2) как предполагается защищаться от изменения прочих данных ? Я отдал тебе ReadOnly буфер на парсинг, и продолжаю его менять. Классическое TICTOE ведь, на котором были сломаны защиты миллионов устройств.
3) что будет если злоумышленник передаст управление из атакованной программы НА СЕБЯ ?
По п.3: именно так работали ядерные эксплоиты где-то до 2010-2013 года. Передавая управление на полезную нагрузку в юзермод — при этом юзерский код исполнялся с уровнем привилегий ядра ОС.
Разрабочикам процессоров ПРИШЛОСЬ сделать SMEP/PXN, а затем и SMAP/PAN. Что резко и сильно усложнило эксплуатацию уязвимостей в ядре.
Т.е. даже ПРОСТО ЧИТАТЬ память это ОПАСНО. Даже для читателя. Понимаешь ?
B>> может какието хипстеры из какогото стремного АРМ уже такое сделали?
ЭФ>Я читал, что такое было реализовно в TempleOS
Ага, которая падает по каждому чиху.
А почему не MS-DOS кстати ? Там было ровно то же самое.
B>>> можно передавать между процессами указатели напрямую
IID>> Для этого указатель должен быть подписан выдающей стороной. Иначе ДЫРИЩА в безопасности.
ЭФ>Непонятно почему дырища, и как там может образоваться man-in-the-middle, когда прикладная программа вызывает ядро и обрабатывает из ядра коллбэки.
причём тут MITM
Я о соседних с тобой процессах. Чтобы было понятнее — менее привелегированных. Или содержащих "вкусные" данные (тут вообще полный швах, очевидно).
Представь, у тебя в программе нашли баг (переполнение буфера на стеке, использование уже удалённого объекта, и т.д.)
Причиной бага может быть незначительный дефект в синхронизации. Который даст буквально сотню машинных тактов. Этого может оказаться (и оказывалось) достаточно.
Итак.
Злоумышленник может передать управление на произвольный адрес.
Что ему ещё надо ?
Ему надо как-то разместить в атакуемом приложении полезную нагрузку и запустить её.
Полезная нагрузка не может быть кодом года эдак с 2006, когда началась более-менее массовая поддержка жезелом NoneXecutable бита в MMU.
Значит полезная нагрузка это данные.
Т.е. злоумышленнику надо
— как-то разместить данные в твоей программе. В случае переполнения буфера — его можно сразу переполнить нужными данными. Но как понять где их адрес ?
— передать управление на уже имеющийся в программе код, инициировав ROP/JOP/FOP. Но как найти адрес твоего (и системного кода) ?
В классическом случае злоумышленнику мешают:
— изоляция адресного пространства
— ASLR
— Heap Randomization
В твоём варианте злоумышленнику не мешает НИЧЕГО.
Даже древние "черви Морриса" смогут обрести новое дыхание, которое им перекрыли стековыми канарейками в конце 90х.
!!!КСТАТИ!!!
1) как предполагается защищаться от изменения writable данных ? Злоумышленник находит такой блок (АП-то общее!), и повреждает его, провоцируя твою программу начать исполнение вредоносного кода.
2) как предполагается защищаться от изменения прочих данных ? Я отдал тебе ReadOnly буфер на парсинг, и продолжаю его менять. Классическое TICTOE ведь, на котором были сломаны защиты миллионов устройств.
3) что будет если злоумышленник передаст управление из атакованной программы НА СЕБЯ ?
По п.3: именно так работали ядерные эксплоиты где-то до 2010-2013 года. Передавая управление на полезную нагрузку в юзермод — при этом юзерский код исполнялся с уровнем привилегий ядра ОС.
Разрабочикам процессоров ПРИШЛОСЬ сделать SMEP/PXN, а затем и SMAP/PAN. Что резко и сильно усложнило эксплуатацию уязвимостей в ядре.
Т.е. даже ПРОСТО ЧИТАТЬ память это ОПАСНО. Даже для читателя. Понимаешь ?
B>> может какието хипстеры из какогото стремного АРМ уже такое сделали?
ЭФ>Я читал, что такое было реализовно в TempleOS
Ага, которая падает по каждому чиху.
А почему не MS-DOS кстати ? Там было ровно то же самое.