The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Компания Akamai предложила безопасную систему распределения памяти для OpenSSL

12.04.2014 23:45

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

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

Реализация secure_malloc основана на коде, уже около десяти лет используемом в Akamai для надёжной защиты ключей пользователей. Тем не менее, патч является скорее прототипом для реализации похожей системы, чем решением, готовым для немедленного внедрения в OpenSSL. Например, патч не заботится о переносимости и привязывается к коду ASN1 вместо создания нового API. При этом, если бы подобная технология была добавлена в OpenSSL раньше, она бы позволила избежать утечки закрытых ключей из памяти в процессе эксплуатации уязвимости Heartbleed.

  1. Главная ссылка к новости (https://blogs.akamai.com/2014/...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/39560-malloc
Ключевые слова: malloc, openssl, memory
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (54) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, anonymous (??), 00:22, 13/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Что плохого в ASN.1, если это тот ASN.1? Как раз-таки новые API будут явно хуже... А переносимость - взять либу из net-snmp и норм. Ну, виндyзятникoв не считаем, они должны cтрадaть.
     
     
  • 2.2, Аноним (-), 00:29, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Оно и видно - у openssl замечательное API. Правда, секурно им пользоваться никто толком не может, и в каждой первой программе можно найти дюжину различных продолбов, за редким исключением.
     
     
  • 3.6, Sabakwaka (ok), 01:24, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    OpenSSL — грязная лапша, подлежащая рефакторингу.
    Восемь лет назад было доказано — эта анальная красота нежизнеспособна.

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

     
     
  • 4.8, Ordu (ok), 02:06, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Под шланг с нуля.

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

     
     
  • 5.21, Хрен с горы (?), 11:44, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://hg.mozilla.org/projects/nss
     
     
  • 6.22, YetAnotherOnanym (ok), 12:31, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > https://hg.mozilla.org/projects/nss

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

     
     
  • 7.61, Аноним (-), 02:05, 15/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вам пример либы надо или "сперва добейся"?
     
  • 4.10, Аноним (-), 02:38, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > OpenSSL — грязная лапша, подлежащая рефакторингу.

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

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

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

     
     
  • 5.16, Аноним (-), 07:59, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У него свои.
     
  • 4.28, Аноним (-), 13:36, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Так-то оно так, но какие альтернативы? GnuTLS не сильно лучше, к сожалению.
     
  • 4.59, Аноним (-), 00:31, 15/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ну технически - бабло Тео, правительство США - платило не "за красные глаза" =)
    они баблом не разбрасываются. обычно )
     
  • 2.50, Кирилл (??), 12:44, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А ASN тут причём? Он просто описывает структуры сертификатов. Вернее даже не конкретно сертификатов, а вообще структуру чего угодно.
     

  • 1.3, Аноним (-), 00:32, 13/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Ну будем надеяться, что компания из США - Akamai, не очередная АНБшная компания-прослойка.
    В противном случае, будет уже совсем весело :)
     
     
  • 2.17, Аноним (-), 08:09, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну как-бы, ЦРУ-шная(а точнее - у них есть совместное агенство, вместе с DoS, DoC в плане "информационного доминирования", которое пилит все эти инвестпрограммы :).
     
  • 2.24, YetAnotherOnanym (ok), 12:35, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Ну будем надеяться, что компания из США - Akamai, не очередная АНБшная
    > компания-прослойка.
    > В противном случае, будет уже совсем весело :)

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

     
  • 2.27, Аноним (-), 13:30, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Кто угодно может оказаться агентом АНБ. Единственное решение - аудит кода независимыми аудиторами, чем их больше - тем лучше.
     
     
  • 3.33, 7я колонна (?), 17:58, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ага, аудит кода независимыми аудиторами из АНБ. :) А если вдруг они будут не из АНБ, то их психологически так задавят, что это отвлечёт от любых ошибок в коде.
     
  • 2.39, Аноним (-), 00:19, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут сам Тео заявил - http://article.gmane.org/gmane.os.openbsd.tech/35722 - что в openssh есть жирный баг. Но какой - мол, не скажу. И вообще, юзают тут openssh кучи всяких, но спасиб не присылают. Хм. Отлично. Кажется Тео не очень рад выкусить последствия "лицензия же позволяет".
     
     
  • 3.41, rob pike (?), 01:18, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    То, что не нравится Тео, лицензиями не решается.
    Точно так же OpenSSH под GPL все использовали бы, и никто не говорил спасибо и денег не посылал.
     
  • 3.43, Elhana (ok), 05:58, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Причем тут Theo и спасиб? OpenSSL в отличие от OpenSSH это не проект OpenBSD, хотя по названию и кажется что их. Если бы OpenSSL был их кодом, то там не было бы никаких костылей вида OPENSSL_malloc.

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

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

     
  • 2.51, Кирилл (??), 12:46, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Весь интернет, весь, это АНБэшная сеть. И чего? Котигов, порнуху, сериалы и трусы по интернету это не мешает заполучать. А чего ещё обывателю нужно?
     
     
  • 3.58, Аноним (-), 22:16, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ссылку
     
     
  • 4.67, Тампарам (?), 02:25, 17/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    http://item.rakuten.co.jp/lux-style/c/0000000213/
     
  • 2.62, _yurkis_ (ok), 10:00, 15/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Ну будем надеяться, что компания из США - Akamai, не очередная АНБшная компания-прослойка.

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

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

     

  • 1.5, Аноним (-), 00:50, 13/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    ха, один из крупнейших инвестпроектов ODNI, наряду с Фэйсбуком - выдвигает инициативы в области ИТ-безопасности ? ха !
    впрочем от АНБ-то патчи и "рекомендации" - принимали. пока не оценили ущерб от.
     
     
  • 2.11, Аноним (-), 02:40, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > впрочем от АНБ-то патчи и "рекомендации" - принимали.

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

     

  • 1.9, Аноним (-), 02:20, 13/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Каким блин хреном аллокатор связан с ASN.1?
     
     
  • 2.52, Кирилл (??), 12:53, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Каким блин хреном аллокатор связан с ASN.1?

    Никаким.

     

  • 1.12, Аноним (-), 03:18, 13/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    какой-то бред. Единственный способ более-менее защититься это хранить ключи в отдельном процессе, а в рабочем держать только некие производные данные (например, временные симметричные ключи) через которые нельзя восстановить сами сертификаты.
     
     
  • 2.13, Аноним (-), 03:22, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Кэп намекает что нормальная практика вообще-то затирать ключи после того как они больше не требуются. Тогда их не сопрут, да.
     
     
  • 3.14, Logo (ok), 03:54, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Думаю, вы оба достойны внимания, спасибо.
     
     
  • 4.64, Гость (?), 00:25, 16/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Медицинского? )
     
  • 3.29, Аноним (-), 13:49, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению, для https он требуется постоянно. Все, что можно - и так затирается (если где-то не затирается - срочно присылай патч).

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

     
     
  • 4.31, Аноним (-), 16:53, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Простите Что именно вам требуется постоянно Приватный ключ сертификата Заче... большой текст свёрнут, показать
     
  • 4.34, Аноним (-), 18:13, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    решение от Akamai это обряд (~ нужно срочно что-то сделать.. сделали, отлично, мы хорошо поработали, всё теперь должно быть хорошо и можно успокоиться), который ничего принципально не решает.
     
     
  • 5.63, _yurkis_ (ok), 10:01, 15/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > решение от Akamai это обряд (~ нужно срочно что-то сделать.. сделали, отлично,
    > мы хорошо поработали, всё теперь должно быть хорошо и можно успокоиться),
    > который ничего принципально не решает.

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

     

  • 1.15, maxis11 (ok), 04:39, 13/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > "Yes, rats.  My message implied that we do that.  And I then posted the wrong version of the code. :("

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

     
     
  • 2.23, Аноним (-), 12:32, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    У них ее никога и не было

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

     

  • 1.19, Александр Патраков (?), 10:46, 13/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну и зачем это сделано?

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

     
  • 1.32, Аноним (-), 17:37, 13/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А как обсирали своё еще совсем недавно https://www.opennet.ru/openforum/vsluhforumID3/85416.html
    Обсирай своё! пей к0как0лу!
     
  • 1.36, Xasd (ok), 18:16, 13/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > При этом, если бы подобная технология была добавлена в OpenSSL раньше, она бы позволила избежать утечки закрытых ключей из памяти

    идиоты...

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

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

     
     
  • 2.37, Аноним (-), 19:34, 13/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > кому эти ключи OpenSSL, нужны если взломщик смог добраться до всей памяти обрабатывающего процесса.

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

     
     
  • 3.40, Аноним (-), 00:22, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не всей памяти, а только окна в 64К

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

     
     
  • 4.46, Xaionaro (ok), 11:20, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А какая бывает удачная практика передачи хешей (вместо plaintext паролей) на web-ресурсах при аутентификации?
     
     
  • 5.47, Аноним (-), 12:11, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Никакой. Какая нахрен разница, уведут у тебя пароль или хэш его?
     
     
  • 6.53, Xaionaro (ok), 13:28, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Никакой. Какая нахрен разница, уведут у тебя пароль или хэш его?

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

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

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

     
     
  • 7.55, Аноним (-), 15:44, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мы все еще говорим про web? Нафик ему твой пароль, если он может перехватить и отослать его хэш? А ты потом будешь долбиться в саппорт, сльозно умоляя вернуть угнанный аккаунт и рассказывать им про соли и смещения. К сожалению, они вряд ли посоветуют тебе засунуть их вместе с твоим супер-пупер-паролем туда, куда не светит солнце. А жаль.
     
     
  • 8.56, Xaionaro (ok), 16:30, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А вы никогда не читать как всякие CHAP-ы работают Пусть хоть ушлётся моим парол... текст свёрнут, показать
     

  • 1.38, Аноним (-), 20:36, 13/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Казалось бы, там, в аллокаторе нужно было сделать обнуление выделенной памяти. Нет, городят какую то чушь.
    Не, я понимаю, обнулять память по каждому чиху - производительность просядет, ХайЛоад негодуэ?

     
     
  • 2.48, Аноним (-), 12:12, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >обнулять память по каждому чиху - дополнительные телодвижение, хомячки негодуэ?

    Починил.

     
     
  • 3.54, анан (?), 13:41, 14/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Городить собственный аллокатор - вот это негодуэ. Это только начало...
     
     
  • 4.66, Аноним (-), 01:09, 16/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    начало начала начал, если быть точным.
    linux - начинался с написания "драйвера к minix".
    так у Амазон - еще все впереди.
    и про ИБ книжки почитают и про софтверный инжиринг, все будет, но судя по всему - нескоро.
     

  • 1.45, 0xd34df00d (??), 10:31, 14/04/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На самом деле нет: http://lekkertech.net/akamai.txt
     
     
  • 2.65, Гость (?), 00:30, 16/04/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > На самом деле нет: http://lekkertech.net/akamai.txt

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру