> Так ведь и он создан с учётом того, что "неведома зверушка" интерпретируется как то, что мы укажем. В то время как в шарпе всё-таки неведомых зверушек нет. То есть если ты передаёшь число, а в строке форматирования указываешь %s - как должен вести себя шарп?
Ага, ага. Вот я передал, например, объект класса System.Thread, а в спецификаторе формата указал {0:U} (длинное универсальное время). Как ты думаешь, куда меня пошлёт исполняющая система? И чем тут новые форматы отличаются от старых?
Синтаксис формата для контроля передаваемых типов - неважен. Важно что форматтер должен во всех случаях, когда он не знает как перевести, возбудить исключение. Для [s][n]printf эта же методика подойдёт без изменений.
> Да-да, только это поздновато IMHO. Уже, видишь, и NX-биты в процессорах вводить начали :)
И что тебе дадут те NX-биты? Прямое исполнение кода в стеке - только самый тупой вариант exploit'а, от него уже защитились все кому не лень. wu-ftpd уже года три назад как ломали через модификацию числовой переменной в стеке рядом с переполнившимся буфером и как следствие - нарушение логики работы.
no subject
Date: 2005-09-03 09:12 am (UTC)Ага, ага. Вот я передал, например, объект класса System.Thread, а в спецификаторе формата указал {0:U} (длинное универсальное время). Как ты думаешь, куда меня пошлёт исполняющая система? И чем тут новые форматы отличаются от старых?
Синтаксис формата для контроля передаваемых типов - неважен. Важно что форматтер должен во всех случаях, когда он не знает как перевести, возбудить исключение. Для [s][n]printf эта же методика подойдёт без изменений.
> Да-да, только это поздновато IMHO. Уже, видишь, и NX-биты в процессорах вводить начали :)
И что тебе дадут те NX-биты? Прямое исполнение кода в стеке - только самый тупой вариант exploit'а, от него уже защитились все кому не лень. wu-ftpd уже года три назад как ломали через модификацию числовой переменной в стеке рядом с переполнившимся буфером и как следствие - нарушение логики работы.