2P by neo 3달전 | favorite | 댓글 1개

SBAT(Secure Boot Advanced Targeting)의 정의

  • UEFI Secure Boot가 처음 지정되었을 때, 모든 관련자들이 다소 순진했음
  • Secure Boot의 기본 보안 모델은 커널 레벨의 권한 환경에서 실행되는 모든 코드가 실행 전에 검증되어야 한다는 것
  • 취약점이 발견된 서명된 구성 요소를 폐기하는 방법이 포함되어 있음
  • 그러나 Secure Boot 생태계에서 작동하는 모든 Linux 배포판은 자체 부트로더 바이너리를 생성하므로, 취약점이 식별되면 폐기해야 할 바이너리가 많음
  • 해시를 저장할 수 있는 공간이 제한되어 있어 SBAT가 개발됨

SBAT의 작동 방식

  • 부트 체인의 모든 중요 구성 요소는 서명된 바이너리에 포함된 보안 생성을 선언함
  • 취약점이 식별되고 수정되면 해당 생성이 증가함
  • 업데이트를 통해 최소 생성을 정의할 수 있음
  • 부트 구성 요소는 체인의 다음 항목을 보고, 이름과 생성 번호를 펌웨어 변수에 저장된 것과 비교하여 실행 여부를 결정함
  • 개별 해시를 많이 폐기하는 대신, 특정 번호 이하의 보안 생성을 가진 grub 버전을 신뢰할 수 없다고 말하는 하나의 업데이트를 푸시할 수 있음

최근 이슈의 원인

  • Microsoft는 특정 수준 이하의 보안 생성을 가진 grub 버전을 신뢰하지 않도록 Windows 업데이트를 내보냄
  • 이는 해당 grub 버전에 Windows 보안 부팅 체인을 손상시킬 수 있는 실제 보안 취약점이 있기 때문
  • 문제는 몇몇 Linux 배포판이 새로운 보안 버전의 grub 버전을 아직 제공하지 않았다는 것
  • Microsoft의 의도는 Windows만 있는 시스템에만 SBAT 업데이트를 적용하는 것이었지만, 이는 의도대로 작동하지 않았음

요약

  • Microsoft는 취약한 grub 버전을 사용하여 Windows를 공격할 수 없도록 하기 위해 Windows 업데이트를 밀어냄
  • 이 업데이트는 이중 부팅 시스템에는 적용되지 않도록 했지만, 무시되었음
  • 일부 Linux 배포판은 grub 코드와 SBAT 보안 생성을 업데이트하지 않았음
  • 결과적으로 일부 사용자는 시스템을 부팅할 수 없게 되었음

비난의 대상

  • Microsoft는 이중 부팅 설정을 정확하게 식별할 수 있도록 더 많은 테스트를 했어야 함
  • 그러나 또한 서명된 부트로더를 제공하는 배포판은 이를 업데이트하고 보안 생성을 업데이트해야 함
  • 이는 다른 운영 체제를 공격하는 데 사용될 수 있는 벡터를 제공하기 때문

결론

  • 갑자기 원하는 OS를 부팅할 수 없게 된 최종 사용자가 피해자가 된 것은 안타까운 일임
  • 이는 절대 일어나서는 안 되는 일임
  • UEFI Secure Boot가 대부분의 최종 사용자에게 이점이 없다고 느끼지만, 사후에 필요한 것을 알게 되는 것은 원하지 않는 일이므로 기본적으로 켜져 있는 Microsoft의 선택에 공감함
  • 이중 부팅 시스템에서 업데이트를 피하려는 실패한 시도를 제외하고는 Microsoft의 선택에 공감함

GN⁺의 의견

  • 이 사건은 보안과 사용자 경험 사이의 균형을 맞추는 것이 얼마나 어려운지 보여줌
  • Microsoft와 Linux 배포판 모두 사용자를 보호하기 위해 최선을 다하고 있지만, 이 과정에서 사용자 경험이 희생될 수 있음
  • 이중 부팅 시스템을 사용하는 사용자의 경우 이러한 문제에 직면할 가능성이 더 높음
  • 따라서 이중 부팅을 사용하는 사용자는 두 운영 체제 모두 최신 버전으로 유지하고 정기적으로 업데이트하는 것이 중요함
  • 장기적으로는 Linux와 Windows 커뮤니티 간의 더 나은 협력과 조정이 필요할 것으로 보임
Hacker News 의견
  • 최근 Linux Unplugged 에피소드에서 TPM을 사용하여 Linux 부팅 프로세스의 신뢰 체인을 설정하는 방법을 다루었음, Clevis를 사용하여 매우 흥미로웠음
  • Microsoft의 의도는 Windows Update가 Windows 전용 시스템에만 SBAT 업데이트를 적용하고, 듀얼 부팅 설정은 설치된 배포판이 grub을 업데이트하고 SBAT 업데이트를 자체적으로 배포할 때까지 취약하게 남겨두는 것이었음
    • EFI 부팅 순서를 읽으면 shim을 먼저 부팅하라고 명확히 나와 있을 텐데, 무엇이 잘못되었는지 궁금함
    • 듀얼 부팅 설정에서 사용자가 펌웨어 메뉴를 사용하여 Linux 또는 Windows를 선택하는 경우였는지 궁금함
    • 이 문제는 Microsoft의 정당한 수정 사항으로 보이지만, 커뮤니케이션이 좋지 않았음
  • shim 또는 SB의 일반적인 보안 검사 실패 시 오류 메시지가 매우 싫음, 무엇이 정확히 실패했는지와 해결 방법을 알려주었으면 좋겠음
  • MS가 TPM2.0을 강제하고 SBAT 업데이트를 시행하는 이유 중 하나는 광범위한 루트킷 수준의 악성코드가 존재하기 때문이라고 생각함
  • 듀얼 부팅의 현실에 대해, 10년 전 Win7/8/10에서 suspend-to-hiberfile.sys 문제와 업데이트로 인해 grub이 깨지는 문제가 많았음
    • 10년 전부터 Linux만 사용하기로 결정했으며, 필요할 경우 VM을 사용하거나 별도의 예비 컴퓨터를 사용함
    • 이후로 배포판에 Secure Boot를 성공적으로 설정하고, QEMU 성능 및 패스스루를 조정하는 방법을 배웠으며, QEMU macOS VM을 작동시켰음
    • XCode를 유지하기 위해 몇 달마다 업데이트해야 하는 것이 번거롭지만, 전반적으로 만족스러움
  • Linux를 설치할 때 Secure Boot를 비활성화하는 것이 첫 번째가 아닌가?
  • 주요 질문은 거부되는 grub이 완전히 패치되지 않은 것인지, 아니면 배포판에서 "보안 세대"를 업데이트하지 않고 패치한 것인지임
    • MS가 듀얼 부팅 감지를 시도한 방법에 대해 매우 궁금하며, 누군가(더 숙련된 사람이) 업데이트에서 그 부분을 역공학해주기를 바람
  • Microsoft가 듀얼 부팅 시스템을 깨뜨린 이유는 다른 운영 체제를 공격할 수 있는 벡터를 제공하지 않기 위해서이며, 이는 사회적 계약의 위반임
  • Windows를 시스템에서 제거하고 Linux를 설치하는 데 방해가 되는지, 아니면 Windows를 설치하면 TPM 모듈이 영구적으로 오염되는지 궁금함
  • Windows에서 grub을 업데이트할 수 있는지, 아니면 Secure Boot를 비활성화하고 Linux를 부팅한 다음 업그레이드하고 다시 활성화하는 것으로 충분한지 궁금함
  • MS의 오래된 취약한 grub 설치를 차단하는 입장은 합리적으로 보이지만, 게임과 단일 레거시 소프트웨어를 위해서만 Windows를 사용하며, 네트워크 접속 없이 사용함
    • Windows 업데이트를 허용하는 순간 모든 것이 운에 맡겨짐
    • MS가 레지스트리 키를 이동시키고 "텔레메트리"(광고 및 행동 데이터 스캔을 위한 ML) 강제를 위해 사용자에게 장난을 치는 것은 충분히 말해줌
    • Windows Pro에서도 이러한 일이 발생하며, Win 10을 사용하고 있음