Nos últimos dois dias, analisei com foco na segurança do AEGIS usando o caso @Dusk . No começo, só consegui memorizar “39 correções, 7 críticas”, mas ao terminar a leitura dos detalhes percebi que os números, na verdade, não são o ponto principal. No fim, esses 7 problemas graves se convergiram em 4 categorias de causa raiz: problemas de alias na sandbox de VM, desserialização insegura do lado do host, taxas e reembolsos do Phoenix que não ficaram completamente vinculados, e também um caminho de falsificação de assinatura BLS.
Por que olhar para as causas raiz, e não apenas para o número de vulnerabilidades? Porque, se a mesma fronteira de confiança não for bem desenhada, o problema pode reaparecer repetidamente em módulos diferentes. Por exemplo: se a entrada ainda não foi validada antes de desserializar, isso parece superficialmente um erro de processamento; na prática, pode esbarrar em segurança de memória do host. Já o conjunto de problemas do Phoenix não é apenas “um cálculo de taxa um pouco errado”: o que falha é que provas, assinaturas e execução de reembolso não seguem o mesmo conjunto de semânticas — no pior cenário, isso pode comprometer a integridade da cadeia de suprimentos e a segurança dos fundos.
A versão oficial diz que, no momento, não foram encontrados indícios de que essas críticas tenham sido exploradas antes de receber correções. Eu posso tratar isso como conclusão da investigação e não vou transformar em “nunca aconteceu”. Para $DUSK , o sinal positivo do AEGIS é que o time publicou internamente a descoberta, chegando às causas raiz e à lógica de correção; o sinal negativo também é bem claro: após o lançamento na mainnet, houve de fato lacunas de alto risco no core stack que puderam afetar execução, autenticação de consenso e a disponibilidade da cadeia.
Então eu não vou carimbar segurança para #dusk usando apenas “fez muitas auditorias”. Observação mais útil é: na próxima rodada, vão continuar divulgando; os testes de regressão para fronteiras do mesmo tipo vão existir; e a auditoria externa consegue abranger o código depois do AEGIS. Vocês se importam mais com o fato de o projeto nunca ter vazado problemas grandes, ou com o fato de, depois de algum vazamento, conseguirem explicar claramente a causa raiz, o impacto e a cadeia de correção?
$USELESS $BOME
Por que olhar para as causas raiz, e não apenas para o número de vulnerabilidades? Porque, se a mesma fronteira de confiança não for bem desenhada, o problema pode reaparecer repetidamente em módulos diferentes. Por exemplo: se a entrada ainda não foi validada antes de desserializar, isso parece superficialmente um erro de processamento; na prática, pode esbarrar em segurança de memória do host. Já o conjunto de problemas do Phoenix não é apenas “um cálculo de taxa um pouco errado”: o que falha é que provas, assinaturas e execução de reembolso não seguem o mesmo conjunto de semânticas — no pior cenário, isso pode comprometer a integridade da cadeia de suprimentos e a segurança dos fundos.
A versão oficial diz que, no momento, não foram encontrados indícios de que essas críticas tenham sido exploradas antes de receber correções. Eu posso tratar isso como conclusão da investigação e não vou transformar em “nunca aconteceu”. Para $DUSK , o sinal positivo do AEGIS é que o time publicou internamente a descoberta, chegando às causas raiz e à lógica de correção; o sinal negativo também é bem claro: após o lançamento na mainnet, houve de fato lacunas de alto risco no core stack que puderam afetar execução, autenticação de consenso e a disponibilidade da cadeia.
Então eu não vou carimbar segurança para #dusk usando apenas “fez muitas auditorias”. Observação mais útil é: na próxima rodada, vão continuar divulgando; os testes de regressão para fronteiras do mesmo tipo vão existir; e a auditoria externa consegue abranger o código depois do AEGIS. Vocês se importam mais com o fato de o projeto nunca ter vazado problemas grandes, ou com o fato de, depois de algum vazamento, conseguirem explicar claramente a causa raiz, o impacto e a cadeia de correção?
$USELESS $BOME
