Uncontrolled format string is a type of software vulnerability discovered around 1989 that can be used in security exploits. Originally thought harmless, format string exploits can be used to crash a program or to execute harmful code. The problem stems from the use of unchecked user input as the format string parameter in certain C functions that perform formatting, such as printf(). A malicious user may use the %s and %x format tokens, among others, to print data from the call stack or possibly other locations in memory. One may also write arbitrary data to arbitrary locations using the %n format token, which commands printf() and similar functions to write the number of bytes formatted to an address stored on the stack.

Details
A typical exploit uses a combination of these techniques to take control of the instruction pointer (IP) of a process, for example by forcing a program to overwrite the address of a library function or the return address on the stack with a pointer to some malicious shellcode. The padding parameters to format specifiers are used to control the number of bytes output and the %x token is used to pop bytes from the stack until the beginning of the format string itself is reached. The start of the format string is crafted to contain the address that the %n format token can then overwrite with the address of the malicious code to execute.

This is a common vulnerability because format bugs were previously thought harmless and resulted in vulnerabilities in many common tools. MITRE's CVE project lists roughly 500 vulnerable programs as of June 2007, and a trend analysis ranks it the 9th most-reported vulnerability type between 2001 and 2006.

Format string bugs most commonly appear when a programmer wishes to output a string containing user supplied data (either to a file, to a buffer, or to the user). The programmer may mistakenly write printf(buffer) instead of printf("%s", buffer). The first version interprets buffer as a format string, and parses any formatting instructions it may contain. The second version simply prints a string to the screen, as the programmer intended. Both versions behave identically in the absence of format specifiers in the string, which makes it easy for the mistake to go unnoticed by the developer.

Format bugs arise because C's argument passing conventions are not type-safe. In particular, the varargs mechanism allows functions to accept any number of arguments (e.g. printf) by "popping" as many arguments off the call stack as they wish, trusting the early arguments to indicate how many additional arguments are to be popped, and of what types.

Format string bugs can occur in other programming languages besides C, such as Perl, although they appear with less frequency and usually cannot be exploited to execute code of the attacker's choice.

History 
Format bugs were first noted in 1989 by the fuzz testing work done at the University of Wisconsin, which discovered an "interaction effect" in the C shell (csh) between its command history mechanism and an error routine that assumed safe string input.

The use of format string bugs as an attack vector was discovered in September 1999 by Tymm Twillman during a security audit of the ProFTPD daemon. The audit uncovered an snprintf that directly passed user-generated data without a format string. Extensive tests with contrived arguments to printf-style functions showed that use of this for privilege escalation was possible.  This led to the first posting in September 1999 on the Bugtraq mailing list regarding this class of vulnerabilities, including a basic exploit. It was still several months, however, before the security community became aware of the full dangers of format string vulnerabilities as exploits for other software using this method began to surface. The first exploits that brought the issue to common awareness (by providing remote root access via code execution) were published simultaneously on the Bugtraq list in June 2000 by Przemysław Frasunek and a person using the nickname tf8. They were shortly followed by an explanation, posted by a person using the nickname lamagra. "Format bugs" was posted to the Bugtraq list by Pascal Bouchareine in July 2000.  The seminal paper "Format String Attacks" by Tim Newsham was published in September 2000 and other detailed technical explanation papers were published in September 2001 such as Exploiting Format String Vulnerabilities, by team Teso.

Prevention in compilers 
Many compilers can statically check format strings and produce warnings for dangerous or suspect formats. In the GNU Compiler Collection, the relevant compiler flags are, -Wall,-Wformat, -Wno-format-extra-args, -Wformat-security, -Wformat-nonliteral, and -Wformat=2.

Most of these are only useful for detecting bad format strings that are known at compile-time. If the format string may come from the user or from a source external to the application, the application must validate the format string before using it.  Care must also be taken if the application generates or selects format strings on the fly. If the GNU C library is used, the -D_FORTIFY_SOURCE=2 parameter can be used to detect certain types of attacks occurring at run-time. The -Wformat-nonliteral check is more stringent.

Detection 

Contrary to many other security issues, the root cause of format string vulnerabilities is relatively easy to detect in x86-compiled executables: For printf-family functions, proper use implies a separate argument for the format string and the arguments to be formatted. Faulty uses of such functions can be spotted by simply counting the number of arguments passed to the function; an 'argument deficiency' is then a strong indicator that the function was misused.

Detection in x86-compiled binaries 

Counting the number of arguments is often made easy on x86 due to a calling convention where the caller removes the arguments that were pushed onto the stack by adding to the stack pointer after the call, so a simple examination of the stack correction yields the number of arguments passed to the printf-family function.'

See also
 Cross-application scripting exploits a similar kind of programming error
 Cross-site scripting
 printf
 scanf
 syslog
 Improper input validation
 SQL injection is a similar attack that succeeds when input is not filtered

References

Further reading
 
 
  (vii+663 pages)

External links
 Introduction to format string exploits 2013-05-02, by Alex Reece
 scut / team-TESO Exploiting Format String Vulnerabilities v1.2 2001-09-09
 WASC Threat Classification - Format String Attacks
 CERT Secure Coding Standards
 CERT Secure Coding Initiative
 Known vulnerabilities at MITRE's CVE project.
 Secure Programming with GCC and GLibc (2008), by Marcel Holtmann

Computer security exploits
포맷 스트링 버그는 취약점 공격에 사용될 수 있는 보안 취약점으로써 1989년 경에 발견되었다. 이전에는 위험하지 않다고 여겨졌지만, 포맷 스트링 익스플로잇은 프로그램을 충돌시키거나 악의적인 코드를 실행 시키는데 사용될 수 있다. 문제는 포맷팅을 수행하는 printf() 같은 특정한 C 함수들에서 검사되지 않은 사용자 입력을 포맷 스트링 파라미터로 사용하는 것으로부터 나온다. 악의적인 사용자는 %s와 %x 포맷 토큰들을 콜 스택 또는 메모리의 가능한 다른 위치의 데이터를 보이게 하는 데 사용할 수 있다. 또한 %n 포맷 토큰을 사용해서 임의적인 데이터를 임의적인 위치로 쓸 수 있는데, 이것은 printf() 와 비슷한 함수들이 많은 바이트들을 스택에 저장된 주소에 쓰게 한다.

상세 
일반적인 익스플로잇은 이러한 기법들의 조합을 사용해서 프로그램이 라이브러리 함수의 주소나 스택의 반환 주소에 악의적인 셸코드를 가리키는 포인터를 겹쳐쓰게 한다. 포맷 명시자들에 대한 패딩 파라미터들은 많은 바이트들의 출력을 제어하는데 사용되며 %x 토큰은 자신이 도달하는 포맷 스트링의 시작까지 스택으로부터 바이트들을 pop하는데 사용된다. 포맷 스트링의 시작은, %n 포맷 토큰이 악의적인 코드(실행할)의 주소로 겹쳐쓸 수 있는 주소를 포함할 수 있게 다듬어 진다.

포맷 버그들이 이전에는 위험하지 않게 여겨졌고 많은 일반적인 툴들의 결과로 나왔기 때문에 이것은 흔한 취약점이다. MITRE의 CVE 프로젝트는 2007년 6월에 500개의 취약한 프로그램들을 보여주었는데, 2001년과 2006년 사이에 9번째로 자주 보고된 취약점 타입이었다.

포맷 스트링 버그들은 프로그래머가 사용자가 제공한 데이터를 포함한 문자열을 print하고자 할 때 가장 흔하게 볼 수 있다. 프로그래머는 실수로 printf(buffer) 를 printf("%s", buffer) 대신에 쓸 수 있다. 첫 번째는 buffer 를 포맷 스트링으로 해석하고 포함하는 어느 포매팅 명령어도 파스(parse)한다. 두 번째는 프로그래머의 의도와 같이 간단하게 문자열을 화면에 보여준다.

포맷 버그들은 C의 인자 전달 컨벤션들이 타입 안전하지 않아서 발생한다. 특히 varargs 메커니즘은 함수들이 어느 개수의 인자들이라도 받아들일 수 있게 하는데(예를 들면 printf) 이것은 원하는 만큼 콜 스택에서 인자들을 pop할 수 있기 때문이다(몇개의 추가적인 인자들이 pop되어야 하는지 그리고 무슨 타입인지를 이전의 인자들이 가리킨다고 믿으며).

포맷 스트링 버그들은 C 외에도 다른 프로그래밍 언어들에도 발생할 수 있다. 하지만 훨씬 적게 발견되며 공격자가 원하는 코드를 실행할 수 있을 만큼 익스플로잇되기도 힘들다.

역사 
포맷 스트링 버그가 발표된 것은 1999 10-15일로 tf8이라는 닉네임으로 보고되었다. 아래는 익스플로잇과 권고문이 바로 그 보고된 것들입니다.

- 익스플로잇: https://dl.packetstormsecurity.net/0006-exploits/wuftpd2600.c

- 보안 권고문 https://www.freebsd.org/security/advisories/FreeBSD-SA-00:29.wu-ftpd.asc

예방 
많은 컴파일러들이 정적으로 포맷 스트링을 검사하고 의심스러운 포맷에 관해서는 경고를 보여준다.

GNU 컴파일러 모음에서 관련있는 컴파일러 플래그들로는, -Wall,-Wformat, -Wno-format-extra-args, -Wformat-security, -Wformat-nonliteral, 그리고 -Wformat=2가 있다.

이것들 대부분은 단지 컴파일 타임 시에 알려진 안좋은 포맷 스트링을 탐지하는데에만 유용하다. 만약 포맷 스트링이 사용자나 애플리케이션의 외부 소스에서 온다면, 애플리케이션은 반드시 그것을 사용하기 전에 검증을 하여야 한다. 또한 애플리케이션이 포맷 스트링을 그때 그때 생성하거나 선택한다면 주의가 필요하다. -Wformat-nonliteral 검사는 더 강력하다.

같이 보기 
 printf
 scanf
 syslog
 부적절한 입력 검증
 SQL 삽입은 (입력이 필터링되지 않았을 때 발생하는) 비슷한 공격이다.

각주

참고 문헌 
 Robert C. Seacord, Secure Coding in C and C++. Addison Wesley, September, 2005. ISBN 0-321-33572-4
 Tobias Klein, Buffer Overflows und Format-String-Schwachstellen. Dpunkt Verlag, ISBN 3-89864-192-9.
 Crispin Cowan, Software Security for Open-Source Systems. IEEE Computer Society, IEEE Security & Privacy, January/February 2003
 Cowan, Crispin (August 2001). FormatGuard: Automatic Protection From printf Format String Vulnerabilities (PDF). Proceedings of the 10th USENIX Security Symposium.

외부 링크 
 scut / team-TESO Exploiting Format String Vulnerabilities v1.2 September 9, 2001
 WASC Threat Classification - Format String Attacks
 CERT Secure Coding Standards
 CERT Secure Coding Initiative
 Known vulnerabilities at MITRE's CVE project.
 Secure Programming with GCC and GLibc  (2008), by Marcel Holtmann

취약점 공격