Charles-Cooper

Vyper from 0.2.13 before 0.2.15 allocates storage slots for @nonreentrant reentrancy locks at the same locations as contract storage variables. When a function using @nonreentrant is called, setting the lock overwrites the overlapping storage variable, corrupting contract state and breaking the contract's intended logic.

اسم البرنامج المعرض للخطر والإصدارات المتأثرة: إصدارات Vyper حتى الإصدار 0.4.2rc1 بما في ذلك الوصف: تتعلق المشكلة بالدالة المدمجة `slice()` في Vyper، والتي يمكن أن تتجاهل الآثار الجانبية عندما يكون طول المخرجات 0 وتكون سلسلة البايت المصدر دالة مدمجة، مثل `msg.data` أو `<address>.code`. يحدث هذا لأن فحص `length >= 1` يتم تخطيه بالنسبة لهذه المواقع المصدرية. ونتيجة لذلك، يمكن تمرير سلسلة بايت بطول صفر تم إنشاؤها باستخدام `slice()` إلى `make byte array copier`، مما يؤدي إلى تجاهل تقييم حجة المصدر الخاصة بها عندما يكون الطول الأقصى 0. وقد يؤدي هذا إلى تجاهل الآثار الجانبية في حجة `start` عندما تكون حجة `length` تساوي 0. التوصيات: بالنسبة للإصدارات حتى الإصدار 0.4.2rc1 بما في ذلك، يُنصح بالتحديث إلى الإصدار 0.4.2، والذي من المتوقع أن يتضمن الإصلاح الذي يمنع أي استدعاء لـ `slice()` بطول 0. كحل مؤقت، تجنب استخدام الدالة `slice()` بطول 0، خاصةً عندما يكون المصدر هو `msg.data` أو `<address>.code`، لمنع حذف الآثار الجانبية المحتملة.

**اسم البرنامج المعرض للثغرة والإصدارات المتأثرة** إصدارات Vyper الأقدم من 0.4.1 **الوصف** تنشأ المشكلة من الطريقة التي يتعامل بها Vyper مع تعليمات AugAssign، وتحديدًا عندما يكون الهدف هو الوصول إلى DynArray ويقوم الجانب الأيمن (rhs) بتعديل المصفوفة. في هذه الحالات، يتم تقييم الهدف المخزّن مؤقتًا أولاً ولا يتم إعادة تقييم فحص الحدود أثناء مرحلة الكتابة للتعليمات. وقد يؤدي ذلك إلى وصول خارج الحدود. على سبيل المثال، يتم تقييم الكود `a[1] += a.pop()` كما لو تم الوصول إلى `a[1]` قبل أن تقوم `a.pop()` بتعديل المصفوفة، مما يتجاوز فحص الحدود الذي كان سيحدث لو تم الوصول إلى `a[1]` بعد `a.pop()`. **التوصيات** بالنسبة للإصدارات الأقدم من 0.4.1، قم بالتحديث إلى الإصدار 0.4.1 أو أحدث لحل هذه المشكلة. في الوقت الحالي، لا توجد معلومات حول حلول بديلة أخرى لهذه الثغرة الأمنية.

**اسم البرنامج المعرض للثغرة والإصدارات المتأثرة** إصدارات Vyper الأقدم من 0.4.1 **الوصف** تنشأ المشكلة عن المعالجة غير السليمة للحالات النهائية المتذبذبة في الدالة `sqrt()`، التي تستخدم الطريقة البابلية لحساب الجذور التربيعية للأعداد العشرية. قد يؤدي ذلك إلى قيام الدالة `sqrt()` بإرجاع نتائج مقربة لأعلى بشكل غير صحيح. يُعتبر تأثير هذه المشكلة منخفضًا، نظرًا لأن الدالة `sqrt()` نادرًا ما تُستخدم في الممارسة العملية. ومع ذلك، نظرًا لأن الدالة `sqrt()` يمكن استخدامها لتحديد شروط الحواف، يُفضل التقريب لأسفل. **التوصيات** بالنسبة للإصدارات الأقدم من 0.4.1، قم بالتحديث إلى الإصدار 0.4.1 فور توفر الإصدار المصحح. كإجراء مؤقت، يُنصح بتجنب استخدام الدالة `sqrt()` حتى يتوفر تصحيح. قم بتقييد استخدام الدالة `sqrt()` في الحسابات الحرجة لتقليل مخاطر الاستغلال.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.3.10 and prior **Description** Using the `create from blueprint` builtin can result in a double eval vulnerability when `raw args=True` and the `args` argument has side-effects. The ` build create IR` function of the `create from blueprint` builtin doesn't cache the mentioned `args` argument to the stack, allowing it to be evaluated multiple times. No vulnerable production contracts were found, and double evaluation of side-effects should be easily discoverable in client tests, resulting in a low impact. **Recommendations** For Vyper versions 0.3.10 and prior, as a temporary workaround, consider disabling the `create from blueprint` builtin with `raw args=True` until a patch is available. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.0 **Description** The issue concerns the ` default ()` function not respecting the `@nonreentrancy` decorator, and the lock not being emitted. This is a known bug with low impact, as using a lock on a `default` function is a sparsely used pattern. No vulnerable production contracts were found. **Recommendations** For versions prior to 0.3.0, update to version 0.3.0 or later to resolve the issue. As a temporary workaround, consider avoiding the use of the `@nonreentrancy` decorator on ` default ()` functions until a patch is applied.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.8 **Description** The issue affects contracts containing large arrays, which might underallocate the number of slots they need by 1. This occurs due to a calculation error in determining the required slots for a storage variable, which uses `math.ceil(type .size in bytes / 32)`. The intermediate floating point step can produce a rounding error if there are enough bits set in the IEEE-754 mantissa. Specifically, if `type .size in bytes` is large (> 2**46) and slightly less than a power of 2, the calculation can overestimate the required slots, while if `type .size in bytes` is slightly more than a power of 2, it can underestimate the required slots. This can lead to overwriting of variables, as demonstrated by example contracts. **Recommendations** For versions prior to 0.3.8, update to version 0.3.8 to resolve the issue. As a temporary workaround, consider reviewing contracts for large arrays and manually verifying the allocation of slots to prevent potential overwriting of variables. Restrict access to contracts containing large arrays to minimize the risk of exploitation until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.10 **Description** The ` abi decode()` function in Vyper does not validate input when it is nested in an expression, allowing for bounds checking to be bypassed and resulting in incorrect results. This can be triggered by constructing specific examples where the output of ` abi decode` is not internally passed to input validating routines. **Recommendations** For versions prior to 0.3.10, update to version 0.3.10 to resolve the issue. As a temporary workaround, consider avoiding the use of ` abi decode()` in nested expressions until the patch is applied. Restrict access to the ` abi decode()` function to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.2.9 through 0.3.9 **Description** The issue concerns locks of the type `@nonreentrant("")` or `@nonreentrant('')` that do not produce reentrancy checks at runtime. This can be mitigated by ensuring the lock name is a non-empty string. **Recommendations** For versions 0.2.9 through 0.3.9, ensure the lock name is a non-empty string as a workaround until the issue is resolved by updating to version 0.3.10 or later. For version 0.3.10 and later, no additional action is required as the issue is fixed in this version.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.3.9 and prior **Description** The memory used by the builtins `raw call`, `create from blueprint`, and `create copy of` can be corrupted under certain conditions, leading to incorrect `calldata` in the sub-context or deploying incorrect bytecode. Each builtin has specific conditions that must be fulfilled for the corruption to happen, including the use of complex expressions that result in writing to memory. As of the time of publication, no patched version exists, and the issue is still being investigated. There might be other cases where the corruption might happen. When the builtin is being called from an `internal` function, the issue is not present if the function calling it wrote to memory before calling it. **Recommendations** For Vyper versions 0.3.9 and prior, as a temporary workaround, consider caching complex expressions in memory prior to the call to the builtin. For example, in the case of `create from blueprint`, cache the `salt` value in memory before passing it to the builtin. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper (affected versions not specified) **Description** The order of evaluation of the arguments of the builtin functions `uint256 addmod`, `uint256 mulmod`, `ecadd`, and `ecmul` does not follow source order. This behavior is problematic when the evaluation of one of the arguments produces side effects that other arguments depend on. For `uint256 addmod(a,b,c)` and `uint256 mulmod(a,b,c)`, the order is `c,a,b`. For `ecadd(a,b)` and `ecmul(a,b)`, the order is `b,a`. **Recommendations** As a temporary workaround, consider ensuring that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects when using builtins from the list above. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper (affected versions not specified) **Description** The Vyper compiler evaluates arguments from right to left instead of left to right for certain expressions, including `unsafe add, unsafe sub, unsafe mul, unsafe div, pow mod256, |, &, ^ (bitwise operators), bitwise or (deprecated), bitwise and (deprecated), bitwise xor (deprecated), raw call, <, >, <=, >=, ==, !=, in, not in (when lhs and rhs are enums)`. This behavior becomes a problem when the evaluation of one argument produces side effects that other arguments depend on. Expressions that can produce side effects include state modifying external calls, state modifying internal calls, `raw call`, `pop()` when used on a Dynamic Array stored in the storage, `create minimal proxy to`, `create copy of`, and `create from blueprint`. **Recommendations** As a temporary workaround, consider ensuring that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.10 **Description** The ecrecover precompile in Vyper does not fill the output buffer if the signature does not verify. However, the ecrecover builtin will still return whatever is at memory location 0. This means that if the compiler has been convinced to write to the 0 memory location with specially crafted data just before the ecrecover, a signature check might pass on an invalid signature. **Recommendations** For versions prior to 0.3.10, update to version 0.3.10 to resolve the issue. As a temporary workaround, consider restricting the use of the ecrecover builtin until a patch is applied. Avoid using the ecrecover operation with immutable reads or hashmap accesses that could write to the 0 memory location.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.8 **Description** In contracts with more than one regular nonpayable function, it is possible to send funds to the default function, even if the default function is marked `nonpayable`. This issue was fixed by the removal of the global `calldatasize` check. **Recommendations** For versions prior to 0.3.8, upgrade to version 0.3.8. For users unable to upgrade, avoid use of nonpayable default functions.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.8 **Description** The issue occurs during codegen when the length word of a dynarray is written before the data. This can result in out-of-bounds array access when the dynarray is on both the lhs and rhs of an assignment, potentially causing data corruption across call frames. The expected behavior is to revert due to out-of-bounds array access. **Recommendations** For versions prior to 0.3.8, update to version 0.3.8 to resolve the issue. As a temporary workaround, consider avoiding assignments where a dynarray is on both the lhs and rhs to minimize the risk of exploitation. Restrict the use of dynarrays in critical functions until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.4 **Description** The issue arises when calling an external contract with no return value, potentially resulting in the contract address being evaluated twice, including any side effects. This could lead to incorrect outcomes for contracts. The problem is usually an efficiency issue but can cause double evaluation of side effects if the contract address evaluation has side effects. **Recommendations** For versions prior to 0.3.4, update to version 0.3.4 or later to resolve the issue. As a temporary workaround, consider assigning contract addresses to variables to avoid double evaluation of side effects. For example, instead of `Foo(Foo(msg.sender).bar()).foo()`, use `t: Foo = Foo(msg.sender).bar()` and then `t.foo()`.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.2 **Description** The issue arises when importing a function from a JSON interface that returns `bytes`, generating bytecode that does not clamp the bytes length, potentially resulting in a buffer overrun. There are no known real-world incidents or estimated numbers of affected devices mentioned. **Recommendations** For versions prior to 0.3.2, upgrade to version 0.3.2 or later to resolve the issue. As a temporary workaround, consider using .vy interfaces instead of importing from JSON interfaces that return `bytes`.

**Name of the Vulnerable Software and Affected Versions** Vyper versions 0.3.1 and prior **Description** The issue arises from the comparison of bytestrings, which can yield incorrect results due to the presence of dirty bytes or the lack of length comparison. Specifically, two bytestrings can compare as equal even if one ends with a null byte (`x00`) because the comparison does not account for the length of the bytestrings. This can lead to incorrect evaluations, such as `b1 == b2` returning `True` when `b1` and `b2` are not identical. **Recommendations** For Vyper versions 0.3.1 and prior, update to version 0.3.2 or later, which is expected to include the patch for this issue. At the moment, there is no information about other workarounds for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.0 **Description** The issue occurs when performing a function call inside a literal struct, resulting in a memory corruption problem due to an incorrect pointer to the top of the stack. **Recommendations** For versions prior to 0.3.0, update to version 0.3.0 to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Vyper versions prior to 0.3.0 **Description** The issue arises from external functions not properly validating the bounds of decimal arguments, leading to potential logic errors. **Recommendations** For versions prior to 0.3.0, update to version 0.3.0 to resolve the issue. As a temporary workaround, consider avoiding the use of decimal arguments in external functions until the issue is resolved.