CWLog - rust

TOCTOU 취약점

2026-05-06T00:00:00+00:00

근래에 긱뉴스(GeekNews)에서 재밌는 글을 봤다: https://news.hada.io/topic?id=29027

안전한 러스트에서 시스템적인 결함까지는 안전하게 처리해주진 못한다. 라는 내용이다.

TOCTOU (Time-of-Check to Time-of-Use)#</a> </h2>

우선 TOCTOU란 단어 그대로 상태를 검사하는 시점과 그 결과를 바탕으로 실제 사용하는 시점 사이에 틈이 생겨 발생하는 취약점이다. 해당 취약점은 프로세스 간 환경이나 멀티 스레드 환경에서 일어나기 쉽다.

발생 원리는 다음과 같이 일어난다.

프로그램이 특정 조건이 안전한지 또는 유효한지 확인한다. (예: 이 파일이 존재하는가?, 이 파일에 쓰기 권한이 있는가?)</li>
검사가 끝난 직후에 프로그램이 다음 코드를 실행하기 전 엄청 짧은 틈이 생긴다. 이때 공격자나 다른 프로세스가 개입하여 상태를 바꾼다. (예: 심볼릭 링크로 일반 파일을 관리자 권한이 필요한 중요한 시스템 파일로 바꿔치기)</li>

프로그램은 1번의 검사 결과가 유효하다고 가정하고 작업을 수행한다. 하지만 이미 상태가 변경되었기 때문에 의도치 않은 동작이 발생한다.</li> </ol>

예시를 보자

use</span> std</span>::</span>path</span>::</span>Path</span>;</span></span>
use</span> std</span>::</span>fs</span>::</span>File</span>;</span></span>
</span>
let</span> path</span> =</span> Path</span>::</span>new</span>(</span>"</span>temp.txt</span>"</span>)</span>;</span></span>
</span>
//</span> 1. 파일이 있는지 확인</span></span>
if</span> path</span>.</span>exists</span>(</span>)</span> {</span></span>
    //</span> 다른 프로세스가 temp.txt를 지우고, </span></span>
    //</span> 동일한 이름으로 /etc/shadow를 가리키는 심볼릭 링크를 생성한다고 가정</span></span>
    </span></span>
    //</span> 2. 파일 열기</span></span>
    //</span> 프로그램은 안전하다고 가정하고 열었지만, 실제로는 시스템 파일을 건드리게 됨</span></span>
    let</span> mut</span> file</span> =</span> File</span>::</span>open</span>(</span>&</span>path</span>)</span>.</span>unwrap</span>(</span>)</span>;</span> </span></span>
    //</span> todo..</span></span>
}</span></span></code></pre>
대강 위와 같이 진행된다.</p>
위쪽에 레퍼런스한 글을 보면 std::fs</code>가 유닉스 기반의 File Descriptor</code> 기반이 아니라 문자열 기반이라 TOCTOU를 일으키기 너무 쉽다는 점을 지적한다.</p>
흠 근데 개인적으로 이건 '러스트' 뿐만 아니라 도구를 어떤식으로 제공해줄 건지에 따른 언어의 철학에 따라 갈린다고 생각한다. 따라서 러스트를 타겟팅해서 까는 건 약간 이해가 안 간다.</p>
뭐 외에도 다른 여러 지적이 있는데, CLI 툴에서 에러 코드를 제대로 안 내고 패닉나서 이를 이용해서 작업을 성공하게 착각시킬 수도 있다고도 하고..</p>
사실 프로그램 설계자측 문제라고 생각한다.</p>
뭐 그래서 이것들을 근거로 급진적으로 러스트 도구들을 넣고있는 우분투를 비판하는 내용이다.</p>


러스트의 HRTB
2026-04-21T00:00:00+00:00
HRTB는 Higher-Rank Trait Bound</code>의 약자다. 기존 라이프타임의 한계를 해결하기 위해 만들어진 문법이다. 예를 들면 다음과 같은 상황과 같다:</p>
fn</span> foo</span><</span>'</span>a</span>,</span> F</span>></span>(</span>closure</span>:</span> F</span>)</span></span>
where</span></span>
    F</span>:</span> Fn</span>(</span>&</span>'</span>a</span> i32</span>)</span>,</span></span>
{</span></span>
    let</span> bar</span> =</span> 42</span>;</span></span>
    </span></span>
    closure</span>(</span>&</span>bar</span>)</span>;</span> //</span> Compile errors here</span></span>
}</span></span></code></pre>
보통 클로저에 참조를 넘겨야할 때 이런 이슈를 꽤 자주 마주친다. 지금 보면 인자 foo</code>가 Fn(&'a i32)</code> 함수 타입 트레잇을 받고 있다. 위 코드를 컴파일해보면 에러가 난다.</p>
위 코드가 왜 에러가 나냐면, 러스트 컴파일러에서 참조 라이프타임을 추론할 때 caller의 라이프타임을 적용시킨다. main</code> 함수에서 foo를 호출했다고 하자. 그럼 &'a</code> 라이프타임은 자연스럽게 main</code> 스코프와 같은 수명을 갖게된다. 즉, 지역 참조인 &bar</code>의 수명이 성립이 안되는 거다. (main</code>보다 빨리 드랍된다.)</p>
그래서 해결책으로 HRTB</strong>를 사용한다.</p>
fn</span> foo</span><</span>F</span>></span>(</span>closure</span>:</span> F</span>)</span></span>
where</span></span>
    F</span>:</span> for</span><</span>'</span>a</span>></span> Fn</span>(</span>&</span>'</span>a</span> i32</span>)</span>,</span></span>
{</span></span>
    let</span> bar</span> =</span> 42</span>;</span></span>
    closure</span>(</span>&</span>bar</span>)</span>;</span></span>
}</span></span></code></pre>
위와 같이 작성할 수 있다. 차이점은 아까 코드와 다르게 제네릭 정의에 함수에 붙지 않고 F에 직접 for<'a></code> 문법으로 바인딩해준다..</p>
이게 무슨 말이냐면 선언하는 주체를 F</code>에게 넘기곘다는 것이다. 즉 기존엔 caller가 라이프타임의 수명을 정했지만 이젠 F</code>가 정한다는 것이다. 사실상 뭐가 들어오든 상관 없는 셈.</p>
이름이 Higher-Rank</code>인 이유도 여기서 나온다. 일반적인 라이프타임 정의는 rank-1, 즉 함수 시그니처 바깥에 있고 위와 같은 바인딩은 trait bound 안쪽, 즉 rank-2가 된다.</p>

참조</strong></p>

https://rust-lang.github.io/rfcs/0387-higher-ranked-trait-bounds.html</a></li>
https://www.rustfinity.com/blog/higher-rank-trait-bounds</a></li>
</ul>


러스트의 Pin
2026-04-06T00:00:00+00:00
러스트에서 범용적인 애플리케이션 코드를 작성할 때는 잘 쓰이지 않는 메모리 고정 Pin</code>에 대해서 알아보자.</p>
일반적인 상황에서는 별로 접할 기회가 없지만, 러스트의 핵심 동작을 이해하려면 반드시 짚고 넘어가야 하는 개념이다. 보통 이 Pin</code>을 마주치게 되는 케이스는 크게 두 가지다.</p>

비동기 (async/await</code>) 생태계</li>
극단적인 성능 최적화 (e.g Zero Allocation Something)</li>
</ol>
우선 비동기부터 빠르게 알아보자.</p>
비동기에서의 Pin</code>#</a>
</h2>
좀 복잡하다. 러스트의 비동기 동작 원리를 이해해야 Pin</code>이 왜 필요한지 알 수 있다. 예를 들어 다음과 같은 비동기 함수가 있다고 가정하자:</p>
async</span> fn</span> foo</span>(</span>)</span> {</span></span>
    let</span> mut</span> buffer</span> =</span> [</span>0</span>u8</span>;</span> 2048</span>]</span>;</span></span>
    let</span> ptr</span> =</span> &</span>mut</span> buffer</span>;</span></span>
    </span></span>
    some_io_action</span>(</span>ptr</span>)</span>.</span>await</span>;</span></span>
    </span></span>
    println!</span>(</span>"</span>bar</span>"</span>)</span>;</span></span>
}</span></span></code></pre>
비동기 함수 내부를 보면, ptr</code>이 동일한 스택 내의 buffer</code>를 가리키는 자기 참조(Self-referential)</strong> 구조를 띠고 있다.</p>
컴파일러는 이 async</code> 블록을 다음과 같은 상태 머신(State Machine)으로 변환한다 (이해를 돕기 위한 의사 코드, 실제로는 Gen된 코드가 더 복잡하다):</p>
enum</span> FooStateMachine</span> {</span></span>
    Start</span>,</span></span>
    //</span> await 지점의 상태를 저장</span></span>
    YieldedAtSomeIo</span> {</span></span>
        buffer</span>:</span> [</span>0</span>u8</span>;</span> 2048</span>]</span>,</span></span>
        ptr</span>:</span> *</span>mut</span> [</span>0</span>u8</span>;</span> 2048</span>]</span>,</span> //</span> 구조체 내부의 buffer를 가리키는 자기 참조</span></span>
    }</span>,</span></span>
    Done</span>,</span></span>
}</span></span></code></pre>
만약 이 foo</code> 상태 머신 객체 자체가 메모리상에서 다른 곳으로 이동(Move)되면 어떻게 될까? buffer</code>의 메모리 주소는 새로운 곳으로 바뀌지만, ptr</code>은 여전히 옛날 주소를 가리키고 있을 것이다. 이 상태에서 ptr</code>을 참조하면 UB가 발생한다.</p>
예를 들어 Vec</code> 내에 Future</code>를 넣는다고 가정해 보자.</p>
let</span> mut</span> foo</span> =</span> Vec</span>::</span>new</span>(</span>)</span>;</span></span>
</span>
//</span> 작업 큐에 비동기 작업을 넣음</span></span>
foo</span>.</span>push</span>(</span>bar</span>(</span>)</span>)</span>;</span></span>
foo</span>[</span>0</span>]</span>.</span>poll</span>(</span>)</span>;</span> //</span> 첫 번째 작업 실행 내부적으로 참조 포인터 생성됨</span></span>
</span>
//</span> 새로운 작업이 들어와서 벡터의 용량(Capacity)이 초과됨</span></span>
foo</span>.</span>push</span>(</span>bar</span>(</span>)</span>)</span>;</span> </span></span>
</span>
//</span> 메모리 재배치가 일어난 후 다시 poll을 시도하면 UB</span></span>
foo</span>[</span>0</span>]</span>.</span>poll</span>(</span>)</span>;</span></span></code></pre>
벡터는 용량이 꽉 차면 더 큰 메모리를 할당받아 기존 요소들을 통째로 새로운 주소로 재배치(Reallocation)한다. 이때 자기 참조 포인터들이 모두 망가진다.</p>
그럼 단순히 Box</code>로 감싸서 힙에 올리면 원본 데이터는 이동하지 않으니까 문제가 없지 않나? 라고 생각할 수 있다. 절반은 맞다. 하지만 Box<T></code>는 내부 데이터에 대한 순수한 가변 참조자(&mut T</code>)를 제공한다. 악의적이거나 실수로 누군가 std::mem::swap(&mut box1, &mut box2)</code>를 때려버리면 힙 위에서도 내부 데이터가 뒤바뀌며 프로그램이 터질 것이다.</p>
그래서 러스트는 Pin<P></code>이라는 구조체를 제공한다. 이건 마법이 아니라, **개발자가 순수한 &mut T</code>를 마음대로 빼내지 못하게 막아버리는 포인터 래퍼(Wrapper)**다. 이게 Future</code> 트레잇의 poll</code> 메서드가 &mut Self</code> 대신 Pin<&mut Self></code>를 인자로 받는 이유다.</p>

Pin</code>의 핵심 동작 원리#</a>
</h2>
최적화 기법을 보기 전에, Pin</code> 자체가 어떻게 동작하는지 톺아보자.</p>
Pin 자체는 이동할 수 있다#</a>
</h3>
헷갈리는 부분인데, Pin</code> 구조체 자체는 자유롭게 이동 가능한 Unpin</code> 타입이다.</strong> Pin<&mut T></code>를 함수 인자로 넘기거나 변수에 재할당하는 행위는 메모리 주소를 담고 있는 8바이트짜리 wrapper를 넘겨주는 것일 뿐이다. 이리저리 move 돼도 결국 가리키는 T</code>의 메모리 주소는 절대 변하지 않는다.</p>
Pin::new</code>와 Pin::new_unchecked</code>#</a>
</h3>
어떤 데이터를 Pin</code>으로 묶을 때는 두 가지 방법이 있다.</p>

Pin::new</code> (safe):</strong> 대상이 Unpin</code> 타입(예: i32</code>, String</code>, 평범한 구조체)일 때만 쓸 수 있다. 애초에 메모리에서 이동해도 아무 문제 없는 타입들이라 컴파일러가 Auto Impl 해준다.</li>
Pin::new_unchecked</code> (unsafe):</strong> 대상이  이동하면 안 되는 !Unpin</code> 타입(예: Future</code>나 아래에서 다룰 침투형 노드)일 때 사용한다. 컴파일러가 안전을 보장할 수 없다.  unsafe</code> 블록을 열고 개발자가 보장의 책임을 져야 한다.</li>
</ol>

극단적인 최적화: 침투형 연결 리스트#</a>
</h2>
이제 극단적인 최적화 케이스에서 Pin</code>이 어떻게 활용되는지 알아보자. 할당 비용을 빡세게 최적화한 **침투형 연결 리스트(Intrusive Linked List)**가 예시로 꼽을 수 있겠다.</p>
일반적인 Linked List</code>는 보통 다음과 같이 구현된다.</p>
struct</span> Node</span><</span>T</span>></span> {</span></span>
    data</span>:</span> T</span>,</span></span>
    prev</span>:</span> *</span>mut</span> Node</span><</span>T</span>></span>,</span></span>
    next</span>:</span> *</span>mut</span> Node</span><</span>T</span>></span>,</span></span>
}</span></span></code></pre>
노드가 하나 추가될 때마다 힙 할당(Box::new</code> 등)이 발생한다. 비용적으로 별로 좋지 않기 때문에 아래와 같은 침투형 연결 리스트를 사용할 수 있다.</p>
use</span> std</span>::</span>marker</span>::</span>PhantomPinned</span>;</span></span>
use</span> std</span>::</span>pin</span>::</span>Pin</span>;</span></span>
</span>
struct</span> ListLink</span> {</span></span>
    prev</span>:</span> *</span>mut</span> ListLink</span>,</span></span>
    next</span>:</span> *</span>mut</span> ListLink</span>,</span></span>
}</span></span>
</span>
struct</span> Order</span> {</span></span>
    price</span>:</span> u64</span>,</span></span>
    link</span>:</span> ListLink</span>,</span></span>
    </span></span>
    //</span> 컴파일러에게 이 타입은 이동 불가(!Unpin)임을 알림</span></span>
    _marker</span>:</span> PhantomPinned</span>,</span> </span></span>
}</span></span></code></pre>
여기서 PhantomPinned</code>라는 마커 타입이 나온다.</p>
현재 Stable Rust에서는 impl !Unpin for Order {}</code> 처럼 명시적인 Negative Impl 문법을 지원하지 않는다. 그래서 러스트에서 지원해주는 !Unpin</code>인 PhantomPinned</code> 더미 필드를 집어넣어서 구조체 전체를 전염시켜 강제로 !Unpin</code> 타입으로 만드는 꼼수를 쓴다.</p>
구조체가 !Unpin</code>이 되면, 안전한 Rust 내에서는 절대 Pin</code>을 벗겨내고 &mut Order</code>를 가져올 수 없다. 즉, 누군가 std::mem::swap</code>으로 주문을 섞어버리는 것을 원천 차단한다. 실제로 마커 타입 넣고 std::mem::swap</code> 돌려보면 Unpin</code> 트레잇을 만족하지 않는다면서 컴파일 삐꾸낸다.</p>
리스트를 순회할 때 Order</code>의 포인터가 아니라 내부 필드인 ListLink</code>의 포인터를 얻게 된다. 원본 Order</code> 객체를 다루려면 포인터 역산을 해야 한다. 다행히 러스트 1.77부터 offset_of!</code> 매크로를 지원하여 일일이 바이트를 계산할 필요가 없어졌다.</p>
use</span> std</span>::</span>mem</span>::</span>offset_of</span>;</span></span>
</span>
impl</span> ListLink</span> {</span></span>
    unsafe</span> fn</span> get_parent</span>(</span>&</span>self</span>)</span> -></span> *</span>mut</span> Order</span> {</span></span>
        //</span> 포인터 주소 구하기</span></span>
        let</span> link_ptr</span> =</span> self</span> as</span> *</span>const</span> ListLink</span> as</span> *</span>const</span> u8</span>;</span></span>
        </span></span>
        //</span> offset_of! 매크로를 사용해서 Order 내의 link 필드 오프셋 구하기</span></span>
        let</span> offset</span> =</span> offset_of!</span>(</span>Order</span>,</span> link</span>)</span>;</span></span>
        </span></span>
        //</span> link 주소에서 오프셋만큼 빼서 본체의 시작 주소로 이동</span></span>
        let</span> parent_ptr</span> =</span> link_ptr</span>.</span>sub</span>(</span>offset</span>)</span>;</span></span>
        </span></span>
        //</span> 원본 Order 캐스팅</span></span>
        parent_ptr</span> as</span> *</span>mut</span> Order</span></span>
    }</span></span>
}</span></span></code></pre>
unsafe</code>하긴 하지만, ListLink</code>가 무조건 Order</code> 내부에 존재한다는 것을 API 설계자가 캡슐화로 보장한다면 문제없이 동작한다.</p>
이거 외에 개발자가 신경써줘야할 게 좀 있다.</p>
1. Pin 투영 (Pin Projection)#</a>
</h3>
Pin<&mut Order></code> 상태인 구조체에서 내부 필드를 가져오는 헬퍼 함수를 작성할 때 주의해야 한다. **Pin 투영(Projection)**이라고 하는데, 구조체 설계자가 다음 두 가지 중 하나를 선택해야 한다.</p>

Structural Pinning:</strong> 내부 필드(link</code>)도 절대로 메모리에서 재배치되면 안 된다. 따라서 getter는 반드시 Pin<&mut ListLink></code>를 반환해야 한다.</li>
Non-Structural Pinning:</strong> 내부 필드(price</code>)는 값만 빼서 바꿔도 리스트에 타격이 없다. 따라서 내부 타입인 &mut u64</code>를 반환해도 된다.</li>
</ul>
조심해야할 부분은 동일한 필드에 대해 묶인 참조(Pin<&mut T></code>)와 풀린 참조(&mut T</code>)를 동시에 노출하는 것</strong>이다. 이렇게 되면 풀린 참조를 통해 swap</code>을 해버릴 수 있어 Pin</code>이 보장하던 불변성이 파괴되며 UB가 된다. Pin 투영의 모든 보장의 책임은 전부 개발자에게 있어서 꽤 까다롭다.</p>
2. Drop 보장성#</a>
</h3>
객체가 메모리에서 해제될 때 호출되는 Drop</code> 트레이트도 고려해줘야한다.
구조체가 묶여(Pin</code>) 있더라도 소멸자 함수인 drop(&mut self)</code> 함수의 인자로 순수한 &mut self</code>를 던져준다.</p>
이때 Structural하게 묶어둔 필드(link</code>)를 replace</code>하거나 재배치해버리면 UB가 발생한다. 따라서 Drop</code> 내부에서는 Pin::new_unchecked(self)</code>를 사용해 강제로 다시 족쇄를 채운 뒤, 안전하게 리스트 연결을 해제(Unlink)하는 로직을 작성해야 한다.</p>
추가로, 메모리 압축을 위한 #[repr(packed)]</code> attribute를 걸면 내부 필드 메모리 정렬이 깨져 포인터 연산 시 CPU 예외가 발생할 수 있다.</p>

참조</strong></p>

https://medium.com/intro-to-rust/2020-04-24-pin-3500b145cca</a></li>
https://doc.rust-lang.org/std/pin/index.html</a></li>
</ul>