Unity 플랫폼 보호: 개발자 문제 해결 가이드

개요

Unity 2017.1 이상 버전으로 빌드된 Android, Windows, Linux, macOS용 게임과 애플리케이션에 영향을 미치는 보안 취약점이 확인되었습니다. 취약점의 악용 사례는 발견되지 않았으며, 사용자나 고객에게 미친 영향도 없는 것으로 알려졌습니다. 이 취약점은 Unity 애플리케이션이 네이티브 및 관리되는 확장 프로그램을 로드하고 실행할 수 있도록 하는 커맨드 라인 인자에서 발생합니다. 이 취약점이 타겟 플랫폼에 미칠 수 있는 영향을 이해하려면 플랫폼별 기술 참고 사항을 확인하세요.

중요: 프로젝트가 Unity 2017 버전부터 오늘 배포된 패치 릴리스 사이의 버전으로 빌드된 경우 영향을 받을 수 있습니다. 영향을 받는 프로젝트를 소유한 모든 개발자는 조치를 취해야 합니다.

문제 해결 옵션

Unity 2017.1 이상 버전으로 Android, Windows 또는 macOS용 게임이나 애플리케이션을 개발했거나 릴리스한 경우에는 조치를 취해야 합니다. 이 취약점이 Linux에 영향을 미칠 위험은 낮으므로 개발자들은 패치된 버전의 Unity로 업데이트함으로써 충분히 보호받을 수 있습니다.

유니티는 2019.1부터 이후 버전에 대해 에디터의 패치 버전을 릴리스했습니다. 애플리케이션이 Unity 2019 이상 버전으로 빌드된 경우 유니티에서는 패치된 Unity 에디터로 애플리케이션을 다시 빌드할 것을 권장합니다. 그러나 유니티에서는 소스에서 프로젝트를 다시 빌드할 수 없거나 2017/2018 버전으로 빌드한 경우를 위해 '빌드된 애플리케이션 패치' 섹션에 설명된 대로 패치 툴도 제공합니다.

1. 패치된 Unity 에디터로 다시 빌드(권장)

영향을 받는 Unity 에디터 버전별로 패치된 릴리스를 다운로드할 수 있습니다. 패치된 Unity 에디터를 다운로드한 다음 애플리케이션을 다시 빌드할 수 있습니다.

패치된 Unity 에디터 버전으로 애플리케이션을 다시 빌드하는 방법은 다음과 같습니다.

1. 애플리케이션을 빌드할 때 사용한 Unity 버전(예: Unity 6.1, Unity 2022.2 등)과 일치하는 Unity 에디터 최신 릴리스를 다운로드합니다.
2. Unity Hub
3. Unity 다운로드 아카이브
4. 업데이트된 에디터에서 프로젝트를 엽니다.
5. 애플리케이션을 다시 빌드하고 다시 테스트합니다.
6. 배포 채널에 다시 퍼블리시합니다.

2. 빌드된 애플리케이션 패치

소스에서 다시 빌드할 수 없는 경우(또는 앱을 다시 빌드하는 동안 핫픽스를 배포하려는 경우), Unity 애플리케이션 패치 프로그램을 사용하여 기존 Android, Windows, macOS 빌드를 업데이트하세요.

Unity 애플리케이션 패치 프로그램을 사용하는 방법은 다음과 같습니다.

1. Unity 애플리케이션 패치 프로그램 다운로드: 툴 다운로드
2. 라이선스 계약, 사용 가이드, 고급 옵션을 검토하세요. 자세한 내용은 패치 프로그램 기술 자료를 참조하세요.
3. 기존 빌드를 대상으로 패치 프로그램 툴을 실행합니다. Windows 또는 macOS 빌드를 패치하려면 인터넷에 연결되어 있어야 합니다.
4. 패치 후 애플리케이션을 테스트하여 기능을 확인합니다.
5. 배포 채널에 다시 퍼블리시합니다.

Unity 애플리케이션 패치 프로그램이 어떻게 동작하는지 이해하려면 플랫폼별 기술 참고 사항을 확인하세요.

참고:

• 패치 프로그램은 일부 변조 방지 또는 부정 행위 방지 솔루션으로 보호된 빌드와 호환되지 않습니다.
• 패치 후에는 항상 애플리케이션의 무결성과 기능을 확인하세요.
• Unity 애플리케이션 패치 프로그램 툴 자체는 Unity 6.0으로 개발되었으므로, 툴 실행에는 관련 Windows 또는 macOS 시스템 요구 사항이 적용됩니다.

플랫폼별 기술 참고 사항

다음 섹션에서는 보안 취약점이 Android, Windows, macOS 애플리케이션에 미치는 영향과 Unity 애플리케이션 패치 프로그램이 각 플랫폼에서 어떻게 동작하는지를 설명합니다.

릴리스 스트림의 일부 베타와 패치 릴리스는 영향을 받지 않을 수 있습니다. 최종 릴리스가 아닌 버전으로 빌드해 배포한 경우 영향을 받는 전체 버전 목록을 확인하시기 바랍니다.

참고: Google, Meta, Microsoft에서는 플랫폼을 더 안전하게 보호하기 위해 OS 수준의 추가 조치를 배포했습니다. 그러나 Unity 애플리케이션을 완전히 안전하게 유지하려면 반드시 패치하거나 다시 빌드해야 합니다.

Android

참고: 취약점의 악용 사례는 발견되지 않았으며, 사용자나 고객에게 미친 영향도 없는 것으로 알려졌습니다.

Android의 경우, 제작한 Unity 앱이 Unity 2019.1 이상 버전으로 빌드되었다면 어떠한 특별한 권한이나 설정에 관계없이 조치를 취해야 합니다.

또한 앱이 Unity 2017 이상 버전으로 빌드되었고 Mono 런타임(32비트만 해당)을 사용하는 경우 취약점이 존재할 수 있습니다. 최종 릴리스가 아닌 버전으로 빌드해 배포한 경우 영향을 받는 전체 버전 목록을 확인하시기 바랍니다.

• Android에서는 일반적으로 애플리케이션이 서로 격리되어 있고, 취약점이나 잘못된 구성이 없는 한 앱 간 코드 삽입은 불가능합니다.
• 이 취약점을 악용하면 동일 디바이스 내 다른 앱이 목적별로 제작된 인텐트와 xrsdk-pre-init-library 커맨드 라인 인자나 Mono로 빌드한 32비트 앱에서 overrideMonoSearchPath를 통해 Unity 앱을 실행하고 악성 네이티브 라이브러리를 삽입할 수 있습니다.
• Android 앱은 datafolder나 monoProfiler커맨드 라인 인자에 취약하지 않습니다.

Android 관련 주요 변경 사항

Android의 이 취약점 해결과 관련된 주요 변경 사항은 없습니다.

Android용 Unity 애플리케이션 패치 프로그램

Android에서 Unity 애플리케이션 패치 프로그램은 APK 또는 AAB를 언팩하고 libunity.so와 boot.config를 로컬에서 수정하여 취약한 코드 경로를 차단한 다음, APK 또는 AAB를 다시 패키징하고 서명합니다.

Unity 애플리케이션 패치 프로그램은 xrsdk-pre-init-library 문자열을 8rsdk-pre-init-library로 변경하여 libunity.so와 boot.config 모두에서 취약한 코드 경로를 차단합니다. 이 변경으로 인해, 인자 구문 분석 방식의 특성상 커맨드 라인 인자(또는 Android의 인텐트 엑스트라)로는 사용할 수 없게 됩니다. 단, boot.config 설정에서는 여전히 동작할 수 있으므로 boot.config 파일 내에서 사용되는 내용도 함께 패치합니다.

또한 Unity 애플리케이션 패치 프로그램은 Mono를 사용하는 32비트 빌드에서 overrideMonoSearchPath 인수를 비활성화하며, libunity.so에서 overrideMonoSearchPath 문자열의 첫 번째 문자를 유효하지 않은 유니코드 문자 0xC0로 교체합니다.

Windows

참고: 취약점의 악용 사례는 발견되지 않았으며, 사용자나 고객에게 미친 영향도 없는 것으로 알려졌습니다.

Windows와 같은 데스크톱 플랫폼에서는 실행 중인 프로세스에 코드를 삽입할 수 있는 다양한 방법이 있습니다. 그러나 이러한 방법들은 일반적으로 시스템 권한 수준과 보안 경계에 의해 제한됩니다. 대부분의 경우 본인이 직접 시작한 프로세스에만 코드를 삽입할 수 있고, 만일 삽입하더라도 해당 프로세스가 이미 가진 권한 이상으로는 추가 권한을 얻을 수 없습니다.

그러나 이 상황에서 Unity 앱이 커스텀 URL 스키마 핸들러로 등록되어 있다면 권한 상승에 취약할 수 있습니다. 이러한 등록은 애플리케이션에서 수행하거나(예: 딥링크 지원 또는 브라우저에서의 앱 실행), 다른 애플리케이션에서 수행할 수도 있습니다(예: 타사 게임 런처 또는 스토어 플랫폼).

타사 애플리케이션이 사용자의 애플리케이션을 스키마 핸들러로 등록했는지 확인하거나 등록을 막을 방법이 없으므로, Unity에서는 모든 Windows용 Unity 애플리케이션에 대해 예방 차원에서 패치를 적용할 것을 권장합니다.

• 등록된 URL 스키마가 있는 경우, 무결성 수준이 낮으면(샌드박스 환경이거나 권한이 제한된 프로세스 등) 코드를 실행하는 공격자가 이 Unity 취약점을 악용하여 앱을 실행하고 DLL을 삽입할 수 있습니다. 그 결과 애플리케이션이 원래보다 높은 권한으로 공격자가 제공한 코드를 실행하게 됩니다.
• 삽입은 위에 나와 있는 취약한 커맨드 라인 인자를 통해 발생할 수 있습니다.

Windows 관련 주요 변경 사항

• 앱에서 -datafolder 커맨드 라인 인자를 사용하여 datafolder를 이동하는 경우, 다음과 같이 customDataFolder를 UnityMain 함수에 두 번째 인자로 전달해야 합니다.
• int UnityMain(HINSTANCE hInst, LPCWSTR customDataFolder, LPWSTR szCmdLine, int nCmdShow)
• 앱에서 XR 제공자를 전환하기 위해 xrsdk-pre-init-library를 커맨드 라인 인자로 사용한 경우, OpenXR을 사용하거나 별도의 빌드를 제공하는 방식으로 전환할 것을 권장합니다.
• overrideMonoSearchPath 커맨드 라인 인자를 제거하고 별도의 앱을 빌드하거나 동일한 빌드에 모든 스크립트를 포함하는 것이 좋습니다.

Windows용 Unity 애플리케이션 패치 프로그램

Windows 빌드의 경우 Unity 애플리케이션 패치 프로그램 툴에서는 사용 중인 Unity 버전에 맞는 패치된 UnityPlayer.dll(또는 Unity 2017.1로 빌드한 애플리케이션의 .exe)을 다운로드한 다음 빌드된 애플리케이션의 취약한 파일을 해당 파일로 교체합니다.

참고: Unity 애플리케이션 패치 프로그램은 Unity 서버에서 사전 패치된 바이너리를 가져오며, 사용자가 해당 바이너리를 받기 전에 테스트와 검증을 거쳤음을 보장합니다.

UnityPlayer.dll은 취약한 커맨드 라인 파라미터를 무시하도록 수정되었습니다.

xrsdk-pre-init-library는 여전히 boot.config 설정으로 동작합니다.

중요: 앱에서 -datafolder 커맨드 라인 인자를 사용하여 datafolder(Unity 2022.2에서 도입)를 이동하는 경우 Windows 관련 주요 변경 사항 섹션에 안내된 새로운 방식을 적용해야 합니다.

macOS

참고: 취약점의 악용 사례는 발견되지 않았으며, 사용자나 고객에게 미친 영향도 없는 것으로 알려졌습니다.

macOS에서는 카메라 액세스나 사용자 문서 폴더 액세스와 같이 많은 권한이 애플리케이션 단위로 관리됩니다. macOS는 이러한 권한의 남용을 방지하기 위해 강화된 런타임 보안 기능을 포함한 여러 메커니즘을 제공합니다. 기본적으로, 강화된 런타임 보안으로 빌드된 앱은 서명되지 않았거나 다른 서명이 적용된 코드를 로드할 수 없습니다.

강화된 런타임 사용은 인증 절차에서 필수이며, 이 방식은 Mac App Store가 아닌 플랫폼에서 배포될 때 권장됩니다. Mac App Store에서 배포할 경우 엄격하게 지켜야 할 필수 사항은 아니지만, 앱에서는 최소한 App Sandbox를 사용해야 합니다. App Sandbox는 앱이 시스템에서 액세스할 수 있는 항목을 제한하지만, 앱의 자체 프로세스에 코드 삽입이 발생하는 것을 방지하지는 않습니다. 강화된 런타임을 사용하지 않아도 DYLD_INSERT_LIBRARIES 등의 기술이 이미 지원되므로 이 취약점으로 인해 해당 환경에서 악용 가능성이 증가하지 않습니다. 그렇더라도 유니티는 영향을 받는 모든 macOS 앱을 패치하거나 다시 빌드하여 취약한 코드 경로를 제거할 것을 권장합니다. 이렇게 하면 추후 강화된 런타임이 활성화되거나 Mac App Store가 아닌 플랫폼에서 배포될 경우 보안을 유지할 수 있습니다.

애플리케이션이 Unity 2017.1 이상(Mono 스크립팅 백엔드 포함)이나 Unity 2019.1 이상(스크립팅 백엔드 포함)으로 빌드되었고 강화된 런타임을 사용해 빌드되었으며, 코드 삽입 방지를 약화시키는 특정 런타임 예외가 활성화되어 있다면 조치를 취해야 합니다. 앱을 취약하게 만들 수 있는 예외는 다음과 같습니다.

• 라이브러리 확인 비활성화(com.apple.security.cs.disable-library-validation) - 서명되지 않았거나 다른 서명이 적용된 플러그인이나 프레임워크 로드를 허용합니다. 이로 인해 xrsdk-pre-init-library나 datafolder 인자를 사용할 때 악성 네이티브 .dylib 파일이 로드될 수 있습니다.
• JIT 컴파일 코드 실행 허용(com.apple.security.cs.allow-jit) - datafolder 또는 overrideMonoSearchPath 인자가 악용될 경우 악성 관리 코드가 실행될 수 있습니다. 이 예외를 허용하는 것은 Mono 스크립팅 백엔드를 사용하는 모든 경우에 필수 사항입니다.
• 서명되지 않은 실행 가능한 메모리 허용(com.apple.security.cs.allow-jit) - 이 또한 datafolder 인자가 악용될 경우 악성 관리 코드 실행으로 이어질 수 있습니다.
• Unity 2023.2 이상으로 빌드된 앱: 이러한 예외에 해당하지 않더라도 datafolder의 악용 가능성은 여전히 남아 있습니다.

강화된 런타임 보안은 일반적으로 흔히 사용되는 코드 삽입 방식을 차단하여 애플리케이션을 이러한 공격으로부터 보호합니다. 위 예외 중 하나라도 활성화된 경우, 영향받는 Unity 앱에서는 공격자가 xrsdk-pre-init-library나 datafolder, overrideMonoSearchPath 커맨드 라인 인자를 통해 코드를 삽입할 수 있습니다.

이로 인해 공격자가 프로세스에 악성 .dylib 또는 관리되는 어셈블리를 삽입할 수 있습니다. 앱 자체에 부여되지 않은 권한에는 액세스할 수 없습니다.

macOS 관련 주요 변경 사항

• 앱에서 -datafolder 커맨드 라인 인자를 사용하여 datafolder를 이동하는 경우, 심링크를 사용할 것을 권장합니다.
• overrideMonoSearchPath 커맨드 라인 인자를 제거하고 별도의 앱을 빌드하거나 동일한 빌드에 모든 스크립트를 포함하는 것이 좋습니다.

macOS용 Unity 애플리케이션 패치 프로그램

macOS 프로젝트의 경우 Unity 애플리케이션 패치 프로그램 툴에서는 사용 중인 Unity 버전에 맞는 패치된 UnityPlayer.dylib를 다운로드한 다음 빌드된 애플리케이션의 취약한 파일을 해당 파일로 교체합니다. boot.config 변수 xrsdk-pre-init-library가 8rsdk-pre-init-library로 변경되었습니다. 이 변경으로 인해 인자 파싱 방식의 특성상 커맨드 라인 인자로는 사용할 수 없게 됩니다. 단, boot.config 설정에서는 여전히 동작할 수 있으므로 boot.config에 포함된 경우에도 함께 패치합니다.

Unity 애플리케이션 패치 프로그램 1.3의 새로운 동작:

• 패치 프로그램은 강화된 런타임이나 권한과 무관하게 모든 macOS 애플리케이션의 UnityPlayer.dylib를 패치합니다.
• com.apple.security.cs.disable-library-validation 권한 없이 강화된 런타임을 사용하는 애플리케이션의 경우 패치가 완료되면 패치 프로그램을 통해 권한이 서명되지 않습니다.
• 패치 프로그램에서 애플리케이션을 서명하지 않을 경우 애플리케이션을 수동으로 서명해야 하며, 그렇지 않으면 실행되지 않는다는 경고 메시지가 표시됩니다.
• 이 변경 사항에서는 개발자가 명시적으로 다시 서명하지 않으면 패치된 애플리케이션이 약화된 보안 상태에서 실행되지 않도록 합니다.

패치 프로그램을 통해 앱이 서명되면 임시 서명을 사용하여 로컬 테스트를 수행합니다. 애플리케이션이 이전에 개발자 ID 인증서로 서명되고 Apple에서 인증된 경우, 패치 작업에서 해당 인증은 무효화됩니다. 릴리스 전에 소프트웨어 배포 시 Apple의 권장 사항에 따라 다시 서명하고 재인증하시기 바랍니다.

Linux

참고: 취약점의 악용 사례는 발견되지 않았으며, 사용자나 고객에게 미친 영향도 없는 것으로 알려졌습니다.

Linux에서는 취약한 Unity 커맨드 라인 인자가 LD_PRELOAD 메커니즘과 유사하게 작동합니다. 표준 Linux 보안 모델에 따르면 이러한 인자는 권한 경계를 넘지 않으므로 LD_PRELOAD에서 발생 가능한 것과 비교해 추가적인 위험이 발생하지 않습니다.

AppArmor, bubblewrap, Firejail 또는 SELinux와 같은 환경에서 제한된 프로세스가 제한 범위를 벗어나 Unity 애플리케이션을 실행할 수 있는 경우, 이미 임의 코드 실행이 가능하며, 이 취약점이 추가적인 위험을 초래하지는 않습니다. 특정 SELinux 또는 AppArmor 설정에서는 Unity가 임의의 인자로 시작될 수 있는 동안에도 흔히 사용되는 삽입 방식(LD_PRELOAD, ptrace)이 차단될 수 있습니다. 이 경우, 취약한 인자는 정책 제한을 우회하여 실행 가능한 악용 경로가 될 수 있습니다.

완화 조치

위험성이 낮기 때문에 유니티는 Unity 애플리케이션 패치 프로그램의 Linux 버전을 출시하지 않았습니다. 특히 엄격한 액세스 제어 정책이 적용되는 환경에서 필요한 경우, 패치된 Unity 에디터로 Linux 애플리케이션을 다시 빌드하여 취약한 코드 경로를 제거하세요.

기타 플랫폼(iOS, 콘솔 등)

iOS를 포함한 다른 모든 Unity 지원 플랫폼에서는 취약점이 악용될 가능성이 발견되지 않았습니다. 최고 수준의 보안을 위해, 유니티에서는 최신 패치가 적용된 Unity 에디터로 앱을 다시 빌드할 것을 권장합니다.

리소스

• 패치된 Unity 에디터 다운로드
• Unity 애플리케이션 패치 프로그램 다운로드
• 유니티 보안 권고
• CVE 세부 정보
• Unity 지원 서비스

애플리케이션의 보안을 강화하고 사용자를 보호하기 위해 조치가 필요합니다. 질문이 있거나 도움이 필요한 경우, Unity 지원 팀에 문의해 주세요.