Heartbleed на пальцах
Ты здесь, сервер? Это я, Маргарет.
Ты здесь, сервер? Это я, Маргарет.
14.04.2014, 14:38
Очень интересное и информативное объяснение, спасибо.
Но все равно я не понимаю - т.е. были определенные команды для сервера, которые когда выполнялись, то вызывали такой поток доп. информации? Так ведь?
Но все равно я не понимаю - т.е. были определенные команды для сервера, которые когда выполнялись, то вызывали такой поток доп. информации? Так ведь?
Примерно так. Проблема была в этих запросах "скажи" (т.н. "heartbeat-запросы"): сервер не проверял границы запрашиваемой памяти, поэтому можно было так изменить запрос, чтобы вытащить не только кусок памяти, содержащий ответ, но и еще кучу рандомной информации, которая лежит "дальше" в памяти.
Что, собственно, и сделала Меган в комиксе: "убедила" сервер в том, что в слове "шляпа" 500 букв.
я правильно понимаю, что строчка "Meg хочет 500 букв: ШЛЯПА" появляется в памяти только в тот момент, когда приходит этот запрос? Тогда откуда такое кол-во остаточной информации? Разве что это только та информация, которая там появляется в дилей между принятием этого запроса и записью его в память И попыткой прочитать его из памяти. Но в таком случае полезность этого жутко теряется.
Дело в том, что только 5 букв заполняются словом "шляпа", а остальные остаются нетронутыми от других запросов. А если без аналогий - вся ин-фия хранится в памяти, пока не будет перезаписана (или сервер выключен). Таким образом, запросив размер памяти больший, чем тот, в который помещен ответ, который сервер хочет вернуть пользователю, он возвращает значения, хранящиеся в соседних участках памяти. А там может быть чужая информация.
Тем не менее, особенность работы с памятью в с/с++ в том, что по-умолчанию память, которая была использована для хранения данных в переменных, не очищается(т.е. не забивается нулями). Это можно делать явно в деструкторе, но в 99.99% случаев этим никто не страдает. В рамках одного процесса могли выполняться самые разные запросы ранее, в том числе и содержащие те самые ключи. Потому с некоторой долей вероятности действительно можно получить кусок памяти с весьма важной инфой. Учитывая, что уязвимость повторяемая, т.е. получать случайные куски памяти можно сколько угодно раз, получается жопа - когда-нибудь среди бесполезного мусора все равно попадется что-то ценное.
Ну, теоретически-то можно, но практически - вряд ли. Поскольку системная память на процесс выделяется все-таки блоками (см. M_MMAP_THRESHOLD), так что в начале процесс нагребает себе памяти в кучу, а потом, в среднем, использует то, что нагреб, изредка отдавая блоки или используя новые.
Да, команда типа пинга. У тебя с сервером защищенное соединение. И тебе надо знать - оно живо или нет? Как сделать? Вот есть такая фича Hearbeat где была команда типа "спросить что живой" вида: Сервер, скажи слово ЯЖИВ (4буквы)
но по ошибке в этой фиче он отдавал столько букв, сколько реально запросили, и брал он их откуда-то типа из оперативки.
но по ошибке в этой фиче он отдавал столько букв, сколько реально запросили, и брал он их откуда-то типа из оперативки.
В протоколе SSL идет проверка на разрыв соединений "heartbeat" (сердцебиение). Клиент опрашивает сервер на разрыв соединения и просит вернуть какую-то часть данных для этого. Сервер покорно возвращает, но при этом размер данных он не проверяет и можно запросить больше, чем надо. В этом случае сервер вернет эти данные, взяв их из оперативной памяти.
http://www.computerra.ru/98046/heartbleed-simple/
http://www.computerra.ru/98046/heartbleed-simple/
8 апреля в популярной криптографической библиотеке OpenSSL, использующейся многими веб-сервисами для шифрования передаваемого трафика была обнаружена критическая уязвимость, позволяющая злоумышленникам получать доступ к чужим логинам и паролям от этих самых сервисов.
А теперь ещё раз и более человеческим языком. Начиная с марта 2012 года, когда обновлялся этот компонент, отвечающий за сохранность ваших данных на различных сайтах (включая Skrill), в нём присутствовала дыра, через которую любой компетентный хакер, прознавший о её существовании раньше остальных, мог без шума и пыли тырить конфиденциальные данные типа логинов и паролей от подверженных уязвимости сервисов типа Facebook, Twitter, Gmail, Skrill и множества других (включая популярный VPN-сервис HideMyAss).
Так вот, во вторник (8 апреля) информация о баге была широко освещена в СМИ, когда большинство подсуетившихся уже успели накатить патч и залатать брешь, потому как обнаружили её заметно раньше (один из сотрудников Гугла, кстати) и сообщили разработчикам OpenSSL.
Короче говоря, суть этого поста - предупредить о потенциальной опасности увода аккаунтов на различных сервисах (особенно это касается платёжных систем: Skrill, Neteller) и посоветовать заменить пароли везде, где только можно. И дело тут вот в чём.
Несмотря на то, что те же Skrill поспешно пропатчили свою систему и отбрехались, мол, в Багдаде всё спокойно, стоит сказать: если сегодня дыру залатали - это совсем не значит, что вчера (когда она была ещё открытой) у вас не утащили пароль. Смекаете, да? В общем, бережёного бог бережёт. (источник pokeroff.ru)
А теперь ещё раз и более человеческим языком. Начиная с марта 2012 года, когда обновлялся этот компонент, отвечающий за сохранность ваших данных на различных сайтах (включая Skrill), в нём присутствовала дыра, через которую любой компетентный хакер, прознавший о её существовании раньше остальных, мог без шума и пыли тырить конфиденциальные данные типа логинов и паролей от подверженных уязвимости сервисов типа Facebook, Twitter, Gmail, Skrill и множества других (включая популярный VPN-сервис HideMyAss).
Так вот, во вторник (8 апреля) информация о баге была широко освещена в СМИ, когда большинство подсуетившихся уже успели накатить патч и залатать брешь, потому как обнаружили её заметно раньше (один из сотрудников Гугла, кстати) и сообщили разработчикам OpenSSL.
Короче говоря, суть этого поста - предупредить о потенциальной опасности увода аккаунтов на различных сервисах (особенно это касается платёжных систем: Skrill, Neteller) и посоветовать заменить пароли везде, где только можно. И дело тут вот в чём.
Несмотря на то, что те же Skrill поспешно пропатчили свою систему и отбрехались, мол, в Багдаде всё спокойно, стоит сказать: если сегодня дыру залатали - это совсем не значит, что вчера (когда она была ещё открытой) у вас не утащили пароль. Смекаете, да? В общем, бережёного бог бережёт. (источник pokeroff.ru)
дыра и ныне там)
xkcd без этой картинки в комментариях - это как оглаф, в котором никого не выебали.
Прекрасно сказано!
в слове «шляпа» 500 букв, что неясного?
Вот для таких, как ты, ватники по безопасности интернета накатили патч :D
Жмых говно
плюсую за перевод!
по-твоему любой баг - причина, чтобы автора называть быдлокодером?
кроме того OpenSSL open-source продукт, и пол-интернета пользуются им совершенно не заморачиваясь насчет доната
..но как только там нашли баг - люди, тащащие его практически бесплатно оказались мудилами и быдлокодерами, логичнос
кроме того OpenSSL open-source продукт, и пол-интернета пользуются им совершенно не заморачиваясь насчет доната
..но как только там нашли баг - люди, тащащие его практически бесплатно оказались мудилами и быдлокодерами, логичнос
> Сделать дыру в протоколе, который подключают дополнительно для повышения защищенности передачи данных
ну охуеть теперь, то что он предназначен для повышения защищенности говорит о том, что там не может быть ошибок и уязвимостей?
> М-да, это надо суметь
Поддержка этой библиотеки - хобби, им за это практически никто не платит, так что fuck off
> А что если ему АНБ приплатило за "случайную" ошибку?
Новый тренд - к любому багу присобачивать АНБ?
ну охуеть теперь, то что он предназначен для повышения защищенности говорит о том, что там не может быть ошибок и уязвимостей?
> М-да, это надо суметь
Поддержка этой библиотеки - хобби, им за это практически никто не платит, так что fuck off
> А что если ему АНБ приплатило за "случайную" ошибку?
Новый тренд - к любому багу присобачивать АНБ?
