Charles-Cooper

Name of the Vulnerable Software and Affected Versions: Vyper versions up to and including 0.4.2rc1 Description: The issue concerns the `slice()` builtin in Vyper, which can elide side effects when the output length is 0 and the source bytestring is a builtin, such as `msg.data` or `<address>.code`. This occurs because the check for `length >= 1` is skipped for these source locations. As a result, a 0-length bytestring constructed with `slice()` can be passed to `make byte array copier`, which elides evaluation of its source argument when the max length is 0. This can lead to side effects in the `start` argument being elided when the `length` argument is 0. Recommendations: For versions up to and including 0.4.2rc1, consider updating to version 0.4.2, which is expected to include the fix that disallows any invocation of `slice()` with length 0. As a temporary workaround, avoid using the `slice()` function with a length of 0, especially when the source is `msg.data` or `<address>.code`, to prevent potential side effects from being elided.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Vyper anteriores à 0.4.1 **Descrição** O problema surge da maneira como o Vyper lida com instruções AugAssign, especificamente quando o alvo é um acesso a um DynArray e o lado direito (rhs) modifica o array. Nesses casos, o alvo em cache é avaliado primeiro e a verificação de limites não é reavaliada durante a etapa de escrita da instrução. Isso pode levar a um acesso fora dos limites. Por exemplo, o código `a[1] += a.pop()` é avaliado como se `a[1]` fosse acessado antes de `a.pop()` modificar o array, contornando a verificação de limites que ocorreria se `a[1]` fosse acessado após `a.pop()`. **Recomendações** Para versões anteriores à 0.4.1, atualize para a versão 0.4.1 ou posterior para resolver este problema. No momento, não há informações sobre outras soluções alternativas para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Vyper anteriores à 0.4.1 **Descrição** O problema surge do tratamento inadequado de estados finais oscilantes na função `sqrt()`, que utiliza o método babilônico para calcular raízes quadradas de decimais. Isso pode fazer com que a `sqrt()` retorne incorretamente resultados arredondados para cima. O impacto deste problema é considerado baixo, pois a `sqrt()` é raramente utilizada na prática. No entanto, como a `sqrt()` pode ser usada para determinar condições de contorno, o arredondamento para baixo é preferível. **Recomendações** Para versões anteriores à 0.4.1, atualize para a versão 0.4.1 assim que a versão corrigida estiver disponível. Como medida temporária de contorno, considere evitar o uso da função `sqrt()` até que uma correção esteja disponível. Restrinja o uso da função `sqrt()` em cálculos críticos para minimizar o risco de exploração.

**Nome do software vulnerável e versões afetadas** Versões do Vyper anteriores à 0.3.0 **Descrição** O problema diz respeito ao fato de a função ` default ()` não respeitar o decorador `@nonreentrancy`, e de o bloqueio não ser emitido. Trata-se de um bug conhecido de baixo impacto, uma vez que o uso de um bloqueio em uma função `default` é um padrão pouco utilizado. Não foram encontrados contratos de produção vulneráveis. **Recomendações** Para versões anteriores à 0.3.0, atualize para a versão 0.3.0 ou posterior para resolver o problema. Como solução temporária, considere evitar o uso do decorador `@nonreentrancy` em funções ` default ()` até que um patch seja aplicado.

**Nome do software vulnerável e versões afetadas** Versões 0.3.10 e anteriores do Vyper **Descrição** O uso da função integrada `create from blueprint` pode resultar em uma vulnerabilidade de avaliação dupla quando `raw args=True` e o argumento `args` tem efeitos colaterais. A função ` build create IR` da função embutida `create from blueprint` não armazena em cache o referido argumento `args` na pilha, permitindo que ele seja avaliado várias vezes. Não foram encontrados contratos de produção vulneráveis, e a avaliação dupla de efeitos colaterais deve ser facilmente detectável em testes de clientes, resultando em um impacto baixo. **Recomendações** Para as versões 0.3.10 e anteriores do Vyper, como solução temporária, considere desativar a função interna `create from blueprint` com `raw args=True` até que um patch esteja disponível. No momento, não há informações sobre uma versão mais recente que contenha uma correção para essa vulnerabilidade.

**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.

**Nome do software vulnerável e versões afetadas** Versões do Vyper anteriores à 0.3.4 **Descrição** O problema ocorre ao chamar um contrato externo sem valor de retorno, o que pode resultar na avaliação do endereço do contrato duas vezes, incluindo quaisquer efeitos colaterais. Isso pode levar a resultados incorretos nos contratos. O problema geralmente é uma questão de eficiência, mas pode causar a avaliação dupla de efeitos colaterais se a avaliação do endereço do contrato tiver efeitos colaterais. **Recomendações** Para versões anteriores à 0.3.4, atualize para a versão 0.3.4 ou posterior para resolver o problema. Como solução alternativa temporária, considere atribuir endereços de contrato a variáveis para evitar a avaliação dupla de efeitos colaterais. Por exemplo, em vez de `Foo(Foo(msg.sender).bar()).foo()`, use `t: Foo = Foo(msg.sender).bar()` e, em seguida, `t.foo()`.

**Nome do software vulnerável e versões afetadas** Versões do Vyper anteriores à 0.3.2 **Descrição** O problema ocorre ao importar uma função de uma interface JSON que retorna `bytes`, gerando um bytecode que não limita o comprimento dos bytes, o que pode resultar em um estouro de buffer. Não há relatos de incidentes reais nem estimativas do número de dispositivos afetados. **Recomendações** Para versões anteriores à 0.3.2, atualize para a versão 0.3.2 ou posterior para resolver o problema. Como solução alternativa temporária, considere usar interfaces .vy em vez de importar de interfaces JSON que retornam `bytes`.

**Nome do software vulnerável e versões afetadas** Versões 0.3.1 e anteriores do Vyper **Descrição** O problema decorre da comparação de sequências de bytes, que pode gerar resultados incorretos devido à presença de bytes corrompidos ou à falta de comparação de comprimento. Especificamente, duas cadeias de bytes podem ser comparadas como iguais mesmo que uma termine com um byte nulo (`x00`), pois a comparação não leva em conta o comprimento das cadeias de bytes. Isso pode levar a avaliações incorretas, como `b1 == b2` retornando `True` quando `b1` e `b2` não são idênticos. **Recomendações** Para as versões 0.3.1 e anteriores do Vyper, atualize para a versão 0.3.2 ou posterior, que deverá incluir o patch para este problema. No momento, não há informações sobre outras soluções alternativas para esta vulnerabilidade.

**Nome do software vulnerável e versões afetadas** Versões do Vyper anteriores à 0.3.0 **Descrição** O problema ocorre ao realizar uma chamada de função dentro de uma estrutura literal, resultando em um problema de corrupção de memória devido a um ponteiro incorreto para o topo da pilha. **Recomendações** Para versões anteriores à 0.3.0, atualize para a versão 0.3.0 para resolver o problema.

**Nome do software vulnerável e versões afetadas** Versões do Vyper anteriores à 0.3.0 **Descrição** O problema decorre do fato de funções externas não validarem adequadamente os limites dos argumentos decimais, levando a possíveis erros lógicos. **Recomendações** Para versões anteriores à 0.3.0, atualize para a versão 0.3.0 para resolver o problema. Como solução temporária, considere evitar o uso de argumentos decimais em funções externas até que o problema seja resolvido.