Dynamic Linking in ELF

ELF is the binary format that allows for being both executable and linkable. It is de-facto standard in Linux.


A. Linking Overview

As the size of the program functionality grows, modulization helps programmersย to maintain their code with efficiency. During compilation, an object file is generated per module. Afterwards, aย linker (i.e., ld or ld.gold) takes one or more object files and combines them into a single executable file, library file, or another object file. Aย linker plays an pivotal role toย resolve the locations like re-targeting absolute jumps.

An object file contains a symbol – a primitive datatype to beย identified – that references another object file in nature. There are two symbol kinds: local symbols and external symbols. A local symbol resides in the same object file (often for the relocation purpose at linking time). For the latter, if an external symbol is defined inside the object file it can beย called from otherย modules. If undefined, it requires to find the symbol to which references. The referenced symbol can be located in either another object file or a library file, a collection of object files that can be shared by other executables.

A library can be static or dynamic. If an application employs a symbol in a static library (.a extension), the compiler directly merges the object file that contains the symbol with a final executable. When the object file contains another symbol in another object file, it should be resolved and combined at compilation time as well although the object file is not required by the original program. In case of a dynamic library (shared object or .so extension), the final executable does not embed the object file. Instead, it delays the resolution of undefined symbols until runtime and lets a dynamic linker do its job. Hence, aย statically linked executable can run itself without a library at runtime whereas a dynamically linked one cannot.

Here we demystify how dynamic linking works with a simple example for the shared object or position independent code (-fPIC option in a gcc and clang) in x86_64 (AKA AMD64).


B. Sample Program

Here is a tinyย source code that has two modules (test.c and func.c) and one header file (func.h).ย 


C. ELF Header and Tables forย Program Header and Section Header

ELF consists of three parts: ELF Header, Program Header Table and Section Header Table.ย 

First off, ELF header is quite self-explantionary with the defined struct itself in Elf64_Ehdr. See the comments below.

The program header table (PHT) describes how a loader maps the binary into virtual address space (or VA) when loading, whereas the section header table (SHT) has the entries of each defined section header when linking. Each mapped region in VA by a PHT entry is often called a segment from a loader view. As is a section by a SHTย entry from a linker view.

The final executable file mainย is shown as following (Figure 1). The linker view on the left shows how each section is stored as a file at offline. The loader view on the right shows how each segment is loaded asย a process at runtime.ย For instance, [S1] is the first section whose size is 0x1c with (A)llocatable by a loader. R, X and W denote readable, executable and writable respectively. On a loader view, there are four major chucks of memory: 0x400000-0x401000 (RX), 0x401000-0x402000 (RW), regions for shared objects and the space for stack and heap.

A friendly ‘readelf‘ command illustrates what each segment and section look like by reading the structure. Note that there are a lot of sections appended during compilation.ย 


D. ย Linking process

Before moving on, here is what the object looks like (in crt1.o). The relocation record shows that there are four locations that cannot be resolved while compilation process. That is why the 4-byte address is empty filled with 0x0s. The first relocation entry at offset 12 has the reference of __libc_csu_fini, defined in another object. We can see that _start function actually calls our main function at offset 0x20, the entry point of the final executable.

Now, when the given program is compiled by default, gcc or clang driver combines necessary files (i.e., CRT) to allow a loader to handle it properly. ย The Figure 2 illustrates them. (*) means the function is defined in the object file, whereas others are declared outside of the file. (i.e., using extern keyword in C) For example, crt1.o defines _startย in the file ย but the function __libc_start_main has to be resolved in a linking time (or maybe later).

Let’s seeย the layout of all functions from each object file. Figure 3 is part of sections from 10 to 13 in Figure 1. Interesting enough, the layout of all functions in a single object file is not inter-mixed.


E. Dynamic Linking

When dynamic linking is required (modern compiler set it by default), a compiler generates .dynamic section (section index 17 above). Note that executable files and shared object files have a separate procedure linkage table (PLT).

With theย sample we have, the dynamic section contains 24 entries as following. Pay attention to the highlighted, which are required by dynamic linker. The section .plt.got (PLTGOT)ย is the very place that the final fix-ups are storedย by dynamic linker. The .rela.plt (JMPREL) and .rela.dyn (RELA) are the relocation section tables that describe relocation entries.

Here are the symbols in relocation sections. The type “R_X86_64_JUMP_SLOT” means these symbols need toย be resolved at runtime by dynamic linker. The offset is the location that resolved reference has to be stored.

The Figure 4 (before resolution) and 5 (after resolution) illustrate how dynamic linker resolves the references on the fly. With disassembly, three symbols are called at 0x400448, 0x4004c4 and 0x4005c7. At first, they are supposed to jump to somewhere in PLT.ย Again, another jump instruction in PLT corresponds to somewhere in a .got.plt. The value in .got.plt has the address of next instruction in .pltย that has pointed to itself (+6).

For example, the address of printf@plt is 0x400490, and it jumps to 0x400496 after dereferencing (rip+0x158a is 0x401a20, and 0x400496 is stored in there). Then it pushes 0x2 and jumps to .plt table.

Here is the snapshot after the resolution of __libc_start_main and printf at glibc. The code forย __gmon_start__ is already in the final executable. (thus 0x400486). At this point, all references are successfully resolved by dynamic linker. Note that the reference is resolved only once when it is called for the first time.ย 

The address of the routineย for the resolution is stored at 0x401a08, which isย dl_runtime_resolve_avx in this example.

For more curious readers, here are the source files from glibc that defines __dl_runtime_resolve and _dl_fixup internally. Withย several breakpoints in debugging, the routine stores the link_map at %rdi register and the reloc_index at %rsi register. This index is the very one pushed in .plt section.




Cyber Grand Challenge by DARPA

1. Overview

2014๋…„ ์—ฌ๋ฆ„, ๋ฏธ ๊ตญ๋ฐฉ์„ฑ ์—ฐ๊ตฌ๋ถ€๋ฌธ์„ ๋‹ด๋‹นํ•˜๊ณ  ์žˆ๋Š” DARPA (Defense Advanced Research Projects Agency)์—์„œ ๋งค์šฐ ํฅ๋ฏธ๋กœ์šด competition event๋ฅผ ์ง„ํ–‰ํ•œ๋‹ค. ์ด๋ฆ„ํ•˜์—ฌ Cyber Grand Challenge – ์ž๋™ํ™”๋œ ๊ณต๊ฒฉ๋ฐฉ์–ด ์‹œ์Šคํ…œ (automated cyber reasoning system) ํ•˜์— ์ƒํ˜ธ ๊ฐ„์˜ ๊ณต๊ฒฉ๊ณผ ๋ฐฉ์–ด๋ฅผ ๋ชจ๋‘ ๊ธฐ๊ณ„๊ฐ€ ์‹ค์‹œ๊ฐ„์œผ๋กœ ๋‹ด๋‹นํ•˜๊ฒŒ ํ•ด ๊ฒฝ์Ÿํ•˜๋Š” ๋Œ€ํšŒ๋‹ค.

๋งŽ์€ CTF Challenge ๋Œ€ํšŒ๊ฐ€ ์žˆ์ง€๋งŒ, ์‚ฌ๋žŒ์˜ ๊ฐœ์ž…์—†์ด ์ˆœ์ˆ˜ํžˆ ๊ธฐ๊ณ„๋งŒ์„ ์ด์šฉํ•ด ์ทจ์•ฝ์ ์„ ์ฐพ๊ณ , ๊ณต๊ฒฉ๊ณผ ๋ฐฉ์–ด๋ฅผ ํ•˜๋Š” ๊ฒฝ์šฐ๋Š” ์„ธ๊ณ„์ ์œผ๋กœ ์ฒ˜์Œ์ด์—ˆ๋‹ค. ๊ฒŒ๋‹ค๊ฐ€ ์ƒ๋‹นํžˆ ํฐ ๊ธˆ์•ก์˜ ์ƒ๊ธˆ์€ ๋ณด์•ˆ์ธ์˜ ๊ด€์‹ฌ์„ ๋Œ๊ธฐ์— ์ถฉ๋ถ„ํ–ˆ๋‹ค.ย 

๋Œ€ํ‘œ๋งํฌ๋Š” ์—ฌ๊ธฐ https://cgc.darpa.milย ๋กœ ๊ฐ์ข… ๋ฌธ์„œ์™€ ๋Œ€ํšŒ๊ฒฐ๊ณผ๋ฅผ ํ™•์ธํ•  ์ˆ˜ ์žˆ๋‹ค. ๋Œ€ํšŒ๋Š” 3๋…„๊ฐ„ ์˜ˆ์„ (2014๋…„)๊ณผ ์ตœ์ข…ํ›„๋ณด ๊ฒฐ์„ ์ „(2015๋…„)์„ ๊ฑฐ์ณ 2016๋…„ 8์›” 4์ผ DEF CON์—์„œ Final ๊ฒฐ์Šน์ „์„ ์น˜๋ฃฌ๋‹ค. Final์€ 7๊ฐœ์˜ ํŒ€์ด ๊ฒจ๋ฃฐ ์˜ˆ์ •์ด๋ฉฐ, ์šฐ์Šน์ž๋Š” ๋ฌด๋ ค 20๋งŒ๋ถˆ์˜ ์ƒ๊ธˆ์„ ๊ฑฐ๋จธ์ฅ˜ ์ˆ˜ ์žˆ๋‹ค.

์ž‘๋…„ USENIX technical session์—์„œ Invite Talk์œผ๋กœ DARPA์˜ Mike๊ฐ€ ๋‘๋ฒˆ์˜ ๋Œ€ํšŒ๋ฅผ ์น˜๋ฅด๋ฉด์„œ ์žˆ์—ˆ๋˜ ๊ณผ์ •๊ณผ ๊ฒฐ๊ณผ๋ฅผ ๋ฐœํ‘œํ–ˆ๋‹ค. ๋ฐœํ‘œ์ž๋ฃŒ๋Š” ์—ฌ๊ธฐ๋ฅผ ์ฐธ๊ณ ํ•˜๊ธฐ ๋ฐ”๋ž€๋‹ค.ย 

UPDATED ย (As of Aug. 8, 2016)ย 
a.ย Mayhem declaredย the final winner of historic Cyber Grand Challenge.
b. Mayhem has been developed as a cyber reasoning system since 2012 by Sang Kil Cha et al., see the paper, Unleashing MAYHEM on Binary Code, for more details)
c. CFE File Archive is available now.



๋ฌด์—‡๋ณด๋‹ค๋„ DARPA๋Š” ์ทจ์•ฝ์  ์ž์ฒด์— ์ดˆ์ ์„ ๋งž์ถœ ์ˆ˜ ์žˆ๋„๋ก ๊ธฐ์กด ๋ฆฌ๋ˆ…์Šค ํ™˜๊ฒฝ์„ ๋ณ€ํ˜•ํ•œ DECREE๋ผ๋Š” ์šด์˜์ œ์ฒด๋ฅผ ๊ฐœ๋ฐœํ–ˆ๋‹ค. DECREE๋Š” ์ˆ˜๋ฐฑ ๊ฐœ์˜ system call์ด ์กด์žฌํ•˜๋Š” ๋ฆฌ๋ˆ…์Šค์™€๋Š” ๋‹ค๋ฅด๊ฒŒ ์‹คํ–‰ํŒŒ์ผ์ด ๋‹ค์Œ๊ณผ ๊ฐ™์ด ๋‹จ 7๊ฐœ์˜ system call๋งŒ์„ ์ด์šฉํ•˜๋„๋ก ์„ค๊ณ„ํ–ˆ๋‹ค. (Header ํŒŒ์ผ ์ฐธ์กฐ)

  • int transmit(int fd, const void *buf, size_t count, size_t *tx_bytes);
  • int receive(int fd, void *buf, size_t count, size_t *rx_bytes);
  • int fdwait(int nfds, fd_set *readfds, fd_set *writefds);
  • int allocate(size_t length, int is_X, void **addr);
  • int deallocate(void *addr, size_t length);
  • int random(void *buf, size_t count, size_t *rnd_bytes);

์ƒˆ๋กœ์šด ์šด์˜์ฒด์ œ์—์„œ ์ž‘๋™ํ•  ์ˆ˜ ์žˆ๋Š” ์‹คํ–‰ํŒŒ์ผ์„ ์ปดํŒŒ์ผํ•  ์ˆ˜ ์žˆ๋„๋ก gcc๋ฅผ ์ˆ˜์ •ํ•˜๊ณ , ์‹คํ–‰ํŒŒ์ผํฌ๋งท ๋˜ํ•œ ๊ธฐ์กด์˜ ELF๋ฅผ ๊ธฐ๋ฐ˜์œผ๋กœ ํ•œ cgc ํฌ๋งท์„ ์ƒˆ๋กœ ์ •์˜ํ–ˆ๋‹ค. ์ด๋Š” ๊ธฐ์กด์˜ ์–ด๋–ค ์šด์˜์ฒด์ œ์—์„œ๋„ ํŒŒ์ผ์˜ ์‹คํ–‰์€ ๋ฌผ๋ก  ๋Œ€ํšŒ์—์„œ ๋ฐœ๊ฒฌํ•œ ์ทจ์•ฝ์ ๊ณผ exploit ๋ชจ๋‘ ๋ฌด๋ฏธ์˜ํ•จ์„ ์˜๋ฏธํ•œ๋‹ค. ๊ทธ๋ฆฌ๊ณ  IPC (Inter-Process Communication) ๋„ ๋ฌด์ฒ™ ์ œํ•œ์ ์ด๋‹ค. ๊ณต์œ  ๋ฉ”๋ชจ๋ฆฌ๋ฅผ ์ง€์›ํ•˜์ง€ ์•Š์œผ๋ฉฐ, ๋‹จ์ˆœํ•œ ์–‘๋ฐฉํ–ฅ ํ†ต์‹ ๋งŒ์„ ์ง€์›ํ•œ๋‹ค.

CyberGrandChallenge Github์— ์žˆ๋Š” walk-through ๋ฌธ์„œ๋ฅผ ๋”ฐ๋ผ VirtualBox์™€ vagrant๋ฅผ ์„ค์น˜ํ•˜๊ณ  vbox๋ฅผ ์ถ”๊ฐ€ํ•œ ํ›„ ๋‹ค์Œ๊ณผ ๊ฐ™์ด 5๊ฐœ์˜ VM์„ ์ฐจ๋ก€๋กœ ๋ถ€ํŒ…ํ•  ์ˆ˜ ์žˆ๋‹ค.

๋‹ค์Œ์€ default๋กœ ์„ค์ •๋˜์–ด ์žˆ๋Š” CRS์„œ๋ฒ„์— ssh๋กœ ์—ฐ๊ฒฐํ•œ ๋ชจ์Šต์ด๋‹ค. ๊ฒŒ์ŠคํŠธ ์šด์˜์ฒด์—์ œ์„œ /vagrant๋กœ ์ด๋™ํ•˜๋ฉด ์ž๋™์œผ๋กœ Vagrant ์Šคํฌ๋ฆฝํŠธ์— ์˜ํ•ด ํ˜ธ์ŠคํŠธ ์šด์˜์ฒด์ œ์˜ ํ˜„์žฌ ๋””๋ ‰ํ† ๋ฆฌ๋ฅผ ๊ณต์œ ํ•˜๊ณ  ์žˆ์Œ์„ ์•Œ ์ˆ˜ ์žˆ๋‹ค.


3. Challenge Binaries and Utilities

2015๋…„ Grand Challenge์—์„œ DARPA๋Š” ๋Œ€ํšŒ์šฉ์œผ๋กœ 131๊ฐœ์˜ Compile๋œ Binary๋งŒ์„ ๊ณต๊ฐœํ–ˆ๋‹ค. ํ•˜์ง€๋งŒ, ํ˜„์žฌ Github Repository์—์„œ ๋ชจ๋“  ๋ฐ”์ด๋„ˆ๋ฆฌ์˜ ์†Œ์Šค์ฝ”๋“œ์™€ ์ทจ์•ฝ์ , PoV (Proof of Vulnerability), ๊ทธ๋ฆฌ๊ณ  ์ƒ์„ธํ•œ ์„ค๋ช… (Service Description)์„ ์ œ๊ณตํ•˜๊ณ  ์žˆ๋‹ค.ย 

131๊ฐœ์˜ ๋ฐ”์ด๋„ˆ๋ฆฌ๋Š” ๋‹จ์ˆœํ•˜๊ฒŒ ๋งŒ๋“  ์šด์˜์ฒด์ œ์—์„œ ์‹ค์ œ ์„œ๋น„์Šค์™€ ์œ ์‚ฌํ•  ๋งŒํผ์˜ ๋ณต์žก๋„๋ฅผ ๊ฐ€์ง„ ์„œ๋น„์Šค๋ฅผ ์ œ๊ณตํ•  ์ˆ˜ ์žˆ๋‹ค. 72๊ฐœ์˜ CC ํŒŒ์ผ (7000 LOC), 1236๊ฐœ์˜ ํ—ค๋” (19๋งŒ LOC), 1996๊ฐœ์˜ C ํŒŒ์ผ (20๋งŒ LOC), 6000์—ฌ ๊ฐœ์˜ ํ•จ์ˆ˜์™€ 590๊ฐœ์˜ PoV๊ฐ€ ์ด๋ฅผ ๋Œ€๋ณ€ํ•œ๋‹ค.ย 

(1) CGC Executable Format (CGCEF)

CGC ์‹คํ–‰ ํฌ๋งท์€ ์ฒ˜์Œ 15๋ฐ”์ดํŠธ์˜ ํ—ค๋”๊ฐ€ ELF์™€ ๋‹ค๋ฅด๋‹ค. \x7fCGC๋กœ ์‹œ์ž‘ํ•จ์„ ์•Œ ์ˆ˜ ์žˆ๋‹ค.ย 

CGC ์‹คํ–‰ํฌ๋งท์€ cgcef-verify๋ผ๋Š” ๋„๊ตฌ๋กœ ์ •์ƒ์—ฌ๋ถ€๋ฅผ ํ™•์ธํ•  ์ˆ˜ ์žˆ์œผ๋ฉฐ, readelf์™€ ๊ฐ™์ด readcgcef๋กœ ์ฝ์„ ์ˆ˜ ์žˆ๋‹ค.ย  PATH ํ™˜๊ฒฝ๋ณ€์ˆ˜๋ฅผ ์‚ด์ง ์กฐ์ •ํ•ด์„œ ๊ธฐ์กด์˜ bintools์„ ํŽธํ•˜๊ฒŒ ๋Œ€์ฒดํ•  ์ˆ˜๋„ ์žˆ๋‹ค.


(2) CGCEF Program Headers

CGCEF๋Š” ์„น์…˜์œ ํ˜•์ด(section type) 4๊ฐœ๋ฐ–์— ์—†๋‹ค. ๋ชจ๋“  ๋ฐ”์ด๋„ˆ๋ฆฌ๋Š” ์ •์ ์œผ๋กœ ์—ฐ๊ฒฐ(Statically Linked)๋˜์–ด ์žˆ์œผ๋ฉฐ, ๋™์ ๋งํ‚น (Dynamic Linked)๊ณผ thread๋ฅผ ์‚ฌ์šฉํ•˜์ง€ ์•Š๋Š”๋‹ค. ๋”ฐ๋ผ์„œ TLS (Thread Local Storage) ์„น์…˜๋„ ์กด์žฌํ•˜์ง€ ์•Š๋Š”๋‹ค.


(3) CGCEF Section Headers

์„น์…˜ํ—ค๋”๋Š” ๋””๋ฒ„๊น…ํ•  ๋•Œ ์ •๋ณด ์ œ๊ณต์šฉ์œผ๋กœ๋งŒ ์‚ฌ์šฉํ•˜๋ฉฐ, Loader๋Š” ์ด ์„น์…˜์„ ๋ฌด์‹œํ•˜๊ณ  ๋กœ๋”ฉํ•œ๋‹ค. ๋ฐฐํฌ์šฉ(release)์œผ๋กœ ์ œ๊ณตํ•˜๋Š” ๋ฐ”์ด๋„ˆ๋ฆฌ๋Š” ๋ณดํ†ต ์ด ์„น์…˜์ด ์ œ๊ฑฐ๋˜๊ณ (stripped) ์—†๋‹ค๊ณ  ๋ณด๋ฉด ๋œ๋‹ค.

(4) IDA Pro modules for CGC

Reversing์„ ํ•  ๋•Œ ํ‘œ์ค€๋„๊ตฌ์ฒ˜๋Ÿผ ๋งŽ์€ ์‚ฌ๋žŒ๋“ค์ด ์• ์šฉํ•˜๋Š” IDA Pro์—์„œ๋„ Loadingํ•  ์ˆ˜ ์žˆ๋„ Module์„ ์ œ๊ณตํ•œ๋‹ค.ย ์—ฌ๊ธฐ์„œ (http://idabook.com/cgc/) ๋ฒ„์ „์— ๋งž๋Š” ๋ชจ๋“ˆ์„ ๋‹ค์šด๋ฐ›์•„ ์„ค์น˜ํ•˜๋ฉด CGC ๋ฐ”์ด๋„ˆ๋ฆฌ๋ฅผ ๋กœ๋”ฉํ•  ๋•Œ ์ž๋™์œผ๋กœ Loader๋ฅผ ์„ ํƒํ•ด ์ค€๋‹ค.

(5) How to run CGC binary as a service

์ผ์ผํžˆ ์‹คํ–‰ํ•˜๊ธฐ ๋ฒˆ๊ฑฐ๋กœ์šฐ๋ฉด, ๋‹ค์Œ๊ณผ ๊ฐ™์ด ์ž„์˜๋กœ ์„œ๋ฒ„์™€ ํด๋ผ์ด์–ธํŠธ๋ฅผ ์‹คํ–‰ํ•ด ํ™•์ธํ•ด ๋ณผ ์ˆ˜ ์žˆ๋‹ค. ๋‹ค์Œ๊ณผ ๊ฐ™์ด cqe ๋ฐ”์ด๋„ˆ๋ฆฌ์˜ pollerย directory ๋‚ด์— for-testing๊ณผ for-release ๋‘ ๊ฐ€์ง€ ํ˜•ํƒœ์˜ ๋งŽ์€ sample data๋กœ ํ…Œ์ŠคํŠธํ•ด ๋ณผ ์ˆ˜ ์žˆ๋‹ค.

๋˜ํ•œ pov ๋””๋ ‰ํ† ๋ฆฌ์—๋Š” ์‹ค์ œ ์ทจ์•ฝ์ ์„ triggerํ•˜๋Š” ์ž…๋ ฅ๊ฐ’(input)์„ ๊ฐ€์ง€๊ณ  ์žˆ์–ด ์‹ค์ œ ์ทจ์•ฝํ•œ ์ฝ”๋“œ๊ฐ€ ์–ด๋””์ธ์ง€ ์‚ดํŽด๋ณด๊ธฐ์— ์•ˆ์„ฑ๋งž์ถค์ด๋‹ค. ์•„๋ž˜ ์˜ˆ์ œ๋Š” client์™€ ํ†ต์‹ ํ•œ ํ›„ exit code๊ฐ€ 0์ด ์•„๋‹Œ ์ƒํƒœ๋กœ ์ข…๊ฒฐ๋˜์—ˆ๊ธฐ์— ์„œ๋ฒ„ ์ธก์—์„œ ์‹ค์ œ register status๋ฅผ ๋ณด์—ฌ์ฃผ๊ณ  ์žˆ๋‹ค.


4. CWE Distribution forย CGC Binaries

CWE๋Š”ย MITRE (https://cwe.mitre.org/)์—์„œ ์ œ๊ณตํ•˜๋Š” ์ผ์ข…์˜ ์ทจ์•ฝ์  ๋ถ„๋ฅ˜(Common Weakness Enumeration)๋ผ๊ณ  ๋ณผ ์ˆ˜ ์žˆ๋‹ค. ย Semi-Final์—์„œ ์ œ๊ณตํ•œ 131๊ฐœ์˜ ๋ฐ”์ด๋„ˆ๋ฆฌ Description์„ ๊ธฐ๋ฐ˜์œผ๋กœ ์‚ดํŽด๋ณธ ๊ฒฐ๊ณผ ๋‹ค์Œ ํ‘œ์™€ ๊ฐ™์ด ๋Œ€๋žต 60์—ฌ๊ฐœ์˜ ๋ถ„๋ฅ˜์™€ 300๊ฐœ ์ด์ƒ์˜ ์ทจ์•ฝ์ ์„ ๊ฐ€์ง€๊ณ  ์žˆ์Œ์„ ์•Œ ์ˆ˜ ์žˆ๋‹ค.

CWE NoCWE DescriptionTotal
CWE-20Improper Input Validation9
CWE-22Improper limitation of a pathname to a restricted directory1
CWE-59Improper link resolution before file access1
CWE-61UNIX symbolic link following1
CWE-119Improper Restriction of Operations within the Bounds of a Memory Buffer6
CWE-120Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')22
CWE-121Stack-based buffer overflow24
CWE-122Heap-Based Buffer Overflow29
CWE-123Write-what-where Condition1
CWE-125Out-of-bounds read13
CWE-127Buffer Under-read1
CWE-128Wrap-around Error1
CWE-129Improper Validation of Array Index14
CWE-131Improper Calculation of Buffer Size11
CWE-134Uncontrolled Format Sting7
CWE-170Improper Null Termination1
CWE-176Improper handling of unicode encoding1
CWE-190Integer overflow or wraparound16
CWE-191Integer underflow (Wrap or Wraparound)3
CWE-193Off-by-one error11
CWE-195Signed to Unsigned Conversion Error5
CWE-196Unsigned to Signed Conversion Error1
CWE-200Information Exposure1
CWE-201Information Exposure Through Sent Data1
CWE-252Unchecked Return Value1
CWE-275Permission issues1
CWE-326Inadequate Encryption Strength1
CWE-327Use of a Broken or Risky Cryptographic Function1
CWE-328Reversible One-Way Hash1
CWE-367TOCTOU Error2
CWE-369Divide by zero1
CWE-400Uncontrolled Resource Consumption1
CWE-415Double Free1
CWE-416Use After Free8
CWE-434Unrestricted upload of file with dangerous type1
CWE-457Use of uninitialized variable5
CWE-467Use of sizeof() on a Pointer Type2
CWE-469Use of Pointer Subtraction to Determine Size1
CWE-471Modification if Assumed-Immutable Data1
CWE-476Null Pointer Dereference24
CWE-665Improper Initialization1
CWE-674Uncontrolled recursion5
CWE-680Integer Overflow to Buffer Overflow2
CWE-682Incorrect calculation1
CWE-690Unchecked Return Value1
CWE-704Incorrect type conversion or cast3
CWE-755Improper Handling of Exceptional Conditions1
CWE-763Release of Invalid Pointer or Reference1
CWE-783Operator Precedence Logic Error1
CWE-785Use of Path Manipulation Function without Maximum-sized Buffer1
CWE-787Out-of-bounds Write22
CWE-788Access of Memory Location After End of Buffer6
CWE-798Use of Hard-coded Credentials1
CWE-805Buffer Access with Incorrect Length Value2
CWE-822Untrusted Pointer Dereference4
CWE-823Use of Out-of-range Pointer Offset2
CWE-824Access of Uninitialized Pointer5
CWE-825Expired Pointer Dereference1
CWE-839Numeric Range Comparison Without Minimum Check4
CWE-843Access of Resource Using Incompatible Type 'Type Confusion'5
CWE-908Use of Uninitialized Resource3

TOP 5๋Š” ์ง์ž‘ํ•  ์ˆ˜ ์žˆ๋“ฏ์ด Classic Buffer Overflow, Stack-based Overflow, Heap-based Overflow, Out-of-Bounds Write, Null Pointer Dereferencing์ด๋‹ค.