최근 Heartbleed 버그는 내가 생성 한 ssh 키에 영향을 미치며 Github, Heroku 및 기타 유사한 사이트에서 코드를 푸시 / 풀하기 위해 사용합니까?
사용한 키를 교체해야합니까?
최근 Heartbleed 버그는 내가 생성 한 ssh 키에 영향을 미치며 Github, Heroku 및 기타 유사한 사이트에서 코드를 푸시 / 풀하기 위해 사용합니까?
사용한 키를 교체해야합니까?
답변:
아니요, Heartbleed는 실제로 SSH 키에 영향을 미치지 않으므로 사용중인 SSH 키를 교체하지 않아도됩니다.
첫째, SSL과 SSH는 두 가지 용도로 사용되는 두 가지 보안 프로토콜입니다. 마찬가지로 OpenSSL과 OpenSSH는 이름의 유사성에도 불구하고 완전히 다른 두 소프트웨어 패키지입니다.
둘째, Heartbleed 악용으로 인해 취약한 OpenSSL TLS / DTLS 피어가 임의의 64kB 메모리를 반환하지만 OpenSSL 사용 프로세스에서 액세스 할 수있는 메모리로 제한됩니다. 해당 OpenSSL 사용 프로세스가 SSH 개인 키에 액세스 할 수없는 경우 Heartbleed를 통해 유출 할 수 없습니다.
또한 일반적으로 SSH를 사용하여 연결하는 서버 에만 SSH 공개 키를 배치 하며, 이름에서 알 수 있듯이 공개 키는 공개 할 수있는 키입니다. 누가 아는지는 중요하지 않습니다. 사실, 대중이 올바른 공개 키를 알고 싶어 합니다.
이 취약점이 취약한 버전의 OpenSSL을 클라이언트 측 TLS / DTLS 라이브러리로 사용하는 클라이언트 앱에 영향을 줄 수 있다는 점을 지적한 @Bob에게 감사드립니다. 예를 들어, 웹 브라우저 또는 SSL 기반 VPN 클라이언트가 취약한 버전의 OpenSSL을 사용하고 악의적 인 서버에 연결된 경우 해당 악의적 인 서버는 Heartbleed를 사용하여 해당 클라이언트 소프트웨어 메모리의 임의의 조각을 볼 수 있습니다. 어떤 이유로 든 해당 클라이언트 앱에 SSH 개인 키 사본이 메모리에 있으면 Heartbleed를 통해 유출 될 수 있습니다.
내 머리 위로, 암호화되지 않은 SSH 개인 키의 사본을 메모리에 저장할 수있는 SSH 이외의 소프트웨어는 생각하지 않습니다. 그것은 SSH 개인 키를 디스크에 암호화 된 상태로 유지한다고 가정합니다. SSH 개인 키를 디스크에서 암호화하지 않은 경우 OpenSSL TLS 사용 파일 전송 또는 백업 프로그램을 사용하여 네트워크를 통해 홈 디렉토리를 복사하거나 백업 할 수 있다고 가정합니다 ( ~/.ssh/id_rsa또는 다른 SSH 개인 키 포함) ), 암호화되지 않은 SSH 개인 키의 복사본을 메모리에 넣을 수 있습니다. 그런 다음 다시 암호화되지 않은 SSH 개인 키를 악성 서버에 백업하는 경우 Heartbleed보다 더 큰 걱정이있을 것입니다. :-)
둘째, Heartbleed 익스플로잇으로 인해 취약한 OpenSSL TLS / DTLS 피어가 임의의 64kB 메모리를 반환하지만 OpenSSL을 사용하는 프로세스에서 액세스 할 수있는 메모리로 제한되어 있습니다. "
기계가 손상되면 ssh를 포함하여 기계를 어떻게 신뢰할 수 있습니까? heartbleed.com에서
"실제로 누출이 무엇입니까?
우리는 공격자의 관점에서 자체 서비스 중 일부를 테스트했습니다. 우리는 흔적을 남기지 않고 외부에서 스스로를 공격했습니다. 권한있는 정보 나 자격 증명을 사용하지 않으면 서 X.509 인증서, 사용자 이름 및 암호, 인스턴트 메시지, 전자 메일 및 업무상 중요한 문서 및 통신에 사용되는 비밀 키를 스스로 훔칠 수있었습니다. "
누군가가 악의가없는 것으로 추정되는 서버에 암호없이 개인 키를 넣었을 수도 있지만 ... b / c SSL 버그로 인해 사용자의 비밀번호가 유출되었습니다. 'sudo'를 가진 사용자는 아마도 문제가되지는 않지만 ...
사람들은 때때로 미친 짓을합니다
http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/