FlawOpen

flawopen.com/Teardowns/cve-2026-65995-osmand-aidl-authorization

● CVE-2026-65995 · 높음
보안 연구 · FlawOpen

CVE-2026-65995: OsmAnd AIDL 권한 우회

OsmAnd 5.3.3은 내보낸 Android AIDL 서비스에서 알 수 없는 호출자를 자동 승인해 기기에 이미 설치된 모든 앱이 위치 및 파일 작업에 접근할 수 있게 했습니다. 공개 권고문은 수정 사실을 확인하지만 최초 수정 버전이나 CVSS 점수는 밝히지 않습니다.

💡 알기 쉬운 설명 (ELI5)

방문자 명단을 확인해야 하는 건물 안내 데스크가 새 방문자가 올 때마다 곧바로 승인 명단에 추가한다고 상상해 보세요. OsmAnd 서비스는 같은 휴대전화의 앱에 비슷하게 대응했습니다. 알 수 없는 호출자를 활성 상태로 등록한 뒤 연동 인터페이스를 열어 주었습니다. 수정하려면 명시적인 승인과 실제 Android 호출자 신원 확인이 필요합니다.

핵심 개념 및 용어

AIDL
Android Interface Definition Language: Binder IPC를 통해 한 Android 프로세스가 다른 프로세스가 공개한 메서드를 호출하는 방식입니다.
내보낸 서비스
다른 앱이 연결할 수 있는 Android 서비스입니다. 민감한 메서드는 권한이나 동등한 호출자 검증으로 보호해야 합니다.
호출자 UID
운영체제가 앱 프로세스에 부여한 ID입니다. 서비스는 호출자가 제공한 패키지명이 아니라 Binder에서 UID를 가져와야 합니다.
CWE-862
공유 권한 경계의 부재에 대한 FlawOpen의 편집상 분류입니다. GHSL은 여러 약점 중 하나로 CWE-862를 나열하며 CVSS 점수는 공개하지 않았습니다.

프레임워크 매핑

  • MITRE CWE에 대한 FlawOpen의 개념적 매핑입니다. 공급업체나 CVE 레코드가 이 연구 시연에 해당 약점 ID를 지정한 것은 아닙니다. CWE-862

근본 원인 분석 (Root Cause)

GitHub Security Lab은 OsmAnd 5.3.3을 테스트해 내보낸 OsmandAidlServiceV2에 Android 권한이 없고 OsmandAidlApi.isAppEnabled()가 알 수 없는 ConnectedApp을 enabled=true로 생성한다고 확인했습니다. getApi()는 이 검사 결과로 AIDL 호출을 허용했기 때문에 새 로컬 앱은 사용자 승인까지 거부되는 대신 승인된 앱으로 저장되었습니다. GHSL에 따르면 위치/내비게이션 데이터를 반환하는 메서드와 경로 순회 문제가 있는 파일 작업 등 97개 AIDL 메서드가 노출됐습니다. 공격자는 같은 기기에 앱을 미리 설치해야 하지만 해당 앱에 위치 권한이나 추가 사용자 동작은 필요하지 않습니다. GHSL이 설명한 파일 영향은 OsmAnd 저장소 샌드박스 안에 한정되며 기기 전체 파일 시스템에 대한 접근은 아닙니다. 유지관리자는 2026년 6월 28일 수정 사실을 확인했지만 권고문은 최초 수정 버전을 밝히지 않습니다. CVSS 점수는 공개되지 않았습니다. FlawOpen은 위치 정보와 무결성에 영향을 주는 작업이 노출된 점을 근거로 심각도를 편집상 High로 평가합니다. CWE-862는 FlawOpen의 주요 편집상 매핑이며 GHSL이 단독으로 부여한 분류가 아닙니다.

단계별 공격 실행 흐름

단계 1

로컬 앱이 내보낸 서비스에 연결

취약한 서비스는 Android 권한 없이 내보내졌습니다. 같은 기기에 설치된 앱은 OsmAnd 위치 권한을 요청하지 않고 연결할 수 있었습니다.

단계 2

검사가 직접 승인을 생성

알 수 없는 패키지에 대해 isAppEnabled()가 enabled=true인 ConnectedApp을 생성해 저장했습니다. 검사가 확인해야 할 접근을 오히려 허용했습니다.

단계 3

공유 경계가 여러 기능을 개방

getApi()는 이 결과로 AIDL 호출을 처리했습니다. GHSL은 getAppInfo()와 파일 복사 작업을 포함해 97개 메서드에 도달할 수 있다고 설명합니다.

단계 4

영향은 문서화된 조건 안에 한정

악성 앱은 기기에 이미 설치돼 있어야 합니다. GHSL은 위치/내비게이션 노출과 OsmAnd 샌드박스 안의 파일 영향을 설명하며 기기 전체 접근이나 고객 기기의 실제 악용은 입증하지 않습니다.

소스 코드 비교: 취약한 구현 vs 보안 패치

취약 코드 발췌는 GHSL이 테스트한 5.3.3 분석에서 가져왔습니다. 아래 예시는 최소 fail-closed 정책 스케치이며 OsmAnd 패치나 완전한 권한 구현은 아닙니다. 승인 절차에서 UID, 설치된 패키지의 서명, 사용자 동의, 각 메서드의 권한 범위를 확인해야 합니다. 운영 서비스는 Binder 경계에서 권한을 확인하고 민감한 메서드를 각각 제한해야 합니다. GHSL은 수정 사실을 확인했지만 전체 diff나 최초 수정 버전은 공개하지 않았습니다. 지원 버전으로 업데이트하고 공급자 최신 안내를 확인하세요. 이 코드는 교육용이며 exploit 또는 위치/파일 payload를 포함하지 않습니다.

소스 코드 발췌: 메서드: isAppEnabled()

취약한 구현
public boolean isAppEnabled(@NonNull String pack) {
    ConnectedApp connectedApp = connectedApps.get(pack);
    if (connectedApp == null) {
        connectedApp = new ConnectedApp(app, pack, true);
        connectedApps.put(pack, connectedApp);
        saveConnectedApps();
    }
    return connectedApp.isEnabled();
}
보안 강화 패치
private final Set<Integer> approvedCallerUids = new HashSet<>();

private boolean isAppEnabled() {
    // 사용자의 명시적 승인과 신원 확인을 마친 뒤에만 값을 채우세요.
    return approvedCallerUids.contains(Binder.getCallingUid());
}

엔지니어링 및 시스템 보안 강화 체크리스트

출처