Jonatan Männchen

Improper neutralization of escape, meta, or control sequences allows a malicious package publisher or a hostile repository server to inject terminal control sequences into the output of Mix tasks. The software prints strings from the package repository and documentation search service directly to the terminal via `Hex.Shell.info/1` and `Hex.Shell.error/1` without neutralizing control characters. This affects package metadata, configuration snippets in `mix hex.info`, search results in `mix hex.package search` and `mix hex.search`, owner and organization listings, publish and sponsor URLs, the authenticated username in `mix hex.user`, policy identities in `mix hex.policy`, and API error bodies rendered by `Hex.Utils.print error result/1`. An attacker can embed ANSI escape sequences—such as cursor movement, line erase, carriage returns, and OSC 52 clipboard writes—or Unicode bidirectional overrides to forge displayed URLs, package descriptions, and suggested commands, conceal real output, or write to the clipboard. This can be triggered by any developer running a documentation search that surfaces a malicious package.

AshAuthentication allows the disclosure of user password digests to readers of the audit store. The `audit log` add-on builds `extra data` for each entry in the `AshAuthentication.AddOn.AuditLog.Auditor.build extra data/4` function, which takes the `:actor` from the action callback context verbatim. When an audited action is invoked with `actor:` set to a user record, the record—including the `hashed password` attribute—is deposited into the audit entry. While other identities are collapsed via `AshAuthentication.user to subject/1` and parameters are filtered, the actor remains unfiltered. Setting the attribute `sensitive?: true` is ineffective as it only redacts `inspect/1` output and not JSON encoding or raw-term storage. Exploitation requires independent read access to the audit store (e.g., database credentials, backups, or log shippers), enabling offline password attacks against active accounts. Persistence of this data depends on the data layer; raw-term stores keep it verbatim, whereas SQL stores may drop the entry unless the user resource derives `Jason.Encoder`.

تسمح مشكلة تتعلق باجتياز المسار النسبي في وحدة zip التابعة لـ stdlib بكتابة الملفات خارج دليل الاستخراج المقصود عند معالجة أرشيف zip مُعد خصيصًا. تستخدم الدالتان `zip:unzip/1,2` و`zip:extract/1,2` الدالة `zip:check dir level/2` للتحقق من صحة مسارات الدخول عن طريق تتبع عمق الدليل باستخدام عداد صحيح. ونظرًا لأن عملية التحقق ترفض فقط المسارات التي تكون فيها القيمة النهائية للعداد سالبة، فإن مسارًا مثل `../x/y` يمكن أن يتسبب في أن يصبح العداد سالبًا أثناء عملية التجاوز ثم يعود إلى الصفر، مما يؤدي إلى تجاوز الفحص والتوجيه إلى موقع خارج دليل الاستخراج عبر `add cwd`. توجد هذه المشكلة في الملف `lib/stdlib/src/zip.erl`.

يفشل محلل نص الطلب `Plug.Parsers.MULTIPART`، المستخدم لتحميل الملفات والنماذج متعددة الأجزاء، في فرض حد `:length` على جميع الموارد المستهلكة. حيث يقوم المحلل بحساب البايتات الموجودة في نص الجزء فقط، متجاهلًا بايتات رأس الجزء والأجزاء ذات النصوص الفارغة. يمكن لمهاجم بعيد غير مصدق استغلال هذه الثغرة عن طريق إرسال طلب واحد يحتوي على أجزاء ملفات عديدة ذات نصوص فارغة مع اسم ملف غير فارغ في `Content-Disposition`. تؤدي هذه العملية إلى إنشاء ملف مؤقت عبر `Plug.Upload` والاحتفاظ ببنية `Plug.Upload` لكل جزء، مما يؤدي إلى نمو غير محدود للذاكرة واستنفاد مساحة القرص ووحدات inode. ترتبط هذه المشكلة بالملف `lib/plug/parsers/multipart.ex` والدوال `Plug.Parsers.MULTIPART.parse multipart/2`، و`Plug.Parsers.MULTIPART.parse multipart headers/5`، و`Plug.Parsers. MULTIPART.parse multipart body/4`، و`Plug.Parsers.MULTIPART.parse multipart file/4`.

يسمح التعطيل غير السليم لمحددات المعلمات للمهاجم بحقن أو تجاوز سمات ملفات تعريف الارتباط HTTP. تقوم الدالة `encode/2` الموجودة في `Plug.Conn.Cookies` بإنشاء رأس استجابة Set-Cookie عن طريق إدراج قيمة ملف تعريف الارتباط ومساره، والمجال، و`same site`، والسمات الإضافية دون تعطيل المحدد ’;‘. إذا قام أحد التطبيقات بوضع بيانات يسيطر عليها المهاجم في قيمة ملف تعريف الارتباط أو إحدى سماته، مثلًا من خلال الدالة `put resp cookie/4`، فيمكن للمهاجم إدخال علامة ’;‘ لإلحاق أو تجاوز سمات مثل نطاق المجال والمسار، أو إزالة علامتي Secure و HttpOnly. وقد يؤدي ذلك إلى «تبديل ملفات تعريف الارتباط» و«تثبيت الجلسة». وعلى الرغم من رفض علامات إرجاع العربة وتغذية السطر والبايتات الفارغة، مما يمنع تقسيم استجابة HTTP، إلا أن إدخال السمات عبر علامة ’;‘ يظل ممكنًا.

يمكن لمهاجم غير مصدق أن يتسبب في هجوم رفض الخدمة ضد أي نقطة نهاية تقوم بتركيب مقبس Phoenix باستخدام وسيلة نقل قناة يمكن الوصول إليها، مثل WebSocket أو LongPoll. تكمن المشكلة في الروتين `Elixir.Phoenix.Socket`:handle in/4 الموجود في الملف lib/phoenix/socket.ex. نظرًا لأن وسائل النقل في Phoenix لا تحدد عدد القنوات التي يمكن لعملية نقل واحدة الانضمام إليها، يمكن للعميل إرسال عدد غير محدود من رسائل phx join عبر اتصال واحد. يؤدي هذا إلى إنشاء عمليات قنوات مفرطة، مما قد يستنفد الحد الأقصى لعدد العمليات في BEAM ويمنع الآلة الافتراضية من بدء عمليات جديدة لحركة المرور المشروعة. يحدث هذا التضخيم ضمن اتصال واحد، مما يجعل حدود الاتصال على مستوى طبقة الشبكة والحد من المعدل غير فعالين.

يحتوي عميل Presence JavaScript في phoenix على فحص غير سليم للحالات غير العادية، مما يسمح لمهاجم يتمتع بوصول عادي إلى القناة بالتسبب في رفض خدمة مستمر من جانب العميل لجميع مشاهدي موضوع قناة التواجد. تكمن المشكلة في ملف `assets/js/phoenix/presence.js` داخل روتينات `Presence.syncState()` و`Presence.syncDiff()`. يستخدم العميل اختبار «الصحة» البسيط (`state[key]`) بدلاً من فحص وجود خاصية خاصة للتحقق من وجود حالة التواجد. ونظرًا لأن مفاتيح التواجد تخضع لسيطرة المهاجم، يمكن للمستخدم تقديم مفتاح يطابق اسم عنصر في `Object.prototype` (مثل ` proto ` أو `constructor` أو `toString` أو `hasOwnProperty`). يؤدي هذا إلى إرجاع البحث `Object.prototype` المدمج بدلاً من `undefined`، مما يدفع الكود إلى محاولة قراءة `.metas.map(...)` من النموذج الأولي، الأمر الذي يطلق استثناء `TypeError` لم يتم التقاطه. يمنع هذا الاستثناء تحديث الحالة المحلية ويوقف تشغيل `onSync()`. ونظرًا لأن الخادم يستمر في دفع المفتاح الخبيث، تظل المزامنة معطلة لجميع مشاهدي الموضوع حتى يغادر المهاجم. وهذا يمثل خلطًا في وقت القراءة لكائن النموذج الأولي وليس تلوثًا للنموذج الأولي.

يوجد ثغرة حقن مسار URL في محول Microsoft Graph الخاص بـ Swoosh. يقوم المكون `Swoosh.Adapters.MsGraph` بإنشاء عنوان URL لطلب واجهة برمجة تطبيقات Microsoft Graph عن طريق إدراج عنوان البريد الإلكتروني للمرسل في المسار `/users/{from}/sendMail` دون التحقق من صحته أو ترميزه بنسبة مئوية. في التطبيقات التي يُشتق فيها عنوان «from» من مدخلات غير موثوق بها أو متأثرة بالمستخدم، يمكن للمهاجم استخدام أحرف خاصة بعناوين URL مثل «/» أو «?» أو «#» في الجزء المحلي من العنوان لتجاوز جزء المسار المقصود. وهذا يسمح للمهاجم بإعادة كتابة مسار الطلب وسلسلة الاستعلام، وإعادة توجيه طلب POST المصادق عليه إلى نقاط نهاية Graph أخرى ضمن نطاقات الرمز المميز باستخدام رمز حامل التطبيق.

يمكن للمهاجمين غير المصادق عليهم استنفاد ذاكرة BEAM وتعطيل الخادم عن طريق بث نص طلب أحادي كبير الحجم أو بطيء التدفق. تقوم الدالة `read full body/3` الموجودة في ’Elixir.GRPC.Server.Adapters.Cowboy.Handler‘ بتجميع كل جزء مستلم في ملف ثنائي واحد متزايد الحجم دون حد أقصى للحجم. علاوة على ذلك، إذا أغفل العميل رأس `grpc-timeout`، يتم تعيين مهلة القراءة لكل جزء إلى ما لا نهاية، مما يمكّن العميل الذي يرسل البيانات ببطء شديد من الحفاظ على الاتصال إلى أجل غير مسمى بينما يزداد استهلاك الذاكرة. يكفي اتصال واحد لاستنفاد ذاكرة الخادم وتعطيل العقدة.

يمكن للمهاجمين المصادق عليهم الوصول إلى الموارد الخاصة بمستخدمين آخرين أو تعديلها عن طريق تهريب قيمة متعارضة لأي حقل مرتبط بمسار عبر سلسلة الاستعلام أو نص الطلب. يحدث هذا في الدالة `map request/5` داخل `Elixir.GRPC.Server.Transcode` (lib/grpc/server/transcode.ex)، حيث يتم استخدام `Map.merge/2` مع ربط المسار كحجة أولى، مما يمنحها أولوية دمج أدنى. ونتيجة لذلك، يؤدي طلب مثل «GET /users/me/profile?user id=victim» أو طلب POST يحتوي على `user id` في نص الطلب إلى بنية protobuf تم فك تشفيرها، حيث يتم استبدال الحقل المرتبط بالمسار بالقيمة التي يقدمها المهاجم. وهذا يسمح بتجاوز المعالجات التي تستخدم هذه الحقول للتوثيق، أو التحقق من الملكية، أو تحديد نطاق الاستخدام المتعدد. تتطلب هذه المشكلة تمكين تحويل الترميز من HTTP إلى gRPC.

يسمح الاستهلاك غير المنضبط للموارد في وحدة «Version» التابعة للمكتبة القياسية للمهاجم بالتسبب في هجوم «رفض الخدمة» (DoS) عن طريق استنفاد موارد وحدة المعالجة المركزية (CPU) والذاكرة. يقوم محلل الإصدار بتحويل المكونات الرقمية إلى أعداد صحيحة دون تحديد طولها، مما يفرض تحويلًا فائقًا للخطي وغير مرن من قاعدة 10 إلى عدد صحيح بدقة عشوائية عبر `String.to integer/1` (المعروف أيضًا باسم `:erlang.binary to integer/1`). تؤدي هذه العملية إلى تثبيت جدولة BEAM، ويمكن للمكونات الأكبر حجمًا أن تؤدي إلى حدوث خطأ `SystemLimitError` غير مكتشف يؤدي إلى تعطل العملية المستدعية. يكفي وجود سلسلة طولها حوالي ميغابايت واحد لإثارة هذه المشكلة، ولا يتطلب الأمر أي مصادقة. يمكن الوصول إلى المشكلة عبر الروتين `parse digits/2` في `lib/version.ex` ونقاط الدخول العامة بما في ذلك `Version.parse/1` و`Version.parse!/1` و`Version.match?/3` و`Version.compare/2` و`Version.parse requirement/1`.

يؤدي التعطيل غير السليم لتسلسلات CRLF (رجوع العربة وتغذية السطر) في رؤوس HTTP إلى السماح بحقن رؤوس HTTP. تقوم الدالة `Tesla.Multipart.add content type param/2` بإلحاق السلاسل التي يزودها المستدعي بقائمة `content type params` متعددة الأجزاء دون التحقق من صحة أحرف `r` أو ` `. بعد ذلك، تقوم الدالة `Tesla.Multipart.headers/1` بدمج هذه المعلمات حرفياً لإنشاء رأس Content-Type الصادر. يمكن للمهاجم الذي يقدم معلمة تحتوي على `r ` تقسيم سطر الرأس، مما يتيح حقن رؤوس تعسفية في طلب HTTP الصادر. تؤثر هذه المشكلة على التطبيقات التي تقوم بإعادة توجيه المدخلات غير الموثوق بها، مثل مجموعة الأحرف أو سلاسل المعلمات التي يقدمها المستخدم، إلى الدالة `Tesla.Multipart.add content type param/2`. وقد يؤدي ذلك إلى تزوير رؤوس الطلبات الصادرة أو تهريب الطلبات المحتمل ضد الخادم الأعلى.

يؤدي التعامل غير السليم مع البيانات شديدة الضغط إلى حدوث هجوم رفض الخدمة عبر قنبلة فك الضغط في نصوص استجابات HTTP. عند استخدام `Tesla.Middleware.DecompressResponse` أو `Tesla.Middleware.Compression` في مسار البرمجيات الوسيطة، يتم فك ضغط نصوص الاستجابات بشكل متسرع دون حد أقصى للحجم. تقوم الدالة `decompress body/2` بتمرير نص الاستجابة بالكامل إلى `:zlib.gunzip/1` أو `:zlib.unzip/1` دون وضع حد أقصى لحجم المخرجات. علاوة على ذلك، تقوم الدالة `compression algorithms/1` بتقسيم رأس `content-encoding` بفواصل، وتقوم `decompress body/2` بالتكرار لكل رمز. يمكن للخادم الذي يوفر رأس `content-encoding` يحتوي على عدة رموز gzip أن يؤدي إلى عمليات فك ضغط متكررة، مما يتسبب في تضخم البيانات أسيًّا حيث تتوسع حمولة شبكة صغيرة إلى غيغابايتات من كومة BEAM (منطقة الذاكرة التي تستخدمها الآلة الافتراضية لـ Erlang)، مما يؤدي إلى استنفاد الذاكرة وتعطل أو تجميد العملية المستدعية.

يؤدي التعامل غير السليم مع التمييز بين الأحرف الكبيرة والصغيرة في `Tesla.Middleware.FollowRedirects` إلى تسرب بيانات الاعتماد إلى مصادر خارجية في عمليات إعادة التوجيه عبر المصادر. تحاول البرمجيات الوسيطة إزالة الرؤوس الحساسة من خلال مقارنتها بقائمة مرشحات مكتوبة بأحرف صغيرة تحتوي على `authorization` و`host`. ومع ذلك، نظرًا لأن Tesla يحتفظ بمفاتيح الرؤوس تمامًا كما قدمها المستدعي، دون أي توحيد، فإن الرؤوس التي تستخدم الكتابة الكبيرة القياسية، مثل `Authorization`، لا تتطابق مع المرشح المكتوب بأحرف صغيرة ويتم توجيهها إلى وجهة إعادة التوجيه. يمكن للمهاجم الذي يستطيع التحكم في استجابة `Location:` — سواء من خلال نقطة نهاية خاصة به، أو مصدر إعادة توجيه مفتوح، أو مصدر مخترق — التقاط رموز حامل (token) أو مواد ترخيص أخرى. يحدث هذا عندما تستخدم التطبيق `Tesla.Middleware.FollowRedirects` وتقوم بتعيين رؤوس تحتوي على مفاتيح غير مكتوبة بأحرف صغيرة.

يؤدي الترميز أو الهروب غير الصحيح للمخرجات إلى السماح بحقن رأس جزء متعدد الأجزاء من خلال قيم معلمة `Content-Disposition` غير المحروصة. تقوم الدالة `part headers for disposition()` باستيفاء معلمات التوزيع دون التحقق من صحة أحرف إرجاع العربة (`r`) أو تغذية السطر (` `) أو علامات الاقتباس المزدوجة. يتم استلام هذه القيم من الجهة المستدعية عبر `add field()` (المعلمة `name`) و`add file()` (المعلمة `filename`) و`add file content()` (المعلمة `filename` وخيارات التوزيع الأخرى). يمكن أن يؤدي حرف الاقتباس المزدوج إلى إغلاق معلمة مقتبسة قبل الأوان، في حين أن تسلسلات `r ` يمكن أن تنهي رأس `Content-Disposition` لبدء رأس مزور جديد أو إنهاء كتلة الرأس لإضافة بايتات في مقدمة نص الجزء. بالإضافة إلى ذلك، يستخدم مسار اسم الملف الافتراضي في `add file()` دالة `Path.basename()`، التي لا تزيل أحرف إرجاع العربة أو تغذية السطر.

تسمح مشكلة في Tesla.Adapter.Mint بحدوث هجوم رفض الخدمة (DoS) عن طريق استنفاد جدول الذرات (atom table). تقوم الدالة `open conn/2` بتحويل مخطط URL للطلبات الصادرة إلى ذرة BEAM باستخدام `String.to atom(uri.scheme)` دون التحقق من قائمة السماح. ذرات BEAM هي إدخالات دائمة لا تخضع لعملية جمع القمامة (garbage collection) وتقتصر على جدول محدود يضم حوالي 1,048,576 إدخالًا. يمكن للمهاجم القادر على التأثير على عنوان URL للطلب — من خلال ميزات إعادة توجيه عناوين URL على مستوى التطبيق مثل webhooks أو البروكسيات أو أدوات الاستيراد، أو عبر رأس Location عندما تكون `Tesla.Middleware.FollowRedirects` نشطة — إنشاء ذرة جديدة لكل طلب عن طريق تغيير سلسلة مخطط العنوان. وبمجرد امتلاء جدول الذرات، تتعطل الآلة الافتراضية، مما يؤدي إلى إيقاف تشغيل التطبيق بالكامل.

تسمح مشكلة نقص في التفويض في الوحدة النمطية `Elixir.Oban.Web.Jobs.DetailComponent` باستبدال عامل المهام دون إذن. يفشل معالج `handle event(”save-job“, ...)` في إجراء فحوصات التفويض، في حين أن المعالجات الأخرى مثل cancel و delete و retry تتحقق من الامتيازات باستخدام `can?/2`. يمكن للمستخدم المصادق عليه الذي يتمتع بحق الوصول `:read only` إرسال حدث WebSocket مزور من نوع `save-job` عبر LiveView لتجاوز حقل عامل المهمة واستبداله بأي وحدة `Oban.Worker` أخرى موجودة في التطبيق. ونتيجة لذلك، أثناء محاولة التنفيذ التالية، سيستدعي Oban الدالة `perform/1` على الوحدة النمطية التي اختارها المهاجم بدلاً من الوحدة المقصودة. يحدث هذا عند نشر لوحة تحكم Oban.Web وإتاحتها للمستخدمين الذين يتمتعون بامتيازات محدودة لإدارة المهام.

يؤدي الاستهلاك غير المنضبط للموارد في الوحدة النمطية `Elixir.Oban.Web.CronExpr` إلى استنفاد الذاكرة من خلال التوسع غير المحدود لنطاق مهام كرون. يمكن للمهاجم الذي يمتلك صلاحيات جدولة مهام كرون إرسال تعبير كرون ضار. عندما يقوم مستخدم لديه حق الوصول إلى لوحة التحكم بعرض قائمة مهام كرون، يتم استدعاء الدالة `describe/1` لعرض التعبير. تقوم الدالة `parse range/1` بتحليل نقاط نهاية النطاق باستخدام `Integer.parse/1` دون إجراء فحوصات للحدود، وتقوم الدالتان المساعدتان `expand dom parts/1` و`expand dow parts/1` بتجسيد النطاق على الفور عبر `Enum.to list/1`. قد تؤدي هذه العملية إلى تخصيص ما يقارب 2.4 جيجابايت من الذاكرة، مما يؤدي إلى توقف أو تعطل عقدة BEAM (آلة إرلانغ الافتراضية).

يؤدي الاستهلاك غير المنضبط للموارد في نقل SOCKS5 داخل `src/hackney socks5.erl` إلى حدوث إغراق. في حين يتم تطبيق مهلة الانتظار التي يحددها المتصل خلال مرحلة التفاوض SOCKS5، فإن ترقية الاتصال إلى TLS عبر الدالة `ssl:connect/2` تعود افتراضيًا إلى مهلة انتظار لا نهائية لأن المتغير `Timeout` لا يتم توجيهه. ونتيجة لذلك، يمكن لبروكسي SOCKS5 ضار يُكمل عملية المصافحة ثم يتوقف أو يرسل TLS ServerHello جزئيًا أن يتسبب في تعطل عملية الاتصال إلى أجل غير مسمى، متجاهلًا خيارات `connect timeout` أو `recv timeout`.

يؤدي التعطيل غير السليم لتسلسلات CRLF، والمعروف أيضًا باسم «حقن CRLF»، إلى السماح بتقسيم طلبات/استجابات HTTP. يقوم كود ترقية WebSocket الموجود في `src/hackney ws.erl` بنسخ خيارات المضيف والمسار والرؤوس (`ExtraHeaders`) والبروتوكولات من خريطة الخيارات التي يوفرها المستدعي إلى السجل الداخلي `#ws data{}` في `init/1`، ثم يدمجها حرفياً في طلب الترقية الخام لـ HTTP/1.1 عن طريق التسلسل الثنائي في `do handshake/1`. ونظرًا لعدم إجراء أي إزالة لـ CRLF أو NUL في مواقع الإدخال الأربعة هذه، يمكن للمهاجم الذي يتحكم في هذه الخيارات — مثل إعادة توجيه مكونات URL أو قيم الرؤوس من مدخلات غير موثوق بها إلى `hackney ws:start link/1` — إدخال رؤوس HTTP تعسفية في طلب ترقية WebSocket الصادر. ويمكن أن يؤدي ذلك إلى حقن الرؤوس، أو انتحال بيانات الاعتماد تجاه الخادم الأعلى، أو تسميم السجلات وذاكرة التخزين المؤقت، أو تهريب الطلبات عبر بروكسيات وسيطة.