дизассемблерный листинг
Canary word защищает не только адрес возврата, но и кадр, что очень хорошо, правда в оптимизированном коде, генерируемый этим же самым компилятором, локальные переменные адресуются непосредственно через ESP и дополнительный регистр им не нужен, поэтому, фактически защищается только один адрес возврата. Остальные переменные остаются незащищенными, что открывает простор для махинаций с указателями. В частности, хакер может перезаписать глобальную переменную canary своим значением — тогда его проверка пройдет нормально. Это даже упрощает (!) атаку: в незащищенной системе существует проблема ввода "запрещенных" символов, которую не всегда возможно обойти. Операция XOR позволяет генерировать любые символы! В частности, чтобы сформировать символ нуля, достаточно положить в canary и зашифрованный адрес возврата два одинаковых символа. Как известно X XOR X = 0. Остальные символы генерируются аналогичным способом.
Самое интересное, что Microsoft переняла ошибку ранних версий Stack-Guard, причем даже не его ошибку, а особенность поведения компилятора GCC, позволяющую атакующему воздействовать на регистр ESP через модификацию указателя кадра стека. Microsoft Visual C++ 6.0 закрывал кадр стека безопасной конструкций ADD ESP,XXX, а .NET вместо этого использует MOV ESP, EBP. И хотя указатель кадра защищен canary word, это еще не повод ослаблять защиту! Canary word генерируется не совсем случайным путем и угадать его с нескольких попыток вполне реально, ну а инструкция XOR позволит подделать любой символ. Короче говоря, если бы в Microsoft думали головой…
