FlawOpen

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

● CVE-2026-65995 · उच्च
सुरक्षा अनुसंधान · FlawOpen

CVE-2026-65995: OsmAnd AIDL प्राधिकरण बाईपास

OsmAnd 5.3.3 ने export की गई Android AIDL सेवा में अज्ञात कॉल करने वालों को स्वतः मंज़ूरी दी, जिससे डिवाइस पर पहले से इंस्टॉल कोई भी ऐप स्थान और फ़ाइल क्रियाओं तक पहुँच सकता था। सार्वजनिक advisory सुधार की पुष्टि करती है, लेकिन पहली सुधरी रिलीज़ या CVSS स्कोर नहीं बताती।

💡 आसान भाषा में (ELI5)

ऐसे भवन रिसेप्शन की कल्पना करें जिसे अतिथि सूची जाँचनी चाहिए, लेकिन वह हर नए आगंतुक को आते ही स्वीकृत सूची में जोड़ देता है। OsmAnd की सेवा ने उसी फ़ोन के ऐप्स के साथ ऐसा ही किया: अज्ञात कॉलर को सक्षम के रूप में दर्ज किया और फिर एकीकरण इंटरफ़ेस खोल दिया। सुधार में स्पष्ट स्वीकृति और कॉलर की वास्तविक Android पहचान से उसका बंधन आवश्यक है।

इस पेज के मुख्य शब्द

AIDL
Android Interface Definition Language: Binder IPC के माध्यम से एक Android प्रक्रिया को दूसरी प्रक्रिया के खुले तरीकों को कॉल करने की व्यवस्था।
Export की गई सेवा
ऐसी Android सेवा जिससे अन्य ऐप जुड़ सकते हैं। संवेदनशील तरीकों को permission या समान रूप से मजबूत caller जाँच से सुरक्षित करना चाहिए।
कॉलर UID
ऑपरेटिंग सिस्टम द्वारा ऐप प्रक्रिया को दी गई पहचान। सेवा इसे Binder से ले, कॉलर द्वारा बताए पैकेज नाम पर भरोसा न करे।
CWE-862
साझा authorization सीमा की कमी के लिए FlawOpen का संपादकीय वर्गीकरण। GHSL कई कमजोरियों में CWE-862 सूचीबद्ध करता है; advisory CVSS स्कोर प्रकाशित नहीं करती।

फ्रेमवर्क मैपिंग

  • MITRE CWE के लिए FlawOpen की वैचारिक मैपिंग; किसी विक्रेता या CVE रिकॉर्ड ने इस शोध प्रदर्शन को यह कमजोरी ID नहीं दी है। CWE-862

मूल कारण विश्लेषण (Root Cause)

GitHub Security Lab ने OsmAnd 5.3.3 का परीक्षण किया और पाया कि export की गई OsmandAidlServiceV2 पर Android permission नहीं थी तथा OsmandAidlApi.isAppEnabled() अज्ञात ConnectedApp को enabled=true के साथ बनाता था। getApi() इस जाँच के आधार पर AIDL कॉल की अनुमति देता था, इसलिए नया स्थानीय ऐप उपयोगकर्ता की स्वीकृति तक रोके जाने के बजाय अधिकृत के रूप में सहेजा जाता था। GHSL के अनुसार इससे 97 AIDL तरीके खुले, जिनमें स्थान/नेविगेशन डेटा लौटाने वाले तरीके और path traversal समस्या वाली फ़ाइल क्रियाएँ शामिल थीं। हमलावर को उसी डिवाइस पर ऐप पहले से इंस्टॉल करना होगा, लेकिन उस ऐप को location permission या उपयोगकर्ता की अतिरिक्त कार्रवाई की आवश्यकता नहीं है। GHSL द्वारा बताई गई फ़ाइल क्रियाएँ OsmAnd के storage sandbox तक सीमित हैं, पूरे डिवाइस की फ़ाइल प्रणाली तक नहीं। Maintainers ने 28 जून 2026 को सुधार की पुष्टि की, लेकिन advisory पहली सुधरी रिलीज़ नहीं बताती। CVSS स्कोर प्रकाशित नहीं है; FlawOpen स्थान डेटा और integrity को प्रभावित करने वाली क्रियाओं के खुलने के कारण severity को संपादकीय रूप से High मानता है। CWE-862 FlawOpen का मुख्य संपादकीय mapping है, GHSL द्वारा दिया गया एकमात्र वर्गीकरण नहीं।

हमले का चरण-दर-चरण प्रवाह

चरण 1

स्थानीय ऐप export की गई सेवा तक पहुँचता है

कमजोर सेवा Android permission के बिना export की गई थी। उसी डिवाइस का इंस्टॉल किया ऐप OsmAnd की location permission माँगे बिना जुड़ सकता था।

चरण 2

जाँच स्वयं अनुमति बना देती है

अज्ञात पैकेज के लिए isAppEnabled() ने enabled=true वाला ConnectedApp बनाया और सहेजा। जाँच ने वही पहुँच दे दी जिसे उसे सत्यापित करना था।

चरण 3

साझा नियंत्रण कई क्षमताएँ खोलता है

getApi() ने इस परिणाम से AIDL कॉल संभाले। GHSL के अनुसार यह रास्ता getAppInfo() और फ़ाइल कॉपी सहित 97 तरीकों तक पहुँचा।

चरण 4

प्रभाव दस्तावेज़ित शर्तों तक सीमित है

दुर्भावनापूर्ण ऐप पहले से डिवाइस पर इंस्टॉल होना चाहिए। GHSL स्थान/नेविगेशन खुलासे और OsmAnd sandbox में फ़ाइल प्रभाव बताता है; पूरे डिवाइस तक पहुँच या ग्राहक उपकरणों पर वास्तविक हमले की पुष्टि नहीं करता।

सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन

कमजोर कोड GHSL द्वारा जाँचे गए 5.3.3 संस्करण के विश्लेषण से उद्धृत है। नीचे का उदाहरण fail-closed नीति का न्यूनतम खाका है, OsmAnd patch या पूर्ण authorization implementation नहीं: approval flow में UID, installed package की signing identity, user consent और हर method का scope जाँचना होगा। Production service में Binder boundary पर authorization और sensitive methods पर अलग सीमाएँ लागू हों। GHSL सुधार की पुष्टि करता है, लेकिन पूरा diff या पहली सुधरी release नहीं देता; supported version पर update करें और vendor guidance सत्यापित करें। यह शिक्षण कोड है; इसमें exploit या location/file 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());
}

इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट

स्रोत