MV
то что доступны только 32-битные адреса дела не меняет
+
Size: a a a
2020 August 03
MV
ну ты можешь же просто создать статическую переменную с шеллкодом, она будет загружена в васм память
а чтобы обойти ограничение на отсутсвие прав на исполнение, применяется ROP/JOP
M
а чтобы обойти ограничение на отсутсвие прав на исполнение, применяется ROP/JOP
Еще не очень понятно как все это провернуть при рандомизации адресов, хотя для wasm песочниц это редко когда используется
MV
Еще не очень понятно как все это провернуть при рандомизации адресов, хотя для wasm песочниц это редко когда используется
вот это проблема да
lp
если речь идет о том что вдруг помимо уязвимости внутри этой libc есть еще и уязвимость в JIT'ере, то я думаю это уже совсем другая история. Например в блокчейновом случае уже и не важно если где-то там внутри вазма уязвимость - в любом случае поимеют
MV
но иногда рандомизация плохо работает
MV
если речь идет о том что вдруг помимо уязвимости внутри этой libc есть еще и уязвимость в JIT'ере, то я думаю это уже совсем другая история. Например в блокчейновом случае уже и не важно если где-то там внутри вазма уязвимость - в любом случае поимеют
нет, нам не нужна уязвимость в джиттере, здесь джиттер просто сгенерирует уязвимый код, гипотетически сможет привести к arbitrary 32-bit jump
M
нет, нам не нужна уязвимость в джиттере, здесь джиттер просто сгенерирует уязвимый код, гипотетически сможет привести к arbitrary 32-bit jump
Смотря еще какой jit. Если трассирующий то возможно
lp
не понимаю как такое может произойти. Если взять спецификацию - то это просто не возможно семантически. Если такое все таки происходит - значит присутствует уязвимость джита. Третьего варианта не дано
M
но опять же слишком много всего должно сойтись. И vm джитить (а не AOT или интерпретатор) при чем в трассирующем стиле + без рандомизации адрессов и памяти можно выделять сколько хочешь и газа бесконечность - или обмануть газ метр.
lp
опять же. если обмануть газ метр - это тоже другая история с скорее всего последующим геймовером
а то что нужна специфическая вм я тоже не уверен уязвимости то они разные бывают )
но о чем мы можем согласиться - это да много всего должно сойтись )
а то что нужна специфическая вм я тоже не уверен уязвимости то они разные бывают )
но о чем мы можем согласиться - это да много всего должно сойтись )
MV
но опять же слишком много всего должно сойтись. И vm джитить (а не AOT или интерпретатор) при чем в трассирующем стиле + без рандомизации адрессов и памяти можно выделять сколько хочешь и газа бесконечность - или обмануть газ метр.
да, но так обычно и бывает, я попробую сделать poc
MV
да, но так обычно и бывает, я попробую сделать poc
в смысле, что эксплуатировать сложно и обычно нужно несколько уязвимостей
M
Ну и при oob ты же не сможешь ничего записать в guarded страницу. ОС просто не даст тебе это сделать. Не очень понимаю как это вожможно?
MV
а нам и не нужно ничего записывать за guarded page
MV
я попробую накидать poc попозже, мб я где-то не прав
M
Тогда зачем эксплуатировать oob?
MV
а, я всё -таки ошибаюсь
MV
Тогда зачем эксплуатировать oob?
изначально в моей идее для передачи управления по контролируемому адресу
MV
например, в способе эксплуатации dlmalloc под названием house of force можно добиться произвольной перезаписи памяти и перезаписать какой-нибудь указатель в libc. Обычно переписывают какие-нибудь указатели на коллбеки в глобальных stdin/stdout. Но они потом будут вызваны с помощью call_indirect и будут проверены по условной таблице соответствия адреса функции типу. Вот тут как раз мои рассуждения ошибочны.