솜털

Fuzzing
다음에 대한 시리즈 일부
정보 보안
vectorial version
관련 보안 카테고리
위협
방어

솜털 또는 솜털 테스트는 컴퓨터 프로그램에 대한 입력으로 유효하지 않거나 예기치 않은 또는 무작위 데이터를 제공하는 자동 소프트웨어 테스트 기법이다.그런 다음 프로그램은 충돌, 내장 코드 주장 실패 또는 잠재적 메모리 누수와 같은 예외에 대해 모니터링된다.일반적으로 솜털은 구조화된 입력을 취하는 프로그램을 테스트하는 데 사용된다.이 구조는 예를 들어 파일 형식이나 프로토콜로 지정되며 유효하지 않은 입력과 구별된다.효과적인 솜털은 파서에 의해 직접 거부되지 않는다는 점에서 "유효한" 반유효한 입력을 발생시키지만, 프로그램 내에서 더 깊은 곳에서 예기치 않은 동작을 만들어내고 적절히 처리되지 않은 코너 케이스를 노출시킬 수 있을 정도로 "유효하지 않은" 입력을 생성한다.

보안을 위해 신뢰 경계를 넘는 입력이 가장 유용한 경우가 많다.[1]예를 들어 권한 있는 사용자만 액세스할 수 있는 구성 파일을 구문 분석하는 코드보다 어떤 사용자의 파일 업로드를 처리하는 코드를 솜털로 만드는 것이 더 중요하다.

역사

'퍼즈(fuzz)'라는 용어는 교수가 가르치는 1988년 가을 고급 운영체제(CS736) 수업 프로젝트에서[2] 비롯됐다.위스콘신 대학의 바튼 밀러 교수는 1990년에 그 결과가 발표되었다.[3]테스트하기 위해 유닉스 유틸리티는 유틸리티에 대한 임의 입력 및 명령줄 매개 변수를 자동으로 생성하도록 의도되었다.이 프로젝트는 UNIX 명령줄 프로그램이 추락할 때까지 많은 수의 임의 입력을 신속하게 실행함으로써 UNIX 명령줄 프로그램의 신뢰성을 테스트하기 위한 것이었다.밀러의 팀은 그들이 실험한 유틸리티의 25-33%를 파괴할 수 있었다.그리고 나서 그들은 원인을 알아내기 위해 각각의 충돌 사고를 디버깅하고 각각의 감지된 고장을 분류했다.다른 연구자가 다른 소프트웨어와 유사한 실험을 할 수 있도록 도구의 소스 코드, 시험 절차 및 원시 결과 데이터를 공개적으로 이용할 수 있도록 하였다.[4]이 초기 솜털은 이제 블랙박스, 세대, 비정형(dumb) 솜털이라고 불릴 것이다.

1990년 이 솜털 논문은 또한 보안에 대한 신뢰성의 관계에 주목했다: "두 번째, 우리가 발견한 버그 중 하나는 인터넷 웜(gets finger)에 보안 구멍 중 하나를 제공한 동일한 프로그래밍 관행에서 비롯되었다.향후 보안 허점을 나타낼 수 있는 버그를 추가로 발견했다.(1988년 11월 모리스 웜 참조)

원래의 솜털 프로젝트는 1995년, 2000년, 2006년 그리고 가장 최근인 2020년에 기여하기 시작했다.

  • 1995:[5] "재방문" 논문은 네 부분으로 구성되었다. (1) 더 다양한 UNIX 시스템과 더 많은 유틸리티를 포함하여 원래의 명령줄 연구를 재현한다.그 연구는 신뢰성이 더 나빠졌다는 것을 보여주었다.이것은 상용 UNIX 시스템보다 훨씬 신뢰성이 높은 오픈 소스 GNU와 리눅스 유틸리티를 포함한 첫 번째 연구였다. (2) X-Windows에서 GUI(윈도우 기반) 애플리케이션의 솜털 테스트를 도입했다.이 연구는 구조화되지 않은 입력 데이터와 구조화된 입력 데이터(마우스와 키보드 이벤트의 유효한 시퀀스)를 모두 사용했다.X-Windows 애플리케이션의 25%를 다운시킬 수 있었다.또한 X-Windows 서버를 시험하여 충돌 시 복원력이 있음을 보여주었다. (3) 네트워크 서비스의 솜털 시험, 다시 구조화된 시험 입력을 바탕으로 도입하였다.이러한 서비스 중 어떤 것도 충돌하지 않았다. (4) 시스템 라이브러리 콜 리턴 값에 대한 무작위 테스트를 도입했으며, 특히 malloc 함수 제품군에서 무작위로 0을 반환했다.거의 절반의 표준 UNIX 프로그램이 그러한 반환값을 제대로 확인하지 못했다.
  • 2000:[6] 최근에 출시된 Windows NT 운영 체제에 솜털 테스트를 적용하여 Win32 창 시스템에서 실행된 응용 프로그램 테스트.그들은 애플리케이션의 21%를 충돌시킬 수 있었고 테스트된 애플리케이션의 24%를 추가로 매달 수 있었다.다시 말하지만, 애플리케이션은 구조화되지 않은 입력과 구조화된 입력(유효한 키보드와 마우스 이벤트)으로 테스트를 진행 중이었고, 테스트한 애플리케이션의 거의 절반은 중단되었다.그들은 그 실패의 원인을 밝혀냈고 그것들이 이전의 연구들과 비슷하다는 것을 발견했다.
  • 2006:[7] 명령줄 및 창 기반 애플리케이션 모두에 대해 Mac OS X에 솜털 테스트 적용.그들은 135개의 명령줄 유틸리티 프로그램을 테스트하여 테스트한 프로그램의 7%를 손상시켰다.게다가, 그들은 MacOS Aqua 윈도우 시스템 아래에서 실행되는 30개의 어플리케이션을 테스트했고, 테스트된 어플리케이션의 73%를 망가뜨렸다.
  • 2020:[8] 가장 최근에, 그들은 기존의 유닉스 시스템, 특히 Linux, FreeBSD 및 MacOS에 고전적인 세대, 블랙박스, 비정형 테스트를 적용하여, 원래의 기법이 여전히 관련이 있는지, 그리고 현재의 유틸리티 프로그램이 이러한 유형의 테스트에 내성을 가지고 있는지 확인하였다.각 플랫폼에서 약 75개의 유틸리티를 테스트했으며, Linux에서 12%, MacOS에서 16%, FreeBSD에서 19%의 고장률을 보였다. (이러한 고장률은 동일한 시스템의 이전 테스트 결과보다 더 나빴다는 점에 유의하십시오.)각 고장을 분석해 분류해보니 포인터와 배열 오류, 반환 코드 확인 안 하는 등 고전적인 고장 범주가 여전히 새 결과에서 광범위하게 존재한다는 사실을 발견했다.또한, 새로운 실패는 입력 크기나 복잡성에 따라 확장되지 않은 복잡한 프로그램 상태와 알고리즘에서 발생하게 된다.그들은 또한 최근 러스트에서 작성된 UNIX 유틸리티를 시험했고, 메모리 오류가 있을 가능성은 낮지만(예상대로) C에서 작성된 유틸리티와 유사한 신뢰성을 가지고 있다는 것을 발견했다.

2012년 4월 구글은 크롬 웹 브라우저의 보안에 중요한 구성요소를 위한 클라우드 기반 솜털 인프라인 ClusterFuzz를 발표했다.[9]ClusterFuzz가 업로드된 솜털과 충돌할 경우 보안 연구원들이 직접 솜털을 업로드하고 버그 현상금을 수집할 수 있다.

9월 2014년에, Shellshock[10]보안 버그들 널리 사용되는 유닉스 배쉬 껍질에;Shellshock의 대부분의 취약성 일부 웹 서버 구축과 같은( 많은Internet-facing 서비스 특정 요청을 처리하는 데 배쉬를 사용한다, 공격자 배쉬의 취약한 버전을 유발할 수 있도록 fuzzer AFL.[11]을 사용한 것을 발견 것으로 밝혀졌다. execu에임의의 명령을 내리다이를 통해 공격자가 컴퓨터 시스템에 대한 무단 액세스를 얻을 수 있다.)[12]

2015년 4월, Hanno Böck는 퍼즐 AFL이 2014 Heartbleed 취약성을 어떻게 찾을 수 있었는지를 보여주었다.[13][14](Heartbleed 취약성은 2014년 4월에 공개되었다.그것은 적들이 그렇지 않으면 암호화된 통신을 해독할 수 있게 하는 심각한 취약점이다.이 취약성은 TLS를 구현하는 OpenSSL에 우연히 유입되어 인터넷 상의 대다수 서버에 의해 사용된다.쇼단은 2016년 4월 23만8000대의 기계가 여전히 취약하다고 보고했으며,[15][16] 2017년 1월 20만 대)

2016년 8월 방위고등연구계획국(DARPA)은 11시간 동안 진행된 완전 자동화 캡쳐-플래그 대회인 제1회 사이버 그랜드 챌린지 결승전을 개최했다.[17]소프트웨어 결함을 실시간으로 발견하고, 활용하고, 수정할 수 있는 자동 방어 시스템을 개발하는 것이 목적이었다.솜털은 상대 소프트웨어의 결함을 발견하기 위한 효과적인 공격 전략으로 사용되었다.취약성 검출 자동화에 엄청난 잠재력을 보였다.우승자는 데이비드 브럼리가 이끄는 ForAllSecure 팀이 개발한 '메이헴'[18]이라는 시스템이었다.

2016년 9월 마이크로소프트는 소프트웨어에서 보안에 중요한 버그를 찾기 위한 클라우드 기반 솜털 테스트 서비스인 프로젝트 스프링필드(Project Springfield)를 발표했다.[19]

2016년 12월, 구글은 몇몇 보안에 중요한 오픈소스 프로젝트를 지속적으로 솜털링할 수 있는 OSS-Fuzz를 발표했다.[20]

블랙햇 2018에서 크리스토퍼 도마스는 프로세서에 숨겨진 RISC 코어의 존재를 드러내기 위해 솜털을 사용하는 것을 시연했다.[21]이 코어는 링 3에서 링 0 명령을 실행하기 위해 기존의 보안 검사를 우회할 수 있었다.

마이크로소프트(MS)는 2020년 9월 소프트웨어 버그 탐지를 자동화하는 자체 호스팅 퍼징(Fuzz) 서비스형 플랫폼 '원퓨즈(OneFuzz)'를 출시했다.[22]윈도우와 리눅스를 지원한다.[23]

조기 무작위 테스트

무작위 입력을 사용한 테스트 프로그램은 데이터가 펀치된 카드에 저장되었던 1950년대로 거슬러 올라간다.[24]프로그래머들은 쓰레기통이나 카드데크에서 뽑은 펀치된 카드를 컴퓨터 프로그램에 입력하기 위해 사용할 것이다.실행으로 원치 않는 행동이 드러나면 버그가 검출된 것이다.

무작위 입력의 실행을 무작위 시험 또는 원숭이 시험이라고도 한다.

1981년에 듀란과 Ntafos는 무작위 입력을 사용한 프로그램 시험의 효과를 공식적으로 조사했다.[25][26]무작위 시험은 프로그램 시험의 가장 나쁜 수단이라고 널리 인식되어 왔지만, 저자들은 그것이 좀 더 체계적인 시험 기법에 대한 비용 효율적인 대안이라는 것을 보여줄 수 있었다.

1983년 애플의 스티브 캅스는 맥페인트와 같은 고전적인 맥 OS 애플리케이션을 위해 임의의 입력을 생성하는 도구인 "The Monkey"[27]를 개발했다.[28]비유적 "원숭이"는 원숭이가 타자기 키보드로 아무렇게나 키를 무한정 때리면 결국 셰익스피어의 작품 전체를 타이핑한다는 무한원숭이 정리를 말한다.시험의 경우, 원숭이는 충돌을 유발하는 입력의 특정 순서를 기록할 것이다.

1991년에는 무작위로 선택한 파라미터로 시스템 호출을 무작위로 실행함으로써 유닉스 및 유닉스 유사 운영체제의 견고성을 시험하기 위한 크래시미 도구가 출시되었다.[29]

종류들

솜털은 다음과 같은 여러 가지 방법으로 분류할 수 있다.[30][1]

  1. 솜털은 입력이 처음부터 생성되는지 또는 기존 입력을 수정하여 생성되는지 여부에 따라 생성 기반 또는 돌연변이 기반일 수 있다.
  2. 퍼즐은 입력 구조를 인지하는지에 따라 벙어리(구조화되지 않음) 또는 스마트(구조화됨)가 될 수 있다.
  3. 퍼즐은 프로그램 구조를 인지하는지에 따라 흰색, 회색 또는 블랙박스가 될 수 있다.

기존 입력 시드의 재사용

돌연변이 기반 솜털은 솜털을 사용하는 동안 종자 입력의 기존 말뭉치를 이용한다.제공된 씨앗을 수정(또는 오히려 변이)하여 입력을 생성한다.[31]예를 들어 이미지 라이브러리 libpng를 솜털로 만들 때 사용자는 유효한 PNG 이미지 파일 집합을 씨앗으로 제공하는 반면 돌연변이 기반 솜털은 이러한 씨앗을 수정하여 각 씨앗의 반유효한 변형을 생성한다.시드 파일의 말뭉치는 수천 개의 잠재적으로 유사한 입력을 포함할 수 있다.자동화된 씨앗 선택(또는 테스트 스위트 축소)을 통해 사용자는 퍼즈 캠페인에서 발견된 총 버그 수를 최대화하기 위해 최상의 씨앗을 선택할 수 있다.[32]

세대 기반 솜털은 처음부터 입력을 생성한다.예를 들어 스마트 생성 기반 퍼저는[33] 사용자가 새로운 입력을 생성하기 위해 제공한 입력 모델을 사용한다.돌연변이 기반 솜털과 달리, 세대 기반 솜털은 종자 입력의 말뭉치의 존재나 품질에 의존하지 않는다.

일부 솜털은 둘 다 할 수 있고, 처음부터 입력을 생성하며, 기존 종자의 돌연변이에 의해 입력을 생성할 수 있다.[34]

입력 구조 인식

일반적으로 솜털은 파일, 키보드 또는 마우스 이벤트의 순서 또는 메시지 순서와 같이 구조화된 입력을 사용하는 프로그램에 대한 입력을 생성하는 데 사용된다.이 구조는 프로그램에 의해 수용되고 처리되는 유효한 입력과 프로그램에 의해 신속하게 거부되는 잘못된 입력을 구별한다.유효한 입력을 구성하는 것은 입력 모델에 명시적으로 명시될 수 있다.입력 모델의 예로는 형식 그래머, 파일 형식, GUI 모델 및 네트워크 프로토콜이 있다.데이터베이스 내용, 공유 메모리, 환경 변수 또는 스레드의 정확한 인터리빙과 같이 일반적으로 입력으로 간주되지 않는 항목도 솜털이 가능하다.효과적인 솜털은 파서로부터 직접 거부되지 않도록 "유효한" 반유효한 입력을 생성하며, 코너 케이스에 스트레스를 주고 흥미로운 프로그램 행동을 할 수 있도록 "유효하지 않은" 입력을 생성한다.

스마트(모델 기반,[34] 문법 기반 [33][35]또는 프로토콜[36] 기반) 퍼저는 입력 모델을 활용하여 유효한 입력의 더 큰 비율을 생성한다.예를 들어 입력을 추상 구문 트리로 모델링할 수 있는 경우, 스마트 돌연변이 기반 퍼즐은[35] 한 노드에서 다른 노드로 전체 하위 트리를 이동하기 위해 무작위 변환을 채택할 것이다.만약 입력을 형식적인 문법으로 모델링할 수 있다면, 스마트 세대 기반의 퍼즐은[33] 문법과 관련하여 유효한 입력을 생성하기 위해 생산 규칙을 인스턴스화할 것이다.그러나 일반적으로 입력 모델은 명시적으로 제공되어야 하며, 이 모델은 독점적이거나, 알려지지 않았거나, 또는 매우 복잡할 때는 하기 어렵다.유효하고 잘못된 입력의 대규모 말뭉치를 사용할 수 있다면, 앙루인의 L* 알고리즘과 같은 문법 유도 기법이 입력 모델을 생성할 수 있을 것이다.[37][38]

벙어리[39][40] 솜털은 입력 모델을 필요로 하지 않으며 따라서 더 다양한 프로그램을 솜털로 만들기 위해 사용될 수 있다.예를 들어 AFL은 무작위 비트를 플립하고, 랜덤 바이트를 "관심" 값으로 대체하며, 데이터 블록을 이동하거나 삭제하여 시드 파일을 수정하는 멍청한 돌연변이 기반 퍼즐이다.그러나 바보 같은 솜털은 프로그램의 주요 구성요소보다는 유효 입력의 낮은 비율을 생성하고 파서 코드를 강조할 수 있다.벙어리 솜털의 단점은 CRC(순환 중복 검사)를 위한 유효한 체크섬의 구성을 통해 설명할 수 있다.CRC는 입력 파일에 포함된 데이터의 무결성이 전송 중에 보존되도록 하는 오류 감지 코드다.체크섬은 입력 데이터를 통해 계산되어 파일에 기록된다.프로그램이 수신된 파일을 처리하고 기록된 체크섬이 재계산된 체크섬과 일치하지 않으면 파일은 유효하지 않은 것으로 거부된다.이제, CRC를 모르는 솜털은 정확한 체크섬을 생성하지 않을 것 같다.그러나, 멍청한 돌연변이 기반 솜털이 보호 데이터를 수정하면 돌연변이 입력에서 잠재적 체크섬을 식별하고 다시 계산하려는 시도가 있다.[41]

프로그램 구조 인식

일반적으로 솜털은 더 높은 수준의 코드 적용범위를 달성할 경우 더 효과적인 것으로 간주된다.근거는, 만약 솜털이 프로그램에서 특정한 구조적 요소를 발휘하지 않는다면, 그것은 또한 이러한 요소들 안에 숨어 있는 버그를 드러낼 수 없다.어떤 프로그램 요소들은 다른 요소들보다 더 중요한 것으로 여겨진다.예를 들어, 사업부 운영자가 0 오류로 분열을 일으키거나 시스템 호출로 프로그램을 중단시킬 수 있다.

블랙박스 퍼즐은[39][35] 프로그램을 블랙박스로 취급하며 내부 프로그램 구조를 알지 못한다.예를 들어 임의로 입력을 생성하는 무작위 시험 도구는 블랙박스 퍼즐로 간주된다.따라서 블랙박스 퍼저는 초당 수백 개의 입력을 실행할 수 있고, 쉽게 병렬화할 수 있으며, 임의 크기의 프로그램으로 확장할 수 있다.그러나 블랙박스 솜털은 표면을 긁어내 '샤로우' 버그를 노출시킬 수 있을 뿐이다.따라서, 입력된 프로그램의 출력을 관찰함으로써 퍼징하는 동안 프로그램의 내부 구조(및 행동)에 대해 점진적으로 학습할 수 있는 블랙박스 퍼즐을 개발하려는 시도가 있다.예를 들어, LearnLib는 웹 애플리케이션의 동작을 나타내는 자동화를 생성하기 위해 능동적인 학습을 사용한다.

화이트박스 퍼저는[40][34] 프로그램 분석을 활용하여 코드 적용 범위를 체계적으로 늘리거나 특정 중요한 프로그램 위치에 도달한다.예를 들어 SAGE는[42] 심볼적 실행을 활용하여 프로그램의 다른 경로를 체계적으로 탐색한다.프로그램 사양을 사용할 수 있는 경우 화이트박스 퍼저는 모델 기반 테스트의 기법을 활용하여 입력을 생성하고 프로그램 사양을 기준으로 프로그램 출력을 확인할 수 있다.화이트박스 퍼즐은 프로그램 깊숙이 숨어있는 버그를 노출시키는데 매우 효과적일 수 있다.그러나 (프로그램 또는 그 규격의) 분석에 사용되는 시간은 엄청나게 길어질 수 있다.흰색 상자 솜털이 입력을 생성하는 데 상대적으로 너무 오래 걸리는 경우, 검은색 상자 솜털이 더 효율적일 것이다.[43]따라서 블랙박스 솜털의 효율성과 화이트박스 솜털의 효과를 결합하려는 시도가 있다.[44]

회색 상자 솜털은 프로그램 분석보다 계측기를 사용하여 프로그램에 대한 정보를 수집한다.예를 들어, AFL과 libFuzzer는 입력에 의해 발휘되는 기본 블록 전환을 추적하기 위해 경량 계측기를 이용한다.이는 합리적인 성능 오버헤드로 이어지지만 솜털 중 코드 커버리지의 증가에 대해 솜털에 알려줌으로써 회색 상자 솜털이 취약성 탐지 도구를 매우 효율적으로 만든다.[45]

사용하다

솜털은 대부분 악의적인 의도로 악용될 수 있는 보안에 중요한 프로그램의 취약점을 노출하기 위한 자동화된 기법으로 사용된다.[9][19][20]더 일반적으로, 솜털은 벌레가 없는 것보다 벌레의 존재를 보여주기 위해 사용된다.버그를 발견하지 않고 몇 주 동안 솜털을 휘두르는 캠페인을 한다고 해서 그 프로그램이 옳다는 것을 증명하는 것은 아니다.[46]결국, 프로그램은 아직 실행되지 않은 입력에 대해 여전히 실패할 수 있다. 모든 입력에 대해 프로그램을 실행하는 것은 엄청나게 비싸다.프로그램이 모든 입력에 대해 올바른지 입증하는 것이 목적이라면, 형식 명세서가 존재해야 하며 형식 방법의 기법을 사용해야 한다.

버그 노출

버그를 노출하기 위해서는 퍼저가 예상된(정상적인) 프로그램 동작과 예상치 못한(버기) 프로그램 동작을 구별할 수 있어야 한다.그러나 기계가 항상 버그와 형상을 구별할 수는 없다.자동 소프트웨어 테스트에서는 이를 테스트 오라클 문제라고도 한다.[47][48]

일반적으로 솜털은 사양이 없을 때 충돌 입력과 충돌하지 않는 입력을 구별하고 단순하고 객관적인 측정을 사용한다.충돌은 쉽게 식별할 수 있으며 잠재적인 취약성(예: 서비스 거부 또는 임의 코드 실행)을 나타낼 수 있다.그러나 충돌이 없다고 해서 취약성이 없는 것은 아니다.예를 들어, 입력으로 인해 버퍼 오버플로가 발생할 때 C로 작성된 프로그램이 충돌하거나 충돌하지 않을 수 있다.오히려 프로그램의 행동이 정의되지 않았다.

충돌 이외의 고장에 더 민감한 솜털을 만들기 위해 세척제를 사용하여 고장이 감지될 때 프로그램을 충돌시키는 주장을 주입할 수 있다.[49][50]버그 종류에 따라 다른 살균제가 있다.

퍼징은 또한 기준 구현이 가능한 경우 "차등" 버그를 감지하는 데 사용될 수 있다.자동 회귀 테스트의 경우 생성된 입력은 동일한 프로그램의 두 가지 버전에서 실행된다.[51]자동화된 차등 시험의 경우,[52] 생성된 입력은 동일한 프로그램의 두 가지 구현(예: lighttpd와 httpd는 모두 웹 서버의 구현임)에서 실행된다.두 변종이 동일한 입력에 대해 서로 다른 출력을 생성하는 경우 하나는 버그가 있을 수 있으므로 좀 더 면밀하게 검사해야 한다.

정적 분석 보고서 유효성 검사

정적 프로그램 분석은 프로그램을 실제로 실행하지 않고 분석한다.이는 도구가 실제로 존재하지 않는 프로그램의 문제를 보고하는 잘못된 긍정으로 이어질 수 있다.동적 프로그램 분석과 함께 솜털을 사용하면 보고된 문제를 실제로 목격하는 입력을 생성할 수 있다.[53]

브라우저 보안

현대의 웹 브라우저는 광범위한 솜털을 가지고 있다.구글 크롬의 크롬 코드는 1만5000개 코어를 보유한 크롬 보안팀이 지속적으로 솜털을 만들어 낸다.[54]Microsoft Edge와 Internet Explorer의 경우 Microsoft는 제품 개발 중에 670 기계 년으로 솜털 테스트를 수행했으며, 10억 HTML 파일에서 4,000억 이상의 DOM 조작을 생성했다.[55][54]

툴체인

솜털은 비교적 짧은 시간에 많은 입력을 생성한다.예를 들어, 2016년 구글 OSS-퍼즈 프로젝트는 일주일에 약 4조개의 투입물을 생산했다.[20]따라서 많은 솜털은 자동화된 고장 유발 입력 생성에 따르는 수동적이고 지루한 작업을 자동화하는 툴체인을 제공한다.

자동 버그 트라이어지

주요 기사:버그 트라이어지

자동화된 버그 트라이지는 많은 수의 고장을 유발하는 입력을 근본 원인에 의해 그룹화하고 각각의 버그를 심각도에 따라 우선순위를 매기는 데 사용된다.솜털은 많은 입력을 발생시키며, 고장을 유발하는 많은 입력을 효과적으로 노출시킬 수 있다.이러한 버그 중 일부만 보안에 중요하므로 우선 순위가 높은 패치를 적용해야 한다.예를 들어, CERT Coordination Center는 리눅스 triage 도구를 제공하여, 생성된 스택 추적에 의해 충돌 입력을 그룹화하고, 악용될 가능성에 따라 각 그룹을 나열한다.[56]MSEC(Microsoft Security Research Centre)는 !explicable 도구를 개발하여 먼저 충돌하는 입력에 대한 해시를 생성하여 고유성을 확인한 다음 취약성 등급을 부여했다.[57]

  • 착취성
  • 아마 착취할 수 있을 것이다.
  • 아마 착취할 수 없거나
  • 알 수 없는

이전에 보고되지 않은, 3종 버그는 자동으로 버그 추적 시스템에 보고될 수 있다.예를 들어 OSS-Fuzz는 이전에 보고되지 않은 구별되는 버그가 버그 트래커에 직접 보고되는 몇몇 보안에 중요한 소프트웨어 프로젝트에 대해 대규모 장기간의 솜털 캠페인을 실시한다.[20]OSS-Fuzz 버그 트래커는 자동으로 유지관리자에게 취약한 소프트웨어를 알려주고, 업로드된 최소 장애 유발 입력을 이용하여 가장 최근의 개정에서 버그가 고정되었는지 정기적으로 점검한다.

자동화된 입력 최소화

자동화된 입력 최소화(또는 테스트 사례 감소)는 고장을 실제로 유발하는 오류를 유발하는 입력의 일부를 분리하기 위한 자동화된 디버깅 기법이다.[58][59]고장을 유발하는 입력이 크고 대부분 기형이라면 개발자가 버그를 정확히 일으키는 것이 무엇인지 이해하기 어려울 수 있다.고장을 유발하는 입력을 고려할 때 자동화된 최소화 도구는 원래의 버그를 재생산하는 동안 가능한 많은 입력 바이트를 제거할 것이다.예를 들어 델타 디버깅은 확장 바이너리 검색 알고리즘을 사용하여 이러한 최소 입력을 찾는 자동화된 입력 최소화 기법이다.[60]

참고 항목

참조

  1. ^ a b John Neystadt (February 2008). "Automated Penetration Testing with White-Box Fuzzing". Microsoft. Retrieved 2009-05-14.
  2. ^ Barton P. Miller (September 1988). "Fall 1988 CS736 Project List" (PDF). Computer Sciences Department, University of Wisconsin-Madison. Retrieved 2020-12-30.
  3. ^ Barton P. Miller; Lars Fredriksen; Bryan So (December 1990). [https:/ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf "An Empirical Study of the Reliability of UNIX Utilities"] (PDF). Communications of the ACM. {{cite journal}}:수표 url=가치(도움말)
  4. ^ "Fuzz Testing of Application Reliability". University of Wisconsin-Madison. Retrieved 2020-12-30.
  5. ^ Barton P. Miller; David Koski; Cjin P. Lee; Vivekananda Maganty; Ravbi Murthy; Ajitkumar Natarajan; Jeff Steidl (April 1995). [https:/ftp.cs.wisc.edu/paradyn/technical_papers/fuzz-revisited.pdf "Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services"] (PDF). Computer Sciences Technical Report #1268, University of Wisconsin-Madison. {{cite journal}}:수표 url=가치(도움말)
  6. ^ Justin Forrester; Barton P. Miller (September 2000). [https:/ftp.cs.wisc.edu/paradyn/technical_papers/fuzz-nt.pdf "An Empirical Study of the Robustness of Windows NT Applications Using Random Testing"] (PDF). 4th USENIX Windows Systems Symposium. {{cite journal}}:수표 url=가치(도움말)
  7. ^ Barton P. Miller; Gregory Cooksey; Fredrick Moore (July 2006). [https:/ftp.cs.wisc.edu/paradyn/technical_papers/Fuzz-MacOS.pdf "An Empirical Study of the Robustness of MacOS Applications Using Random Testing"] (PDF). First International Workshop on Random Testing. {{cite journal}}:수표 url=가치(도움말)
  8. ^ Barton P. Miller; Mengxiao Zhang; Elisa Heymann (2021). "The Relevance of Classic Fuzz Testing:Have We Solved This One?" (PDF). IEEE Transactions on Software Engineering: 1. arXiv:2008.06537. doi:10.1109/TSE.2020.3047766. S2CID 221139874.
  9. ^ a b "Announcing ClusterFuzz". Retrieved 2017-03-09.
  10. ^ Perlroth, Nicole (25 September 2014). "Security Experts Expect 'Shellshock' Software Bug in Bash to Be Significant". The New York Times. Retrieved 25 September 2014.
  11. ^ Zalewski, Michał (1 October 2014). "Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)". lcamtuf's blog. Retrieved 13 March 2017.
  12. ^ Seltzer, Larry (29 September 2014). "Shellshock makes Heartbleed look insignificant". ZDNet. Retrieved 29 September 2014.
  13. ^ Böck, Hanno. "Fuzzing: Wie man Heartbleed hätte finden können (in German)". Golem.de (in German). Retrieved 13 March 2017.
  14. ^ Böck, Hanno. "How Heartbleed could've been found (in English)". Hanno's blog. Retrieved 13 March 2017.
  15. ^ "Search engine for the internet of things – devices still vulnerable to Heartbleed". shodan.io. Retrieved 13 March 2017.
  16. ^ "Heartbleed Report (2017-01)". shodan.io. Retrieved 10 July 2017.
  17. ^ Walker, Michael. "DARPA Cyber Grand Challenge". darpa.mil. Retrieved 12 March 2017.
  18. ^ "Mayhem comes in first place at CGC". Retrieved 12 March 2017.
  19. ^ a b "Announcing Project Springfield". 2016-09-26. Retrieved 2017-03-08.
  20. ^ a b c d "Announcing OSS-Fuzz". Retrieved 2017-03-08.
  21. ^ Christopher Domas (August 2018). "GOD MODE UNLOCKED - Hardware Backdoors in x86 CPUs". Retrieved 2018-09-03.
  22. ^ "Microsoft: Windows 10 is hardened with these fuzzing security tools – now they're open source". ZDNet. September 15, 2020.
  23. ^ "Microsoft open-sources fuzzing test framework". InfoWorld. September 17, 2020.
  24. ^ Gerald M. Weinberg (2017-02-05). "Fuzz Testing and Fuzz History". Retrieved 2017-02-06.
  25. ^ Joe W. Duran; Simeon C. Ntafos (1981-03-09). A report on random testing. Icse '81. Proceedings of the ACM SIGSOFT International Conference on Software Engineering (ICSE'81). pp. 179–183. ISBN 9780897911467.
  26. ^ Joe W. Duran; Simeon C. Ntafos (1984-07-01). "An Evaluation of Random Testing". IEEE Transactions on Software Engineering. IEEE Transactions on Software Engineering (TSE) (4): 438–444. doi:10.1109/TSE.1984.5010257. S2CID 17208399.
  27. ^ Andy Hertzfeld (2004). Revolution in the Valley:The Insanely Great Story of How the Mac Was Made?. O'Reily Press. ISBN 978-0596007195.
  28. ^ "Macintosh Stories: Monkey Lives". Folklore.org. 1999-02-22. Retrieved 2010-05-28.
  29. ^ "crashme". CodePlex. Retrieved 2021-05-21.
  30. ^ Michael Sutton; Adam Greene; Pedram Amini (2007). Fuzzing: Brute Force Vulnerability Discovery. Addison-Wesley. ISBN 978-0-321-44611-4.
  31. ^ Offutt, Jeff; Xu, Wuzhi (2004). "Generating Test Cases for Web Services Using Data Perturbation". Workshop on Testing, Analysis and Verification of Web Services. 29 (5): 1–10. doi:10.1145/1022494.1022529. S2CID 52854851.
  32. ^ Rebert, Alexandre; Cha, Sang Kil; Avgerinos, Thanassis; Foote, Jonathan; Warren, David; Grieco, Gustavo; Brumley, David (2014). "Optimizing Seed Selection for Fuzzing" (PDF). Proceedings of the 23rd USENIX Conference on Security Symposium: 861–875.
  33. ^ a b c Patrice Godefroid; Adam Kiezun; Michael Y. Levin. "Grammar-based Whitebox Fuzzing" (PDF). Microsoft Research.
  34. ^ a b c Van-Thuan Pham; Marcel Böhme; Abhik Roychoudhury (2016-09-07). "Model-based whitebox fuzzing for program binaries". Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering - ASE 2016. Proceedings of Automated Software Engineering (ASE'16). pp. 543–553. doi:10.1145/2970276.2970316. ISBN 9781450338455. S2CID 5809364.
  35. ^ a b c "Peach Fuzzer". Retrieved 2017-03-08.
  36. ^ Greg Banks; Marco Cova; Viktoria Felmetsger; Kevin Almeroth; Richard Kemmerer; Giovanni Vigna. SNOOZE: Toward a Stateful NetwOrk prOtocol fuzZEr. Proceedings of the Information Security Conference (ISC'06).
  37. ^ Osbert Bastani; Rahul Sharma; Alex Aiken; Percy Liang (June 2017). Synthesizing Program Input Grammars. Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2017). arXiv:1608.01723. Bibcode:2016arXiv160801723B.
  38. ^ "VDA Labs - Evolutionary Fuzzing System". Archived from the original on 2015-11-05. Retrieved 2009-05-14.
  39. ^ a b Ari Takanen; Jared D. Demott; Charles Miller (31 January 2018). Fuzzing for Software Security Testing and Quality Assurance, Second Edition. Artech House. p. 15. ISBN 978-1-63081-519-6. 사용 가능한 전체 문서(2018년 9월 19일 자료 보관)
  40. ^ a b Vijay Ganesh; Tim Leek; Martin Rinard (2009-05-16). "Taint-based directed whitebox fuzzing". IEEE. Proceedings of the ACM SIGSOFT International Conference on Software Engineering (ICSE'09).
  41. ^ Wang, T.; Wei, T.; Gu, G.; Zou, W. (May 2010). TaintScope: A Checksum-Aware Directed Fuzzing Tool for Automatic Software Vulnerability Detection. 2010 IEEE Symposium on Security and Privacy. pp. 497–512. CiteSeerX 10.1.1.169.7866. doi:10.1109/SP.2010.37. ISBN 978-1-4244-6894-2. S2CID 11898088.
  42. ^ Patrice Godefroid; Michael Y. Levin; David Molnar (2008-02-08). "Automated Whitebox Fuzz Testing" (PDF). Proceedings of Network and Distributed Systems Symposium (NDSS'08).
  43. ^ Marcel Böhme; Soumya Paul (2015-10-05). "A Probabilistic Analysis of the Efficiency of Automated Software Testing". IEEE Transactions on Software Engineering. 42 (4): 345–360. doi:10.1109/TSE.2015.2487274. S2CID 15927031.
  44. ^ Nick Stephens; John Grosen; Christopher Salls; Andrew Dutcher; Ruoyu Wang; Jacopo Corbetta; Yan Shoshitaishvili; Christopher Kruegel; Giovanni Vigna (2016-02-24). Driller: Augmenting. Fuzzing Through Selective Symbolic Execution (PDF). Proceedings of Network and Distributed Systems Symposium (NDSS'16).
  45. ^ Marcel Böhme; Van-Thuan Pham; Abhik Roychoudhury (2016-10-28). "Coverage-based Greybox Fuzzing as Markov Chain". Coverage-based Greybox Fuzzing as a Markov Chain. Proceedings of the ACM Conference on Computer and Communications Security (CCS'16). pp. 1032–1043. doi:10.1145/2976749.2978428. ISBN 9781450341394. S2CID 3344888.
  46. ^ Hamlet, Richard G.; Taylor, Ross (December 1990). "Partition testing does not inspire confidence". IEEE Transactions on Software Engineering. 16 (12): 1402–1411. doi:10.1109/32.62448.
  47. ^ Weyuker, Elaine J. (1 November 1982). "On Testing Non-Testable Programs". The Computer Journal. 25 (4): 465–470. doi:10.1093/comjnl/25.4.465.
  48. ^ Barr, Earl T.; Harman, Mark; McMinn, Phil; Shahbaz, Muzammil; Yoo, Shin (1 May 2015). "The Oracle Problem in Software Testing: A Survey" (PDF). IEEE Transactions on Software Engineering. 41 (5): 507–525. doi:10.1109/TSE.2014.2372785. S2CID 7165993.
  49. ^ "Clang compiler documentation". clang.llvm.org. Retrieved 13 March 2017.
  50. ^ "GNU GCC sanitizer options". gcc.gnu.org. Retrieved 13 March 2017.
  51. ^ Orso, Alessandro; Xie, Tao (2008). BERT: BEhavioral Regression Testing. Proceedings of the 2008 International Workshop on Dynamic Analysis (WODA 2008). ACM. pp. 36–42. doi:10.1145/1401827.1401835. ISBN 9781605580548. S2CID 7506576.
  52. ^ McKeeman, William M. (1998). "Differential Testing for Software" (PDF). Digital Technical Journal. 10 (1): 100–107.
  53. ^ Babić, Domagoj; Martignoni, Lorenzo; McCamant, Stephen; Song, Dawn (2011). Statically-directed Dynamic Automated Test Generation. Proceedings of the 2011 International Symposium on Software Testing and Analysis. ACM. pp. 12–22. doi:10.1145/2001420.2001423. ISBN 9781450305624. S2CID 17344927.
  54. ^ a b Sesterhenn, Eric; Wever, Berend-Jan; Orrù, Michele; Vervier, Markus (19 Sep 2017). "Browser Security WhitePaper" (PDF). X41D SEC GmbH.
  55. ^ "Security enhancements for Microsoft Edge (Microsoft Edge for IT Pros)". Microsoft. 15 Oct 2017. Retrieved 31 August 2018.
  56. ^ "CERT Triage Tools". CERT Division of the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU). Retrieved 14 March 2017.
  57. ^ "Microsoft !exploitable Crash Analyzer". CodePlex. Retrieved 14 March 2017.
  58. ^ "Test Case Reduction". 2011-07-18.
  59. ^ "IBM Test Case Reduction Techniques". 2011-07-18. Archived from the original on 2016-01-10. Retrieved 2011-07-18.
  60. ^ Zeller, Andreas; Hildebrandt, Ralf (February 2002). "Simplifying and Isolating Failure-Inducing Input". IEEE Transactions on Software Engineering. 28 (2): 183–200. CiteSeerX 10.1.1.180.3357. doi:10.1109/32.988498. ISSN 0098-5589. Retrieved 14 March 2017.

추가 읽기

외부 링크