https://opennet.ru/openforum/vsluhforumID3/87203.html В процессе анализа исходных текстов клиента для работы в анонимной сети Tor обнаружена (http://www.viva64.com/ru/b/0178/) необычная уязвимость, которая может привести к оседанию в системной памяти остаточных данных, которые могут содержать конфиденциальную информацию, например, введённые пароли. Интерес представляет то, что формально код Tor не содержит ошибок и уязвимость является следствием особенностей работы некоторых компиляторов. <br><br><br>Проблема связана с тем, что Tor использует для очистки кэша функцию memset(), которая игнорируется в результате работы оптимизаторов некоторых компиляторов, что может привести к появлению неочищенных областей памяти после закрытия приложения. Например, при выборе режима оптимизации на скорость (-O2) Microsoft Visual Studio 2010 просто удаляет вызов memset при обнулении данных, если буфер в дальнейшем не используется в коде.<br><br><br>В качестве примера корректного подхода к очистке буферов приводится OpenSSL, в котором для очистки создана специальная функция, затирающая содержим https://opennet.ru/openforum/vsluhforumID3/87203.html#76 Sat, 10 Nov 2012 14:56:53 GMT &gt; Ну да, конечно, операционка сидит и протирает сотни мегов нулями после завершения <br>&gt; процесса. Заняться ей нечем, ага.<br><br>Учите матчасть.<br> https://opennet.ru/openforum/vsluhforumID3/87203.html#75 Sat, 10 Nov 2012 14:45:03 GMT м... никак?<br>вообще, у них (внезапно!) может быть другая реализация, на которой их компилятор так себя не ведет. либо, они обложили этот кусок кода прагмами с отключением оптимизации<br> https://opennet.ru/openforum/vsluhforumID3/87203.html#74 Sat, 10 Nov 2012 14:40:43 GMT &gt; *(volatile int *)0xDEADBEAF = 0; <br>&gt; *(volatile int *)0xDEADBEAF = 0; <br><br>звездочки забыл<br> https://opennet.ru/openforum/vsluhforumID3/87203.html#73 Sat, 10 Nov 2012 14:39:21 GMT &gt; 'volatile' придумали НЕ для этого: volatile придумали для того, чтобы компилятор не пытался помещать в регистр переменную, которую изменяют из другого места<br><br>... и, кроме этого, количество записей в volatile-переменную после оптимизации строго совпадало с тем, что было до нее. иными словами, компилятор не имеет права выкинуть одну из повторяющихся строк:<br>(volatile int *)0xDEADBEAF = 0;<br>(volatile int *)0xDEADBEAF = 0;<br>ровно как и:<br>i = *(const volatile int *)0xDEADBEAF;<br>i = *(const volatile int *)0xDEADBEAF;<br> https://opennet.ru/openforum/vsluhforumID3/87203.html#72 Sat, 10 Nov 2012 12:11:12 GMT Интересно как подобная проблема безопасности решается в той же реализации ssl у самих М$<br> https://opennet.ru/openforum/vsluhforumID3/87203.html#71 Sat, 10 Nov 2012 11:41:48 GMT &gt;&gt; тогда весь смысл оптимизации теряется если компилятор не вправе изменять код.<br>&gt; Он его в праве изменять только таким образом который не меняет результат <br>&gt; выполнения программы. Разное содержимое памяти после работы программы как видим может <br>&gt; являть собой проблему.<br><br>=&gt; Все программы сложнее хелловорлда проблемны.<br><br>Сейчас же вот всё надо бросить и ради разработчиков одной программы, не способных освоить опции компилятора, переписать весь компилятор. А на остальных пофиг, пускай у них код тормозит.<br> https://opennet.ru/openforum/vsluhforumID3/87203.html#70 Sat, 10 Nov 2012 11:33:16 GMT Как ни странно, компилятор работал, как его просили.<br> https://opennet.ru/openforum/vsluhforumID3/87203.html#69 Sat, 10 Nov 2012 09:49:55 GMT тест содержал буфер из 4 байт? )<br> https://opennet.ru/openforum/vsluhforumID3/87203.html#68 Sat, 10 Nov 2012 09:44:44 GMT &gt;&gt; /* Handle error */ <br>&gt; Хорошая обработка ошибок :). При том в 50% программ оно так и <br>&gt; остается :) <br><br>ну минимум туда можно всунуть return -1, для полного феншуя,<br>обработать errno и свалить всё в лог. <br><br>Кстати, а чё будет с системой, если mlock прошел, а unlock не смог или его прибили киллом 9 ?<br>