URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 95360
[ Назад ]

Исходное сообщение
"Akamai предложил безопасную систему распределения памяти для..."

Отправлено opennews , 13-Апр-14 00:22 
Обеспокоенная вопросом обеспечения высокого уровня безопасности проекта OpenSSL, компания Akamai (http://ru.wikipedia.org/wiki/Akamai_Technologies), поддерживающая крупнейшую сеть доставки контента, предложила (https://blogs.akamai.com/2014/04/heartbleed-update.html) разработчикам OpenSSL патч (http://thread.gmane.org/gmane.comp.encryption.openssl.user/5... с реализацией нового менеджера распределения памяти, позволяющего обеспечить безопасное нахождение в оперативной памяти приватных ключей.


Для хранения особо важных данных, таких как RSA-ключи, вместо OPENSSL_malloc предлагается использовать  функцию secure_malloc,  размещающую данные в безопасной области, помещённой в отдельной куче (сформированный через mmap непрерывный регион памяти)  и обрамлённой сверху и снизу  дополнительными защищающими страницами памяти, мешающими проникновению по блуждающим указателям. Кроме того, выделяемая через secure_malloc область закреплена за ОЗУ и не может быть вытеснена или отображена на диск, а также, когда это возможно, не будет фигурировать с core-дампах.

Реализация secure_malloc основана на коде, уже около десяти лет используемом в Akamai для надёжной защиты ключей пользователей. Тем не менее, патч является скорее прототипом для реализации похожей системы, чем решением, готовым для немедленного внедрения в OpenSSL. Например, патч не заботится о переносимости и привязывается к коду ASN1 вместо создания нового API. При этом, если бы подобная технология была добавлена в OpenSSL раньше, она бы позволила избежать утечки закрытых ключей из памяти в процессе эксплуатации уязвимости Heartbleed (http://www.opennet.me/opennews/art.shtml?num=39518).


URL: https://blogs.akamai.com/2014/04/heartbleed-update.html
Новость: http://www.opennet.me/opennews/art.shtml?num=39560


Содержание

Сообщения в этом обсуждении
"Akamai предложил безопасную систему распределения памяти для..."
Отправлено anonymous , 13-Апр-14 00:22 
Что плохого в ASN.1, если это тот ASN.1? Как раз-таки новые API будут явно хуже... А переносимость - взять либу из net-snmp и норм. Ну, виндyзятникoв не считаем, они должны cтрадaть.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 00:29 
Оно и видно - у openssl замечательное API. Правда, секурно им пользоваться никто толком не может, и в каждой первой программе можно найти дюжину различных продолбов, за редким исключением.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Sabakwaka , 13-Апр-14 01:24 
OpenSSL — грязная лапша, подлежащая рефакторингу.
Восемь лет назад было доказано — эта анальная красота нежизнеспособна.

Под шланг с нуля.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Ordu , 13-Апр-14 02:06 
> Под шланг с нуля.

Где ссылка на твой репозиторий?


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Хрен с горы , 13-Апр-14 11:44 
https://hg.mozilla.org/projects/nss

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено YetAnotherOnanym , 13-Апр-14 12:31 
> https://hg.mozilla.org/projects/nss

Может, NaCl тоже его проект? ;)


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 15-Апр-14 02:05 
Вам пример либы надо или "сперва добейся"?

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 02:38 
> OpenSSL — грязная лапша, подлежащая рефакторингу.

Для начала отреFUCKторить надо TLS. В том виде каком оно сейчас - это хрен с два кто сможет секурно использовать.

> Под шланг с нуля.

Вроде для грибочков еще рано. А у вас вроде уже сезон.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 07:59 
У него свои.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 13:36 
Так-то оно так, но какие альтернативы? GnuTLS не сильно лучше, к сожалению.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 15-Апр-14 00:31 
ну технически - бабло Тео, правительство США - платило не "за красные глаза" =)
они баблом не разбрасываются. обычно )

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Кирилл , 14-Апр-14 12:44 
А ASN тут причём? Он просто описывает структуры сертификатов. Вернее даже не конкретно сертификатов, а вообще структуру чего угодно.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 00:32 
Ну будем надеяться, что компания из США - Akamai, не очередная АНБшная компания-прослойка.
В противном случае, будет уже совсем весело :)

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 08:09 
ну как-бы, ЦРУ-шная(а точнее - у них есть совместное агенство, вместе с DoS, DoC в плане "информационного доминирования", которое пилит все эти инвестпрограммы :).

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено YetAnotherOnanym , 13-Апр-14 12:35 
> Ну будем надеяться, что компания из США - Akamai, не очередная АНБшная
> компания-прослойка.
> В противном случае, будет уже совсем весело :)

Поставьте себя на место сотрудника АНБ и подумайте - можете Вы позволить такой организации как Akamai (и любой другой CDN) не быть под Вашим колпаком?


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 13:30 
Кто угодно может оказаться агентом АНБ. Единственное решение - аудит кода независимыми аудиторами, чем их больше - тем лучше.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено 7я колонна , 13-Апр-14 17:58 
Ага, аудит кода независимыми аудиторами из АНБ. :) А если вдруг они будут не из АНБ, то их психологически так задавят, что это отвлечёт от любых ошибок в коде.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 14-Апр-14 00:19 
Тут сам Тео заявил - http://article.gmane.org/gmane.os.openbsd.tech/35722 - что в openssh есть жирный баг. Но какой - мол, не скажу. И вообще, юзают тут openssh кучи всяких, но спасиб не присылают. Хм. Отлично. Кажется Тео не очень рад выкусить последствия "лицензия же позволяет".

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено rob pike , 14-Апр-14 01:18 
То, что не нравится Тео, лицензиями не решается.
Точно так же OpenSSH под GPL все использовали бы, и никто не говорил спасибо и денег не посылал.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Elhana , 14-Апр-14 05:58 
Причем тут Theo и спасиб? OpenSSL в отличие от OpenSSH это не проект OpenBSD, хотя по названию и кажется что их. Если бы OpenSSL был их кодом, то там не было бы никаких костылей вида OPENSSL_malloc.

Он спасибо за OpenSSH хочет и вопрос про баг риторический: Если бы мы объявили о баге в OpenSSH, как хреново бы стало интернетам, учитывая что он установлен почти везде?  

Это намек на донат, т.к. похоже они бабло на год собрали и все успокоились и денежку подкидывать перестали.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Кирилл , 14-Апр-14 12:46 
Весь интернет, весь, это АНБэшная сеть. И чего? Котигов, порнуху, сериалы и трусы по интернету это не мешает заполучать. А чего ещё обывателю нужно?

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 14-Апр-14 22:16 
ссылку

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Тампарам , 17-Апр-14 02:25 
http://item.rakuten.co.jp/lux-style/c/0000000213/

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено _yurkis_ , 15-Апр-14 10:00 
>Ну будем надеяться, что компания из США - Akamai, не очередная АНБшная компания-прослойка.

В противном случае, будет уже совсем весело :)

Блин, там же патч лежит. Небольшой, кстати. А глазами посмотреть? Нет, я понимаю что если Вы не параноик это не значит что за Вами не следят. Но там не заумная криптоматематика а обычный алокатор памяти!


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 00:50 
ха, один из крупнейших инвестпроектов ODNI, наряду с Фэйсбуком - выдвигает инициативы в области ИТ-безопасности ? ха !
впрочем от АНБ-то патчи и "рекомендации" - принимали. пока не оценили ущерб от.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 02:40 
> впрочем от АНБ-то патчи и "рекомендации" - принимали.

Особенно удачно они NIST'у ГПСЧ новый впарили.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 02:20 
Каким блин хреном аллокатор связан с ASN.1?

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Кирилл , 14-Апр-14 12:53 
> Каким блин хреном аллокатор связан с ASN.1?

Никаким.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 03:18 
какой-то бред. Единственный способ более-менее защититься это хранить ключи в отдельном процессе, а в рабочем держать только некие производные данные (например, временные симметричные ключи) через которые нельзя восстановить сами сертификаты.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 03:22 
Кэп намекает что нормальная практика вообще-то затирать ключи после того как они больше не требуются. Тогда их не сопрут, да.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Logo , 13-Апр-14 03:54 
Думаю, вы оба достойны внимания, спасибо.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Гость , 16-Апр-14 00:25 
Медицинского? )

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 13:49 
К сожалению, для https он требуется постоянно. Все, что можно - и так затирается (если где-то не затирается - срочно присылай патч).

С выносом в отдельный процесс - вполне рабочее решение, хотя на хайлоаде оверхед на IPC может оказаться существенным. Решение Akamai этого оверхеда не имеет. Выглядит грязным хаком, каким и является - но это можно допилить, сделав человеческое api для специальной аллокации.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 16:53 
> К сожалению, для https он требуется постоянно.

Простите?! Что именно вам требуется постоянно?! Приватный ключ сертификата? Зачем?! Пароль для сайта?! Ну в общем то что тырят нынче оптом. Парни, это вообще в памяти не должно было висеть. Так что одни бракоделы запалили и подставили толпу других бракоделов. Каскад FAILов :).

> Все, что можно - и так затирается

А что же тогда народ тырит оптом нынче? Типа паролей к онлайн банкам и прочей прелести.

> (если где-то не затирается - срочно присылай патч).

У меня пупок развяжется за всеми долбоклюями их обсироны подтирать.

> С выносом в отдельный процесс - вполне рабочее решение, хотя на хайлоаде
> оверхед на IPC может оказаться существенным. Решение Akamai этого оверхеда не
> имеет. Выглядит грязным хаком, каким и является - но это можно
> допилить, сделав человеческое api для специальной аллокации.

Костыли они такие. Что характерно, на безопасность все это повлияет мало. Если толпа ламеров будет и дальше "шифровать соединение", думая что за них все сделает мегаумная либа, а авторы либы к тому же нисколько не будут париться о том что с их ламерами-пользователями случится - оно и дальше будет как-то вот так. Я уже приводил эталоннейший пример: большинство софта отличного от браузера кладет болт на, допустим, фингерпринт сертификата сервера. Его увидеть то можно далеко не везде, не то что заметить что он изменился. Наиболее стойкие шифры как приоритетные указывает спасибо если каждый сотый долбоклюй, поэтому что там будет по факту использовано при конекте к "вон тому серверу" - лотерея полнейшая. Какая при этом безопасность? Ну я думаю понятно какая.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 18:13 
решение от Akamai это обряд (~ нужно срочно что-то сделать.. сделали, отлично, мы хорошо поработали, всё теперь должно быть хорошо и можно успокоиться), который ничего принципально не решает.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено _yurkis_ , 15-Апр-14 10:01 
> решение от Akamai это обряд (~ нужно срочно что-то сделать.. сделали, отлично,
> мы хорошо поработали, всё теперь должно быть хорошо и можно успокоиться),
> который ничего принципально не решает.

Полная безопасность это вариант сферического коня в вакууме.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено maxis11 , 13-Апр-14 04:39 
> "Yes, rats.  My message implied that we do that.  And I then posted the wrong version of the code. :("

Ну что за ... Они там (разрабы в Akamai) кажись не умеют пользоваться системой контроля версий.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 12:32 
У них ее никога и не было

git init
git add -A
git commit -m "trololo"
git diff


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Александр Патраков , 13-Апр-14 10:46 
Ну и зачем это сделано?

От утечки чужих Cookies это бы не защитило, так как особая схема распределения памяти применяется только к закрытому ключу. И, как любая другая нестандартная схема распределения памяти, это сводит эффективность valgrind'а и встроенных в ОС средств защиты к нулю.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 17:37 
А как обсирали своё еще совсем недавно http://www.opennet.me/openforum/vsluhforumID3/85416.html
Обсирай своё! пей к0как0лу!

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Xasd , 13-Апр-14 18:16 
> При этом, если бы подобная технология была добавлена в OpenSSL раньше, она бы позволила избежать утечки закрытых ключей из памяти

идиоты...

взлом потенциально позволил извлечь ДЕЙСТВИТЕЛЬНО важные данные, а не только ключи OpenSSL.

кому эти ключи OpenSSL, нужны если взломщик смог добраться до всей памяти обрабатывающего процесса.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 19:34 
> кому эти ключи OpenSSL, нужны если взломщик смог добраться до всей памяти обрабатывающего процесса.

Не всей памяти, а только окна в 64К


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 14-Апр-14 00:22 
> Не всей памяти, а только окна в 64К

Но даже там порой находится что-то интересное. При том на вопрос "а какого хрена у вас тут вообще пользовательские пароли в памяти висят?" большинство каналий тихо ныкаются в кусты. Потому что они тут "соединение шифровали".


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Xaionaro , 14-Апр-14 11:20 
А какая бывает удачная практика передачи хешей (вместо plaintext паролей) на web-ресурсах при аутентификации?

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 14-Апр-14 12:11 
Никакой. Какая нахрен разница, уведут у тебя пароль или хэш его?

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Xaionaro , 14-Апр-14 13:28 
> Никакой. Какая нахрен разница, уведут у тебя пароль или хэш его?

9452-проходный SHA512-хеш с солью, смещениями и другими защитами неплохо повышает технические средства необходимые для получения исходного пароля.

Да и к тому же даёт некоторое время на смену паролей, если произошла утечка, даже если злоумышленник имеет доступ к серьёзным кластерам.

Да и вообще, чего я капитаню? Для вас действительно нет разницы увели у вас пароль или лишь хеш от него?


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 14-Апр-14 15:44 
Мы все еще говорим про web? Нафик ему твой пароль, если он может перехватить и отослать его хэш? А ты потом будешь долбиться в саппорт, сльозно умоляя вернуть угнанный аккаунт и рассказывать им про соли и смещения. К сожалению, они вряд ли посоветуют тебе засунуть их вместе с твоим супер-пупер-паролем туда, куда не светит солнце. А жаль.

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Xaionaro , 14-Апр-14 16:30 
> Мы все еще говорим про web? Нафик ему твой пароль, если он
> может перехватить и отослать его хэш? А ты потом будешь долбиться
> в саппорт, сльозно умоляя вернуть угнанный аккаунт и рассказывать им про
> соли и смещения.

А вы никогда не читать как всякие CHAP-ы работают? Пусть хоть ушлётся моим паролем, ему это ничего не даст.

Hint: Хеш генерируется на основе запроса посылаемого от сервера (который каждый раз шлёт разный запрос).

> К сожалению, они вряд ли посоветуют тебе засунуть
> их вместе с твоим супер-пупер-паролем туда, куда не светит солнце. А
> жаль.

Плохой вы человек..


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 13-Апр-14 20:36 
Казалось бы, там, в аллокаторе нужно было сделать обнуление выделенной памяти. Нет, городят какую то чушь.
Не, я понимаю, обнулять память по каждому чиху - производительность просядет, ХайЛоад негодуэ?


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 14-Апр-14 12:12 
>обнулять память по каждому чиху - дополнительные телодвижение, хомячки негодуэ?

Починил.


"Akamai предложил безопасную систему распределения памяти для..."
Отправлено анан , 14-Апр-14 13:41 
Городить собственный аллокатор - вот это негодуэ. Это только начало...

"Akamai предложил безопасную систему распределения памяти для..."
Отправлено Аноним , 16-Апр-14 01:09 
начало начала начал, если быть точным.
linux - начинался с написания "драйвера к minix".
так у Амазон - еще все впереди.
и про ИБ книжки почитают и про софтверный инжиринг, все будет, но судя по всему - нескоро.

"Компания Akamai предложила безопасную систему распределения ..."
Отправлено 0xd34df00d , 14-Апр-14 10:31 
На самом деле нет: http://lekkertech.net/akamai.txt

"Компания Akamai предложила безопасную систему распределения ..."
Отправлено Гость , 16-Апр-14 00:30 
> На самом деле нет: http://lekkertech.net/akamai.txt

Наконец кто-то заревьювил код Акамая, ради чего виlимо и выкладывали. ^)