사용 시간 확인
Time-of-check to time-of-use소프트웨어 개발에서 체크타임오브유즈(TOCTOU, TOCTOU 또는 TOC/TOU)는 시스템 일부(보안 자격 증명 등) 상태를 체크하고 그 체크 결과를 사용하는 레이스 조건에 의해 발생하는 소프트웨어 버그 클래스입니다.
TOCTOU 레이스 조건은 UNIX에서 [1]파일시스템상의 조작간에 공통적이지만 로컬소켓이나 데이터베이스 트랜잭션의 부적절한 사용 등 다른 컨텍스트에서 발생할 수 있습니다.1990년대 초에 BSD 4.3 UNIX의 메일 유틸리티는 임시 파일에 대한 악용 가능한 경쟁 조건을 가지고 있었습니다.이는 BSD 4.3 UNIX가mktemp()
[2] 기능합니다.[3]OpenSSH의 이전 버전에서는 Unix [4]도메인 소켓에 대한 부정 이용 가능한 레이스 조건이 있었습니다.그것들은 현대 시스템에서 여전히 문제로 남아 있습니다. 2019년 현재 도커의 TOCTOU 레이스 조건은 호스트 [5]플랫폼의 파일 시스템에 대한 루트 액세스를 허용합니다.
예
이 섹션은 어떠한 출처도 인용하지 않습니다.(2022년 7월 (이 를 에 대해 학습합니다) |
Unix 에서는, 다음의 C 코드(사용 시)setuid
프로그램에 TOCTOU 버그가 있습니다.
한다면 (접근("파일, W_OK) != 0) { 퇴장(1); } fd = 열다.("파일, O_WR만); 쓰다(fd, 완충 장치, 크기(완충 장치));
여기에서는, 액세스의 목적은, 실제의 유저가 다음의 작업을 실행했는지 아닌지를 확인하는 것입니다.setuid
일반적으로 프로그램에서는 파일 쓰기가 허용됩니다(즉,access
는 유효 사용자 ID가 아닌 실제 사용자 ID를 체크합니다).
이 레이스 상태는 공격에 취약합니다.
피해자. | 공격자 |
한다면 (접근("파일, W_OK) != 0) { 퇴장(1); } fd = 열다.("파일, O_WR만); // 실제로 /etc/passwd에 쓰는 중 쓰다(fd, 완충 장치, 크기(완충 장치)); | // // // 접근 확인 후 심볼링크("/etc/passwd", "파일); // 열기 전에 "파일"이 암호 데이터베이스를 가리킵니다. // // |
이 예에서는 공격자는 이 네트워크 간의 레이스 조건을 부정 이용하는 경우가 있습니다.access
그리고.open
속이다setuid
공격 대상자가 시스템 비밀번호 데이터베이스의 엔트리를 덮어쓰도록 합니다.TOCTOU 레이스는 권한 상승에 사용할 수 있으며 머신에 대한 관리 액세스 권한을 얻을 수 있습니다.
이 일련의 이벤트는 정확한 타이밍을 필요로 하지만 공격자는 큰 어려움 없이 이러한 조건을 조정할 수 있습니다.
즉, 운영체제에 의해 관리되는 상태(이 경우 파일 시스템 이름 공간)가 시스템 호출 간에 변경되지 않는다고 가정할 수 없습니다.
신뢰할 수 있는 타이밍의 TOCTOU
TOCTOU 레이스 조건을 부정 이용하는 경우는, 공격자의 조작이 공격 대상자의 조작과 적절히 인터리브 할 수 있도록 정확한 타이밍이 필요합니다.위의 예에서 공격자는 다음 명령어를 실행해야 합니다.symlink
사이의 정확한 시스템 호출access
그리고.open
가장 일반적인 공격의 경우 공격자는 공격 대상자의 각 작업 후에 실행되도록 스케줄링해야 합니다. 이를 "싱글 스테핑"이라고도 합니다.
BSD 4.3 메일 유틸리티의 경우mktemp()
공격자는 한 프로세스에서 메일 유틸리티를 계속 실행하고 임시 파일 이름을 계속 추측하고 다른 프로세스에서 심볼 링크를 계속 만들 수 있습니다.[2]공격은 보통 1분 이내에 성공할 수 있습니다.
피해자 프로그램을 싱글스텝하는 기술에는 파일 시스템[6] 미로와 알고리즘 복잡성 [7]공격이 포함됩니다.어느 경우든 공격자는 공격 대상자의 스케줄링을 제어하기 위해 OS 상태를 조작합니다.
파일 시스템 미로는 공격 대상자가 OS 캐시에 없는 디렉토리 엔트리를 읽도록 강제하고 OS는 공격 대상자가 디스크에서 디렉토리를 읽을 때 sleep 상태로 만듭니다.알고리즘 복잡도 공격은 공격 대상자가 캐시된 파일 이름의 커널 해시 테이블을 통과하는 단일 시스템 호출 내에서 전체 스케줄링 퀀텀을 소비하도록 합니다.공격자는 공격 대상자가 조회할 파일과 동일한 값으로 해시되는 이름을 가진 파일을 매우 많이 만듭니다.
TOCTOU 방지
개념적인 단순함에도 불구하고, TOCTOU 경주 조건은 피하고 없애기가 어렵습니다.한 가지 일반적인 기술은 사전 점검 대신 오류 처리를 사용하는 것입니다. EAFP의 철학에 따라 "허락보다 용서를 구하는 것이 더 쉽다" (LBIL: "도약하기 전에 살펴보기") 이 경우 점검은 없으며 보류 가정 실패는 오류가 [8]반환됨으로써 신호를 보냅니다.
파일 시스템의 TOCTOU 레이스 조건의 경우, 기본적인 과제는 2개의 시스템 호출 간에 파일 시스템을 변경할 수 없도록 하는 것입니다.2004년에는 TOCTOU 레이스 조건을 [9]회피하기 위한 휴대용 결정론적 기술이 없다는 불가능한 결과가 발표됐다.
이 불가능한 결과로부터, 파일 기술자를 추적하고 정확성을 보장하기 위한 라이브러리가 [10]연구자들에 의해 제안되었습니다.
연구 커뮤니티에서 제안된 대안 솔루션은 UNIX 시스템이 파일 시스템 또는 OS 커널에서 트랜잭션을 채택하는 것입니다.트랜잭션은 OS에 대한 동시성 제어 추상화를 제공하며 TOCTOU 레이스를 방지하는 데 사용할 수 있습니다.아직 트랜잭션을 채택한 프로덕션 UNIX 커널은 없지만 Valor 파일[11] 시스템과 TxOS [12]커널을 포함한 개념 증명 연구 프로토타입을 Linux용으로 개발했습니다.Microsoft Windows는 NTFS 파일 시스템에 [13]트랜잭션을 추가했지만 Microsoft는 트랜잭션을 사용하지 않도록 권장하고 있으며 향후 Windows 버전에서 [14]트랜잭션이 제거될 수 있음을 시사했습니다.
파일 잠금은 단일 파일의 레이스 조건을 방지하기 위한 일반적인 기술이지만 파일 시스템 이름 공간 및 기타 메타데이터로 확장되지 않으며 네트워크 파일 시스템에서 잠금이 제대로 작동하지 않으며 TOCTOU 레이스 조건을 방지할 수 없습니다.
setuid 바이너리의 경우 가능한 해결책은seteuid()
시스템 콜을 실행하여 유효 사용자를 변경한 후open()
의 차이점setuid()
operating system간에 문제가 [15]있을 수 있습니다.
「 」를 참조해 주세요.
레퍼런스
- ^ Wei, Jinpeng; Pu, Calton (December 2005). "TOCTTOU Vulnerabilities in UNIX-Style File Systems: An Anatomical Study". USENIX. Retrieved 2019-01-14.
- ^ a b "mktemp(3)". Linux manual page. 2017-09-15.
- ^ Shangde Zhou(周尚德) (1991-10-01). "A Security Loophole in Unix". Archived from the original on 2013-01-16.
- ^ Acheson, Steve (1999-11-04). "The Secure Shell (SSH) Frequently Asked Questions". Archived from the original on 2017-02-13.
- ^ "Docker Bug Allows Root Access to Host File System". Decipher. Duo Security. Retrieved 2019-05-29.
- ^ Borisov, Nikita; Johnson, Rob; Sastry, Naveen; Wagner, David (August 2005). "Fixing races for fun and profit: how to abuse atime". Proceedings of the 14th Conference on USENIX Security Symposium. Baltimore, MD. 14: 303–314. CiteSeerX 10.1.1.117.7757.
{{cite journal}}
: CS1 유지보수: 날짜 및 연도(링크) - ^ Xiang Cai; Yuwei Gui; Johnson, Rob (May 2009). "Exploiting Unix File-System Races via Algorithmic Complexity Attacks" (PDF). Proceedings of the IEEE Symposium on Security and Privacy. Berkeley, CA: 27–41. doi:10.1109/SP.2009.10. ISBN 978-0-7695-3633-0. S2CID 6393789.
- ^ Martelli, Alex (2006). "Chapter 6: Exceptions". Python in a Nutshell (2 ed.). O'Reilly Media. p. 134. ISBN 978-0-596-10046-9.
- ^ Dean, Drew; Hu, Alan J. (August 2004). "Fixing Races for Fun and Profit: How to use access(2)". Proceedings of the 13th USENIX Security Symposium. San Diego, CA): 195–206. CiteSeerX 10.1.1.83.8647.
{{cite journal}}
: CS1 유지보수: 날짜 및 연도(링크) - ^ Tsafrir, Dan; Hertz, Tomer; Wagner, David; Da Silva, Dilma (June 2008). "Portably Preventing File Race Attacks with User-Mode Path Resolution". Technical Report RC24572, IBM T. J. Watson Research Center. Yorktown Heights, NY.
- ^ Spillane, Richard P.; Gaikwad, Sachin; Chinni, Manjunath; Zadok, Erez (February 24–27, 2009). "Enabling Transactional File Access via Lightweight Kernel Extensions" (PDF). Seventh USENIX Conference on File and Storage Technologies (FAST 2009). San Francisco, CA.
{{cite web}}
: CS1 유지보수: 날짜 및 연도(링크) - ^ Porter, Donald E.; Hofmann, Owen S.; Rossbach, Christopher J.; Benn, Alexander; Witchel, Emmett (October 11–14, 2009). "Operating System Transactions" (PDF). Proceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP '09). Big Sky, MT.
{{cite web}}
: CS1 유지보수: 날짜 및 연도(링크) - ^ Russinovich, Mark; Solomon, David A. (2009). Windows Internals. Microsoft Press. ISBN 978-0735648739.
- ^ "Alternatives to using Transactional NTFS". Microsoft Developer Network. Retrieved 10 December 2015.
- ^ Hao Chen; Wagner, David; Dean, Drew (2002-05-12). "Setuid Demystified" (PDF).
추가 정보
- Bishop, Matt; Dilger, Michael (1996). "Checking for Race Conditions in File Accesses" (PDF). Computing Systems. pp. 131–152.
- Tsafrir, Dan; Hertz, Tomer; Wagner, David; Da Silva, Dilma (2008). "Portably Solving File TOCTTOU Races with Hardness Amplification" (PDF). Proceedings of the 6th USENIX Conference on File and Storage Technologies (FAST '08), San Jose (CA), February 26–29, 2008. pp. 189–206.