Mac은 Bash shellshock 버그에 취약합니까?

58

Red Hat은 최근 Bash 쉘에서 주요 보안 관련 버그 를 발표했습니다 . 어떤 사람들은 이것을 "shellshock"버그라고 부릅니다. OS X은 Unix로 구축되었으므로이 버그를 악용하는 공격에 취약합니까?

최종 사용자로서 즉각적인 수정에 대해 걱정해야합니까? 아니면 Apple의 공식 소프트웨어 업데이트를 기다리는 것이 더 낫습니까?

macos security bash

— 헤어 보트
소스

1

또한 참조 apple.stackexchange.com/questions/146849/...

— nohillside

행동 OSX 볼에 영향을 확인하려면 security.stackexchange.com/questions/68123/...

— user151019

속임수가 적고 평신도를위한 조언을 많이 요청하도록 질문을 업데이트했습니다.

— 헤어 보트

1

Apple은 현재 수정 사항을 발표했습니다 : support.apple.com/kb/DL1769

— AT

46

예, 당신은 기술적으로 취약합니다. 따라서 몇 시간 동안 공황 상태에 빠진 당황한 고객을 당황하게하거나 청구하는 것처럼 느껴지면 가십시오!

그러나 실제로는 원격 연결 또는 서버 측 스크립팅을 실행하는 웹 서버에서 SSH 액세스를 허용하지 않으면 위험하지 않습니다. 모르는 사람이 컴퓨터에 원격으로 액세스하여 Bash 명령을 실행할 수있는 방식으로 만 액세스 할 수있는 경우에만 취약합니다.

실제로 어떤 종류의 서버 응용 프로그램도 실행하지 않는 데스크탑 Mac은 심각한 위험에 처하지 않습니다. 나는 여기서“속담 파이”를 먹을 의향이 있지만, 맥 사용자 대부분이 하루 종일 위험에 처할 것이라고 생각하지 않는다.

따라서이 문제는 SSH 공유를 사용하도록 설정하지 않은 데스크톱 사용자가 아니라 전 세계에 노출 된 Mac OS X 및 Unix / Linux 서버의 시스템 관리자에게 주로 중요합니다.

아마도이 위험을 악용하기 위해 Mac 맬웨어 또는 바이러스가 생성 될 위험이 있지만 의심 스럽습니다.

편집 : 그리고이 문제가 내 겸손한 의견으로 대부분의 일반 사용자에게 문제가되는 방법을 자세히 설명하기 위해 bashMac OS X 10.9.5 에서 다음 명령을 실행할 수 있습니다 .

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

그리고 나는 이것을 본다 :

vulnerable
hello

맞춰봐? 합리적으로 생각하지 않으면 그것은 끔찍합니다. 터미널을 열려면 이미 Mac에 로그인해야했습니다. 그리고 위의 SSH에 대해 말한 것을 부정하려면 심지어 SSH가 활성화되어 있어도이 테스트를 실행할 수있는 시점까지 도달하려면 여전히 로그인해야합니다. 그런 다음 SSH를 통해 액세스한다고 가정하면이 명령을 사용하면 다음과 같은 일반 사용자 권한을 넘어서는 작업을 수행 할 수 없습니다.

env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'

이 해킹으로 인해 악용되기 쉽다는 것을 의미하는 경우, 시스템의 핵심 보안이 너무 손상되어 bash결함이 있는 사실 이 실제로는 최소한의 문제가 될 수 있습니다.

이는 그와 같은 전반적인 제어 및 유상 증자에서 문제가되는 잠재적 인 행동이 예상 규범 밖으로 확장하기 때문에 의도하지 않은 액세스를 허용합니다. 그러나 겸손한 견해로는 OpenSSL이나 정원 종류와“위험하다”는“내 화면에 녹화 된 메모에 비밀번호를 남겨 두십시오”위험이 있습니다.

하루가 끝날 무렵에도 표준 절차로 실행하는 모든 Linux / Unix 서버를 패치하고 있습니다. 그리고 수정이 끝나면 관리하는 Mac을 행복하게 패치 할 것입니다. 그러나 실제 일상적인 사용의 경우 높은 사용자 권한을 허용하지 않는 결함으로 인해 어떤 결과가 발생하는지 이해하지 못하기 때문에 걱정하지 않아도됩니다.

업데이트 : Apple의 공식 단어가 여기에 게시되었습니다 . 강조 광산 :

애플 대변인은 “대부분의 OS X 사용자는 최근에 bash 취약점을보고 할 위험이 없다” 고 애플의 대변인은 말했다. 취약한 시스템의 통제. OS X을 사용하면 시스템은 기본적으로 안전하며 사용자가 고급 UNIX 서비스를 구성하지 않는 한 원격 bash 공격에 노출되지 않습니다. 우리는 고급 UNIX 사용자를위한 소프트웨어 업데이트를 신속하게 제공하기 위해 노력하고 있습니다.”

번역 : 클라이언트 문제가 아닌 서버 문제에 대해 위에서 말한 내용은 무엇입니까? 바로 그거죠.

최종 UDPATE : 9 월 29 일 기준으로 소스에서 컴파일하는 데 어려움을 겪고있는 모든 사람을 위해 Apple은 공식적으로 Mac OS X 10.9.5, 10.8.5 및 10.7.5 용 패치를 출시했습니다.

또 다른 최종 업데이트 : 그리고 지금, 애플은 조합의 보안 업데이트를 오늘 출시했습니다 포함 bash뿐만 아니라 업데이 트를 !

참고 : 보안 업데이트 2014-005에는 OS X bash 업데이트 1.0의 보안 콘텐츠가 포함되어 있습니다

— 제이크 굴드
소스

7

"또는 서버 측 스크립팅을 실행하는 웹 서버"또는 응용 프로그램이 실행 중이거나 개방 된 포트에서 수신 대기하여 RPC 명령을 실행하여 쉘 명령을 실행할 수 있습니다. RPC를 수행하는 많은 표준 응용 프로그램이 있기 때문에 이것은 여러 가지 일이 될 수 있습니다. 나는이 대답이 매우 순진하다고 생각합니다. 클라이언트-서버 유형 작업을 수행하는 응용 프로그램을 실행하는 과정에서 실수로 "웹 서버를 실행"하는 것은 매우 쉽습니다.

— Ian C.

3

@IanC. 즉시 사용 가능한 OS X가 실제로 취약한 예를 제공 할 수 있습니까? 예를 들어 WebEx 또는 GotoMeeting과 같은 것이 Bash 기능 근처에 있습니까? 요점은 실제로 사물을 노출시키는 일반 OS X 설치 시나리오를 생각할 수 없다는 것입니다. 너는 할수 있니?

— JakeGould

8

게스트 계정은 ssh에서 사용할 수 없습니다 . 실제로 IIRC에서는 ssh에서 사용할 수 없습니다. 사실 대다수의 OS X 사용자에게 bash 취약점은 전혀 문제가되지 않습니다. 문제가있는 사람들에게는 테스트 픽스가 제공되는 즉시 bash를 다시 컴파일해야하지만 지금은 그렇지 않습니다.

— lbutlr

3

@IanC. 좋아요, 예를 들어. 그러나 여전히 요점을 놓치고 있습니다. 제공하는 모든 예제에서 이러한 취약점을 어떻게 악용합니까? 각각의 경우에 사용자는 시스템에 액세스하여 &로 시작해야합니다. 나는 이것에 대해 변함이 없지만 여전히 위험이 실제로 무엇인지 파악하지 못하고 있습니까? 예를 들어 누군가가 Plex API를 통해 웜을 사용하여 정상적인 사용자 권한 및 액세스 권한 이외의 작업을 수행하기 위해 bash에서 정확히 무엇을해야합니까?

— JakeGould

6

@danielAzuelos “게스트 계정이 열려있는 한 모든 사람은 취약합니다 : [!” 게스트 계정은 아무 관련이 없습니다 bash. 그래서 두려움은 정확히 무엇에 근거합니까? 또한 게스트 계정이 열려 있고 어떻게 든 bash사용할 수 있다고해도 어떻게 해야합니까? 이 익스플로잇을 사용하여 추측 한 것에서 높은 권한이나 그와 비슷한 것은 없습니다. 진지하게, 나는 내 입장에서 기꺼이 기꺼이 기꺼이하지만 OpenSSL이 실제로 문제가되는 반면에별로 공황처럼 보이지 않습니다.

— JakeGould

37

예!

껍질에 이것을 입력하십시오

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

그렇다면 vulnerable당신은 취약합니다.

그것이 말한다면

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

그럼 당신은 좋습니다

수정 : 수정 사항에 연결

— 크리스 아이치 슨
소스

4

감사. 질문을 업데이트했습니다. 취약한 것으로 밝혀지면 Mac 사용자가 어떻게 해결할 수 있습니까?

— 헤어 보트

3

@abbyhairboat 내 답변을 게시했습니다. 외부 환경에 노출 된 서버를 실행하지 않으면 실질적인 위험이 없습니다. 서버 관리자는 이에 대해 걱정해야합니다.

— JakeGould

1

→ 애비 : apple.stackexchange.com/a/146851/22003 관련 답변을 참조하십시오 .

— dan

2

이것을 시도하십시오 env X="() { :;} ; echo busted" /bin/sh -c "echo completed"-시스템을 패치 한 후에도 명령 줄에서 '버릇없는'기침을합니다. 바.

— Trane Francks

1

@ Mark nope, zsh는 안전합니다. 테스트하려면 "bash -c"를 "zsh -c"로 바꿔야합니다.

— ismail

3

AS를 최종 사용자에게 다음 사항을 확인 :

손님 계정이 꺼져 있습니다 :

시스템 환경 설정> 사용자 및 그룹> 게스트 사용자

사용자의 ssh액세스가 꺼져 있습니다 :

시스템 환경 설정> 공유> 원격 로그인

기본적으로 Mavericks에서 둘 다 해제되어 있습니다.

AS를 최종 사용자 ,이다 안전 이 고정 공식 애플 보안 업데이트를 기다리는 bash취약점을.

— 단
소스

1

이것들은 관련이 없습니다. 이러한 특성은 본질적으로 사용자에게 시스템에서 명령을 실행할 수있는 액세스 권한을 부여하므로 사용자가 명령을 활성화 한 경우 사용자가 명령을 실행할 수 있습니다. 셸 쇼크 버그는 사용자를위한 수단 하지 않았다 그렇게 할 수 있도록 명령을 실행할 수 있도록하고자, EG 당신이 실행하는 웹 서버의 사용자. 따라서 귀하의 답변은 "웹 공유 비활성화"라고 말해야합니다 (하지만 확인해야 할 것은 한 가지입니다)

— Josh

애플이 그 설정을 끄지 말라고 화를 냈다. 누가 그들을 가능하게 했습니까? 그렇습니다. 나는 1986 년부터 Mac 사용자이며, 풀 타임 웹 응용 프로그램 개발자 (ssh는 내 인생)이고 아빠는 (어린이를위한 Guest 계정은 그렇게 나쁜 생각이 아닙니다). 이런 식으로 나와 같은 사람들이 Apple 랩탑을 사용한다는 것을 알고 있습니다. 우리를 잃고 싶습니까? 이 취약점을 열어 두는 것이 좋습니다.

— minopret

2

모든 Mac OS X 컴퓨터는 Apple이 bash를 패치하는 보안 업데이트를 발행 할 때까지 "Shellshock"에 기술적으로 취약합니다.

귀하의 질문은 : 원격으로 해킹 당할 수 있습니까?

bash결석 하게 사용하는 소프트웨어가 너무 많아서 그 질문에 대답하기가 매우 어렵습니다. 걱정되는 경우 System Preferences원격 악용을 방지하기 위해 몇 가지 변경 사항을 제안 합니다.

공유 환경 설정에서 모든 공유 서비스를 비활성화하십시오.
보안 및 개인 정보에서 방화벽을 활성화하십시오.

특히 걱정되는 경우 Firewall옵션 버튼을 눌러 다음 을 수행하십시오.

체크를 해제하십시오 Automatically allow signed software to receive incoming connections.
확인하십시오 Block all incoming connections.

DHCP, Bonjour 등을 사용한 레벨 공격에 취약 할 가능성은 여전히 있지만, 다른 서비스가 필요하다면 악용되지 않기를 바라면서 서비스를 계속 운영 할 수 있습니다. 그리고 방화벽도 더 열어 두어야합니다. 기계가 다른 방화벽 뒤에 있으면 괜찮을 것입니다.

또한 "Shellshock"에 의해 로컬 권한 에스컬레이션 공격이 가능합니까? 네, 거의 확실합니다. Mac OS X에는 비슷한 공격이 충분하기 때문에 걱정할 필요가 없습니다. Apple은 로컬 권한 에스컬레이션 버그를 빠르게 패치하지 않습니다. 그리고 Apple은 Apple Script 지원 서비스로 자주 만듭니다. 모든 Mac OS X 시스템이 항상 로컬 공격에 취약하다고 가정하십시오. DEFCON과 같은 해커 회의에 참석해야하는 경우, 해당 목적으로 Linux 상자를 구입하십시오.

업데이트 : 자신의 고정 배쉬 를 다시 컴파일 하는 방법 과 다른 질문 도 있습니다. 나는 이것을 직접 할 것이지만 IMHO는 서버를 실행하지 않고 애플 방화벽을 켜두면 과도합니다.

업데이트 : 터미널 사용에 익숙하다면 여기 에 execsnoop언급 된 프로그램이있어 서버 프로세스에서 bash가 일반적으로 호출되는지 테스트 할 수 있습니다. 서버 프로세스가 비정상적인 상황에서만 bash를 호출 할 수 있기 때문에 마술 총알이 아니지만 좋은 아이디어를 제공합니다.

마지막으로 Apple은 보안 취약점 패치에 대해서는별로 좋지 않지만 PR에는 능숙하므로 비교적 빨리 패치됩니다. 그러므로 "곰보다 더 빨리 달릴 필요는없고 인터넷에서 쉽게 이용할 수있는 수많은 서버보다 더 빨리 달릴 필요가있다"고 생각하는 것이 합리적입니다. :)

— 제프 버지스
소스

2

Mac이 Bash를 사용하지 않기 때문에 Mac이 DHCP를 사용한 공격에 취약 할 가능성은 없습니다.

1

어떻게 알았어? 초기 권고는 취약한 DHCP 클라이언트였습니다. 그리고 많은 기사에 따르면 Mac OS X 및 / 또는 iOS DHCP 클라이언트가 취약 할 수 있습니다. 달리 입증되지 않는 한 모든 서버는 취약한 것으로 가정해야합니다.

— Jeff Burdges

1

아닙니다. 그것은 절대 FUD입니다. OS X의 dhcp 구현을위한 오픈 소스 코드를 모두 검사하고 직접 시스템 호출을 측정하여 확인할 수 있습니다.

3

@JeffBurdges, OS X은 10.3 이후 DHCP와 함께 쉘 실행기를 사용하지 않았으며 그 bash가 시스템에 설치되지 않았습니다. OS X의 DHCP는 Shellshock의 문제가 아닙니다. (걱정할 것이 하나 더 적다. :)

— Trane Francks

1

→ Jeff : 고려하십시오 : strings /usr/libexec/bootpd | egrep '/bin|bash'및 nm -a /usr/libexec/bootpd | egrep 'fork|exec'. 맥 OS X의 버전에 따라이 명령의 출력을 읽고, 당신은 인해 위험 분석을 재고 할 수 dhcpd맥 OS X에 ...하지만 혼자 일 :(.

— 단

2

이 취약점에 대해 듣 자마자이 도구 를 만들었 습니다. 도구가 취약하다고 판단되면 셸을 패치 할 기사에 대한 링크를 제공합니다.

Mac OS X 10.6 이상이 필요합니다.

— 토마스 존스
소스

3

어쩌면 그것은 단지 나입니다 ...하지만 악용을 테스트하기 위해 임의의 사람 코드를 실행하는 아이디어 는 문자열을 쉽게 붙여 넣을 수있을 때 실제로 나쁜 생각 처럼 보입니다 (명확히 테스트를 실행하고 더 이상 아무것도 아닙니다). 터미널 창.

— Joe

나는 그것이 소스가 code.google.com/p/shellshock-check

— Thomas Jones

그러나 때때로 여러 시스템을 테스트하기 위해 사용 편의성을 제공 할 수 있습니다.

— Thomas Jones

나는 이것의 이점을 보지 못한다. 터미널 창에 간단한 명령 줄을 붙여 넣어 취약점을 확인하는 것이 훨씬 쉽습니다.

— Albert Godfrind

여러 시스템을 테스트 할 때, 특히 내 경우에는 플래시 드라이브를 넣고 Shellshock Check.app를 여는 것이 Safari를 열고 bash 명령을 확인한 다음 터미널을 열어서 붙여 넣는 것보다 훨씬 쉽습니다. 명령을 입력 한 다음 Enter 키를 누릅니다. 플래시 드라이브를 연결하고 하나의 응용 프로그램을 여는 것이 훨씬 빠릅니다.

— Thomas Jones