الملخص

حالة CVE: مطلوبة، في انتظار التعيين. تم نشر هذا الاكتشاف باسم GHSA-3gx3-r874-5pp4. عند تعيين CVE، سيُعاد تسمية هذا المستودع إلى CVE-YYYY-NNNNN-supernote-obsidian-plugin-PoC وسيُستبدل هذا الشعار برابط CVE.

الباحث	Dostxodjayev Abdullox (@squeeze440)
التنبيه	GHSA-3gx3-r874-5pp4
CVSS 3.1	5.6 (متوسط)
الضعف	CWE-22، CWE-73

---

الملخص

يسمح اجتياز المسار (Path Traversal) في ميزة المزامنة التلقائية للجهاز في إضافة Obsidian الخاصة بـ Supernote (غير الرسمية) (philips/supernote-obsidian-plugin) الإصدار v2.9.1 لجهاز "Supernote" خبيث أو مارق (أو مهاجم على المسار/على الشبكة المحلية ينتحل عنوان IP للجهاز المقترن) بأن يجعل عميل Obsidian لدى الضحية يكتب ملفًا جديدًا عشوائيًا في أي مكان يمكن لعملية سطح المكتب الكتابة فيه — بما في ذلك خارج مجلد المزامنة المُهيأ وخارج الخزنة (vault) نفسها — عبر حقل uri مُصمَّم بعناية في استجابة سرد دليل الجهاز.

المنتج

philips/supernote-obsidian-plugin ("Supernote (غير الرسمية)")، إضافة مجتمعية لـ Obsidian.md تزامن ملاحظات جهاز Supernote الإلكتروني الحبري الفعلي إلى خزنة عبر خادم HTTP المحلي "Browse and Access" الخاص بالجهاز (http://<device-ip>:8089، بدون مصادقة، بحكم تصميم ميزة الجهاز).

الإصدار المُختبَر

• الإضافة: v2.9.1، الالتزام 48db5bf4dcfb100632c84699c830c1309da1abb9
• الوحدة الفرعية supernote-typescript: الالتزام 195415b3a1f74147... (غير متورطة بذاتها — الخلل بالكامل في كود تخطيط المزامنة الخاص بالإضافة)
• التطبيق المضيف: Obsidian desktop 1.13.4 (ثنائي حقيقي، مُختبَر ديناميكيًا)

تقدير CVSS v3.1

5.6 متوسط — CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:C/C:N/I:H/A:N

• AV:A — خادم HTTP الخاص بالجهاز نصي صريح، غير مُصادَق عليه، ومُهيأ بعنوان IPv4 مجرد (IP_VALIDATION_PATTERN، src/settings.ts:6)؛ الوصول إليه بصفته "الجهاز" يتطلب موقعًا شبكيًا مجاورًا للشبكة المحلية (نقطة وصول مارقة، انتحال ARP، أو ادعاء عنوان IP)، وليس وصولًا عن بُعد عشوائيًا.
• AC:H — يعتمد الاستغلال على أن المهاجم يشغل بالفعل ذلك الموقع الشبكي عندما تتحدث إضافة الضحية إلى directConnectIP:8089؛ فهو ليس محفزًا عن بُعد بضربة واحدة.
• UI:R — يتطلب أن يشغّل الضحية "Sync supernote notes now" (أو أن يكون مفتاح المزامنة التلقائية مُفعَّلًا بالفعل) بينما هو موجَّه نحو نقطة النهاية التي يتحكم بها المهاجم.
• S:C — المكوّن المعرَّض للخطر هو إضافة Obsidian محدودة النطاق بالخزنة؛ بينما تهبط الكتابة خارج الخزنة تمامًا، على نظام ملفات المضيف الأساسي، وهو نطاق أمني مختلف.
• C:N — هذه قدرة كتابة فقط؛ لا يُقرأ شيء مرة أخرى إلى المهاجم.
• I:H — تهبط بايتات يتحكم بها المهاجم في مسار يختاره المهاجم باسم ملف يختاره المهاجم. تحذير محدود: writeBinaryAt() (src/syncEngine.ts:40-47) يأخذ فرع الإنشاء فقط للمسارات غير المتتبعة بالفعل في بيان المزامنة الخاص بالإضافة، كما أن Vault.createBinary() في Obsidian نفسه يرفض الكتابة فوق ملف موجود فعليًا في المسار المُحلَّل بصمت (مؤكَّد تجريبيًا — انظر PoC) — لذا فهذا "زرع ملف جديد في أي مكان"، وليس "الكتابة فوق أي ملف موجود."
• A:N — لم يُثبَت أي تأثير على التوافر.

التفاصيل

يسرد runDeviceSync() (src/syncEngine.ts:100-196) ملفات الجهاز المقترن عبر scanDeviceSupernoteTree() (src/FileListModal.ts:53-68)، الذي يتكرر عبر سرد دليل HTTP الخاص بالجهاز ويحتفظ بأي مدخل يتطابق name الخاص به مع /\.(note|spd)$/i (src/FileListModal.ts:46,63). حقل uri لكل مدخل — وهو سلسلة منفصلة ومُتحكَّم بها بشكل مستقل في نفس كائن JSON الذي يعيده الجهاز — لا يُتحقق منه أبدًا مقابل name أو مقابل أي شيء آخر.

ثم يُغذَّى uri الخام مباشرة إلى deviceUriToVaultPath() (src/deviceSync.ts:153-161):

const INVALID_FILENAME_CHARS = /[\\:*?"<>|]/g;   // deviceSync.ts:144

export function deviceUriToVaultPath(syncFolder: string, deviceUri: string): string {
    const segments = deviceUri
        .split('/')
        .filter((s) => s.length > 0)
        .map((s) => s.replace(INVALID_FILENAME_CHARS, '_'));

    const cleanRoot = syncFolder.replace(/^\/+|\/+$/g, '');
    return cleanRoot ? `${cleanRoot}/${segments.join('/')}` : segments.join('/');
}

يزيل INVALID_FILENAME_CHARS الرموز \ : * ? " < > | لكنه لا يزيل أو يرفض أبدًا مقاطع المسار ... ينجو uri الجهاز بالقيمة /../../PWNED.txt دون تغيير ويُدمج مع مجلد المزامنة المُهيأ (الافتراضي "Supernote sync") لإنتاج vaultPath = "Supernote sync/../../PWNED.txt".

يحسب syncEngine.ts:128 قيمة vaultPath هذه من uri الخام في السرد، ثم يمررها ensureFolder()/writeBinaryAt() (syncEngine.ts:146-148، 21-47) مباشرة إلى app.vault.getAbstractFileByPath() / createBinary() / modifyBinary() دون أي فحص للاجتياز. ثم يقوم تحليل المسار الخاص بـ Obsidian بتطبيع مقاطع .. مقابل دليل الخزنة الحقيقي على القرص، فتهبط الكتابة فوق مجلد المزامنة — ومع وجود مقاطع ../ كافية، فوق جذر الخزنة تمامًا، على نظام ملفات المضيف، ضمن نطاق أذونات مستخدم نظام التشغيل نفسه.

فحص الأشقاء: كل نقطة كتابة أخرى في الخزنة في قاعدة الشيفرة هذه (src/main.ts — التقاط انعكاس الشاشة، استيراد PDF/markdown، "attach to note"، DownloadListModal في src/FileListModal.ts:245-246) تبني مسار وجهتها عبر app.fileManager.getAvailablePathForAttachment(file.name) الخاص بـ Obsidian، الذي لا يستهلك سوى حقل name الخاص بالجهاز ولا يمكن استغلاله بهذه الطريقة. deviceUriToVaultPath() في ميزة المزامنة التلقائية الأحدث هي نقطة الكتابة الوحيدة التي تبني بدلًا من ذلك مسارًا يدويًا من حقل uri الخاص بالجهاز، وهي التي تخطت تعقيم .. — حالة واضحة من "تم الفحص على كل شقيق إلا هذا."

تنص واجهة إعدادات الإضافة نفسها: "The sync command never writes anywhere outside this folder" (src/settings.ts، وصف Sync folder) — وهذا PoC يكذّب هذا الضمان مباشرة.

إثبات المفهوم

مؤكَّد ديناميكيًا من البداية إلى النهاية مقابل ثنائي Obsidian 1.13.4 سطح مكتب حقيقي غير معدَّل (Xvfb + fluxbox + xdotool + scrot)، يشغّل main.js المُجمَّع الفعلي للإضافة — دون أي محاكاة لكود الإضافة.

1. بُنيت الإضافة من المصدر (./scripts/build) وحُمِّلت في خزنة اختبار جديدة (Supernote (Unofficial) v2.9.1، مُفعَّلة عبر "Trust author and enable plugins").
2. ضُبط إعداد الإضافة Supernote IP address على 127.0.0.1، وتُرك Sync folder على قيمته الافتراضية Supernote sync.
3. أُقيم خادم Node وهمي بملف واحد لخادم "Browse and Access" الخاص بالجهاز على 127.0.0.1:8089، يحاكي جهازًا خبيثًا/مارقًا. يعيد سرد دليله:

   {"name":"Quick notes.note","size":61,"date":"2026-07-31 00:00:00",
    "uri":"/../../PWNED_BY_DEVICE_SYNC.txt","extension":"note","isDirectory":false}
   

   (name يجتاز مرشح الامتداد .note؛ uri يحمل الاجتياز.) يُجاب على أي GET بالرمز 200 مع بايتات الملف — عملاء HTTP الحقيقيون يطبّعون .. من مسار الطلب الصادر قبل أن يصل إلى الشبكة (RFC 3986)، وهذا غير ذي صلة هنا لأن الكود المعرَّض يحسب مسار الكتابة من سلسلة JSON الأصلية، وليس من عنوان URL للطلب المُطبَّع.
4. شُغِّل إجراء لوحة الأوامر "Supernote (Unofficial): Sync supernote notes now".
5. النتيجة: أُنشئ ملف جديد، PWNED_BY_DEVICE_SYNC.txt، يحتوي على بايتات المهاجم، في دليل واحد فوق جذر الخزنة (شقيق لـ testvault/، خارج الخزنة تمامًا). سجّل data.json الخاص بالإضافة المسار المحسوب حرفيًا: "vaultPath": "Supernote sync/../../PWNED_BY_DEVICE_SYNC.txt".

الأدلة (لقطات حقيقية، ~/engagements/supernote-obsidian-plugin/evidence/):

• 01-vault-escape-file-write.png — طرفية حقيقية: ls -la testvault/ PWNED_BY_DEVICE_SYNC.txt تُظهر الملف كشقيق لدليل الخزنة، بالإضافة إلى محتواه الذي يتحكم به المهاجم عبر cat.
• 02-plugin-data-json-vaultpath.png — ملف حالة المزامنة المحفوظ الخاص بالإضافة يسجّل "vaultPath": "Supernote sync/../../PWNED_BY_DEVICE_SYNC.txt".
• 03-plugin-settings-security-claim.png — واجهة إعدادات الإضافة تدّعي أن أمر المزامنة "never writes anywhere outside this folder."

التأثير