Надежность испорченного состояния обработки исключений

Question

Я в настоящее время изучает особенности надежности и обработки исключений C#/.NET

Это особенно HandleProcessCorruptedStateExceptions атрибутов и CER s с PrepareConstrainedRegions.

Теперь я читал ссылки исходного кода SecureString класса, так как это место, где высоко безопасность важно сохранить данные зашифрованы даже в исключительных ситуациях, и нашел места подобных, как это:

[HandleProcessCorruptedStateExceptions] 
//... 

    RuntimeHelpers.PrepareConstrainedRegions(); 
    try 
    { 
     Unprotect(); 
     // ... 
    } 
    catch(Exception) 
    { 
     Protect(); 
     throw; 
    } 
    finally 
    { 
     Protect(); 
     // ... 
    } 

В чем причина блока catch? Не является ли блок finally достаточным для защиты данных?

Или могут ли эти поврежденные исключения состояния влиять только на catch и прекратить применение после этого?

Answer 1

Finally блоки почти всегда называются, за исключением нескольких случаев. См.

Does the C# "finally" block ALWAYS execute? для получения дополнительной информации.

Так что да, защита всегда называется в Finally.

Answer 2

Необходимо дублирование кода в блоке catch из-за нарушения безопасности в функции фильтрации исключений (не предоставляется C#, но Visual Basic и другие предлагают его). Он позволяет злоумышленнику выполнять свой код в блоке try-catch-finally, после того как исключение поймано и до того, как будет выполнен окончательный блок.

Угроза выглядит так: пользователь Visual Basic вашей библиотеки вызывает исключение после Unprotect() (даже OutOfMemoryException, закончив нехватку памяти), CLR не обнаруживает блокировки catch, тогда CLR выполняет код фильтра исключения пользователя, этот код крадет Unprotect (), и только тогда CLR выполняет Protect() в блоке finally.

Итак, поместите код очистки системы как в блокировки catch, так и в конце, обычная очистка остается только в конце.