Smart Contract Security Newsletter #40(Korea Ver)

Richard Kim
7 min readJun 18, 2020

--

이 게시물은 Smart Contract Security Newsletter의 Author인 Shayan Eskandari님에게 공식적으로 허가를 받아 작업하는 번역본입니다.

출처: https://medium.com/consensys-diligence/smart-contract-security-newsletter-40-860b66fa8d6

메일을 통해 뉴스레터를 구독신청하려면 클릭해주세요

먼저, 최근 몇 주 동안 컨센시스에서 작업한 것들을 소개하겠습니다.

  • 블록체인 보안 DB가 과거에 진행했던 감사(Audit) 정보와 바운티 프로그램들 그리고 보안 컨택 정보를 포함한 블록체인 프로젝트들에 대한 보안 정보의 데이터베이스가 오픈 소스(JSON 형식의 데이터도 포함)로 공개되었습니다.

최근에 여러 프로젝트들(특히 De-Fi)의 보안을 비교 및 평가를 하기 위해 특별히 노력을 기울였습니다. 이러한 작업을 하는 과정들은 어렵고 논쟁의 여지가 있는 일이므로, 우리는 따로 해석해야될 여지가 없는 정보를 찾아 제시하는 것으로 시작하였습니다. 이러한 프로젝트에 PR을 따로 제출하거나 Gitcoin 플랫폼의 grants 기부를 통해 후원할 수 있습니다.

곧 업데이트될 Solidity Visual Auditor의 툴을 사용하여 EVM의 바이트 코드를 디컴파일할 수 있습니다.

최근 뉴스

miner의 수수료로 570만 달러 발생

저번주 이더리움 네트워크에서 Gas Price가 급증하는 모습을 보였습니다. 하지만 트랜잭션의 수가 많을뿐만 아니라 트랜잭션의 수수료로 수백만 달러를 지불하는 트랜잭션이 아래의 리스트에서 보듯이 2번이나 발생하였습니다.

소프트웨어의 버그에서부터 해킹된 거래소의 협박까지 높은 GasPrice가 포함된 트랜잭션 거래의 원인에 대한 입증되지않은 설들이 돌고있습니다.

마이닝 회사인 SparkPoolEthermine트랜잭션 발신자가 나타나면 전액 수수료를 환불하겠다고 발표했습니다. 그러나 해당 글을 공개한 시점에는 트랜잭션 발신자가 정체를 드러내지 않았으며, 마이닝 풀의 회사들은 거래 당일에 마이닝에 참여했던 모든 마이너에게 ETH를 배분하기로 결정했습니다.

Sam Moelius의 트랜잭션 교체 공격 탐지(원문: Detecting transaction replacement attacks)

작년 컨센시스는 블록체인에서의 체계화된 front-running 공격들에 대한 문서를 공개한적이 있습니다. 또한 구체적인 발표를 보고싶어하는 분들을 위해 SBC19에서의 비디오를 함께 공개합니다.

이러한 front-running 공격의 분류 문서는 다양한 공격 타입들의 과정을 이해하고 탐지하는 메커니즘들을 개발하는데 도움이 됩니다. 트랜잭션 교체 공격 탐지에 대한 발표 영상에서, Trail of Bits의 Sam Moelius는 위 문서에서 설명한 공격 중 하나를 탐지하는 방법을 구현한 파트를 발표하였습니다.

Solidity 0.6.9와 0.6.10의 릴리즈

Solidity의 0.6.9 버전이 6월 5일에 릴리즈되었습니다:

Solidity 0.6.9 버전은 solc-js에 대한 SMT-checking이 추가되었고, 모든 변수들에 대해 calldata 옵션이 가능해졌으며 import 디렉토리를 지정하는 메커니즘이 추가되었습니다.

불과 6일 이후, Solidity 0.6.10이 릴리즈되었으며, Solidity도 릴리즈 사이클의 시간을 정하는 파트가 필요해보입니다. 버그의 핵심 원인은 low level에서의 문제가 발생하였습니다:

이번 버그의 원인은 for문 내에 calldata 파라미터를 가진 library 함수들을 호출할 때 발생합니다. 더 자세하게 설명하자면, public 옵션을 가진 library 함수들을 호출할 때 컴파일러가 모든 calldata 인자들을 memory로 복사합니다. internal 옵션을 가진 library 함수는 해당하는 memory 포인터를 받지만, 이를 calldata 포인터로 해석하여 잘못된 위치에서 calldata를 읽고 스택 손상(corruption)을 초래합니다. 스택 손상(corruption)은 calldata 포인터가 두 개의 스택 슬롯을 사용할 수 있고 memory 포인터는 항상 하나의 스택 슬롯만 사용하기때문에 발생합니다. 이로 인해 다른 변수에 문제가 발생하고 함수 return 시에 잘못된 위치로 Jump가 발생할 수 있습니다.

리서치 문서 리스트

참고 링크 리스트

만약 이 뉴스레터가 유익하고 주위 사람들과 공유하고싶다면 Smart Contract Security Newsletter 링크를 통해 가입 후 구독 신청이 가능합니다 !

--

--