por Aptos Labs y OtterSec

Aptos Network utiliza el lenguaje de contrato inteligente Move como modelo de programación subyacente. Si bien Move está diseñado para un ecosistema de contratos inteligentes seguros, una implementación defectuosa de Move puede poner en peligro esas propiedades. En Aptos Labs, nos comprometemos a hacer que Move sea lo más seguro posible, junto con la comunidad. Ambos estamos invirtiendo en herramientas para escribir contratos inteligentes correctos (p. ej., Move Prover, desarrollado principalmente por Aptos), así como en la corrección de los componentes principales del tiempo de ejecución, como Move Virtual Machine. En este artículo, describimos cómo nosotros, junto con nuestros socios, logramos esto último a través de auditorías, recompensas por errores, fuzzing y fortalecimiento de la seguridad de la implementación subyacente.

¿Qué estamos asegurando?

La seguridad de Move se basa en algunas propiedades básicas. Estas propiedades se definen en términos del código de bytes que consume el motor de ejecución de Move y son independientes del idioma de origen:

• Tipo de seguridad : cada valor tiene un tipo único e infalsificable. Por ejemplo, no es posible tomar algún valor del tipo `dirección` y convertirlo en un token relevante para la seguridad del tipo `firmante`.
• Encapsulación modular : los recursos en almacenamiento solo se pueden manipular desde el código dentro de los módulos que declaran esos recursos. Solo las funciones con visibilidades coincidentes pueden llamarse módulo cruzado.
• Propiedad y vigencia : el sistema de habilidades de Move exige que un valor no se copie, elimine, almacene ni use como clave a menos que se declare la habilidad correspondiente para el tipo de valor.
• Seguridad de las referencias : las referencias no sobreviven a los valores a los que apuntan. Una referencia mutable es de propiedad exclusiva, por lo que no es posible crear un alias.

Las siguientes son las preguntas que nos interesan:

1. ¿Está completo el verificador de código de bytes y garantiza que todas las propiedades anteriores se cumplan para cada programa? Esto es importante porque la violación de cualquiera de las propiedades anteriores puede resultar potencialmente en la pérdida de activos.
2. ¿Puede un programa de código de bytes Move bloquear el motor de ejecución? Debido a que en una máquina de estado replicada, todos los nodos ejecutan los mismos programas, esto puede usarse para detener la red.
3. ¿Puede un programa determinado hacer que el motor de ejecución se quede sin recursos (memoria o tiempo)? Esto puede aprovecharse para ataques DoS que ralentizan o suspenden la red.

En el núcleo del desarrollo de código libre de errores se encuentran prácticas disciplinadas de ingeniería de software combinadas con las herramientas adecuadas. En Aptos, seguimos el riguroso proceso de revisión obligatoria del código y pruebas e integración continuas, combinado con las mejores prácticas del ecosistema Rust. Además de estos aspectos tradicionales, también estamos aplicando las siguientes medidas para mantener Move tan seguro como está diseñado para ser.

Auditoría y Consultoría

Una de las medidas más respetadas en la industria para ganar confianza en las redes blockchain es la auditoría. En Aptos Labs, contratamos a Certik ( informe ) y Holburn para auditar la máquina Move Virtual. Se encontraron múltiples problemas críticos, uno de ellos en la categoría de seguridad tipo.

Además de la auditoría externa, Aptos Labs dirigió y organizó un esfuerzo de auditoría comunitaria, centrado en el verificador de bytecode . Ingenieros de Mysten Labs, Starcoin y compañías de auditoría como MoveBit y OtterSec se asociaron con ingenieros de Aptos para este esfuerzo, invirtiendo alrededor de 6 semanas-persona de tiempo de auditoría. Los resultados de esto se capturan en esta hoja de cálculo , en referencia a docenas de documentos creados durante esta auditoría. Este esfuerzo de auditoría encontró y abordó múltiples problemas antes de que Aptos llegara a la red principal.

Por último, pero no menos importante, tenemos una estrecha colaboración con OtterSec . El equipo de OtterSec realizó revisiones de código manuales y desarrolló tecnología de fuzzing para varios objetivos, identificando múltiples problemas críticos tanto en el código de marco de Move VM como en el de Aptos. También lideraron los esfuerzos para agregar una lógica redundante de defensa en profundidad a Move VM (ver a continuación), lo que influyó en nuestro trabajo de diseño en curso para mitigar nuevas vulnerabilidades de pérdida de fondos.

Recompensa de errores

Aptos Labs ejecuta un programa de recompensas por errores . Para errores críticos del tipo que pueden conducir a la pérdida de activos, se ofrecen recompensas de hasta $ 1,000,000. Del mismo modo, los errores de bloqueo pueden recompensarse con hasta $ 100,000.

Con el programa de recompensas, hemos trabajado en estrecha colaboración con un talentoso conjunto de investigadores de seguridad para encontrar y corregir errores. Algunos de esos errores estaban en la categoría crítica, mientras que otros errores han sido fallas encontradas mediante el uso de fuzzers.

Aptos Labs ha cumplido con sus compromisos en recompensas por errores y se pagaron recompensas significativas. Además, Aptos Labs ha seguido utilizando la experiencia de los whitehats que conocimos a través del programa de recompensas y tiene la intención de seguir trabajando junto con esta comunidad.

Fuzzing

El programa de recompensas nos motivó a invertir nosotros mismos en fuzzing en Aptos Labs. El código Move VM se ha modificado para implementar el rasgo de fuzzing `Arbitrary` Rust en puntos relevantes, lo que permite el uso de 'cargo fuzz' para generar y validar dinámicamente módulos de código de bytes. Tenemos algunos trabajos continuos ejecutándose con esos objetivos de fuzzing.

Redundancia

Una forma de lograr una garantía adicional de seguridad es a través de la redundancia. Agregamos el llamado modo paranoico a Move VM, que aplica la seguridad de tipo y las otras reglas mencionadas anteriormente en el momento de la ejecución. Si bien el verificador de código de bytes ya verifica dichas propiedades cuando el código ingresa al sistema, el modo paranoico vuelve a verificar las mismas comprobaciones durante el tiempo de ejecución del código de bytes. El modo paranoico fue ampliamente discutido dentro de la comunidad de Move, con los ingenieros de Aptos liderando el diseño. Para obtener más información, consulte este PR (versión final) y este PR (versión intermedia).

¿Que sigue?

En Aptos Labs, nos comprometemos a hacer que Move sea lo más seguro posible e invertimos mucho en esta área. Aquí describimos los esfuerzos en curso en torno a la auditoría, las recompensas de errores, la fuzzing y el endurecimiento realizados por nosotros y nuestros socios. En el futuro, planeamos continuar invirtiendo en este espacio. Continuaremos ofreciendo un programa de recompensas por errores, interactuando con auditores de seguridad acreditados e impulsando el desarrollo de herramientas de fortalecimiento de la seguridad, por ejemplo, tecnología fuzzing.