CVE-2026-75855

विवरण

server/src/main/java/com/arcadedb/server/http/handler/PostServerCommandHandler.java:

एकमात्र सत्यापन एक गैर-खाली जांच है। databaseName बिना किसी संशोधन के ArcadeDBServer.createDatabase() में प्रवाहित होता है (server/src/main/java/com/arcadedb/server/ArcadeDBServer.java:572):

यह कच्चा स्ट्रिंग संयोजन है, Path.resolve() + कंटेनमेंट जांच नहीं। DatabaseFactory (engine/src/main/java/com/arcadedb/database/DatabaseFactory.java) create()/open() द्वारा डिस्क पर फ़ाइलें लिखने से पहले कभी .normalize() नहीं कहता या सत्यापित नहीं करता कि हल किया गया पथ इच्छित आधार निर्देशिका के अंतर्गत रहता है।

dropDatabase() में समान सत्यापन की कमी है, और चूंकि सर्वर डेटाबेस को कॉलर द्वारा आपूर्ति किए गए शाब्दिक (ट्रैवर्सल-युक्त) नाम के तहत ट्रैक करता है, एक बाद का drop database जो भी निर्देशिका create database ने लिखी थी उसे पुनरावर्ती रूप से हटा देता है।

checkRootUser(user) दोनों कमांड से पहले लागू किया जाता है, इसलिए इसके लिए सर्वर के रूट खाते की आवश्यकता होती है — लेकिन यहाँ रूट ArcadeDB का अपना एप्लिकेशन-स्तरीय सुपरयूज़र है, जरूरी नहीं कि होस्ट तक OS/शेल पहुंच के समान विश्वास स्तर हो। databaseDirectory की कंटेनमेंट को तोड़ने से वह एप्लिकेशन-स्तरीय खाता किसी भी स्थान पर मनमानी फ़ाइलें लिख और हटा सकता है जहाँ JVM प्रक्रिया के पास OS अनुमतियाँ हैं।

PoC

पर्यावरण: ArcadeData/arcadedb @ कमिट 545e703, स्रोत से निर्मित (./mvnw -pl engine,server -am install -DskipTests), arcadedb.server.rootPassword सेट और arcadedb.server.databaseDirectory=/databases के साथ स्टैंडअलोन चलाया गया।

1. पुष्टि करें कि इच्छित डेटाबेस निर्देशिका खाली है।

2. ट्रैवर्सल पेलोड के साथ create database कमांड भेजें:

→ {"result":"ok"} HTTP 200

3. सत्यापित करें कि डेटाबेस कॉन्फ़िगर की गई निर्देशिका के बाहर लिखा गया था:

→ configuration.json, schema.json, dictionary..dict, txlog_.wal — एक पूर्ण, वास्तविक ArcadeDB डेटाबेस। इच्छित databases/ निर्देशिका पूरे समय खाली रहती है।

4. list databases शाब्दिक ट्रैवर्सल स्ट्रिंग को पंजीकृत नाम के रूप में लौटाता है, शून्य सामान्यीकरण की पुष्टि करता है:

5. /etc/arcadedb-poc2 में गहरे ट्रैवर्सल के साथ दोहराया गया — समान रूप से सफल, यह प्रदर्शित करता है कि लेखन /tmp या किसी विशेष फ़ाइलसिस्टम क्षेत्र तक सीमित नहीं है, केवल उसी तक सीमित है जिस पर प्रक्रिया लिख सकती है। न्यूनतम एकल-स्तरीय ../ ट्रैवर्सल के साथ भी पुनरुत्पादित, वास्तविक पथ पलायन की पुष्टि करता है न कि संयोगवश परिणाम की।

6. समान ट्रैवर्सल स्ट्रिंग के साथ drop database निर्देशिका को पुनरावर्ती रूप से हटा देता है:

→ {"result":"ok"}; निर्देशिका बाद में गायब पुष्टि की गई।

7. व्यवहार निर्धारक और स्थिति-निर्भर नहीं है यह पुष्टि करने के लिए पूरी तरह से नए सर्वर पुनरारंभ से अंत-से-अंत तक पुनः परीक्षण किया गया — हर बार समान परिणाम।

प्रभाव

• कौन: ArcadeDB के रूट सर्वर क्रेडेंशियल का कोई भी धारक — एक एप्लिकेशन-स्तरीय खाता जो, उत्पाद के अपने डिज़ाइन के अनुसार (अलग रूट पासवर्ड, OS पहुंच से भिन्न), OS फ़ाइलसिस्टम नियंत्रण का संकेत देने के लिए नहीं है।
• क्या: किसी भी पूर्ण पथ पर मनमानी फ़ाइल/निर्देशिका निर्माण (create database के माध्यम से) और मनमाना पुनरावर्ती विलोपन (drop database के माध्यम से) जिस पर सर्वर प्रक्रिया लिख सकती है, पूरी तरह से कॉन्फ़िगर किए गए databaseDirectory सैंडबॉक्स के बाहर।
• परिणाम: तैनाती के आधार पर, इसे कोड निष्पादन तक बढ़ाया जा सकता है (जैसे, किसी निर्देशिका में लिखना जिसे बाद में किसी अन्य प्रक्रिया द्वारा लोड/निष्पादित किया जाता है, वेब-सेवित पथ के अंतर्गत फ़ाइलें रोपना, सेवा कॉन्फ़िगरेशन को दूषित करना) या सीधा सेवा अस्वीकार / डेटा विनाश (प्रक्रिया द्वारा पहुंच योग्य मनमानी निर्देशिकाओं को हटाना, जैसे, अन्य अनुप्रयोगों का डेटा)।

सुझाया गया समाधान

पथ विभाजक (/, \) या .. खंड वाले डेटाबेस नामों को सीधे अस्वीकार करें (इस वर्ग के पहचानकर्ताओं के लिए एक सरल अनुमति-सूची regex, जैसे ^[A-Za-z0-9_-]+$, मानक है), और किसी भी फ़ाइल ऑपरेशन से पहले Path.resolve(name).normalize() के साथ अंतिम पथ को रक्षात्मक रूप से हल करें और सत्यापित करें कि यह अभी भी कॉन्फ़िगर किए गए आधार निर्देशिका से शुरू होता है, createDatabase और dropDatabase दोनों में।

क्रेडिट: Pervin Zahidli (@ech0void )