José Valim

يمكن لمهاجم عن بُعد غير مصرح له أن يتسبب في استنفاد الذاكرة في كل من التطبيق وخادم قاعدة البيانات. يحدث هذا عندما يقوم التطبيق بإدراج بيانات يزودها المستخدم في `json extract path/2` أو `field[^key]` أو `splice/1`. يقوم Ecto بتخزين الاستعلامات المُعدة في ذاكرة مؤقتة (cache) ضمن جدول ETS بدون حدود للحجم أو سياسات للحذف. نظرًا لأن عناصر مسار JSON المُدرجة وتوسعات `splice/1` تصبح جزءًا من تعبير الاستعلام بدلاً من أن تكون مجرد معاملات، فإن كل مفتاح فريد أو طول قائمة مختلف ينشئ إدخالاً جديدًا في الذاكرة المؤقتة. عند استخدام ecto sql، يتم إنشاء بيان مُعد جديد في اتصال قاعدة البيانات لكل إدخال. ولا يتم تحرير هذه الذاكرة إلا بعد إعادة تشغيل العمليات.

تسمح ثغرة الملفات المؤقتة غير الآمنة في Mix `deps.partition` لمستخدم محلي بتنفيذ رمز برمجي عشوائي بصلاحيات مستخدم آخر. أثناء عملية تجميع التبعيات المقسمة، يتم تمرير تكوين المشروع إلى أجهزة VM الخاصة بالتقسيم عبر ملف في دليل ثابت الاسم ضمن الدليل المؤقت المشترك للنظام. تستخدم الدالة `Mix.Tasks.Deps.Partition.server/4` في `lib/mix/lib/mix/tasks/deps.partition.ex` الدالة `File.mkdir p/1` لإنشاء هذا الدليل، والتي لا تتحقق من مالك الدليل إذا كان موجودًا بالفعل. يمكن للمهاجم المحلي إنشاء الدليل مسبقًا واستبدال ملف التكوين قبل أن تقوم الدالة `client/0` بقراءته. يقوم العميل بعد ذلك بفك تشفير الملف الخبيث باستخدام `:erlang.binary to term/1` وتنفيذ أوامر shell محقونة عبر خيار `compile:` الخاص بالتبعيات. بالإضافة إلى ذلك، قد تؤدي طبيعة ملف التقسيم القابل للقراءة من قبل الجميع إلى كشف تكوينات المشروع لمستخدمين محليين آخرين. تتطلب هذه المشكلة تفعيل التجميع المقسم عبر المتغير `MIX OS DEPS COMPILE PARTITION COUNT` ووجود دليل مؤقت مشترك للنظام.

يسمح وجود خطأ في التحقق من كمية المدخلات المحددة في وحدة `URI` بمكتبة Elixir القياسية للمهاجم بالتسبب في حالة رفض الخدمة من خلال استنفاد وحدة المعالجة المركزية (CPU) عن طريق تقديم عنوان URL يحتوي على مكون منفذ (port) طويل بشكل مفرط. تقوم الدالة `URI.parse/1` باستخدام `String.to integer/1` داخل `split authority/1` لتحويل المنفذ دون تحديد طوله، مما يسمح بإنشاء عدد صحيح كبير (bignum) يصل إلى 1,262,592 رقمًا عشريًا. وعندما يتم تحويل عنوان URL هذا مرة أخرى إلى نص عبر `URI.to string/1` أو `inspect/1` أو التسجيل (logging) أو تنسيق الأخطاء، يتم استخدام `:erlang.integer to binary/1`. في إصدارات Erlang/OTP 27 و 28 و 29.0، تكون عملية التحويل هذه تربيعية، مما يعني أن وقت وحدة المعالجة المركزية المطلوب يزداد بشكل كبير مع زيادة عدد الأرقام. على سبيل المثال، قد يستغرق المنفذ الذي يحتوي على 400,000 رقم حوالي 2.6 ثانية للمعالجة، بينما قد يستغرق المنفذ بحجم 1 ميجابايت حوالي 18 ثانية. يمكن أن يؤدي ذلك إلى استنفاد وحدة المعالجة المركزية في الخوادم التي تقوم بتحليل وتسجيل أو إعادة إرسال عناوين URL المقدمة من المستخدم في حقول النماذج أو أجسام JSON.

يسمح التحقق غير السليم من الكمية المحددة في الإدخال ضمن وحدة `JSON` في مكتبة Elixir القياسية لمهاجم غير مصرح له بالتسبب في حالة رفض الخدمة من خلال استنفاد وحدة المعالجة المركزية والذاكرة عن طريق تقديم مستند JSON مصمم خصيصًا. تقوم الدالتان `JSON.decode/1` و `JSON.decode!/1` بتحويل الثوابت الصحيحة باستخدام `erlang:binary to integer/1` دون تقييد طولها. ونتيجة لذلك، فإن الثابت الصحيح الذي يحتوي على مليون رقم يستهلك من 100 إلى 300 ضعف وحدة المعالجة المركزية مقارنة بسلسلة نصية من نفس الطول، وتؤدي الثوابت التي تتجاوز حوالي 1.29 مليون رقم إلى إثارة `SystemLimitError`. وتعتبر التطبيقات التي يتم إنشاؤها بواسطة `phx.new` عرضة لهذا الخطر بشكل خاص لأنها تقوم بفك تشفير أجسام الطلبات باستخدام `Plug.Parsers` قبل عملية التوجيه والمصادقة.

يمكن لمهاجم عن بُعد غير مصرح له الكشف عن قاعدة المفتاح السري أو أسرار حساسة أخرى من خلال سجلات التطبيق عن طريق تقديم وسائط ذات أنواع خاطئة. يحدث هذا لأن الوظائف العامة في `Plug.Crypto` تستخدم حراس رأس الوظيفة (function-head guards) للتحقق من صحة الوسائط. عندما يفشل الحارس، تطلق آلة Erlang VM خطأ `FunctionClauseError` يتضمن قيم الوسائط الفعلية في إطار المكدس العلوي. وبما أن كتل `rescue` الخاصة بالمكتبة ووظيفة `Plug.Crypto.prune args from stacktrace/1` تتعامل فقط مع الاستثناءات التي يتم إثارتها داخل جسم الوظيفة، فإنها لا تلتقط فشل الحارس. وبناءً على ذلك، يقوم Plug.Cowboy و Bandit بكتابة هذا الإطار في سجل الأخطاء وإرفاقه كبيانات وصفية لـ `crash reason` والتي قد يتم توجيهها إلى أدوات تتبع الأخطاء. هناك نقطتا دخول رئيسيتان متأثرتان: - تقوم `Plug.Crypto.verify/4` بالكشف عن قاعدة المفتاح السري عندما لا يكون الرمز (token) ثنائيًا ولا فارغًا (nil). - تقوم `Plug.Crypto.secure compare/2` بالكشف عن السر الموجود في جانب الخادم عندما لا يكون أحد المعاملات ثنائيًا، كما يحدث عندما يؤدي رأس طلب مفقود إلى قيمة فارغة (nil). يتطلب الوصول إلى المعلومات المسربة وصولاً منفصلاً إلى سجلات التطبيق أو أداة تتبع الأخطاء.

An issue exists where improper neutralization of input during web page generation allows mutation Cross-site Scripting (XSS). This occurs during a parse and serialize round-trip of attacker-supplied HTML. The functions `LazyHTML.to html/2` and `LazyHTML.Tree.to html/2` determine whether to escape an element's text based solely on its tag name. Consequently, a `style` or `script` element within SVG or MathML foreign content is parsed with decoded character references but serialized as an HTML raw-text element, causing the text to be emitted unescaped. This allows encoded markup to close the element upon re-parsing and become active markup. Applications that parse untrusted HTML, filter the document or tree, and then serialize it for display are affected because the payload remains a plain text node that bypasses element or attribute filters.

Improper validation of input quantities in the inets httpc module allows a malicious or compromised HTTP server to degrade availability. The issue occurs when the server returns a numeric header containing an excessively long sequence of digits. Specifically, `httpc handler.erl` uses the `list to integer/1` function to convert the `Content-Length` header before comparing it against `max body size`, meaning the size check does not prevent the conversion process. Similar unbounded conversions exist in the `format response/1` function for `Content-Length` and the `get ms from retry after/1` function for the `Retry-After` header. Because the conversion function supports arbitrary-precision arithmetic, processing up to 1.26 million digits can consume significant CPU resources, causing delays of hundreds of milliseconds per response for the requesting process.

Improper validation of input quantity in the stdlib allows a remote attacker to degrade availability by providing a URI with a port component consisting of an excessively long sequence of digits. The function `uri string:get port/1` passes the port substring to `binary to integer/1` without a length bound. Consequently, a syntactically valid port of up to approximately 1.26 million digits can be converted successfully, consuming hundreds of milliseconds of arbitrary-precision arithmetic in the calling process. This conversion is triggered via every authority-parsing path in `uri string:parse/1`, including host, registered-name, and IPv4 and IPv6 forms. Any application using `uri string:parse/1` to parse attacker-supplied URIs is exposed.

Improper validation of the specified quantity in input within the snmp module allows a remote attacker to degrade availability. An attacker can send an SNMP message containing a BER INTEGER with an arbitrarily large length field. The function `snmp pdus:dec integer notag/1` defaults its size limit to infinity, and `do dec integer notag/2` accumulates the value across every declared byte using a recursive shift and bitwise or. This causes the workload to grow superlinearly as each operation acts on a progressively larger bignum. While a size-limited variant `dec integer notag/2` exists, it is only used by `dec snmp version/1`. Other fields, including the request identifier, error status, index, generic and specific trap fields, engine boots, time, and varbind values decoded by `dec value/1`, use the unbounded form. The decoding occurs before the PDU is processed, meaning no valid request is required to trigger the issue.

Improper validation of input quantity in the eldap module allows a malicious or compromised LDAP server to degrade availability. The issue occurs when the server returns a referral URL containing a port component consisting of an excessively long sequence of digits. The function `parse port/2` passes the port substring to `list to integer/1` without a length bound. Because the conversion function accepts integers of any size, a syntactically valid port of up to approximately 1.26 million digits can be processed, consuming significant CPU resources through arbitrary-precision arithmetic. This flaw is triggered when an application passes a server-supplied referral to the `parse ldap url/1` function.

An uncontrolled recursion issue in the standard library allows an attacker who controls a list passed to the `inspect/1`, `List.to string/1`, or `List.to charlist/1` functions to exhaust the memory of a BEAM node. The problem occurs when a list's printable prefix exceeds the `:printable limit` (default 4096 elements) but contains a subsequent element that is not a valid code point, such as an atom or an out-of-range integer. This causes the list to be misclassified as a charlist, leading to an `ArgumentError`. In `List.to string/1` and `List.to charlist/1`, the rescue clause attempts to build an error message by calling `inspect(list)`, which re-triggers the same error path. Because this recursion is not in tail position, the process stack grows until the node runs out of memory or the process is killed by `max heap size`.

توجد مشكلة إعادة توجيه مفتوحة (Open Redirect) حيث يمكن للمهاجم إعادة توجيه متصفح الضحية إلى مصدر عشوائي. يحدث هذا لأن الدالة `redirect/2` تستخدم `validate local url!/2` للتأكد من أن الهدف هو مسار محلي، لكنها تفشل في رفض أحرف ASCII tab أو LF أو CR. ونظرًا لأن المتصفحات تقوم بإزالة هذه الأحرف قبل تحليل عنوان URL، فإن قيمة مثل `/<TAB>/example.com` تتجاوز عملية التحقق من الصحة ويتم تفسيرها على أنها عنوان URL نسبي للمخطط. تتأثر الدالة `push patch/2` أيضًا في الإصدارات السابقة للإصدار 0.7.0. تظهر المشكلة عندما يمرر التطبيق قيمة متأثرة من مصدر خارجي كمعلمة `:to`، مثل معلمة `return to` أثناء تسجيل الدخول أو هدف التنقل من حمولة `handle event/3`.

توجد ثغرة تتعلق بحقن SQL في مكتبة postgrex التي يستخدمها elixir-ecto. تحدث هذه الثغرة عند استخدام الخيار `:comment` داخل الدالة `Postgrex.stream/4` أو الدالة `Ecto.Repo.stream/2`. يمكن للمهاجم القادر على التأثير على قيمة المتغير `:comment` استخدام التسلسل `*/` لإغلاق محدد التعليق وإلحاق جمل SQL غير مصرح بها يتم تنفيذها بامتيازات دور الاتصال. يحدث هذا لأن البرنامج يضم التعليق إلى نص العبارة المرسلة في رسالة Parse دون إخفاء أو رفض تسلسل «*/»، كما أن الدالة «stream/4» تفشل في استدعاء دالة التحقق «comment not present!/1» المستخدمة في أماكن أخرى. يقتصر الحقن على العبارة المُرسلة عبر الدفق، حيث إن رسالة Parse لا تقبل سوى أمر واحد.

توجد مشكلة تتعلق بحقن أوامر نظام التشغيل (OS Command Injection) حيث يتم إنشاء أوامر إعداد النشر دون إجراء الهروب الصحيح من قذيفة (shell escaping) لقيم متغيرات البيئة. تقوم الدالتان `docker instructions/2` و`fly instructions/4` في الملف `lib/livebook web/live/hub/teams/deployment group agent component.ex` باستيفاء هذه القيم، والتي تتم معالجتها من خلال الدالة `online docker info/3`. ونظرًا لأن القيم توضع داخل كلمات شل محاطة بعلامتي اقتباس مزدوجتين، يمكن للمهاجم الذي يتمتع بامتيازات تعيين متغيرات بيئة مجموعة النشر استخدام استبدال الأوامر (مثل `$(...)` أو علامات الاقتباس المائلة) أو علامات الاقتباس المزدوجة لحقن أوامر تعسفية. ثم يتم تنفيذ هذه الأوامر على الجهاز المحلي لأي مستخدم يقوم بنسخ وتشغيل تعليمات الإعداد التي تم إنشاؤها من واجهة الويب. لا تتأثر تعليمات Kubernetes لأنها تستخدم التهرب في ملفات YAML.

توجد مشكلة تزوير الطلبات عبر المواقع (CSRF) عندما يتم تكوين Livebook لاستخدام Livebook Teams للتعريف. تقوم الدالة `handle request/4` الموجودة في `lib/livebook/zta/livebook teams.ex` بمعالجة عمليات الاستدعاء المرتدة من نوع OAuth التي تحتوي على علامة `teams identity` ومعلمة `code`. ونظرًا لأن الدالة `create auth request/1` الموجودة في `lib/livebook/teams/requests.ex` لا تولد حالة (state) أو رقم عشوائي (nonce)، يفشل النظام في التحقق مما إذا كانت عملية الاستدعاء المرتدة تتوافق مع الجلسة التي بدأت عملية تسجيل الدخول. يمكن للمهاجم داخل نفس مؤسسة Livebook Teams بدء عملية تسجيل الدخول، والتقاط رمز التفويض، وخداع الضحية لفتح رابط URL يحتوي على هذا الرمز. يؤدي هذا إلى ربط جلسة عمل الضحية بهوية المهاجم. ونتيجة لذلك، تُنسب أي أعمال أو أسرار أو بيانات أنتجها الضحية إلى المهاجم ويصبح بإمكانه الوصول إليها، بينما يعتقد الضحية أنه يستخدم حسابه الخاص.

تسمح مشكلة مفتوحة لم يتم حلها في Livebook لعميل شبكة غير مصدق عليه بالحصول على وصول كامل إلى خادم يفرض المصادقة عبر Livebook Teams. يحدث هذا عندما يقوم وكيل Livebook أو خادم التطبيق بتخزين معرف مجموعة النشر مؤقتًا في ذاكرة التخزين المؤقتة، ويصبح هذا المعرف غير قابل للحل، مثلما يحدث عند حذف المجموعة أثناء انقطاع اتصال الوكيل. تفشل الدالة `handle call/3` الموجودة في `lib/livebook/hubs/team client.ex` في التمييز بين المجموعة غير القابلة للحل والمجموعة التي تم تعطيل فرض الهوية فيها، مما يؤدي إلى قيام النظام بالإبلاغ عن أن فرض الهوية معطل. ونتيجة لذلك، تُرجع الدالة `authenticate/3` الموجودة في `lib/livebook/zta/livebook teams.ex` بيانات تعريف هوية فارغة، والتي تقوم الدالة `build current user/3` في `LivebookWeb.UserPlug` بدمجها في مستخدم جديد يتمتع بحق الوصول الكامل الافتراضي. ثم يتم منح هذا المستخدم حق الوصول بواسطة الدالة `authorized?/1` في `LivebookWeb.AuthPlug`. يمكن للمهاجم استغلال هذه الثغرة لقراءة دفاتر الملاحظات والأسرار، وتنفيذ التعليمات البرمجية على بيئة تشغيل الخادم، وتعطيل العمليات.

يسمح خطأ في التحقق من صحة المصدر لـ JavaScript غير الموثوق به الصادر من دفتر الملاحظات بتشغيل اختصارات لوحة المفاتيح على مستوى الجلسة بأكملها. تعرض ميزة JS-view JavaScript في إطار iframe معزول وعبر الأصول. ومع ذلك، فإن غلاف iframe الموجود في `iframe/priv/static/iframe/v5.html` يقوم بإعادة توجيه أحداث `keydown` إلى الصفحة الأم دون التحقق من `Event.isTrusted`. ونتيجة لذلك، تُعامل الأحداث التي يتم توليدها عبر `window.dispatchEvent` على أنها ضغطات مفاتيح حقيقية. يقوم المرسل في `assets/js/hooks/js view.js` بإعادة إرسال هذه الأحداث، والتي تتم معالجتها بعد ذلك بواسطة معالج الاختصارات العام في `assets/js/hooks/session.js` خلال مرحلة الالتقاط. وهذا يسمح للبرامج النصية الموجودة في بيئة الحماية (sandbox) بتنفيذ الاختصارات في `LivebookWeb.SessionLive`، مثل فرض تقييم جميع الخلايا في دفتر الملاحظات أو إعادة تشغيل بيئة التشغيل، مما يؤدي إلى إتلاف الحالة الموجودة في الذاكرة. وهناك اختصار ثالث يمكنه حذف الخلية التي يتم التركيز عليها. التأثير الأكثر خطورة هو التقييم الكامل القسري، الذي ينفذ كود Elixir الخاص بدفتر الملاحظات دون موافقة المستخدم. ويمكن أن يحدث هذا عندما يفتح المستخدم دفتر ملاحظات من جهة خارجية أو من وثائق منشورة، وينعكس التأثير على جميع المتعاونين المتصلين.

تسمح مشكلة ”اجتياز المسار النسبي“ للمهاجم بكتابة ملف بمحتوى خاضع لسيطرته في مسار عشوائي على النظام. يحدث هذا لأن مسار الاستيراد في `Livebook.LiveMarkdown.Import.file entry metadata to attrs/1` يأخذ الاسم من مصدر دفتر الملاحظات حرفياً دون التحقق من صحته. بالنسبة لمدخلات الملفات من نوع URL، تقوم الدالة `Livebook.Session.file entry cache file/2` بحل الاسم ضمن الدليل المؤقت للجلسة دون التحقق مما إذا كان النتيجة لا تزال ضمن ذلك الدليل. بالإضافة إلى ذلك، تقوم الدالة `Livebook.FileSystem.Utils.resolve unix like path/2` بتجميع أجزاء الدليل الأصلي ولكنها تقتصر على جذر نظام الملفات فقط. ونتيجة لذلك، عند طلب المحتوى وفي حالة عدم وجود ذاكرة تخزين مؤقتة، يقوم النظام بكتابة نص الاستجابة إلى المسار الذي تم تحديده، مع إنشاء الدلائل الأصلية حسب الحاجة. وهذا يسمح للمهاجم بالتحكم في كل من وجهة الملف المكتوب ومحتواه في أي مكان تتمتع فيه العملية بأذونات الكتابة. ويوجد نقص مماثل في فحص الاحتواء في `Livebook.Session.to attachment file entry/2`. يُحدث الضحية هذه الثغرة عن طريق فتح دفتر ملاحظات مزود من قبل المهاجم، مما يؤدي إلى استرداد الإدخال ضمن جلسته المصادق عليها.

توجد مشكلة في البرمجة النصية عبر المواقع في phoenix live view بسبب التحقق غير الصحيح من صحة مخطط عناوين URL. تستخدم الدالتان `valid destination!/2` و`valid live navigation destination!/2` أداة مساعدة داخلية `uri scheme/1` تفشل في اكتشاف المخططات إذا كانت المدخلات تبدأ بمسافة أو بحرف تحكم ASCII. ونظرًا لأن المتصفحات القياسية تزيل هذه الأحرف الافتتاحية قبل التحليل، يمكن للمهاجم تقديم حمولة مثل ” javascript:alert(1)“ التي تتجاوز عملية التحقق من الصحة ويتم التعامل معها على أنها مسار نسبي آمن. وعند عرضها عبر `<.link href={...}>`، يقوم المتصفح بتنفيذ البرنامج النصي في جلسة عمل الضحية. ويؤثر هذا على التطبيقات التي تعرض عناوين URL التي يقدمها المستخدم، مثل أهداف إعادة التوجيه أو روابط الملفات الشخصية.

تسمح ثغرة في الوحدة النمطية `Postgrex.Notifications` للمهاجم بحقن تعليمات SQL في استعلام إعادة الاتصال (reconnect replay) من خلال التلاعب باسم قناة LISTEN. على الرغم من أن الدالة `quote channel/1` تقوم بتنقية علامات الاقتباس المزدوجة، إلا أنها تفشل في إخفاء فاصل علامات الاقتباس بالدولار `$$` المستخدم في كتلة الكود المجهولة داخل الدالة `handle connect/1`. ونظرًا لأن الدالة `listen/3` ترفض فقط البايتات الفارغة والأسماء التي تتجاوز 63 بايت، فإن اسم القناة الذي يحتوي على `$$` يمكن أن ينهي السلسلة المقتبسة بعلامات الاقتباس بالدولار قبل الأوان. يؤدي هذا إلى قيام PostgreSQL بتحليل المدخلات المتبقية كجمل من المستوى الأعلى، مما يؤدي إلى رفض استعلام إعادة التشغيل خلال كل محاولة لإعادة الاتصال. ونتيجة لذلك، يفشل اتصال الإشعارات في إعادة إنشاء الاشتراكات، مما يؤدي إلى رفض الخدمة حيث يتم إسقاط الإشعارات بصمت لجميع القنوات التي تشترك في ذلك الاتصال. يحدث هذا عندما يتم تمرير مدخلات غير موثوق بها كاسم قناة إلى `Postgrex.Notifications.listen/3`.