오픈 소스 운영 체제 배포판인 OpenBSD는 시스템 관리자, 특히 서버를 관리하는 사람들 사이에서 속도, 기능 및 멋진 프런트 엔드보다 보안에 중점을 둔 것으로 잘 알려져 있습니다.
적절하게도 로고는 복어 모양입니다. 부풀어올라 교활한 해커를 물리칠 준비가 된 스파이크가 있습니다.
그러나 OpenBSD 팀은 아마도 전체 배포판이 아니라 원격 액세스 툴킷으로 가장 잘 알려져 있을 것입니다. OpenSSH를 운영 체제 자체에 포함하기 위해 1990년대 후반에 작성되었습니다.
SSH, 줄임말 보안 쉘, 원래 핀란드 컴퓨터 과학자가 만들었습니다. 타투 일로넨 1990년대 중반에 시스템 관리자가 텔넷 프로토콜을 사용하는 위험한 습관에서 벗어날 수 있기를 희망했습니다.
텔넷의 문제
텔넷은 매우 간단하고 효과적이었습니다. 원격 서버에 텔레타이프 연결을 만들기 위해 물리적 유선을 연결(또는 전화선을 통해 모뎀 사용)하는 대신 TELetype NETwork 연결을 사용했습니다.
기본적으로 전용 직렬 연결 또는 전화 접속 전화선을 통해 일반적으로 앞뒤로 흐르는 데이터는 회선 전환 지점 간 링크 대신 패킷 전환 TCP 네트워크 연결을 사용하여 인터넷을 통해 송수신되었습니다. .
동일한 친숙한 로그인 시스템, 더 저렴한 연결, 전용 데이터 회선이 필요하지 않습니다!
물론 텔넷의 가장 큰 결점은 암호화가 전혀 없다는 것입니다. 따라서 정확한 터미널 세션을 스니핑하는 것이 사소하여 크래커가 사용자가 입력한 모든 명령(실수, 명중한 모든 시간 포함)을 볼 수 있습니다. [Backspace]
), 그리고 생성된 출력의 모든 바이트…
… 그리고 물론 세션 시작 시 사용자 이름과 암호.
네트워크 경로에 있는 모든 사용자는 자신의 화면에서 실시간으로 sysadmin 세션을 쉽게 재구성할 수 있을 뿐만 아니라 원격 서버에 보낸 명령을 수정하고 사용자가 눈치채지 못하도록 응답을 가장하여 세션을 변조할 수도 있습니다. 속임수.
심지어 사기꾼 서버를 설정하고 사용자를 유인하여 속임수를 알아차리기 어렵게 만들 수도 있습니다.
강력한 암호화 FTW
Ylönen의 SSH는 텔넷과 같은 세션의 각 끝에 강력한 암호화 및 인증 계층을 추가하는 것을 목표로 했습니다. 보안 쉘 (궁금해 본 적이 있다면 거의 모든 사람들이 그냥 부르지만 이름이 의미하는 바입니다. 에에에에에에에에에 요즈음).
즉각적인 히트를 쳤고 프로토콜은 모든 곳의 시스템 관리자에 의해 빠르게 채택되었습니다.
위에서 언급한 바와 같이 곧 OpenSSH가 뒤따랐으며 1999년 후반에 처음 등장했습니다. 오픈BSD 2.6 놓습니다.
OpenBSD 팀은 그들이 사용하는 프로토콜의 신뢰할 수 있는 무료 오픈 소스 구현을 만들고 싶었습니다. 다른 사람이 사용할 수, 출시 직후 몇 년 동안 Ylönen의 원래 구현을 방해했던 라이센스 또는 상업적 합병증이 없습니다.
실제로 지금 Windows SSH 서버를 실행하고 Linux 컴퓨터에서 연결하는 경우 거의 확실하게 양쪽 끝에서 OpenSSH 구현에 의존하게 될 것입니다.
SSH 프로토콜은 SCP 및 SFTP를 포함하여 널리 사용되는 다른 클라이언트-서버 서비스에서도 사용됩니다. 보안 사본 과 안전한 FTP 각기. SSH는 일반적으로 대화식 로그인의 경우 "안전하게 연결하고 다른 쪽 끝에서 SHell 명령 실행"을 의미합니다. 명령 셸용 Unix 프로그램은 일반적으로 /bin/sh
. SCP는 유사하지만 Unix 파일 복사 명령이 일반적으로 호출되기 때문에 파일 복사용입니다. /bin/cp
, SFTP는 거의 같은 방식으로 이름이 지정됩니다.
OpenSSH는 마을에서 유일한 SSH 툴킷이 아닙니다.
다른 잘 알려진 구현은 다음과 같습니다. libssh2, 자체 애플리케이션에 SSH 지원을 구축하려는 개발자를 위한 것입니다. 드롭 베어, 호주 코더의 벗겨진 SSH 서버 매트 존스턴 이는 가정용 라우터 및 프린터와 같은 소위 IoT(사물 인터넷) 장치에서 널리 발견됩니다. 그리고 퍼티, 인디 오픈 소스 개발자가 제공하는 인기 있는 무료 Windows용 SSH 관련 도구 모음 사이먼 타 담 영국에서.
그러나 일반 SSH 사용자라면 오늘날 최소한 하나의 OpenSSH 서버에 연결했을 것이 거의 확실합니다. 특히 대부분의 최신 Linux 배포판에 표준 원격 액세스 도구로 포함되어 있고 Microsoft가 OpenSSH 클라이언트와 OpenSSH를 모두 제공하기 때문입니다. 요즘 공식 Windows 구성 요소로 서버.
이중 무료 버그 수정
OpenSSH 버전 9.2 방금 나왔고, 릴리즈 노트 다음과 같이 보고합니다.
이 릴리스에는 […] 메모리 안전 문제에 대한 수정 사항이 포함되어 있습니다. [이 버그]는 악용될 수 없다고 생각되지만 대부분의 네트워크 도달 가능 메모리 결함을 보안 버그로 보고합니다.
버그 영향 sshd
, OpenSSH 서버( -d
접미사는 악마, Windows가 호출하는 일종의 백그라운드 프로세스에 대한 Unix 이름 서비스):
SSHD(8): OpenSSH 9.1에 도입된 사전 인증 이중 해제 메모리 오류를 수정합니다. 이것은 악용될 수 없다고 생각되며 chroot(2)의 적용을 받는 권한이 없는 사전 인증 프로세스에서 발생하며 대부분의 주요 플랫폼에서 추가로 샌드박스 처리됩니다.
이중 해제 버그는 프로그램의 다른 부분에서 재사용하기 위해 운영 체제에 이미 반환한 메모리 블록을 의미합니다.
...나중에 더 이상 해당 메모리를 실제로 "소유"하지 않지만 자신이 소유하지 않는다는 사실을 모르는 프로그램의 일부에 의해 나중에 다시 전달됩니다.
(또는 의도적으로 버그를 유발하려는 코드의 지시에 따라 고의적으로 되돌려 보내 취약점 로 이용.)
이는 미묘하고 해결하기 어려운 버그로 이어질 수 있습니다. free()
나중에 다음을 통해 메모리를 요청할 때 코드의 다른 부분에 할당합니다. malloc(
)에 대한 불필요한 호출이 있을 때 블록을 다시 한 번 해제 표시합니다. free()
나타납니다.
그러면 호텔에 체크인할 때 “오, 좋은 소식이군요! 만석인 줄 알았는데 다른 게스트가 일찍 체크아웃을 해서 방을 가질 수 있게 되었습니다.”
방이 깔끔하게 청소되고 새 입주자를 맞이할 준비가 되어 있어 전용 용도로 적절하게 할당된 것처럼 보이더라도 여전히 이전 손님의 키 카드가 실제로 올바르게 취소되었으며 " 이른 체크아웃”은 같은 날 나중에 몰래 들어가 노트북을 훔치는 교활한 계략이 아니었습니다.
버그 수정을 위한 버그 수정
아이러니하게도 최근 OpenSSH 코드 기록을 보면 OpenSSH가 compat_kex_proposal()
, 연결을 설정할 때 사용할 키 교환 알고리즘의 종류를 확인하는 데 사용됩니다.
그러나 그 평범한 버그를 수정하면 더 심각한 취약점이 도입되었습니다.
그건 그렇고, 연결 설정 중에 사용되는 소프트웨어의 일부에 있는 버그의 존재는 이것이 소위 말하는 것입니다. 네트워크 도달 가능 사전 인증 취약성(또는 사전 인증 버그 짧게).
double-free 버그는 실행해야 하는 코드에서 발생합니다. 시간 내에 클라이언트가 원격 세션을 시작했지만 전에 모든 키 계약 또는 인증이 발생했기 때문에 이론적으로 유효성 검사를 위해 암호 또는 암호화 키가 제시되기 전에 취약점이 트리거될 수 있습니다.
OpenSSH 9.0에서, compat_kex_proposal
다음과 같이 생겼습니다(여기에서 크게 단순화됨).
char* compat_kex_proposal(char* suggestion) { if (condition1) { return suggestion; } if (condition2) { suggestion = allocatenewstring1(); } if (condition3) { suggestion = allocatenewstring2(); } if (isblank(suggestion)) { error(); } return suggestion; }
아이디어는 호출자가 키 교환 설정을 제안하는 텍스트 문자열을 포함하는 자신의 메모리 블록을 전달하고 그들이 보낸 바로 그 제안을 사용하기 위한 승인 또는 업데이트된 제안이 있는 새로 할당된 텍스트 문자열을 반환받는 것입니다. .
버그는 조건 1이 거짓이지만 조건 2와 3이 모두 참이면 코드가 다음을 할당한다는 것입니다. 두 새 텍스트 문자열이지만 반환만 한.
에 의해 할당된 메모리 블록 allocatenewstring1()
해제되지 않으며 함수가 반환될 때 메모리 주소가 영원히 손실되므로 어떤 코드도 사용할 방법이 없습니다. free()
앞으로 말이죠.
해당 블록은 본질적으로 버려지며, 메모리 누출.
시간이 지남에 따라 이로 인해 문제가 발생할 수 있으며 메모리 과부하에서 복구하기 위해 서버를 강제로 종료할 수도 있습니다.
OpenSSH 9.1에서는 두 문자열을 할당하지 않고 그 중 하나를 버리기 위해 코드가 업데이트되었습니다.
/* Always returns pointer to allocated memory, caller must free. */ char* compat_kex_proposal(char* suggestion){ char* previousone = NULL; if (condition1) { return newcopyof(suggestion); } if (condition2) { suggestion = allocatenewstring1(); } if (condition3) { previousone = suggestion; suggestion = allocatenewstring2(); } free(previousone); } if (isblank(suggestion()) { error(); } return suggestion; }
이것은 조건 1과 조건 2가 모두 거짓이지만 조건 3이 참이면 코드가 응답으로 다시 보낼 새 문자열을 할당하기 때문에 double-free 버그가 있습니다.
...하지만 호출자가 원래 전달한 문자열을 잘못 해제합니다. allocatenewstring1()
변수를 업데이트하기 위해 호출되지 않습니다 suggestion
.
전달된 제안 문자열 호출자에게 속한 메모리입니다., 따라서 호출자는 나중에 테마를 해제하여 이중 해제 위험으로 이어집니다.
OpenSSH 9.2에서는 사용 가능한 세 가지 메모리 블록을 모두 추적하여 코드가 더욱 신중해졌습니다. suggestion
(다른 사람이 소유한 메모리) 및 도중에 할당될 수 있는 두 가지 새로운 문자열:
/* Always returns pointer to allocated memory, caller must free. */ char* compat_kex_proposal(char* suggestion) { char* newone = NULL; char* newtwo = NULL; if (condition1) { return newcopyof(suggestion); } if (condition2) { newone = allocatenewstring1(); } if (condition3) { newtwo = allocatenewstring2(); } free(newone); newone = newtwo; } if (isblank(newone)) { error(); } return newone; }
조건 1이 참이면 전달된 문자열의 새 복사본이 사용되므로 호출자는 나중에 free()
그들이 원할 때마다 전달된 문자열의 메모리.
조건 1을 통과하고 조건 2가 참이지만 조건 3이 거짓이면 다음에 의해 생성된 대안 제안 allocatenewstring1()
반환되고 전달된 suggestion
문자열은 그대로 남습니다.
조건 2가 거짓이고 조건 3이 참이면 새 문자열이 생성되어 반환되고 전달된 suggestion
문자열은 그대로 남습니다.
조건 2와 조건 3이 모두 참이면 도중에 두 개의 새 문자열이 할당됩니다. 첫 번째는 필요하지 않기 때문에 해제됩니다. 두 번째 것이 반환됩니다. 그리고 합격 suggestion
문자열은 그대로 남습니다.
여러분의 시간과 재능으로 RTxM 당신이 전화하면 확인 free(newone)
언제 newone
is NULL
, "아무 작업도 수행되지 않습니다". 항상 안전하기 때문입니다. free(NULL)
. 그럼에도 불구하고 많은 프로그래머는 여전히 다음과 같은 코드를 사용하여 강력하게 보호합니다. if (ptr != NULL) { free(ptr); }
.
무엇을해야 하는가?
OpenSSH 팀이 제안한 것처럼 이 버그를 악용하는 것은 어려울 것입니다. sshd
프로그램은 사용을 위해 연결을 설정하는 동안 가지고 있습니다.
그럼에도 불구하고 그들은 그것이 바로 보안 허점이라고 보고했기 때문에 업데이트했는지 확인하십시오. OpenSSH 9.2.
그리고 C로 코드를 작성하고 있다면 아무리 경험이 많더라도 메모리 관리가 잘못되기 쉽다는 점을 기억하십시오.
...그러니 조심하세요.
(예, Rust와 그 현대 친구들은 올바른 코드 작성에 도움, 하지만 가끔은 여전히 C를 사용해야 할 것이고 심지어 Rust도 그것을 보장할 수 없습니다. 잘못된 코드 작성 중지 무분별하게 프로그램한다면!)
- SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
- 플라토 블록체인. Web3 메타버스 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
- 출처: https://nakedsecurity.sophos.com/2023/02/03/openssh-fixes-double-free-memory-bug-thats-pokable-over-the-network/