Влияет ли недавняя ошибка Heartbleed на ssh-ключи, которые я сгенерировал и использовал для отправки / извлечения кода с Github, Heroku и другими подобными сайтами?
Нужно ли заменить ключи, которые я использовал?
40
2 ответа
47
Нет, Heartbleed на самом деле не влияет на ключи SSH, поэтому вам, вероятно, не нужно заменять используемые вами ключи SSH.
Во-первых, SSL и SSH - это два разных протокола безопасности для двух разных применений. Аналогично, OpenSSL и OpenSSH также являются двумя совершенно разными программными пакетами, несмотря на сходство их названий.
Во-вторых, эксплойт Heartbleed заставляет уязвимый узел TLS/DTLS OpenSSL возвращать случайные 64 КБ памяти, но он почти наверняка ограничен памятью, доступной этому процессу, использующему OpenSSL. Если этот процесс, использующий OpenSSL, не имеет доступа к вашему закрытому ключу SSH, он не может утечь его через Heartbleed.
Кроме того, вы обычно размещаете свой открытый ключ SSH только на серверах, к которым вы используете SSH для подключения, и, как следует из названия, открытый ключ - это ключ, который вы можете опубликовать. Неважно, кто это знает. Фактически, вы хотите, чтобы публичный пользователь знал ваш правильный открытый ключ.
Спасибо @Bob за указание на то, что уязвимость может повлиять на клиентские приложения, которые используют уязвимые версии OpenSSL в качестве своей клиентской библиотеки TLS/DTLS. Так, если, например, ваш веб-браузер или VPN-клиент на основе SSL использовали уязвимую версию OpenSSL и подключены к вредоносному серверу, этот вредоносный сервер может использовать Heartbleed для просмотра случайных фрагментов памяти этого клиентского программного обеспечения. Если у этого клиентского приложения по какой-то причине была копия ваших закрытых ключей SSH в памяти, оно могло бы просочиться через Heartbleed.
Вдобавок ко всему, я не думаю о каком-либо программном обеспечении, кроме SSH, которое могло бы иметь копию вашего незашифрованного закрытого ключа SSH в памяти. Что ж, это предполагает, что вы храните свои SSH-ключи в зашифрованном виде на диске. Если вы не храните свои закрытые SSH-ключи в зашифрованном виде на диске, то, я полагаю, вы могли бы использовать некоторую программу передачи файлов или резервного копирования с использованием OpenSSL TLS для копирования или резервного копирования вашего домашнего каталога по сети (включая вашу ~/.ssh/id_rsa или другой закрытый ключ SSH), тогда он может иметь незашифрованную копию вашего закрытого ключа SSH в памяти. Опять же, если вы копировали свой незашифрованный закрытый ключ SSH на вредоносный сервер, у вас, вероятно, больше забот, чем у Heartbleed. :-)
1
«Во-вторых, эксплойт Heartbleed заставляет уязвимый узел OpenSSL TLS/DTLS возвращать случайные 64 КБ памяти, но он почти наверняка ограничен памятью, доступной этому процессу, использующему OpenSSL».
если машина скомпрометирована, то как вы можете доверять чему-либо, включая ssh? от heartbleed.com
«Что протекает на практике?
Мы проверили некоторые из наших собственных сервисов с точки зрения злоумышленника. Мы напали на себя извне, не оставив следа. Не используя никакой конфиденциальной информации или учетных данных, мы смогли украсть у нас секретные ключи, используемые для наших сертификатов X.509, имен пользователей и паролей, мгновенных сообщений, электронных писем и важных для бизнеса документов и коммуникаций. "
кто-то мог положить закрытый ключ без ключевой фразы на сервер, который, как он предполагал, не был вредоносным ... но оказался. Ошибка b/c SSL позволила выдать пароль пользователя, который имел «sudo» ... это, вероятно, не проблема .... но ...
люди иногда делают сумасшедшие вещи
http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/