마이크로소프트, Windows 10 업데이트 설치를 위한 명령 줄 조작 권장

 (theregister.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Windows 10용 KB5034441은 BitLocker 우회 취약점을 막기 위한 보안 업데이트지만, 일부 PC에서는 설치 단계에서 실패함
  • 문제의 핵심은 WinRE 복구 파티션으로, 표준 Windows 10 설치 환경의 파티션 크기가 업데이트를 처리하기에 부족할 수 있음
  • 설치 실패 시 0x80070643이 표시될 수 있으나, 실제 원인은 CBS_E_INSUFFICIENT_DISK_SPACE에 해당하는 복구 환경 서비스 실패일 수 있음
  • Microsoft의 임시 해결책은 관리자 명령 프롬프트에서 WinRE를 끄고 복구 파티션을 삭제·재생성하는 방식이라 일반 사용자에게 위험함
  • 사용자들은 이 절차가 “너무 기술적이고 무섭다”고 반응하며, Microsoft가 직접 수정본을 내야 한다는 불만이 커짐

KB5034441 설치 실패와 복구 파티션 문제

  • Microsoft는 2024년 1월 9일 Windows 10 21H2와 22H2용 KB5034441을 배포함
    • 목적은 Windows Recovery Environment, 즉 WinRE를 이용해 BitLocker 암호화를 우회할 수 있는 취약점을 막는 것임
  • 일부 사용자는 업데이트 설치 중 0x80070643 오류를 만남
    • 이 코드는 일반적인 설치 실패 메시지에 가깝고, Microsoft에 따르면 “오류 코드 처리 루틴의 오류” 때문에 실제 원인을 정확히 나타내지 않을 수 있음
  • 실제 원인은 복구 파티션 공간 부족일 수 있음
    • Microsoft가 제시한 실제 오류 문구는 Windows Recovery Environment servicing failed. (CBS_E_INSUFFICIENT_DISK_SPACE)임
    • 표준 Windows 10 설치 PC의 복구 파티션이 이 업데이트를 처리하기에 충분히 크지 않을 가능성이 있음

위험한 수동 우회 절차

  • Microsoft는 디스크 공간 문제를 겪는 사용자에게 KB5028997에 따라 복구 파티션을 직접 조정하라고 안내함
    • 관리자 권한 명령 프롬프트를 열어야 함
    • WinRE를 비활성화한 뒤 복구 파티션을 삭제하고 다시 만드는 명령을 실행해야 함
    • 익숙하지 않은 사용자가 실수하기 쉬운 절차임
  • 소셜 미디어에서는 문제가 널리 발생하고 있으며, 사용자는 Microsoft의 우회 방법 적용을 꺼리는 분위기임
    • 일부 사용자는 절차가 “너무 기술적이고 무섭다”고 표현함
    • 다른 사용자는 “Microsoft가 직접 고쳐야 할 문제”라고 말함
    • 또 다른 사용자는 사용자가 Microsoft의 실수를 고칠 필요가 없으며, 업데이트를 보류하면 Microsoft가 향후 수정본을 배포할 것이라고 말함
  • Microsoft는 1월 16일 관련 공개 문서를 갱신함
    • 다만 가이드 자체는 변경되지 않음
    • “해결책을 작업 중이며 향후 릴리스에서 업데이트를 제공하겠다”고 밝힘

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 업데이트 설치 중 일부 사용자가 0x80070643 오류를 보는데, Microsoft에 따르면 “오류 코드 처리 루틴의 오류” 때문에 실제 오류가 아닐 수도 있다고 함
    오류를 위한 오류 코드 코드가 오류 때문에 오류의 오류 코드를 잘못 보여주는 셈임
    오류 코드 처리 코드를 얼마나 자주 건드리길래 오래전에 고쳐지지 않은 오류가 남아 있는지 궁금함. 원래는 한 번 만들고 잊어도 되는 종류처럼 보이는데, 오래전부터 있었지만 눈에 띄지 않았다면 오류 코드 코드의 품질 보증에도 오류가 있었던 것 같음

    • 그래서 예외와 오류 경로를 다루는 코드를 작성하거나 리뷰할 때는 더 엄격하고 꼼꼼하게 봄
      정상 경로 코드보다 더 단순하고, 말도 안 되게 이해하기 쉽고, 결합도가 낮아야 한다고 생각함. 상속도 추상화도 없고, 의존성 트리도 얕아야 함
      예외 처리 버그 때문에 시스템이 내려간 일을 너무 자주 겪었음. 예외 경로는 애초에 테스트가 거의 안 되거나 빠지는 경우가 많고, 예외는 정의상 예상하지 못한 곳에서 튀어나오는 경향이 강함
    • 나이 드러나는 얘기지만, 예전에 쓰던 OS/2 빌드는 가끔 “이 오류 메시지는 삭제되었습니다”라고 표시했음
    • 1년쯤 전에 맡았던 버그가 결국 로깅 코드의 예외 때문이었음
      예외 처리 코드가 던진 예외를 기록하는 바로 그 경우에만 로깅 코드에서 또 예외가 났음. 내부 도구라서 변경 로그 항목을 일부러 최대한 헷갈리게 써 두며 재미를 봤음
    • 제일 좋아했던 메시지는 작은 글씨로 “Something Happened”, 그리고 다시 “Something Happened”였음

  • 안내를 따라 해 봤고, 일부 사용자에게는 꽤 부담스러워 보일 수 있다는 점도 이해됨
    명령줄 대신 Windows Disk Management로 파티션을 줄이고 필요한 공간을 만들었음
    이 과정용 스크립트가 없다는 게 놀라운데, 그만큼 복잡하고 실수할 여지가 많다는 뜻처럼 보임. 그래서 단순히 더블클릭으로 끝나는 스크립트가 없는 이유도 작업 자체가 까다롭기 때문이라고 봄
    많은 사람이 기대하던 빠른 Windows Update 수정도 낙관하기 어렵지만, 곧 서드파티 개발자들이 이 과정을 자동화하는 스크립트나 프로그램을 내놓을 것 같음

  • “공격자가 Windows Recovery Environment(WinRE)를 이용해 BitLocker 암호화를 우회할 수 있는 취약점”이라는 부분이 있는데, 예전부터 복구 환경이 자동 복호화된 시스템 드라이브에 SYSTEM 권한으로 접근하게 해 주는 것처럼 보여서 늘 이상했음
    수년간 그랬고, 로그인 암호를 잃어버린 머신의 내용을 덤프하는 데도 쓸 수 있었음. 아마 원래 의도된 동작은 아니었던 듯함

    • TPM PIN을 쓰지 않거나 TPM이 2.0 미만일 때만 그런 얘기임
      PIN을 함께 쓰는 BitLocker의 TPM 방식은 TPM에 묻지 않고는 하드 드라이브 키를 알 방법이 없고, TPM은 PIN을 요구함. 무차별 대입 방지와 잠금도 내장돼 있음
    • 기억하기로 WinRE는 복구 작업 전에 로컬 관리자 암호를 요구하지 않나?
      그래서 “자동 잠금 해제”는 일반적으로 큰 단서가 붙는 기능이고, 가능하면 PIN, 암호, 네트워크 잠금 해제를 권장하는 이유 중 하나임. 다만 업데이트 때마다 노트북을 돌보며 재시작할 때마다 잠금을 풀어 줘야 한다는 단점이 있음

  • Microsoft는 무급 Insiders에게 맡기는 대신 제대로 된 품질 보증 부서를 다시 만들 수 없나? Flavor-Aid를 마시고 Microsoft가 코드를 하나도 잘못 짤 리 없다고 믿는 사람들에게 의존하는 것처럼 보임

    • 피드백 커뮤니티를 보면 Insiders 전체를 그렇게 보는 건 정확하지 않은 듯함
      다만 전통적인 품질 보증 부서를 없앤 지 이제 거의 10년이 됐고, 그 부서는 외부 사용자 검증 활용 이상의 역할을 했음. 솔직히 그 이전 10년에 비해 Windows가 더 자주 터진다고는 말하기 어렵지만, 지난 20년간 의료 시스템 같은 곳에서 패치 문제로 발생한 장애 통계는 실제 수치로 보고 싶음

  • 수정 방법이 겁나 보이긴 해도, 그래도 뭔가라도 내놓은 건 고맙게 봄
    몇 년 전 업데이트가 적지 않은 사람들의 ReFS 배열을 망가뜨렸을 때는 롤백 말고는 해결책을 받지 못했고, 결국 그 업데이트가 필수가 되면서 제거도 불가능해져 배열을 처음부터 다시 만들어야 했음

    • 뭔가를 내놓은 건 맞지만, 여전히 큰 사고임
      유료 제품에서 찌꺼기라도 던져 준다고 고마워할 일은 아님. 혹시 의도와 다르게 읽었다면 미안함
      Microsoft가 설치를 망가뜨리고 반쪽짜리 수정책을 내놓은 데 책임을 물어야 함. 복잡한 문제라 해도 데스크톱 운영체제 시장의 선두이고 그걸로 막대한 돈을 버는 회사라면 더 잘해야 함

  • 문제는 복구 파티션이 없거나 충분히 크지 않다는 것임
    Win10 가상 머신에서는 복구 파티션이 필요 없어서 설치 후 삭제했는데, 이제 해당 설치를 업데이트할 수 없게 됨

    • 복구 파티션을 비활성화하는 안내를 따라 했고, 애초에 공간을 할당하지 않았던 것 같음
      재부팅 후 Windows 11로 업그레이드할 수 있었고, 나중에 더 큰 문제가 생기지 않았기를 바람. 다음 단계로 안내된 시스템 파티션 크기 조정은 정말 건드리고 싶지 않았음
      경우마다 다르겠지만, 우연히 마주친 이 버그가 Hacker News 첫 페이지에 올라온 게 재미있음

  • “간단한 문제 하나 고치려고 명령줄로 가고 싶지 않아서 Windows를 쓴다”는 말이 있는데, 이미 그 동아리에 들어와 있었던 셈임
    몇 년 전 Windows가 갑자기 내 사용자 디렉터리에 접근 권한이 없다고 판단해서 Explorer와 작업 표시줄이 이상하게 망가진 시스템이 된 적이 있음
    고치려면 관리자 콘솔로 들어가 새 사용자를 만들고, 예전 계정의 파일을 새 계정으로 옮긴 뒤 소유권과 권한을 바꿔야 했음. 그러니 그래픽이라서 Windows가 쉽다는 생각은 헛소리임
    어차피 이상한 실패 모드에 빠져서 명령을 쳐 가며 수습해야 한다면 그냥 Linux와 NetBSD를 계속 쓰겠음

  • 전직 Windows 개발자로서 Windows 업그레이드 때문에 크게 짜증났던 기억이 있음
    설치 폴더에 더 이상 안정적으로 쓸 수 없게 됐고, 레지스트리에 쓰게 하더니 데이터 폴더와 다른 위치들로 나눠 쓰게 만들었음. 그래서 설치를 “열 갈래”로 쪼개서 데이터 위치를 관리해야 했고, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER 등을 다룬 뒤 설치 권한 상승을 요청해야 했음
    설치 폴더의 파일을 삭제했는데 Windows가 백그라운드에서 그 파일의 예전 버전을 복원하는 버그를 디버깅했던 기억도 어렴풋이 남아 있음. c:\program files는 가상화되어 더 이상 진짜 디렉터리처럼 동작하지 않았음

    • 설치 폴더에 안정적으로 쓸 수 없게 된 건 아마 Windows XP 때 들어온 변화였고, 좋은 변화였다고 봄
      사용자 프로그램이 실행 파일로 가득 찬 폴더에 쓰게 두는 건 보안상 끔찍함

  • 모든 업데이트를 공개되자마자 바로 설치하지 않는 편이 낫다는 판단도 가능함

    • macOS와 iOS에서는 잠깐 기다리는 식으로 쓰지만, Windows에는 자동 업데이트를 원하지 않는다고 설명할 방법을 못 찾았음
      특히 밤새 돌아가는 계산 작업 중간에 업데이트되는 건 곤란함
    • Microsoft가 그걸 바꿨나, 아니면 Windows 10 Home은 아직도 사용자가 최신 업데이트를 즉시 설치하도록 강제하나?
    • Google이 Android와 Chrome OS에서 하듯이 Microsoft도 이런 업데이트를 내부에서 먼저 먹어 보나?

  • 기자가 Linux를 써 봤다면 무작위 숫자처럼 보이는 오류 코드보다 훨씬 나은 오류 메시지를 보여준다는 걸 알았을 것임

    • 말 그대로 잘못된 오류 메시지를 보여준 상황 아닌가?
      Microsoft에 따르면 “오류 코드 처리 루틴의 오류 때문에” 이 오류가 올바른 오류가 아닐 수도 있다고 되어 있음
    • Windows를 쓰기 좋게 만드는 건 오류 메시지가 아니라 원클릭 해결임
    • 종료 코드 139라, 흠
    • 맞지만, 가끔 유용한 메시지는 dmesg에서만 찾을 수 있음
답변달기