strcpy도 안 씁니다

(cURL과 libcurl)

2025년 12월 29일 · Daniel Stenberg · 댓글 10개

얼마 전, 우리가 curl 소스 코드를 훑어보며 결국 모든 strncpy() 호출을 없앴다고 언급한 적이 있습니다.

strncpy()는 이상한 함수이고 API도 형편없습니다. 대상 버퍼를 널 종료(null-terminate)하지 않을 수도 있고, 대상 버퍼를 0으로 패딩 하기도 합니다. 솔직히 말해 대부분의 코드베이스는 이 함수를 완전히 피하는 편이 더 낫습니다. 사용할 때마다 잠재적인 실수 지점이 되기 때문입니다.

그때 strncpy를 멸종시키는 리라이트(rewrite)를 하면서, 우리는 문자열을 제대로 전부 복사하든가 아니면 오류를 반환하도록 반드시 만들었습니다. 문자열을 일부만 복사하는 것이 올바른 선택인 경우는 드물고, 정말 필요하다면 memcpy로 복사한 뒤 널 종료를 명시적으로 처리하면 됩니다. 그래서 strlcpy 같은 것들도 사용할 이유가 없었습니다.

curl에서 시간에 따른 strncpy 밀도

그런데 strcpy는?

하지만 strcpy는 유효한 사용처가 있고, API도 그다지 나쁘거나 혼란스럽지는 않습니다. strcpy의 가장 큰 문제는 사용할 때 대상 버퍼의 길이도, 소스 문자열의 길이도 지정하지 않는다는 점입니다.

보통 C 프로그램에서 strcpy는 양쪽(소스와 대상)을 완전히 통제할 수 있을 때만 써야 하므로, 이것은 일반적으로 문제가 되지 않습니다.

하지만 보통 과 항상 은 같은 말이 아닙니다. 우리는 모두 인간이고 실수를 합니다. strcpy를 사용한다는 것은 최소 하나, 어쩌면 두 개의 버퍼 크기 체크가 함수 호출 전에 이루어졌다는 의미입니다. 상황이 좋다면요.

그러나 시간이 흐르면서(수십 년 살아남는 코드를 상상해 봅시다) 서로 다른 사고방식과 접근을 가진 많은 작성자들이 코드를 유지보수하고 패치하고 개선하고 다듬다 보면, 그 크기 체크와 함수 호출이 서로 멀어지며 따로 놀게 될 수 있습니다. 둘이 멀어질수록, 그 사이에 어떤 일이 생겨 체크 중 하나가 무효화되거나 strcpy의 전제 조건이 바뀌어 버릴 위험이 커집니다.

체크를 코드 가까이 강제하기

크기 체크가 복사 동작 자체에서 분리되지 않도록 하기 위해, 우리는 며칠 전 문자열 복사 대체 함수를 도입했습니다. 이 함수는 인자로 대상 버퍼, 대상 크기, 소스 버퍼, 소스 문자열 길이 를 받고, 복사와 널 종료 문자가 모두 들어갈 수 있을 때만 실제 복사를 수행합니다.

이 덕분에 memcpy()로 대체 구현이 가능해졌습니다. 이제 우리는 strncpy를 이미 금지했던 것처럼, curl 소스 코드에서 strcpy의 사용도 완전히 금지할 수 있게 되었습니다.

이 함수 버전은 필요한 정보가 더 많아서 strcpy보다 약간 더 번거롭고 일이 늘어납니다. 하지만 이 접근법의 장점이 추가적인 고통을 감수할 만큼의 가치가 있고, 전체를 더 잘 감시(오버사이트)하는 데 도움이 될 거라 믿습니다. 앞으로 시간이 지나면 어떻게 될지 보겠죠. 10년 뒤에 다시 돌아와서 어떻게 발전했는지 봅시다!

curl에서 시간에 따른 strcpy 밀도

c
void curlx_strcopy(char *dest,

                   size_t dsize,

                   const char *src,

                   size_t slen)

{

  DEBUGASSERT(slen < dsize);

  if(slen < dsize) {

    memcpy(dest, src, slen);

    dest[slen] = 0;

  }

  else if(dsize)

    dest[0] = 0;

}

the strcopy source

AI 슬롭

이 변경의 추가적인(사소한) 긍정적 부작용은 물론, 이로 인해 AI 챗봇들이 curl 소스 코드에서 strcpy 사용을 찾아내고 “안전하지 않다”고 우기며 보고서를 만들어내는 일을 효과적으로 막을 수 있다는 점입니다(사람들이 아직도 그런 질문을 하는 모양이더군요). 소스 코드에 strcpy가 들어 있으면, 환각에 기반한 취약점 주장(hallucinated vulnerability claims)을 생성하는 꿀단지처럼 작동한다는 건 이미 여러 번 입증됐습니다.

그래도 결국 그들은 다른 무언가를 찾아내서 또 보고서를 꾸며낼 테니, 총합적으로 이득이 있을지는 모르겠습니다. AI 슬롭은 우리가 이길 수 있는 게임이 아닙니다.

태그: cURL and libcurl, Security

게시물 탐색

이전 글: A curl 2025 review