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

Question

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

В особенности это атрибут HandleProcessCorruptedStateExceptions и CER с PrepareConstrainedRegions.

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

[HandleProcessCorruptedStateExceptions]
//...

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

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

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

Answer 1

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

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

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

Answer 2

Блоки

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

ВСЕГДА выполняется ли блок "finally" в C #? для более.

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