| 1.1, аноним2 (?), 10:11, 09/11/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– | |
> ...вместо размера буфера передаётся размер указателя на буфер...
Веселые кодеры, блин. Банальнейший эпик-фейл.
| | |
| |
| 2.9, XoRe (ok), 13:12, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
 >> ...вместо размера буфера передаётся размер указателя на буфер...
> Веселые кодеры, блин. Банальнейший эпик-фейл.
Да ладно, вопрос одного символа (*|&).
| | |
| |
| 3.59, Аноним (-), 10:44, 10/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> <facepalm> тесты писать не?
Для сабжевого случая это довольно сложно. Потому что тестировать всю операционку, все либы вообще и компилер - это немножечко так напряжно.
| | |
|
|
| 1.2, Анонимус_б6 (?), 10:12, 09/11/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
чем сложнее системы, тем все более странные проблемы они вызывают и тем сложнее^3 их исследовать на предмет странностей
| | |
| 1.4, Andrew Kolchoogin (?), 10:41, 09/11/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– | |
Мне вот только непонятна мысль автора статьи насчёт того, что "компилятор ВПРАВЕ удалить вызов memset(), если ... " -- это в каком стандарте на C написано, что компилятор чего-то там вправе УДАЛЯТЬ?
Но всё равно и Tor, и OpenSSL поступают плохо. Надо, конечно, звать mlock(), потом затирать (плевать, чем -- нулями тоже сойдёт), а потом звать munlock().
| | |
| |
| 2.5, BratSinot (?), 11:49, 09/11/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Мне вот только непонятна мысль автора статьи насчёт того, что "компилятор ВПРАВЕ удалить вызов memset(), если ... " -- это в каком стандарте на C написано, что компилятор чего-то там вправе УДАЛЯТЬ?
А чего там непонятного? Компилятор вправе делать что ему вздумается до тех пор, пока это не влияет на конечный результат, что собственно и происходит с memset.
| | |
| |
| 3.6, Аноним (-), 12:27, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
То есть, игнорирование функции memset — это нормальное действие компилятора?! На мыло такие компиляторы!!!
| | |
| |
| 4.7, CssfPZS (ok), 12:43, 09/11/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
 >Например, при выборе режима оптимизации на скорость (-O2) Microsoft Visual Studio 2010
>просто удаляет вызов memset при обнулении данных, если буфер в дальнейшем не используется
>в коде.
Там же не про GCC написано =)
А так все логично, говно компилятор от Microsoft Visual Studio 2010, под говно платформой
дает говно результат.
Как дуршлаг не латай, все равно дырявый, так что или безопасность или винда.
| | |
| |
| 5.22, kuku (?), 13:45, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
+1
Мелкософт мог бы предупредить об этой "оптимизации"...
Или вывести список таких "оптимизации".
А так остаётся ответить, что это не адекватно со стороны
"кого-то там" где-то там...
| | |
| |
| 6.33, Aaa (?), 17:42, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
ну вообще то gcc на этой теме тоже когда-то светился
| | |
| |
| 7.35, Aaa (?), 17:45, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
помнится кто-то даже выступал по этой теме и было предложено помечать такие функции как обязательные к исполнению и оптимизатор их не должен трогать, вот только сдвинулось ли с места - не знаю
| | |
|
|
|
| 4.11, Аноним (-), 13:14, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
При включенной оптимизации - да. Если ты не хочешь чтобы компилятор компилировал именно то, что ты написал, тебе необходимо отключить оптимизацию.
Твой кэп.
| | |
| |
| |
| 6.23, Аноним (-), 13:54, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>При включенной оптимизации - да. Если ты не хочешь чтобы компилятор компилировал именно то, что ты написал, тебе необходимо отключить оптимизацию.
>>Твой кэп.
>>наоборот, Кэп
Если ты не хочешь чтобы компилятор компилировал именно то, что ты написал, тебе необходимо включать оптимизацию, так что-ли?
| | |
| |
| 7.31, pavlinux (ok), 16:00, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
 проверять надо возвращаемые значения. А прогах по безопасности еще и повторную проверку вставлять.
| | |
|
|
| 5.41, Аноним (-), 19:14, 09/11/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Твой кэп.
Хреновый кэп. Если оптимизация ломает поведение программы, это, пардон, буллшит.
| | |
| |
| 6.55, Аноним (-), 01:30, 10/11/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
Буллшит - это когда чудаки пальцем тыкают не подумав, а потом удивляются, чо это оно не работает.
| | |
| |
| 7.61, Аноним (-), 10:46, 10/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Буллшит - это когда чудаки пальцем тыкают не подумав, а потом удивляются,
> чо это оно не работает.
Ну надо же какие наглецы, полагают что компилятор должен работать как просят и не подкладывать свинью.
| | |
|
|
|
|
| 3.8, Аноним (-), 12:50, 09/11/2012 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> до тех пор, пока это не влияет на конечный результат
Удаление memset в данном случае, как показано, влияет на конечный результат, просто компилятор не в состоянии определить что эта память потом используется. Соответственно это ошибка в Visual Studio.
| | |
| |
| 4.10, rain87 (?), 13:14, 09/11/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
так память и не используется. данные просто остаются в памяти, в этом и потенциальная уязвимость. в целом к компилятору придраться нельзя, с его точки зрения он всё правильно сделал
| | |
| |
| |
| 6.20, Xasd (ok), 13:38, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Глядя на данную проблему, все таки можно придраться.
где проблема-то? как ты получишь доступ к этой [не очищенной] памяти?
разработаешь rootkit и заразишь им компьютер? но с такимже успехом ты можешь разработать rootkit и ЗАРАНЕЕ заразить систему чтобы она делала ежесекундный разбор и сохранение нужных участков оперативной памяти... никакой super_forced_memset() не поможет
| | |
|
|
| 4.14, kai (??), 13:33, 09/11/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Удаляй memset() @ будь плохим парнем^W компилятором
| | |
| 4.27, Anonplus (?), 15:36, 09/11/2012 [^] [^^] [^^^] [ответить]
| +4 +/– |
Компилятор делает все правильно. Он видит, что эта память потом нигде не используется. Значит и очищать ее незачем. В этом и есть суть оптимизаций - выкидывается "лишний" код. Если вы хотите эту память непременно очистить (из соображений секьюрности) - пишите отдельную собственную функцию для очистки памяти, вместо дефолтной. Или отключайте режим оптимизации, тогда компилятор скомпилирует все именно так, как вы написали. Но уж будьте любезны, тогда, писать сразу быстрый код, так как оптимизация ложится на ваши плечи.
| | |
| |
| 5.36, Andrew Kolchoogin (?), 18:34, 09/11/2012 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Он видит, что эта память потом нигде не используется. Значит и очищать ее незачем.
Ой. Лихо вы...
Смотрите. Единица трансляции -- это файлы .c, перечисленные в командной строке компилятора, плюс всё то, что в них поместит препроцессор оператором #include. Компилятор не вправе предполагать, что какие-то другие файлы в операционной системе вообще существуют.
А теперь, внимание, фокус: в первом исходнике я пишу код, в котором аллоцирую ОЗУ, и вызываю функцию, находящуюся во втором исходнике, которой передаю указатель на вышеупомянутую область ОЗУ. В этой функции я делаю pthread_create() -- система у меня с MMU, мне можно -- и из дочернего потока вызываю функцию из третьего исходника, в которой делаю memset() этой области данными вида 0xaa55 -- и всё, "закрывающая фигурная скобка" (tm).
Я что, не вправе ожидать, что поток-создатель там эти 0xaa55 увидит, если включу оптимизацию у компилятора?
Или C-компилятор у нас теперь стал stateful, и сохраняет информацию обо всех оттранслированных ими файлах за всё время, начиная с установки операционной системы?
Или он магически должен догадаться, что я в предыдущем исходнике поток создал, и слежу за этой же областью ОЗУ из, так сказать, "другого места"?
| | |
| |
| 6.45, aaa (??), 20:32, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
>> Или он магически должен догадаться, что я в предыдущем исходнике поток создал, и слежу за этой же областью ОЗУ из, так сказать, "другого места"?
для этого и придумали volatile
иначе если ты в программе нигде ее больше не используешь то компилятор вправе выкинуть этот memset, дабы не делать лишнюю работу (результаты которой все-равно никому не нужны)
| | |
| |
| 7.48, Andrew Kolchoogin (?), 20:36, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>> Или он магически должен догадаться, что я в предыдущем исходнике поток создал,
>>> и слежу за этой же областью ОЗУ из, так сказать, "другого места"?
> для этого и придумали volatile
'volatile' придумали НЕ для этого: volatile придумали для того, чтобы компилятор не пытался помещать в регистр переменную, которую изменяют из другого места.
Но вот про выкидывание кода ни в одном стандарте нигде ничего не написано.
> иначе если ты в программе нигде ее больше не используешь то компилятор
> вправе выкинуть этот memset, дабы не делать лишнюю работу (результаты которой
> все-равно никому не нужны)
Ссылку на документ, согласно которому компилятор чего-то там "вправе выкинуть", в студию.
| | |
| |
| 8.52, aaa (??), 20:56, 09/11/2012 [^] [^^] [^^^] [ответить] | +/– | тогда весь смысл оптимизации теряется если компилятор не вправе изменять код С ... текст свёрнут, показать | | |
| |
| 9.62, Аноним (-), 10:47, 10/11/2012 [^] [^^] [^^^] [ответить] | +/– | Он его в праве изменять только таким образом который не меняет результат выполне... текст свёрнут, показать | | |
|
|
|
| 6.58, Xasd (ok), 04:52, 10/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Или он магически должен догадаться, что я в предыдущем исходнике поток создал, и слежу за этой же областью ОЗУ из, так сказать, "другого места"?
а думаешь компилятор не сможет понять -- используется ли некая переменная (указатель на блок памяти) -- ТОЛЬКО в одном исходном файле, или же существуют внешние (extern) функции которые способны этот указатель передать во вне... ыыыЫЫ?
помоему вполне логично предположить что если некий указатель замешан (напрямую или внутри структуры) на параметры extern-функции -- то значит НЕ НАДО делать связанные с ним высокоуровневые оптимизации.
...соответственно компилятор делать их и НЕ будет :-)
точнее говоря -- компилятор будет делать высокоуровневые оптимизации только если уверен что переменная (указатель на блок памяти) не имеет связи с "внешним миром".
# P.S.: ну и конешно же я надеюсь что когда ты пишешь программу на C/C++ -- то ты же НЕ используешь всякие "неопределённые поведения (undefined behaviour)"? а если используешь -- то значит ты сам себе злобный буратино, стреляющий себе в ногу :).
| | |
|
|
|
|
|
| 1.12, Xasd (ok), 13:29, 09/11/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> вместо размера буфера передаётся размер указателя на буфер
строгая типизайия -- оказалась не такая уж и строгая [для функции сёравно какой-именно int ей забирать :-D]
...а вот любители утиной типизации -- 20 раз проверят (глазами, и/или тэстами) свой код на то чтобы он делал то что надо.
| | |
| |
| 2.26, Crazy Alex (ok), 14:50, 09/11/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Какая, на фиг, строгая типизация в сях? Ох уж эти фанатики, вечно болтают, не разбираясь в предмете...
| | |
|
| 1.17, Xasd (ok), 13:35, 09/11/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
вообще говоря -- что-то мне не нравится что программы пытаются брать на себя функции операционной системы.
программа должна сделать ТОЛЬКО ''delete[] my_secret_array'' и дальше НЕ ОБЯЗАНА следить чтобы это утекло из оперативной памяти.
...за приватностью оперативной и виртуальной памяти -- должна следить операционная система.
не так уж и сложно сделать внутри /etc/crypttab -- строчку связанную со SWAP [этим должны заниматсья разработчики дистрибутивов, конешно же, а не простые пользователи].
малоли какие алгоритмы существуют в операционной системе для работы с памятью, и это ну точно не должно волновать прикладную программу!
| | |
| |
| |
| 3.21, Xasd (ok), 13:44, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Tor не совсем уж прикладная программа.
Tor -- конешно же -- да -- необычная программа.
..но обсуждаемая проблема как я понимаю касается вообще любой программы которая работает с паролями, например.
сейчас наверно почти каждый-второй разработчик какого-нибудь своего демона -- читая эту тему и думает:
"""
ой! щаз надо обязательно вставить: mlock() и munlock() в исходный код демона (в функцию очищения паролей из памяти)!
приватность в опасности!!!
"""
| | |
| |
| 4.40, Аноним (-), 19:05, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
Все верно, без явной поддержки со стороны ОС, я даже и не придумаю, как это можно надежно решить. Нужен отдельный сист. вызов.
| | |
|
| 3.63, Аноним (-), 10:48, 10/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Tor не совсем уж прикладная программа.
А какая, пардон? Прикладуха самая обычная. Ну, как прокси-сервак например.
| | |
|
| 2.25, Аноним (-), 14:47, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> программа должна сделать ТОЛЬКО ''delete[] my_secret_array'' и дальше НЕ ОБЯЗАНА следить чтобы это утекло из оперативной памяти
И тормозить будет твоя операционка нещадно, затирая содержимое памяти после каждого delete.
| | |
| 2.29, Аноним (-), 15:43, 09/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
> программа должна сделать ТОЛЬКО ''delete[] my_secret_array'' и дальше НЕ ОБЯЗАНА следить
> чтобы это утекло из оперативной памяти.
Программы бывают разные. Вот в частности с криптографическими ключами намного лучше если программа явно рулит памятью и может явно изничтожить ключ в известный ей момент времени. Во избежание всяких идиотских сюрпризов типа: программа заверщилась а следующая получила память с ключом, ибо GC соптимихировал немного и забил на зануление памяти, т.к. та прога не заказывала инициализированную область. А то что она чужой ключ прочла - ой, фигня получилась!
| | |
| |
| 3.56, Xasd (ok), 04:24, 10/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Во избежание всяких идиотских сюрпризов типа: программа заверщилась а следующая получила память с ключом
<sarcasm>ды щаз! 25 раз получит новая программа необнулённую память!</sarcasm> ЛОЛ :-D ! это же просто смешно!
такое только в MS-DOS было
| | |
| |
| 4.64, Аноним (-), 10:50, 10/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> такое только в MS-DOS было
Ну да, конечно, операционка сидит и протирает сотни мегов нулями после завершения процесса. Заняться ей нечем, ага.
| | |
| |
| 5.76, XPEH (?), 18:56, 10/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Ну да, конечно, операционка сидит и протирает сотни мегов нулями после завершения
> процесса. Заняться ей нечем, ага.
Учите матчасть.
| | |
|
|
|
|
| 1.28, Аноним (-), 15:41, 09/11/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
> Microsoft Visual Studio 2010 просто удаляет вызов memset
Бюро Медвежьих Услуг.
| | |
| |
| 2.44, Crazy Alex (ok), 20:22, 09/11/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
GCC -O3 делает то же самое, насколько мне известно. Думаю, что и другие компиляторы в процессе оптимизации тоже выкидывают какие-либо действия с областями памяти,которые в дальнейшем не используются. Освобождаемый стек - типичный пример. И для подавляющего большиснтва приложений это оптимлаьная стратегия. А если пишешь экзотику - принимай специальные меры, это вполне возможно. В общем, нормальная ситуация - дефолтная реализация удобная для большиснства, а меньшинство может с разумными затратами сделать так, как ему нужно (в данном случае - использовать вместо memset свою аналогичную функцию).
| | |
| |
| 3.65, Аноним (-), 10:50, 10/11/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> GCC -O3 делает то же самое,
-O3 это вообще небезопасная оптимизация в GCC на свой страх и риск. Стабильным и беспроблемным является -O2. Им все вменяемые люди и пользуются.
| | |
|
| 2.57, Xasd (ok), 04:28, 10/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Microsoft Visual Studio 2010 просто удаляет вызов memset
> Бюро Медвежьих Услуг.
в чём заключается медвежья услуга?
уязвимость -- сугубо теоретическая.
если не обнулился блок-памяти щаз, значит обнулится чуть по-пожже.
в этом и заключается оптимизация!
если бы блок памяти не обнулялся бы ВООБЩЕ (и доставался в таком виде другой программе) -- вот тут бы тогда можно было бы начать говорить про медведей :) .
но реальность такова что ново-запущенным программам -- достаются уже подчищенные кусочки памяти [а уж в какой конкретно момент они были подчищенны -- не всё ли равно?]
| | |
| |
| 3.66, Аноним (-), 10:51, 10/11/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> в чём заключается медвежья услуга?
В том что результат выполнения программы изменился.
> уязвимость -- сугубо теоретическая.
Не, извините, возможность посторонним хапнуть ключ/пароль/... откуда-то слева - это даже теоретически очень плохо.
| | |
|
|
| 1.38, vi (?), 18:46, 09/11/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > В процессе анализа исходных текстов клиента для работы в анонимной сети Tor
> обнаружена (http://www.viva64.com/ru/b/0178/) необычная уязвимость
> при выборе режима оптимизации на скорость (-O2) Microsoft Visual Studio 2010
> просто удаляет вызов memset при обнулении данных, если буфер в дальнейшем
Зачем, достали, очередной зонд из ... пользователей offtop/
| | |
| 1.72, Аноним (-), 16:11, 10/11/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Интересно как подобная проблема безопасности решается в той же реализации ssl у самих М$
| | |
| |
| 2.75, ваноним (?), 18:45, 10/11/2012 [^] [^^] [^^^] [ответить]
| +/– |
м... никак?
вообще, у них (внезапно!) может быть другая реализация, на которой их компилятор так себя не ведет. либо, они обложили этот кусок кода прагмами с отключением оптимизации
| | |
|
|
