[Dev] TOCTOU (Time of check to time of use)문제란 무엇인가?

 

Java List의 컬렉션 팩토리 메서드인 of를 살펴보던 중 내부 코드에서 흥미로운 코멘트를발견했다.

 

아래 Java 코드를 보자.

 

comment like:

// copy and check manually to void TOCTOU ?

 

    /**
     * Creates a new List from an untrusted array, creating a new array for internal
     * storage, and checking for and rejecting null elements.
     *
     * @param <E> the List's element type
     * @param input the input array
     * @return the new list
     */
    @SafeVarargs
    static <E> List<E> listFromArray(E... input) {
        // copy and check manually to avoid TOCTOU
        @SuppressWarnings("unchecked")
        E[] tmp = (E[])new Object[input.length]; // implicit nullcheck of input
        for (int i = 0; i < input.length; i++) {
            tmp[i] = Objects.requireNonNull(input[i]);
        }
        return new ListN<>(tmp, false);
    }

 

 

여기서 TOCTOU 문제라는 것이 무엇일까 궁금해서 찾아보았다.

 

내가 File을 오픈하는 코드를 작성한다고 생각하자.

 

File접근 권한이 있는지 혹은 File이 정상인지 등 체크하는 Access로직이 앞단에 있을것이고, 이후 내가 실제 File을 Open하여 Write

하는 로직이 뒤에 나올 것이다.

 

1. Access

2. Write

 

그런데 여기서 1, 2사이에 Attacker가 내가 참조하려는 File의 위치를 바꾸거나 하는 등의 명령을 실행한다면? 나는 2. Write시에 내가 원하는 동작이 아닌 무언가 잘못된 것을 하게 될 것이다.

즉 굳이 Attacker가 아니더라도 race condition에 의해서 내가 Write시 하려는 동작에서의 파일이 무언가 바뀌게 될 가능성이 있다는 것이다. 이 software bug를 TOCTOU라고 부른다.

 

따라서 위 Java코드를 보면 copy를 해서 모두 비교하는 로직을 담고 있다. copy를 해서 복사본을 하나 더 만들어서 (외부의 요인으로 바뀌지 않는 List를 만들어서) 비교를 하는 것이다.

 

참고로 이 방지를 위해 여러 방안이 논의되었다고 한다. file system에 Transaction을 도입한다던지, 마소에 도입했다는데 권장하지 않으며 이후 feature에서 빠질 가능성이 있다고 언급되었다고 한다.

 

 

 

TOCTOU에 대한 좀 더 자세한 설명은 아래 wikipedia를 참고하자.

https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use