INSIDE THE BUFFER OVERFLOW ATTACK:M

INSIDE THE BUFFER OVERFLOW ATTACK:

MECHANISM, METHOD, & PREVENTION
Mark E. Donaldson
April 3, 2002
GSEC Version 1.3

ABSTRACT

The objective of this study is to take one inside the buffer overflow attack and bridge the gap between the “descriptive account” and the “technically intensive account”. The intent is to provide a logical, detailed, and technical. explanation of the problem and the exploit that can be well understood by all, including those with little background in the mechanics and methodology of applications
programming. rights
We will begin by looking at the “problem” and the problemfull “mechanism”, and then investigate the “means” and the “method”. Based on what we find, we will

security concern, it is certainly within the realmretainsof possibility that the buffer overflow attack be reduced to a level of insignificance through true

conclude with recommendations, and a menu for “prevention”. Hopefully this
approach may also help bridge the gap between “knowledge” and

“understanding”. Although it may never be possible to purge the world of this

understanding. Robert Louis StevensonAuthoronce wrote: “Look at yourself. Could you be a doctor, a healing man, with the things those eyes have seen? There’s a lot of knowledge in those eyes, but no understanding.1” The technology community must move from fighting buffer overrun attacks defensively to fighting them offensively. To do this, they must transform their knowledge into understanding.

THE PROBLEM 2002,
Problematic buffer Instituteoverruns2 related to the C programming language data integrity model were first recognized as early as 1973. The first well known

exploit of this vulnerability occurred in 1988 when the well documented and infamous Internet Worn shutdown over 6,000 systems in just a few short hours, utilizing an unchecked buffer initialized by the gets() function call in the fingerd

daemon process. Despite this lengthy history and simple preventative methods, the buffer overflow continues to be a significant and prominent computer security
concern even today. For example, buffer overflow problems are implicated in
© SANS

1 Robert Louis Stevenson from “The Body Snatcher” published in 1881.

2 Buffer overflows have assumed several different names over the years. These include buffer overrun, stack overrun, and stack overflow. In practice, all these terms share the same definition and can be used synonymously and interchangeably. Additionally, the stack buffer overflow exploit is often referred to as “stack smashing” in modern day parlance.

2/6/2003 Page 1 of 24






© SANS Institute 2002, As part of the Information Security Reading Room. Author retains full rights.

five of the Sans “Top 20” vulnerabilities.3 If one ventured to the SuSE Linux Web Site, they would find 22 buffer overflow vulnerabilities since January 2001 that require patching (see Table I). Additionally, of the 44 CERT advisories published between 1997 and 1999, 24 were related to buffer overrun issues.

TABLE I
BUFFER OVERFLOW VULNERABILITIES SUSE LINUX
Date Vulnerability
12.03.2002 buffer overflow in zlib library .
04.03.2002 buffer overflow in squid
28.02.2002revised: buffer overflow in cupsd
28.02.2002 buffer overflows in mod_php4 and mod php
25.02.2002buffer overflow in cupsd
25.01.2002buffer overflow in rsync buffer overflow in rsync
16.01.2002buffer overflow corruption in /usr/bin/at rights

07.01.2002buffer overflow in mutt
24.12.2001buffer overflow in glibc globbing functionsfull
03.12.2001buffer overflow problems in openssh
28.11.2001buffer overflows in wuftpd
10.10.2001 overflow in lpd/lprold
20.09.2001buffer overflow in WindowMaker
03.09.2001daemon buffer overflow (nkitb)
retains
23.08.2001signedness buffer overflow in sendmail
17.08.2001 fetchmail buffer overflow
24.07.2001(xli) buffer overflow, local+remote
18.04.2001exploitable buffer overflow in sudo
09.04.2001xntpd remotely exploitable buffer overflow
27.03.2001buffer overflow in eperl
Author
22.03.2001one-byte-buffer overflow in bsd-ftpd and in timed
31.01.2001buffer overflow in bind8 (new problem; January 2001)
lingering buffer overruns2002,
Resident and left in program code are often attributed to
the buffer overflow Institutevulnerability and attack remain only loosely and informally documented in the literature. From this one might conclude the problem is

“lazy”, “sloppy”, or “uncaring” programmers, or to modern compilers that fail to
perform integrity or bounds checking on their source input or machine output
instructions. However, these views may be a bit too simplistic. The root of the

problem may run deeper than that. For instance, despite their prevalence today,


generally not well understood. This may explain why overrun vulnerabilities
continue to appear in new software applications.
SANS is necessary here. Indeed, the buffer overflow and exploit
Some clarification©
problem are well known. Unfortunately, “well known” and “well understood” are often two entirely different views of the same thing. For instance, nearly every book, article, or white paper worth its salt that focuses on computer security

3 These include W2-ISAPI Extension Buffer Overflows, U1-Buffer Overflows in RPC Services, U3-Bind Weaknesses, U5-LPD (remote print protocol daemon), and U6–sadmind and mountd. 2/6/2003 Page 2 of 24






© SANS Institute 2002, As part of the Information Security Reading Room. Author retains full rights.

mentions the buffer overflow vulnerability and their enabling factors. They normally even site preventions or defenses against them. However, they typically avoid discussing or describing the intricate details or complex mechanisms of their cause and their manipulative use in terms that can easily be understood by the novice or inexperienced programmer, system administrator, or computer security practitioner or principal.

Certainly, several detailed accounts of the buffer overflow exploit have been written. These were cited by Nicole LaRock Decker in her GSEC paper “Buffer Overflows: Why, How and Prevention”. However, these accounts. were written by exceptionally brilliant, and perhaps devious, programmers that chose to jump straight into the details of the low level machine and assembler code necessary
to effect the overrun exploit. A typical reader of these accounts usually becomes
rights
overwhelmed by the third paragraph, and lays the document to rest.
THE MECHANISM full
1997 study “Stack Smashing VulnerabilitiesretainsInThe UNIX Operating System.” However, the vulnerability is not just limited to C or UNIX. Indeed, both DilDog
Buffer overflow vulnerabilities are often attributed to the combined effects of the
permissions security features of the UNIX operating system and defects in the C

programming language. Such was the premise assumed by Nathan Smith in his

Overflow” and “Exploiting Windows NT4 Author Buffer Overruns.” The paper “Windows
and David Litchfield demonstrated the exploit could be used effectively against

the Windows NT kernel in their respective papers “The Tao Of Windows Buffer

NT Buffer Overflow’s Start to Finish” shows the problem present and able within the MFC4 as well. Hence, this2002,paper views the buffer overflow as a language and an operating system independent problem.
Microsoft Corporation defines the buffer overflow attack as follows:

A buffer overflow attackInstituteisan attack in which a malicious user exploits an unchecked buffer in a program and overwrites the program code with their-own data. If the

program code is overwritten with new executable code, the effect is to change the program's operation as dictated by the attacker. If overwritten with other data, the likely effect is to cause the program to crash.

Since Microsoft has produced their fair share of buffer overflow vulnerabilities
over the years, SANS they should be well versed on the problem and we should not


doubt the validity © of this description. Thus, we will use this as our official working
definition. But what exactly does this mean? And, how do we get there?





4 MFC is the acronym for Microsoft Foundation Class, Microsoft’s C++ OOP library.

Kết quả (Việt) 1:

Bên trong các cuộc tấn công tràn bộ đệm:

cơ chế, phương pháp, & công tác phòng chống
Mark E. Donaldson
3 tháng 4 năm 2002
GSEC Phiên bản 1.3

trừu tượng

mục tiêu của nghiên cứu này là để có một bên trong cuộc tấn công tràn bộ đệm và thu hẹp khoảng cách giữa các tài khoản"mô tả" và "tài khoản kỹ thuật chuyên sâu". Mục đích là để cung cấp một hợp lý, chi tiết, và kỹ thuật. giải thích về vấn đề và khai thác có thể được hiểu rõ bởi tất cả, bao gồm cả những người có ít nền trong cơ học và phương pháp luận của ứng dụng
lập trình. quyền
chúng tôi sẽ bắt đầu bằng cách nhìn vào vấn đề"" và problemfull "cơ chế", và sau đó điều tra các phương tiện"" và "phương pháp". Dựa trên những gì chúng tôi tìm thấy, chúng tôi sẽ

mối quan tâm an ninh, nó là chắc chắn trong vòng khả năng realmretainsof rằng cuộc tấn công tràn bộ đệm được giảm đến một mức độ không quan trọng thông qua đúng

kết luận với các khuyến nghị, và chọn "chống". Hy vọng rằng điều này
phương pháp tiếp cận cũng có thể giúp thu hẹp khoảng cách giữa "kiến thức" và

"hiểu biết". Mặc dù nó có thể không bao giờ có thể dọn sạch các thế giới này

sự hiểu biết. Robert Louis StevensonAuthoronce đã viết: "nhìn vào chính mình. Có thể bạn trở thành một bác sĩ, một người đàn ông chữa bệnh, với những đôi mắt đã thấy? Đó là rất nhiều kiến thức trong đôi mắt, nhưng không có understanding.1 "cộng đồng công nghệ phải di chuyển từ chiến đấu tấn công bộ đệm tràn ngập phòng thủ để chiến đấu họ offensively. Để làm điều này, họ phải chuyển đổi kiến thức của mình vào sự hiểu biết.

Năm 2002 vấn đề,
vấn đề bộ đệm Instituteoverruns2 liên quan đến C lập trình ngôn ngữ toàn vẹn mô hình dữ liệu đầu tiên được công nhận sớm nhất là năm 1973. Người đầu tiên nổi tiếng

khai thác lỗ hổng này diễn ra năm 1988 khi các tài liệu và nổi tiếng Internet mòn tắt trên các hệ thống 6.000 trong chỉ là một vài giờ ngắn, sử dụng một bộ đệm đánh dấu khởi tạo bởi cuộc gọi chức năng gets() trong fingerd

quá trình daemon. Mặc dù này dài lịch sử và phương pháp phòng ngừa đơn giản, lỗi tràn bộ đệm tiếp tục là một bảo mật máy tính quan trọng và nổi bật
quan tâm ngay cả ngày nay. Ví dụ, bộ đệm tràn vấn đề có liên quan đến
© SANS

1 Robert Louis Stevenson từ "The cơ thể Snatcher" được xuất bản vào năm 1881.

2 tràn bộ đệm đã giả định một số tên gọi khác nhau trong những năm qua. Chúng bao gồm bộ đệm overrun, ngăn xếp overrun và ngăn xếp tràn. Trong thực tế, tất cả các điều khoản này chia sẻ cùng một định nghĩa và có thể được sử dụng synonymously và thay thế cho nhau. Ngoài ra, khai thác lỗi tràn bộ đệm ngăn xếp thường được gọi là "stack đập" trong parlance ngày nay.

2/6/2003 Trang 1 của 24



© SANS viện năm 2002, như là một phần của phòng đọc sách bảo mật thông tin. Tác giả vẫn giữ đầy đủ quyền.

năm trong số Sans "Top 20" vulnerabilities.3 nếu một mạo hiểm để SuSE Linux Web trang web, họ sẽ tìm thấy 22 bộ đệm tràn lỗ hổng kể từ tháng 1 năm 2001 đòi hỏi phải vá (xem bảng tôi). Ngoài ra, của tư vấn CERT 44 xuất bản từ năm 1997 đến năm 1999, 24 được liên quan đến bộ đệm tràn ngập các vấn đề.

bàn tôi
bộ đệm tràn lỗ hổng SUSE LINUX
ngày lỗ hổng
12.03.2002 lỗi tràn bộ đệm trong thư viện zlib.
04.03.2002 lỗi tràn bộ đệm trong mực
28,02.2002revised: lỗi tràn bộ đệm trong cupsd
28.02.2002 bộ đệm tràn trong mod_php4 và mod php
25.02.2002buffer tràn trong cupsd
25.01.2002buffer tràn trong rsync lỗi tràn bộ đệm trong rsync
16.01.2002buffer tham nhũng tràn trong/usr/bin/at quyền

07.01.2002buffer tràn trong mutt
24.12.2001buffer tràn trong glibc globbing functionsfull
03.12.2001buffer tràn vấn đề trong openssh
28.11.2001buffer tràn trong wuftpd
10.10.2001 tràn trong lpd/lprold
20.09.2001buffer tràn trong WindowMaker
lỗi tràn bộ đệm 03.09.2001daemon (nkitb)
giữ lại
23.08.2001signedness lỗi tràn bộ đệm trong sendmail
17.08.2001 lỗi tràn bộ đệm fetchmail
lỗi tràn bộ đệm 24.07.2001(xli), địa phương từ xa
18.04.2001exploitable lỗi tràn bộ đệm trong sudo
09.04.lỗi tràn bộ đệm khai thác từ xa 2001xntpd
27.03.2001buffer tràn trong eperl
tác giả
22.03.2001one-byte-buffer tràn trong bsd-ftpd và trong hẹn giờ
31.01.2001buffer tràn trong bind8 (vấn đề mới; Tháng 1 năm 2001)
nán lại bộ đệm overruns2002,
cư dân và còn lại trong mã chương trình thường được quy cho
lỗi tràn bộ đệm Institutevulnerability và tấn công chỉ vẫn lỏng lẻo và không chính thức tài liệu trong các tài liệu. Từ đây, người ta có thể kết luận vấn đề là

"lười", "sloppy", hoặc "uncaring" lập trình, hoặc để trình biên dịch hiện đại không
thực hiện toàn vẹn hoặc giới hạn kiểm tra về nguồn gốc của họ đầu vào hoặc đầu ra máy
hướng dẫn. Tuy nhiên, những quan điểm có thể là một chút quá đơn giản. Gốc rễ của sự

vấn đề có thể chạy sâu hơn đó. Ví dụ, mặc dù sự phổ biến của họ hôm nay,


nói chung không được hiểu rõ. Điều này có thể giải thích lý do tại sao tràn ngập các lỗ hổng
tiếp tục xuất hiện trong các ứng dụng phần mềm mới.
SANS là cần thiết ở đây. Thật vậy, lỗi tràn bộ đệm và khai thác
làm rõ một số ©
vấn đề đang nổi tiếng. Thật không may, "nổi tiếng" và "cũng hiểu" thường là hai quan điểm hoàn toàn khác nhau của cùng một điều. Ví dụ, gần như mỗi cuốn sách, bài viết, hoặc giấy trắng giá trị muối của nó tập trung vào bảo mật máy tính

3 bao gồm W2-ISAPI mở rộng bộ đệm tràn, U1-đệm tràn trong dịch vụ RPC, điểm yếu U3-ràng buộc, U5-LPD (giao thức in từ xa daemon), và U6-sadmind và mountd. 2/6/2003 trang 2 của 24



© SANS viện năm 2002, như là một phần của phòng đọc sách bảo mật thông tin. Tác giả vẫn giữ đầy đủ quyền.

đề cập đến dễ bị tổn thương tràn bộ đệm và các yếu tố cho phép của họ. Họ thường ngay cả trang web preventions hoặc phòng thủ chống lại họ. Tuy nhiên, họ thường tránh thảo luận hoặc mô tả chi tiết phức tạp hoặc các cơ chế phức tạp của nguyên nhân của họ và sử dụng manipulative của họ trong điều kiện mà có thể dễ dàng được hiểu bởi những người mới hoặc thiếu kinh nghiệm lập trình viên, quản trị hệ thống, hoặc máy tính bảo mật chuyên viên hoặc hiệu trưởng.

chắc chắn, một số chi tiết tài khoản của việc khai thác lỗi tràn bộ đệm đã được viết. Những đã được trích dẫn bởi Nicole LaRock Decker trong giấy GSEC của cô "tràn bộ đệm: tại sao, như thế nào và công tác phòng chống". Tuy nhiên, các tài khoản này. được viết bởi đặc biệt rực rỡ, và có lẽ quanh co, lập trình viên đã chọn để nhảy thẳng vào các chi tiết của thấp cấp máy và lắp ráp mã cần thiết
để có hiệu lực khai thác overrun. Một độc giả điển hình của các tài khoản thường trở nên
quyền
bị choáng ngợp bởi đoạn thứ ba, và đưa vào văn bản để nghỉ ngơi.
THE cơ chế đầy đủ
1997 nghiên cứu "Xếp chồng tuyệt VulnerabilitiesretainsInThe hệ điều hành UNIX." Tuy nhiên, các lỗ hổng là không chỉ giới hạn C hoặc UNIX. Thật vậy, cả hai DilDog
bộ đệm tràn lỗ hổng thường được quy cho những ảnh hưởng kết hợp của các
tính năng bảo mật quyền của các hệ điều hành UNIX và khiếm khuyết trong C

ngôn ngữ lập trình. Đó là tiền đề cho rằng bởi Nathan Smith trong

tràn "và"Exploiting Windows NT4 tác giả bộ đệm nghiêm." Giấy "Windows
và David Litchfield chứng minh việc khai thác có thể được sử dụng có hiệu quả chống lại

hạt nhân Windows NT trong giấy tờ tương ứng của họ "Tao Windows đệm

lỗi tràn bộ đệm NT bắt đầu để kết thúc" cho thấy vấn đề hiện tại và có thể trong vòng MFC4 là tốt. Do đó, this2002, giấy xem lỗi tràn bộ đệm như là một ngôn ngữ và một hệ điều hành độc lập vấn đề.
tập đoàn Microsoft xác định tấn công tràn bộ đệm như sau:

Một bộ đệm tràn attackInstituteisan tấn công trong đó một người sử dụng độc hại khai thác một bộ đệm đánh dấu trong một chương trình và sẽ ghi đè mã chương trình với dữ liệu của họ sở hữu. Nếu các

mã chương trình được ghi đè bằng mã thực thi mới, hiệu quả là để thay đổi hoạt động của chương trình là khiển bởi những kẻ tấn công. Nếu ghi đè bằng dữ liệu khác, hiệu quả có khả năng là gây ra chương trình sụp đổ.

Kể từ khi Microsoft đã sản xuất của họ chia sẻ công bằng của bộ đệm tràn lỗ hổng
trong những năm qua, SANS họ nên được thành thạo về vấn đề và chúng tôi không nên


nghi ngờ tính hợp lệ © của mô tả này. Vì vậy, chúng tôi sẽ sử dụng này như chúng tôi làm việc chính thức
định nghĩa. Nhưng những gì chính xác này có nghĩa là? Và, làm thế nào để chúng tôi có được có?


4 MFC là viết tắt của Microsoft Foundation Class, Thư viện C OOP của Microsoft.

Kết quả (Việt) 2:

INSIDE THE ATTACK BUFFER tràn: cơ chế, phương pháp, và PHÒNG Mark E. Donaldson 03 tháng 4 2002 GSEC Phiên bản 1.3 TÓM TẮT Mục tiêu của nghiên cứu này là để có một bên trong cuộc tấn công tràn bộ đệm và thu hẹp khoảng cách giữa "mô tả tài khoản" và "tài khoản kỹ thuật chuyên sâu". Mục đích là để cung cấp một hợp lý, chi tiết, và kỹ thuật. giải thích về những vấn đề và khai thác có thể được hiểu rõ tất cả, bao gồm cả những người có chút nền tảng về cơ chế và phương pháp luận của các ứng dụng lập trình. quyền Chúng tôi sẽ bắt đầu bằng cách nhìn vào "vấn đề" và problemfull "cơ chế", và sau đó điều tra "có nghĩa là" và "phương pháp". Dựa trên những gì chúng ta thấy, chúng tôi sẽ quan tâm an ninh, chắc chắn nó nằm trong khả năng realmretainsof rằng cuộc tấn công tràn bộ đệm được giảm đến một mức độ vô nghĩa thông qua đúng kết luận với các khuyến nghị, và một trình đơn cho "phòng ngừa". Hy vọng rằng đây cách tiếp cận cũng có thể giúp thu hẹp khoảng cách giữa "kiến thức" và "hiểu biết". Mặc dù nó có thể không bao giờ có thể tẩy thế giới này hiểu biết. Robert Louis StevensonAuthoronce đã viết: "Hãy nhìn vào chính mình. Bạn có thể là một bác sĩ, một người đàn ông chữa bệnh, với những điều đôi mắt đã thấy? Có rất nhiều kiến thức trong đôi mắt, nhưng không có understanding.1 "Cộng đồng công nghệ phải di chuyển từ đấu tranh chống các cuộc tấn công tràn bộ đệm phòng thủ để chiến đấu với họ tấn công. Để làm điều này, họ phải chuyển đổi kiến thức của họ vào sự hiểu biết. VẤN ĐỀ 2002, đệm có vấn đề Instituteoverruns2 liên quan đến lập trình C mô hình toàn vẹn dữ liệu ngôn ngữ lần đầu tiên được công nhận vào đầu năm 1973 cũng được biết đến đầu tiên khai thác của lỗ hổng này xảy ra vào năm 1988 khi tốt tài liệu và Internet nổi tiếng mòn tắt máy hơn 6.000 hệ thống chỉ trong vài giờ ngắn ngủi, sử dụng một bộ đệm không được kiểm soát khởi tạo bởi được () gọi chức năng trong fingerd quá trình daemon. Mặc dù có lịch sử lâu dài này và các phương pháp phòng ngừa đơn giản, lỗi tràn bộ đệm tiếp tục là một bảo mật máy tính quan trọng và nổi bật mối quan tâm ngày nay. Ví dụ, vấn đề tràn bộ đệm được liên quan đến © SANS 1 Robert Louis Stevenson từ "The Body Snatcher" được xuất bản vào năm 1881. 2 tràn bộ đệm đã giả định nhiều tên khác nhau trong những năm qua. Chúng bao gồm đệm tràn ngập, chồng bị tàn phá, và tràn stack. Trong thực tế, tất cả các điều khoản chia sẻ cùng một định nghĩa và có thể được sử dụng đồng nghĩa và thay thế cho nhau. Ngoài ra, tràn bộ đệm khai thác thường được gọi là "chồng đập" theo cách nói ngày nay. 2003/02/06 Trang 1 của 24 © SANS Institute năm 2002, Là một phần của Reading Room bảo mật thông tin. Tác giả giữ toàn quyền. năm của Sans "Top 20" vulnerabilities.3 Nếu một phiêu lưu đến SuSE Linux trang web, họ sẽ tìm thấy 22 lỗ hổng tràn bộ đệm kể từ tháng Giêng năm 2001 đòi hỏi phải vá (xem bảng I). . Ngoài ra, trong số 44 khuyến cáo CERT công bố từ năm 1997 đến năm 1999, 24 có liên quan đến các vấn đề tràn bộ đệm BẢNG tôi BUFFER lỗ hổng tràn SUSE Linux ngày dễ bị tổn thương 2002/03/12 lỗi tràn bộ đệm trong thư viện zlib. 2002/04/03 tràn bộ đệm trong mực 28.02.2002revised: tràn bộ đệm trong cupsd 2002/02/28 tràn bộ đệm trong mod_php4 và mod php 25.02.2002buffer tràn trong cupsd tràn 25.01.2002buffer trong rsync tràn bộ đệm trong rsync 16.01.2002buffer tràn tham nhũng trong / usr / bin / tại quyền 07.01.2002buffer tràn trong mutt 24,12 .2001buffer tràn trong glibc globbing functionsfull vấn đề 03.12.2001buffer tràn trong openssh 28.11.2001buffer tràn trong wuftpd 2001/10/10 tràn trong lpd / lprold 20.09.2001buffer tràn trong WindowMaker 03.09.2001daemon tràn bộ đệm (nkitb) giữ 23.08.2001signedness tràn bộ đệm trong sendmail 2001/08/17 fetchmail tràn bộ đệm 2001/07/24 (xli) tràn bộ đệm, địa phương + từ xa 18.04.2001exploitable tràn bộ đệm trong sudo 09.04.2001xntpd khai thác từ xa lỗi tràn bộ đệm 27.03.2001buffer tràn trong eperl Tác giả tràn 22.03.2001one-byte bộ đệm trong bsd- ftpd và hẹn giờ tràn 31.01.2001buffer trong bind8 (vấn đề mới; Tháng 1 năm 2001) kéo dài overruns2002 đệm, thường trú và để lại trong mã chương trình thường do lỗi tràn bộ đệm Institutevulnerability và tấn công chỉ còn lại một cách lỏng lẻo và không chính thức ghi nhận trong các tài liệu. Từ này có thể kết luận vấn đề là "lười biếng", "cẩu thả", hoặc lập trình "không quan tâm", hoặc các trình biên dịch hiện đại mà không thực hiện nguyên vẹn hoặc kiểm tra giới hạn về nguồn đầu vào hay đầu ra máy hướng dẫn. Tuy nhiên, những quan điểm này có thể là một chút quá đơn giản. Các gốc rễ của vấn đề có thể chạy sâu hơn. Ví dụ, mặc dù tỷ lệ hiện nay của họ, nói chung chưa được hiểu rõ. Điều này có thể giải thích tại sao lỗ hổng tràn tiếp tục xuất hiện trong các ứng dụng phần mềm mới. SANS là cần thiết ở đây. Thật vậy, lỗi tràn bộ đệm và khai thác Một số làm rõ © vấn đề là cũng được biết đến. Thật không may, "nổi tiếng" và "hiểu rõ" thường là hai quan điểm hoàn toàn khác nhau của cùng một điều. Ví dụ, hầu hết các cuốn sách, bài báo, hoặc giấy trắng trị giá muối của nó tập trung vào bảo mật máy tính , bao gồm 3 W2-ISAPI mở rộng tràn bộ đệm, U1-đệm tràn trong RPC dịch vụ, điểm yếu U3-Bind, U5-LPD (giao thức in ấn từ xa daemon), và U6-sadmind và mountd. 2003/02/06 Trang 2 trong 24 © SANS Institute năm 2002, Là một phần của Reading Room bảo mật thông tin. Tác giả giữ toàn quyền. đề cập đến lỗ hổng tràn bộ đệm và các yếu tố cho phép của họ. Họ thường thậm chí biện pháp can thiệp tại chỗ hoặc phòng thủ chống lại họ. Tuy nhiên, họ thường tránh thảo luận hoặc mô tả các chi tiết phức tạp hoặc các cơ chế phức tạp của sự nghiệp của họ và sử dụng thao tác của họ trong điều kiện có thể dễ dàng được hiểu bởi những người mới hoặc thiếu kinh nghiệm lập trình, quản trị hệ thống, hoặc học bảo mật máy tính hoặc hiệu trưởng. Chắc chắn, một số tài khoản chi tiết của khai thác lỗi tràn bộ đệm đã được viết. Chúng được trích dẫn bởi Nicole Larock Decker trong giấy GSEC của cô "tràn bộ đệm: Tại sao, như thế nào và phòng ngừa". Tuy nhiên, các tài khoản này. được viết bởi các lập trình đặc biệt xuất sắc, và có lẽ quanh co, đã chọn để nhảy thẳng vào các chi tiết của máy ở mức độ thấp và mã lắp ráp cần thiết để thực hiện việc khai thác tràn. Một độc giả điển hình của các tài khoản này thường trở thành quyền bị choáng ngợp bởi đoạn thứ ba, và đặt tài liệu để nghỉ ngơi. CƠ CHẾ đầy đủ 1997 nghiên cứu "Stack Smashing VulnerabilitiesretainsInThe Hệ điều hành UNIX." Tuy nhiên, lỗ hổng này không chỉ giới hạn trong C hoặc UNIX. Thật vậy, cả hai DilDog lỗ hổng tràn bộ đệm thường được cho là do ảnh hưởng kết hợp của các tính năng cho phép bảo mật của hệ điều hành UNIX và các khuyết tật trong C ngôn ngữ lập trình. Như vậy là tiền đề cho rằng Nathan Smith trong mình tràn "và" Khai thác Windows NT4 Tác giả đệm vượt. "Bài báo" Windows và David Litchfield đã chứng minh có thể được khai thác sử dụng có hiệu quả chống lại các nhân Windows NT trong các giấy tờ tương ứng của họ "The Tao của Windows đệm Bắt đầu NT tràn bộ đệm để Finish "cho thấy vấn đề hiện tại và có thể trong MFC4 là tốt. Do đó, this2002, giấy views tràn bộ đệm như một ngôn ngữ và một hệ điều hành vấn đề độc lập. Tập đoàn Microsoft xác định cuộc tấn công tràn bộ đệm như sau: Một lỗi tràn bộ đệm attackInstituteisan tấn công, trong đó một người dùng độc hại khai thác một bộ đệm không được kiểm soát trong một chương trình và ghi đè các chương trình mã với dữ liệu của mình. Nếu các mã chương trình được ghi đè bằng mã thực thi mới, hiệu quả là thay đổi hoạt động của chương trình là quyết định bởi những kẻ tấn công. Nếu ghi đè bằng các dữ liệu khác, các tác động có thể là để làm cho chương trình bị lỗi. Kể từ khi Microsoft đã sản xuất chia sẻ công bằng của họ về lỗ hổng tràn bộ đệm trong những năm qua, SANS họ cần phải thành thạo về vấn đề này và chúng ta không nên nghi ngờ về tính hợp lệ của © Mô tả này. Vì vậy, chúng tôi sẽ sử dụng như làm việc chính thức của chúng tôi định nghĩa. Nhưng chính xác điều này có nghĩa là gì? Và, làm thế nào để chúng ta đạt được điều đó? 4 MFC là viết tắt của Microsoft Foundation Class, C của Microsoft ++ thư viện OOP.