buffer overflow

back to index

description: anomaly in computer security and programming that could be exploited as a security vulnerability

60 results

The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities

by Justin Schuh  · 20 Nov 2006  · 2,054pp  · 359,149 words

Tools Fuzz-Testing Tools Case Study: OpenSSH Preassessment Implementation Analysis High-Level Attack Vectors Documentation of Findings Summary II. Software Vulnerabilities 5. MEMORY CORRUPTION Introduction Buffer Overflows Process Memory Layout Stack Overflows Off-by-One Errors Heap Overflows Global and Static Data Overflows Shellcode Writing the Code Finding Your Code in Memory

one of the primary charges of the code review process. Implementation vulnerabilities encompass several well-publicized vulnerability classes you’ve probably heard of, such as buffer overflows and SQL injection. Going back to the TELNET example, you can also find implementation vulnerabilities in specific versions of TELNET software. Some previous implementations of

they often influence the selection of one platform over another. Therefore, these measures are viewed as operational, not implementation measures. Nonexecutable Stack The classic stack buffer overflow is quite possibly the most often-used software vulnerability in history, so hardware vendors are finally trying to prevent them at the lowest possible level

length parameter is unsigned; it’s unlikely that signed integer vulnerabilities will be found. Code comprehension strategies identify the consistent use of a buffer structure. Buffer overflows seem unlikely due to the consistent use of these buffer mechanisms. You might want to do a candidate point search to identify double free() vulnerabilities

numerous online resources about exploitation techniques, such as phrack magazine (www.phrack.org) and Uninformed magazine (www.uninformed.org). * * * Buffer Overflows You’re probably familiar with the term “buffer overflow,” but if not, a buffer overflow is a software bug in which data copied to a location in memory exceeds the size of the reserved destination

how the CPU and OS manage processes. * * * Note Some of the vulnerabilities in this book are more complex memory corruption vulnerabilities that aren’t technically buffer overflows, but share many of the same characteristics. This discussion of exploitability is largely applicable to these types of issues, especially the “Assessing Memory Corruption Impact

based on where the buffer is located. The following sections address common and unique attack patterns associated with each location. Stack Overflows Stack overflows are buffer overflows in which the target buffer is located on the runtime program stack. They are the most well understood and, historically, the most straightforward type of

how variables are ordered internally in a stack frame. The compiler can (and often does) reorder variables for optimization purposes. * * * The authenticate() function has a buffer overflow. Specifically, the sprintf() function doesn’t limit the amount of data it writes to the output buffer. Therefore, if the username string is around 1024

in this segment requires application-specific attacks similar to the vulnerability in Listing 5-2. Exploitability depends on what variables can be corrupted when the buffer overflow occurs and how the variables are used. For example, if pointer variables can be corrupted, the likelihood of exploitation increases, as this corruption introduces

the possibility for arbitrary memory overwrites. Shellcode Buffer overflows are usually exploited by directing execution to a known location in memory where attacker-controlled data is stored. For an exploit to be successful, this

into serving the attacker’s purpose. Address Space Layout Randomization Address space layout randomization (ASLR) is a technology that attempts to mitigate the threat of buffer overflows by randomizing where application data and code is mapped at runtime. Essentially, data and code sections are mapped at a (somewhat) random memory location when

they are loaded. Because a crucial part of buffer overflow exploitation involves overwriting key data structures or returning to specific places in memory, ASLR should, in theory, prevent reliable exploitation because attackers can no longer

implications of negative values in signed types and see whether unexpected results can be produced that could lead to security exposures. In this case, a buffer overflow can be triggered because of the erroneous length check; consequently, the oversight is quite serious. * * * Auditing Tip: Signed/Unsigned Conversions You want to look

code of l0pht’s antisniff tool (http://packetstormsecurity.org/sniffers/antisniff/). It’s an excellent bug for demonstrating some vulnerabilities that have been discussed. A buffer overflow was first discovered in the software involving the improper use of strncat(), and after that vulnerability was patched, researchers from TESO discovered that it was

Therefore, when reviewing this application, you must determine whether any of these variable relationships can be violated, as the resulting inconsistent state could cause a buffer overflow. In this code, two variables could become desynchronized in one instance: the buf and alloc variables. This problem occurs in buffer_append_space(), which is

present a potential vulnerability. Listing 7-17 from NTPD, the network time protocol (NTP) daemon, demonstrates a more complicated copying loop. Listing 7-17. NTPD Buffer Overflow Example while (cp < reqend && isspace(*cp)) cp++; if (cp == reqend || *cp == ',') { buf[0] = '\0'; *data = buf; if (cp < reqend) cp++; reqpt = cp; return v; }

the wrong order. Because ptr has already been incremented, maxsize is decremented by zero. Therefore, maxsize fails to account for the time string, and a buffer overflow could occur when vsnprintf() is called with the incorrect length. Multiple Length Calculations on the Same Input A common situation that leads to length miscalculations

vulnerabilities in the past. If the destination buffer supplied as the first parameter isn’t large enough to handle the input data elements, a buffer overflow could occur. Buffer overflows happen primarily because of printing large strings (using the %s or %[] format specifiers). Although less common, other format specifiers (such as %d or %

\n"); OutputDebugString(szBuf); #endif } This example is a classic misuse of vsprintf(). The destination buffer’s size isn’t accounted for at all, so a buffer overflow occurs if the vsprintf() function can be called with any string larger than 2048 bytes. * * * Note The _wsprintfA() and _wsprintfW() functions copy a maximum

when supplying the correct length parameter to strncat (that is, sizeof(buf) – strlen(buf) – 1), an integer underflow could occur, also resulting in a buffer overflow. strlcpy() The strlcpy() function is a BSD-specific extension to the libc string APIs. It attempts to address the shortcomings of the strncpy() function. Specifically

parameter is returned. Common Issues Parsing text at the character level can be a complicated task. Small oversights made by application developers can result in buffer overflows, operating on uninitialized memory regions, or misinterpretations of the content. Code auditors need to focus on code regions that manipulate text, particularly write operations

the cchWideChar parameter. Doing this means twice as many bytes could be written to the output buffer than space has been allocated for, and a buffer overflow might occur. The MultiByteToWideChar() function is summarized in the following list: • Function—int MultiByteToWideChar(UINT CodePage, DWORD dwFlags, LPCSTR lpMultiByteStr, int cbMultiByte, LPWSTR lpWideCharStr,

= (WCHAR *)calloc(length, sizeof(WCHAR)); MultiByteToWideChar(cp, 0, instr, -1, outstr, -1); return outstr; } The MultiByteToWideChar() function in Listing 8-32 is vulnerable to a buffer overflow when a multibyte code page is used. Why? Because the output string length is calculated by multiplying the input string length by two. However, this

-frees. Anthony Osborne and John McDonald (one of this book’s authors) published an advisory for Network Associates (NAI)’s Covert Labs that outlined multiple buffer overflows in several glob() implementations used in FTP daemons. The advisory is archived at www.securityfocus.com/advisories/3202. * * * Environment Issues In addition to the

connections. When auditing proxy firewalls you want to focus on the same kinds of issues you would encounter when auditing network servers. Specifically, numeric issues, buffer overflows, format strings, and similar implementation-level bugs are likely to show up in parsers for complex network protocols. In addition, you should focus on making

result from type conversions and arithmetic boundary conditions. Text-based protocols, on the other hand, tend to contain vulnerabilities related more to text processing—standard buffer overflows, pointer arithmetic errors, off-by-one errors, and so forth. * * * Note One exception is text-based protocols specifying lengths in text that are converted

|| memcmp(vendor->data, MYVERSION, sizeof(MYVERSION)){ sprintf(buffer, "warning, unknown client version: %s\n", vendor->data); log(buffer); return 0; } return 1; } Obviously, a straightforward buffer overflow exists if a vendor ID larger than 1,024 bytes is supplied to the parse_version() function. Encryption Vulnerabilities ISAKMP is now a widely accepted

might look like this: <?xml version = "1.0" encoding="UTF-8"> XER Vulnerabilities The most likely vulnerabilities in XER are obviously text-based errors—simple buffer overflows or pointer arithmetic bugs. When auditing XER implementations, remember that programs that exchange data by using XER are often exposing a huge codebase to untrusted

Keith, 637 BSD linux, 459 securelevels, 492 setenv( ) function, 576-577 BUF-MEM_grow( ) function, 311-312 buffer overflow, text-based protocols, 933-934 Buffer Overflow in NSS Library’s ssl2_HandleClientHelloMessage listing (7-34), 365 buffer overflows, 168-169 global overflows, 186 heap overflows, 183-186 off-by-one errors, 180-183 process memory layout

3), 216 change monitoring, 83 Character Black-List Filter listing (8-22), 435 character equivalence, Unicode, 456-457 character expansion, text strings, 401 Character Expansion Buffer Overflow listing (8-4), 401 character sets, 446 character stripping vulnerabilities, metacharacters, filtering, 437-439 character types, C programming language, 205 Character White-List Filter listing

1038 stack cookies, 190-191 COPY method, 1022 core files, 519 CoRegisterClassObject( ) function, 744 Correct Use of GetFullPathName( ) listing (8-13), 416 corruption (memory), 167 buffer overflows, 168-169 global overflows, 186 heap overflows, 183-186 off-by-one errors, 180-183 process memory layout, 169 SHE (structured exception handling) attacks, 178

vendor ID payloads, 971 TCP headers, 865 validation, 866-867 UDP headers, validation, 864 headers (HTTP), Referer, 1030-1031 heap hardening, 191-193 heap overflows, buffer overflows, 183-186 heap protection, operational vulnerabilities, preventing, 77-78 Henriksen, Inge, 1089 HERT (Hacker Emergency Response Team), 877 Hex-encoded Pathname Vulnerability listing (8-27

Vulnerabilities), 322 7-13 (List Pointer Update Error), 324 7-14 (Linux Teardrop Vulnerability), 325 7-15 (Simple Nonterminating Buffer Overflow Loop), 328 7-16 (MS-RPC DCOM Buffer Overflow Listing), 329 7-17 (NTPD Buffer Overflow Example), 329 7-18 (Apache mod_php Nonterminating Buffer Vulnerability), 331 7-19 (Apache 1.3.29/2.X

Use in ProFTPD), 354 7-32 (Sendmail Return Value Update Vulnerability), 356 7-33 (Length Miscalculation Example for Constructing an ACC log), 362 7-34 (Buffer Overflow in NSS Library’s ssl2_HandleClientHelloMessage), 365 7-35 (Out-of-Order Statements), 366 7-36 (Netscape NSS Library UCS2 Length Miscalculation), 367 7-37

memory, 0 bytes, allocating, 370-371 memory blocks, shared memory blocks, 201-202 memory buffers, unitialized memory buffers, 314 memory corruption, 167 assessing, 196-202 buffer overflows, 168-169 global overflows, 186 heap overflows, 183-186 off-by-one errors, 180-183 process memory layout, 169 SHE (structured exception handling) attacks, 178

loosely coupled modules, 33 strongly coupled modules, 33 Modulus Vulnerability Example listing (6-28), 275 mount points, UNIX, 463 MOVE method, 1022 MS-RPC DCOM Buffer Overflow Listing listing (7-16), 329 MSDN (Microsoft Developer Network), 626 MTA (mulitthreaded apartment), COM (Component Object Model), 729 multibyte character sequences, interpretation, 455 MultiByteToWideChar( )

payloads, ISAKMP (Internet Security Association and Key Management Protocol), 966-968 NSAPI (Netscape Server Application Programming Interface), 1010 NTP (network time protocol) daemon, 329 NTPD Buffer Overflow Example listing (7-17), 329 NtQuerySystemInformation( ) function, 632 NUL byte injection queries, Perl, 1094 NUL Bytes in Multibyte Code Pages listing (8-32), 456

descriptor objects, 631 handles, 632-636 namespaces, 629-632 nonsecurable objects, 629 SymbolicLink objects, 629 system objects, 628 Oechslin, Philippe, 46 off-by-one errors, buffer overflows, 180-183 Off-by-One Length Miscalculation listing (5-2), 175 Off-by-One Length Miscalculation listing (5-3), 181 Off-by-One Overwrite listing

27 Problems with 64-bit Systems listing (7-42), 375 proc file system (UNIX), 511 procedures, stored, 1063-1064 Process Explorer, 636 process memory layout, buffer overflows, 169 process outline, code review, 93 processes multiple process, shared memory, 756 process synchronization, 762 interprocess synchronization, 770-783 lock matching, 781-783 synchronization object

-791 SIGSTOP default action, 787 simple binary CPs (candidate points), 122 simple lexical CPs (candidate points), 122 Simple Mail Transfer Protocol (SMTP), 921 Simple Nonterminating Buffer Overflow Loop listing (7-15), 328 Simple Object Access Protocol (SOAP), 1085 simple type conversions, C programming language, 231-232 single sign-on (SSO) system,

The C++ Programming Language

by Bjarne Stroustrup  · 2 Jan 1986  · 923pp  · 516,602 words

a place where runtime efficiency is crucial and where inlining is a must. Virtual functions are used to achieve flexibility for the operations dealing with buffer overflow and underflow only (§21.6.4). However, a programmer sometimes wants to output an object for which only a base class is known. Since the

Gray Hat Python: Python Programming for Hackers and Reverse Engineers

by Justin Seitz  · 15 Feb 2009  · 312pp  · 52,762 words

. DLL AND CODE INJECTION Remote Thread Creation DLL Injection Code Injection Getting Evil File Hiding Coding the Backdoor Compiling with py2exe 8. FUZZING Bug Classes Buffer Overflows Integer Overflows Format String Attacks File Fuzzer file_fuzzer.py Future Considerations Code Coverage Automated Static Analysis 9. SULLEY Sulley Installation Sulley Primitives Strings Delimiters

events where applicable. An advantage of a scripted debugger is the ability to build custom event handlers to automate certain debugging tasks. For example, a buffer overflow is a common cause for memory violations and is of great interest to a hacker. During a regular debugging session, if there is a

buffer overflow and a memory violation occurs, you must interact with the debugger and manually capture the information you are interested in. With a scripted debugger, you

doesn't have permission to access or in a particular way that it is not allowed. The faults that lead to access violations range from buffer overflows to improperly handled null pointers. From a security perspective, every access violation should be reviewed carefully, as the violation might be exploited. When an access

output all of the pertinent crash information. Let's first create a test harness that will use the dangerous C function strcpy() to create a buffer overflow. Following the test harness, we will write a brief PyDbg script to attach to and handle the access violation. Let's start with the test

script. Open a new file called buffer_overflow.py, and enter the following code. buffer_overflow.py from ctypes import * msvcrt = cdll.msvcrt # Give the debugger time to attach, then hit a button raw_input("Once the debugger

, press any key.") # Create the 5-byte destination buffer buffer = c_char_p("AAAAA") # The overflow string overflow = "A" * 100 # Run the overflow msvcrt.strcpy(buffer, overflow) Now that we have the test case built, open a new file called access_violation_handler.py, and enter the following code. access_violation_handler

= raw_input("Enter the Process ID: ") dbg = pydbg() dbg.attach(int(pid)) dbg.set_callback(EXCEPTION_ACCESS_VIOLATION,check_accessv) dbg.run() Now run the buffer_overflow.py file and take note of its PID; it will pause until you are ready to let it run. Execute the access_violation_handler.py

PyDbg, we will build a utility program to help root out (pun intended) exploitable flaws in software applications. Certain function calls are more prone to buffer overflows, format string vulnerabilities, and memory corruption. We want to pay particular attention to these dangerous functions. The tool will locate the dangerous function calls and

found in software that runs as an independent process on the host operating system and are most likely to result in a successful host compromise. Buffer Overflows Buffer overflows are the most common type of software vulnerability. All kinds of innocuous memory-management functions, string-manipulation routines, and even intrinsic functionality are part of

the programming language itself and cause software to fail because of buffer overflows. In short, a buffer overflow occurs when a quantity of data is stored in a region of memory that is too small to hold it. A metaphor to explain

is overwritten, he is on his way to getting full code execution and ultimately a compromise in some form or another. There are two primary buffer overflow types: stack-based overflows and heap-based overflows. These types behave quite differently but still produce the same result: attacker-controlled code execution. A stack

overflow is characterized by a buffer overflow that subsequently overwrites data on the stack, which can be used as a means to control execution flow. Code execution can be obtained from a

associated PyCommand to make Gflags changes, and it ships with Immunity Debugger. For download and documentation, visit http://debugger.immunityinc.com/. In order to target buffer overflows from a fuzzing perspective, we simply try to pass very large amounts of data to the target application in the hope that it will make

take a look at a contrived example of how an integer overflow can result in allocating far too little space and possibly resulting in a buffer overflow down the road: MOV EAX, [ESP + 0x8] LEA EDI, [EAX + 0x24] PUSH EDI CALL msvcrt.malloc The first instruction takes a parameter off the stack

memory than what the developer intended to allocate. If this small buffer is supposed to hold a large portion of user-supplied input, then a buffer overflow occurs. To target integer overflows with a fuzzer, we need to make sure we are passing both high positive numbers and low negative values in

an attempt to achieve an integer overflow, which could lead to undesired behavior in the target application or even a full buffer overflow condition. Now let's take a quick peek at format string attacks, which are another common bug found in applications today. Format String Attacks Format

configured to either allow anonymous users to connect to the server or force users to authenticate. Because we know that the WarFTPD bug involves a buffer overflow in the USER and PASS commands (both of which are used for authentication), we are going to assume that authentication is required. The format for

The IDA Pro Book

by Chris Eagle  · 16 Jun 2011  · 1,156pp  · 229,431 words

the destination buffer is sufficient to hold all of the data to be copied from source. Such unchecked copy operations are a major cause of buffer overflow vulnerabilities. In the example shown in Example 15-4, we work in reverse to iterate across all of the cross-references to (as opposed to

dedicated to IDA. What we will do is assume that the reader is familiar with some of the basic concepts of software vulnerabilities, such as buffer overflows, and discuss some of the ways that IDA may be used to hunt down, analyze, and ultimately develop exploits for those vulnerabilities. Discovering New Vulnerabilities

strcpy label and then choosing View ▸ Open Subviews ▸ Cross References. Visit each cross-reference and analyze the parameters provided to strcpy to determine whether a buffer overflow may be possible. Step 3 may require a substantial amount of code and data-flow analysis to understand all potential inputs to the function call

example, consider the task of locating all functions that contain stack-allocated buffers, since these are the functions that might be susceptible to stack-based buffer-overflow attacks. Rather than manually scrolling through a database, we can develop a script to analyze the stack frame of each function, looking for variables that

, many computers continue to run operating systems that allow code to be executed in the stack, as is done in a plain-vanilla stack-based buffer-overflow attack. Even when stack protections are in place, overflows may be used to corrupt stack-based pointer variables, which can be further leveraged to complete

an attack. Regardless of what you intend to do when you discover a stack-based buffer overflow, it is vital to understand exactly what stack content will be overwritten as your data overflows the vulnerable stack buffer. You will probably also be

and Naming Stack View window, Basic Debugger Displays stack-allocated arrays, Stack-Allocated Arrays stack-allocated structures, Stack-Allocated Structures, Using Structure Templates stack-based buffer overflow, IDA and the Exploit-Development Process stack-manipulation operations, Sequential Flow Instructions standard calling convention, The C Calling Convention standard structures, Parsing C Header Files

Hacking Exposed: Network Security Secrets and Solutions

by Stuart McClure, Joel Scambray and George Kurtz  · 15 Feb 2001  · 260pp  · 40,943 words

. Think of the implications of this if you were logged in with root privileges while web surfing. What if your sniffer is susceptible to a buffer overflow attack (http://www.w00w00.org/advisories/snoop.html)? Throughout this section, we will address specific remote attacks that fall under one of the preceding three

Profit.” This article had a profound effect on the state of security as it popularized how poor programming practices can lead to security compromises via buffer overflow attacks. Buffer overflow attacks date as far back as 1988 and the infamous Robert Morris Worm incident; however, useful information about specific details of this attack was

Color profile: Generic CMYK printer profile Composite Default screen Hacking / Hacking Exposed: Network Security / McClure/Scambray / 2748-1 / Chapter 8 Chapter 8: Hacking UNIX A buffer overflow condition occurs when a user or process attempts to place more data into a buffer (or fixed array) than was originally allocated. This type of

behavior is associated with specific C functions like strcpy(), strcat(), and sprintf(), among others. A buffer overflow condition would normally cause a segmentation violation to occur. However, this type of behavior can be exploited to gain access to the target system. Although

program. Instead of the function returning to its proper memory location, the attackers execute the nefarious assembly code that was sent as part of the buffer overflow data, which will run /bin/sh with root privileges. Game over. It is imperative to remember that the assembly code is architecture and operating system

dependent. A buffer overflow for Solaris X86 running on Intel CPUs is completely different from one for Solaris running on SPARC systems. The following listing illustrates what an egg

shellcode creation tools, can be found at http://teso.scene.at/releases.php3. Overflow Attack Countermeasures U Buffer Secure Coding Practices The best countermeasure for buffer overflow is secure programming practices. Although it is impossible to design and code a program that is completely free of bugs, there are steps that help

minimize buffer overflow conditions. These recommendations include the following: ▼ Design the program from the outset with security in mind. All too often, programs are coded hastily in an

(http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/). Their approach is to immunize the programs at compile time to help minimize the impact of buffer overflow. Additionally, proof-of-concept defense mechanisms include Libsafe (http://www.bell-labs.com/org/11356/html/security.html), which aims to intercept calls to vulnerable

functions on a systemwide basis. For a complete description of Libsafe’s capabilities and gory detail on exactly how buffer overflows work, see (http://www.bell-labs.com/org/11356/docs/ libsafe.pdf ). Keep in mind that these mechanisms are not a silver bullet, and users

calls. ■ Reduce the amount of code that runs with root privileges. This includes minimizing the use of SUID root programs where possible. Even if a buffer overflow attack were executed, users would still have to escalate their privileges to root. ▲ Above all, apply all relevant vendor security patches. P:\010Comp\Hacking\748

is the OpenBSD (www.openbsd.org) project run by Theo de Raadt. The OpenBSD camp continually audits their source code and has fixed hundreds of buffer overflow conditions, not to mention many other types of security-related problems. It is this type of thorough auditing that has given OpenBSD a reputation for

/ipf/ipf-howto.html for more information. Disable Stack Execution Some purists may frown on disabling stack execution in favor of ensuring each program is buffer-overflow free. It has few side effects, however, and protects many systems from some canned exploits. In Linux there is a no-stack execution patch available

programmer extraordinaire, Solar Designer. For Solaris 2.6 and 7, we highly recommend enabling the “no-stack execution” settings. This will prevent many Solaris-related buffer overflows from working. Although the SPARC and Intel application binary interface (ABI) mandate that the stack has execute permission, most programs can function correctly with stack

the latest “warez.” In addition to the risks associated with allowing anonymous access, FTP servers have had their fair share of security problems related to buffer overflow conditions and other insecurities. One of the latest FTP vulnerabilities has been discovered in systems running wu-ftpd 2.6.0 and earlier versions (ftp

. There have been scores of sendmail security vulnerabilities discovered over the last ten years, and there are more to come. Many vulnerabilities related to remote buffer overflow conditions and input validation attacks have been identified. One of the most popular sendmail attacks was the sendmail pipe vulnerability that was present in sendmail

the privileges of bin: helo mail rcpt data . mail rcpt data from: | to: bounce from: bin to: | sed '1,/^$/d' | sh Aside from the common buffer overflow and input validation attacks, it is quite possible to exploit sendmail’s functionality to gain privileged access. A common attack is to create or modify

profile: Generic CMYK printer profile Composite Default screen Hacking / Hacking Exposed: Network Security / McClure/Scambray / 2748-1 / Chapter 8 Chapter 8: Hacking UNIX ploit the buffer overflow condition and send back an xterm or a reverse telnet and the game is over. Other dangerous RPC services include rpc.statd (http://www.cert

allows remote access of an exported file system. The potential for abusing NFS is high and is one of the more common UNIX attacks. Many buffer overflow conditions related to mountd, the NFS server, have been discovered. Additionally, NFS relies on RPC services and can be easily fooled into allowing attackers to

. Any SUID program that is dynamically linked to libc and honors the LC_MESSAGES environmental variable is subject to a buffer overflow attack. This buffer overflow condition affects many different programs because it is a buffer overflow in the system libraries (libc) rather than one specific program, as discussed earlier. This is an important point, and

one of the reasons we chose this example. It is possible for a buffer overflow condition to affect many different programs if the overflow condition exists in libc. Let’s discuss how this vulnerability is exploited. First, we need to

this vulnerability. As you can imagine, the ease of obtaining root access is a major attraction to most attackers when using local buffer overflow exploits. Buffer Overflow Countermeasure U Local The best buffer overflow countermeasure is secure coding practices combined with a non-executable stack. If the stack had been non-executable, we would have had

a much harder time trying to exploit this vulnerability. See the remote “Buffer Overflow Attacks” section earlier for a complete listing of countermeasures. Evaluate and remove the SUID bit on any file that does not absolutely require SUID permissions

more abuse than a SUID root file. Almost every attack previously mentioned abused a process that was running with root privileges—most were SUID binaries. Buffer overflow, race conditions, and symlink attacks would be virtually useless unless the program were SUID root. It is unfortunate that most UNIX vendors slap on the

/ 2748-1 / Chapter 8 Chapter 8: Hacking UNIX local exploitation techniques may allow attackers to subvert the security of even the most hardened UNIX systems. Buffer overflow conditions are discovered daily. Insecure coding practices abound, while adequate tools to monitor such nefarious activities are outdated in a matter of weeks. It is

at this writing.) Java is a carefully designed language that restrains programmers from making many of the mistakes that lead to security problems, such as buffer overflows. Strong typing of the language is enforced at compile and also at execution time by the Java Virtual Machine (JVM) and its built-in bytecode

our testing, setting security zones to an appropriate level takes care of this problem. (See the discussion of security zones earlier.) MOutlook/OE Date Field Buffer Overflow Popularity: Simplicity: Impact: Risk Rating: 7 9 10 9 Does it seem that ActiveX lies at the heart of most of these exploits? On July

code revelation attacks like ::$DATA, information exposures via sample scripts like showcode.asp, piggybacking privileged command execution on backend database queries (MDAC/RDS), and straightforward buffer overflow exploits (IISHack). Although all these issues have been patched in IIS 5, a new crop of exposures has arisen to keep system administrators busily applying

some groundwork for Web hacking and discussed the basic toolkit, let’s talk about some specific IIS 5 attacks: ▼ Buffer overflows ■ File system traversal ▲ Source code revelation IIS 5 Buffer Overflows Practically exploitable remote buffer overflows on Windows are rare, but many of the most serious have been discovered in IIS. The first was the .htr

, as shown in the following example, where [buffer] is approximately 420 characters. GET /NULL.printer HTTP/1.0 Host: [buffer] This simple request causes the buffer overflow and would normally halt IIS; however, Windows 2000 automatically restarts IIS (inetinfo.exe) after such crashes to provide greater resiliency for Web services. Thus, this

214 2000: Network Security Secrets & Solutions / Scambray & McClure / 9262-3 / Chapter 10 Hacking Exposed Windows 2000: Network Security Secrets & Solutions jill essentially exploits the IPP buffer overflow and “shovels a shell” back to the attackers system (see Chapter 7 for details on shell shoveling). The shoveled shell runs in the context of

: Network Security Secrets & Solutions / Scambray & McClure / 9262-3 / Chapter 10 Hacking Exposed Windows 2000: Network Security Secrets & Solutions Figure 10-1. To prevent the .printer buffer overflow exploit and many like it that rely on built-in ISAPI filters, simply remove the application mappings for the appropriate extension in the IIS Admin

) and provides support for administrative scripts (.ida files) and Internet Data Queries (.idq files). Thus, we sometimes refer to this issue as the “ida/idq buffer overflow.” P:\010Comp\Hacking\262-3\ch10.vp Thursday, August 09, 2001 12:37:37 PM HackingGeneric / Hacking Windows Color profile: CMYK Exposed printer profile Composite

Default screen 2000: Network Security Secrets & Solutions / Scambray & McClure / 9262-3 / Chapter 10 Chapter 10: Hacking IIS 5 and Web Applications Exploitation of the buffer overflow involves sending an overlong variable to idq.dll, as shown in the following example, where [buffer] is equivalent to approximately 240 bytes: GET /null.ida

proof-of-concept exploit code for the ida/idq bffer overflow. This is likely because of the difficulty of exploiting the nature of this particular buffer overflow, which doesn’t permit simple loading of shellcode into a predefined location in memory. Instead, eEye claimed it was forced to load the shellcode into

than the IIS 5). Thus, with the exception of a few unreliable pieces of code, currently no publicly available exploits exist for the ida/idq buffer overflow. The authors are aware of functional but unreleased exploits for this problem, however. Nevertheless, this vulnerability has been exploited to great effect on Web servers

%u00=a Also, the presence of the directory %systemdrive%\notworm is a tell-tale sign that a server has been compromised. MFrontPage 2000 Server Extensions Buffer Overflow Popularity: 6 Simplicity: 9 Impact: 4 Risk Rating: 6 The Chinese security research group NSFocus released an advisory on June 25, 2001, describing its discovery

of a buffer overflow in the Front Page 2000 Server Extensions (FPSE 2000), a set of three programs that support features such as collaborative authoring, hit counters, email form

attacked (we discuss file system traversal attacks in the next section). When either of these DLLs receives a URL request longer than 258 bytes, a buffer overflow occurs. Exploiting this vulnerability successfully, an attacker can remotely execute arbitrary code on any unpatched server running FPSE 2000. NSFocus produced an exploit called fpse2000ex

advantage of this vulnerability. It released UNIX/Linux source code only. To compile this exploit under Cygwin, using the procedure discussed previously under the IPP buffer overflow, you might need to add the following line to the header includes section at the top of the source code file: #include <sys/socket.h

>whoami whoami [carriage return] VICTIM\IWAM_victim As you can see by the output of the whoami utility from the Resource Kit, exploitation of this buffer overflow on Windows 2000 yields compromise of the IWAM_machinename account, which possesses only Guest-equivalent privileges on the local system. For more background on Guests

a mechanism for escalating privilege once Guest-equivalent access has been attained on IIS 5 in an upcoming section. Simpler exploits than the FPSE 2000 buffer overflow can be used in conjunction with such attacks, as we also discuss in the upcoming section on file system traversal. U Countermeasures for FPSE 2000

the same server, exploitation of these vulnerabilities can lead to complete system compromise. Thus, although they don’t have the same immediate impact of the buffer overflow attacks previously covered, they can be the next best thing. The two file system traversal exploits we examine in the following are the Unicode and

this, as shown in the following example using IsapiExt.dll: dumpbin /imports IsapiExt.dll | find "RevertToSelf" Source Code Revelation Attacks Although seemingly less devastating than buffer overflow or file system traversal exploits, source code revelation attacks can be just as damaging. If a malicious hacker can get an unauthorized glimpse at the

the most appropriate way to eliminate these vulnerabilities is to remove the script mapping for .htr, as discussed in the previous section on the IPP buffer overflow (see Figure 10-1). However, if your application relies on .htr-based password reset, then removing the application mapping for .htr isn’t a viable

Reversing: Secrets of Reverse Engineering

by Eldad Eilam  · 15 Feb 2005  · 619pp  · 210,746 words

contains a pointer to the attacker’s code at the correct offset, so that this address would overwrite the function’s return address. A typical buffer overflow includes a short code sequence as the payload (the shellcode [Koziol]) and a pointer to the beginning of that code as the return address. This

by the lea edx,[esp-0x64] in the preceding function is worthy of further investigation. Stack Checking There are many possible ways of dealing with buffer overflow bugs. The first and most obvious way is of course to try to avoid them in the first place, but that doesn’t always prove

put something like our poor launch in a production system, Auditing Program Binaries but there are other, far more subtle mistakes that can create potential buffer overflow bugs. One technique that aims to automatically prevent these problems from occurring is by the use of automatic, compiler-generated stack checking. The idea is

[Cowan], Crispin Cowan, Calton Pu, David Maier, Heather Hinton, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, and Qian Zhang. Automatic Detection and Prevention of Buffer-Overflow Attacks. The 7th USENIX Security Symposium. San Antonio, TX, January 1998 and has since been implemented in several compilers. The latest versions of the Microsoft

memory address as a parameter and by having the callee write back into that memory address. The idea is that when a function has a buffer overflow bug, the memory address used for returning values to the caller (assuming that the function does that) can be overwritten using a specially crafted buffer

write data to an arbitrary address in memory attackers can sometimes gain control of the process before the stack-checking code finds out that a buffer overflow had occurred. In order to do that, attackers must locate a function that passes values back to the caller using parameters and that has an

when stack checking fails. As you can see, exploiting programs that have stack-checking mechanisms embedded into them is not as easy as exploiting simple buffer overflow bugs. This means that even though it doesn’t completely eliminate the problem, stack checking does somewhat reduce the total number of possible exploits in

a program. Nonexecutable Memory This discussion wouldn’t be complete without mentioning one other weapon that helps fight buffer overflows: nonexecutable memory. Certain processors provide support for defining memory pages as nonexecutable, which means that they can only be used for storing data, and that

in them. The operating system can then mark stack and data pages as nonexecutable, which prevents an attacker from running code on them using a buffer overflow. At the time of writing, many new processors already support this functionality (including recent versions of Intel and AMD processors, and the IA-64 Intel

2.6 and above, and several patches implemented for the Linux kernel). Needless to say, nonexecutable memory doesn’t exactly invalidate the whole concept of buffer overflow attacks. It is quite possible for attackers to Auditing Program Binaries overcome the hurdles imposed by nonexecutable memory systems, as long as a vulnerable piece

[Blexim], [Koziol]) are a special type of overflow bug where incorrect treatment of integers can lead to a numerical overflow which eventually results in a buffer overflow. The common case in which this happens is when an application receives the length of some data block from the outside world. Except for really

typically be a header length of some sort. This can create significant risks because an attacker could take advantage of integer overflows to create a buffer overflow. Here is an example of code that does this sort of thing: allocate_object: 00401021 push 00401022 push 00401023 mov 00401027 lea 0040102a push 0040102b

269 270 Chapter 7 characters. The buffer can only hold 200 Unicode characters, but the check is going to allow 400 characters. As with many buffer overflow conditions, exploiting this bug isn’t as easy as it seems. First of all, whatever you do you wouldn’t be able to affect Decode

the stack. The system is keeping a pointer to this stack address in a special memory location that is accessed through fs:[0]. When the buffer overflow occurs, it’s also overwriting this exception-handling data structure, and you can replace the exception handler’s address with whatever you wish. This way

notation, 49 attacks copy protection technologies, 324 DoS (Denial-of-Service) attacks, 280 power usage analysis attacks, 319 audio, 321 Automatic Detection and Prevention of Buffer-Overflow Attacks, Crispin Cowan, Calton Pu, David Maier, Heather Hinton, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, and Qian Zhang, 252 B back end of

decompilers, 476–477 backdoor access (with malicious software), 280 backdoors, 276 Bakke, Peat, Automatic Detection and Prevention of Buffer-Overflow Attacks, 252 base object, 29 BaseNamedObjects directory, 83 basic block (BB), 464–466 Beattie, Steve, Automatic Detection and Prevention of

Buffer-Overflow Attacks, 252 beq instruction, 432 Best, Robert M., Microprocessor for Executing Enciphered Programs patent, 311, 318 bge instruction, 432 bgt instruction, 432 binary code, 11

), 345 trusted components, 312 Uncrackable Model, 314 copyright laws, 19 copyrights, 309–310 CopyWrite copy protection technology, 314 Cowan, Crispin, Automatic Detection and Prevention of Buffer-Overflow Attacks, 252 cracking class breaks, 312–313 defined, 309, 357–358 keygenning, 364–365 patching, 358–363 ripping algorithms, 365–370 crackmes Defender brute-forcing

), 18 GLOBAL?? directory, 83 global variables, 542 GNU C Compiler (GCC) and GNU C++ Compiler (G++) compilers, 59 Grier, Aaron, Automatic Detection and Prevention of Buffer-Overflow Attacks, 252 ground rules for reversing sessions, 142–143 H Hacarmy.D, Trojan/Backdoor program, 285–305 Hack SDMI challenge, 22 handles, 81 hardware breakpoints

–256 Hex Workshop (BreakPoint Software, Inc.), 131–132 high-level data management, 38 high-level languages, 33–37 Hinton, Heather, Automatic Detection and Prevention of Buffer-Overflow Attacks, 252 I IA-32 decompilers, 477 IA-32 instructions ADC, 529 ADD, 49–50, 522, 529 CALL, 51, 487, 540 CDQ, 535 CMP, 50

Transformations, 348 low-level data management, 37–38 low-level software, 9–10, 25 M machine code, 11 Maier, David, Automatic Detection and Prevention of Buffer-Overflow Attacks, 252 malicious software adware, 276–277 backdoors, 276 BIOS/firmware, 279–280 defined, 5–6, 273 deleting, 277 information-stealing worms, 278–279 metamorphism

-based software, 317 StarForce suite (StarForce Technologies), 345 trusted components, 312 Uncrackable Model, 314 Protector (Remotesoft), 452–455 Pu, Calton, Automatic Detection and Prevention of Buffer-Overflow Attacks, 252 pure arithmetic, 510–512 R reciprocal multiplication, 524–527 recursive traversal disassemblers, 338–343 redundancy elimination, 57 register keyword, 545 register transfer languages

, 249–250 malicious software, 281 stack overflows, 245–255 string filters, 256 type conversion errors, 260–262 W Wagle, Perry, Automatic Detection and Prevention of Buffer-Overflow Attacks, 252 watermarking, 321–322 Win32 API, 88–90 Win32 subsystem, 104–105 WinDbg debugger command-line interface, 119 disassembler, 119 extensions, 129 features, 119

algorithm, 416 Z Zeltser, Lenny, Malware: Fighting Malicious Code, 280 zero extending, 534–535 zero flag (ZF), 521 Zhang, Qian, Automatic Detection and Prevention of Buffer-Overflow Attacks, 252 589

UNIX® Network Programming, Volume 1: The Sockets Networking API, 3rd Edition

by W. Richard Stevens, Bill Fenner, Andrew M. Rudoff  · 8 Jun 2013

for ai_flags Unrecoverable failure in name resolution ai_family not supported Memory allocation failure hostname or service not provided, or not known User argument buffer overflowed (getnameinfo() only) service not supported for ai_socktype ai_socktype not supported System error returned in errno Figure 11.7 Nonzero error return constants from

The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws

by Dafydd Stuttard and Marcus Pinto  · 30 Sep 2007  · 1,302pp  · 289,469 words

Applications," looks at a set of important vulnerabilities that arise in applications written in native code languages such as C and C++. These vulnerabilities include buffer overflows, integer vulnerabilities, and format string flaws. Because this is a potentially huge topic, we focus on ways to detect these vulnerabilities in web applications and

status code if you attempt to use the put method where it is not supported. ■ 413 Request Entity Too Large — If you are probing for buffer overflow vulnerabilities in native code, and therefore are submitting long strings of data, this indicates that the body of your request is too large for the

the presence of a web server vulnerability. For example, the .printer and . ida/. idq handlers in IIS have in the past been found vulnerable to buffer overflow vulnerabilities. Another common fingerprint to be aware of are URLs that look like this: https://wahh-app/news/O,,2-421206,00.html Chapter 4

handling of sessions and/or access controls ■ Error messages — Information leakage ■ E-mail interaction — E-mail and/or command injection ■ Native code components or interaction — Buffer overflows ■ Use of third-party application components — Known vulnerabilities ■ Identifiable web server software — Common configuration weaknesses, known software bugs 112 Chapter 4 Mapping the Application Mapping

on the parameter, you may be able to leverage the defects in validation to exploit other vulnerabilities, such as SQL injection, cross-site scripting, or buffer overflows. Script-Based Validation The input validation mechanisms built into HTML forms themselves are extremely simple and are insufficiently fine-grained to perform relevant validation of

to prevent different categories of attack. To defend against SQL injection, it doubles up any single quotation marks that appear in user input. To prevent buffer overflow attacks against some native code components, it truncates any overlong items to a reasonable limit. What might go wrong with these filters? 3. What steps

an attacker: ■ Because ActiveX controls typically are written in native languages such as C/C++, they are at risk from classic software vulnerabilities such as buffer overflows, integer bugs, and format string flaws (see Chapter 16 for more details). In recent years, a huge number of these vulnerabilities 556 Chapter 13 Attacking

ActiveX vulnerabilities is to modify the HTML that invokes the control, pass your own parameters to it, and monitor the results: 1. Vulnerabilities such as buffer overflows can be probed for using the same kind of attack payloads described in Chapter 16. Triggering bugs of this kind in an uncontrolled manner is

installed it. For example: ■ A security-focused source code review and penetration test should be carried out on the control to locate vulnerabilities such as buffer overflows. ■ The control should not expose any inherently dangerous methods that call out to the filesystem or operating system using user-controllable Chapter 15 b Attacking

, which can be used to bypass some input filters by submitting alternative encodings of malicious characters. ■ Character blocks, which can be used to probe for buffer overflow vulnerabilities (see Chapter 16). ■ A brute-forcer function, which can be used to generate all the permutations of a particular character set in a specific

the application vulnerable? 16 Attacking Native Compiled Applications Compiled software that runs in a native execution environment has historically been plagued by vulnerabilities such as buffer overflows and format string bugs. Most web applications are written using languages and platforms that run in a managed execution environment in which these classic vulnerabilities

application, including the names and values of every parameter, cookie, request header, and other data. This chapter covers three main categories of classic software vulnerability: buffer overflows, integer vulnerabilities, and format string bugs. In each case, we will describe some common vulnerabilities and then outline the practical steps you can take when

probe a live application for these bugs, you must ensure that the application owner accepts the risks associated with the testing before you begin. Buffer Overflow Vulnerabilities Buffer overflow vulnerabilities occur when an application copies user-controllable data into a memory buffer that is not sufficiently large to accommodate it. The destination buffer is

the nature of the vulnerability, an attacker may be able to exploit it to execute arbitrary code on the server or perform other unauthorized actions. Buffer overflow vulnerabilities have been hugely prevalent in native software over the years and have been widely regarded as Public Enemy Number One that developers of such

software need to avoid. Stack Overflows Buffer overflows typically arise when an application uses an unbounded copy operation (such as strcpy in C) to copy a variable-size buffer into a fixed-size

username string contains more than 32 characters, the _username buffer is overflowed, and the attacker overwrites the data in adjacent memory. In a stack-based buffer overflow, a successful exploit typically involves overwriting the saved return address on the stack. When the checkLogin function is called, the processor pushes onto the stack

return address with a value of his choosing, thereby causing the processor to jump to this address and execute arbitrary code. Heap Overflows Heap-based buffer overflows essentially involve the same kind of unsafe operation as described previously, except that the overflowed destination buffer is allocated on the heap, not the stack

: bool CheckLogin(char* username, char* password) { char* _username = (char*) malloc(32); strcpy(_username, username); In a heap-based buffer overflow, what is typically adjacent to the destination buffer is not any saved return address but other blocks of heap memory, separated by heap control structures

the next time an exception occurs. NOTE Modern compilers and operating systems have implemented various defenses to protect software against programming errors that lead to buffer overflows. These defenses mean that real-world overflows today are generally more difficult to exploit than the examples described here. For further information about these defenses

until the next null byte and therefore included the parameters supplied by another user. Chapter 16 Attacking Native Compiled Applications 659 Detecting Buffer Overflow Vulnerabilities The basic methodology for detecting buffer overflow vulnerabilities is to send long strings of data to an identified target and monitor for anomalous results. In some cases, subtle vulnerabilities

characters it already contains, to create a long string that is likely to pass any content-based filters. Even if you are confident that a buffer overflow condition exists, exploiting it remotely to achieve arbitrary code execution is extremely difficult. Peter Winter-Smith of NGSSoftware has produced some interesting research regarding the

possibilities for blind buffer overflow exploitation. For more information, see the following whitepaper: www.ngssoftware.com/papers/NISR.BlindExploitation.pdf Integer Vulnerabilities Integer-related vulnerabilities typically arise when an application

to ensure that these are decoded correctly. 3. You should monitor the application's responses for anomalous events in the same way as described for buffer overflow vulnerabilities. Format String Vulnerabilities Format string vulnerabilities arise when user-controllable input is passed as the format string parameter to a function that takes format

remote application is to submit data containing various format specifiers and monitor for any anomalies in the application's behavior. As with uncontrolled triggering of buffer overflow vulnerabilities, it is likely that probing for format string flaws will result in a crash within a vulnerable application. HACK STEPS 1. Targeting each parameter

to URL-encode the % character as %25. 4. You should monitor the application's responses for anomalous events in the same way as described for buffer overflow vulnerabilities. Chapter 16 Attacking Native Compiled Applications 645 Summary Software vulnerabilities in native code represent a relatively niche area in relation to attacks on web

inherent risks involved. Questions Answers can be found at http: / /mdsec. net /wahh. 1. Unless any special defenses are in place, why are stack-based buffer overflows generally easier to exploit than heap-based overflows? 2. In the C and C++ languages, how is a string's length determined? 3. Why would

a buffer overflow vulnerability in an off-the-shelf network device normally have a much higher likelihood of exploitation than an overflow in a proprietary web application running

%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n... 5. You are probing for buffer overflow vulnerabilities in a web application that makes extensive use of native code components. You find a request that may contain a vulnerability in one of

mentioned both show how seemingly tiny anomalies can be practically exploited to produce catastrophic results. So never roll your own cryptographic algorithms. Memory Management Vulnerabilities Buffer overflows are among the most serious flaws that can affect any kind of software, because they normally allow an attacker to take control of execution in

within a web server usually enables an attacker to compromise any application it is hosting. The following sections present a tiny sample of web server buffer overflows. They illustrate the pervasiveness of this flaw, which has arisen in a wide range of web server products and components. 688 Chapter 18 ■ Attacking the

Extensions Microsoft IIS versions 4 and 5 contained a range of ISAPI extensions that were enabled by default. Several of these were found to contain buffer overflows, such as the Internet Printing Protocol extension and the Index Server extension, both of which were discovered in 2001. These flaws enabled an attacker to

by default. The advisory posted by Microsoft can be found at www.microsoft. com/technet/security/bulletin/ ms08-062.mspx. Apache Chunked Encoding Overflow A buffer overflow resulting from an integer signedness error was discovered in the Apache web server in 2002. The affected code had been reused in numerous other web

. A write-up of this vulnerability can be found at WWW. securityfocus.com/bid/37966. Chapter 18 ■ Attacking the Application Server 689 WebDAV Overflows A buffer overflow in a core component of the Windows operating system was discovered in 2003. This bug could be exploited through various attack vectors, the most significant

caused an overflow in Sun's Java System Web Server. You can read more about this at www.exploit-db.com/exploits/14287/. A further buffer overflow issue from 2009 was reported in Apache's mod_dav extension. More details can be found at http: / /eve .mitre. org/cgi-bin/cvename .cgi

Native Software Bugs You should closely review any native code used by the application for classic vulnerabilities that may be exploitable to execute arbitrary code. Buffer Overflow Vulnerabilities These typically employ one of the unchecked APIs for buffer manipulation, of which there are many, including strcpy, strcat, memcpy, and sprintf, together with

strFileName[MAX_PATH]; strcpy(strFileName, pszName); } Note that just because a safe alternative to an unchecked API is employed, this is no guarantee that a buffer overflow will not occur. Sometimes, due to a mistake or misunderstanding, a checked API is used in an unsafe manner, as in the following "fix" of

the preceding vulnerability: BOOL CALLBACK CFiles::EnumNameProc(LPTSTR pszName) { char strFileName[MAX_PATH]; strncpy(strFileName, pszName, strlen(pszName)); } Therefore, a thorough code audit for buffer overflow vulnerabilities typically entails a close line-by-line review of the entire codebase, tracing every operation performed on user-controllable data. Integer Vulnerabilities These come

dangerous-sounding names, such as LaunchExe. You can also use COMRaider to perform some basic fuzz testing of ActiveX controls to identify flaws such as buffer overflows. Chapter 21 »A Web Application Hacker's Methodology 805 4 Test the Authentication Mechanism 4.1. Understand the mechanism V \X V Special functions 4

specify the To address of the e-mail, which you can modify directly. 8.2 Test for Native Software Vulnerabilities 8.2.1 Test for Buffer Overflows 8.2.1.1 For each item of data being targeted, submit a range of long strings with lengths somewhat longer than common buffer sizes

-force techniques application mapping naming schemes exercise, 88 authentication security preventing, 196-199 hidden content, 81-85 login function, 162-165 passwords in wiki, 424 buffer overflow detecting, 639-640 hacker's methodology, 837-838 heap overflows, 635-636 off-by-one vulnerabilities, 636-638 software, 687 source code, 709 stack overflows

, 809 vulnerability exploitation for unauthorized access, 813 back-end request injection, 841 browser extensions, 802-804 ActiveX controls, 804 debugger, 803-804 decompiling, 802-803 buffer overflow, 837-838 client-side data transmission, 801 user input, 801-802 cookie scope, 820-821 CSRF, 820 DOM, 849-850 file inclusion, 835-836 format

-652 UDFs, 328 naming schemes application mapping, 85-86 brute-force exercise, 88 identifying, 87 static resources, 87 native client components, 153 native compiled applications buffer overflow, 634-640 examples, 633 format string vulnerabilities, 643-644 integer vulnerabilities, 640-643 testing for, 633-634 native software bugs hacker's methodology, 837-838

API methods, 723 Java, 716 Perl language API methods, 739 PHP API methods, 732 source code application logic flaws, 428 backdoor password, 708 browsing, 743 buffer overflow, 709 bytecode recompiling within browser, 142-143 outside browser, 143 comments, 710-711 decompiling browser extensions, 142-144 error messages, 623 format string vulnerabilities, 710

resource identifier (URI), 44 open redirection vulnerabilities, absolute prefix, 545-546 uniform resource locator (URL) account activation, 184 application mapping, input entry points, 98-99 buffer overflow and length of, 639 bytecode, 140 encoding, 67 SQL injection, 300-301 truncating, 378 format, 44 HTTP requests, 40,44 open redirection vulnerabilities, 542 absolute

Fancy Bear Goes Phishing: The Dark History of the Information Age, in Five Extraordinary Hacks

by Scott J. Shapiro  · 523pp  · 154,042 words

ounces poured into an eight-ounce measuring cup, the extra information spills over into adjacent parts of memory. This spillage is known as a buffer overflow. Any such buffer overflow can overwrite important information, depending on the location of the data buffer. The server stored the data buffer in a special part of the

placed data on the stack. But Morris realized that he could exploit this glitch. He could use the buffer overflow to wrest control from the computer running Finger. Code Hiding in Data To exploit the buffer overflow, Robert constructed a special request. Instead of sending a small string such as rtm, he sent a

of the data buffer—in other words, to the malicious code hiding inside. Thus, when Morris sent his supersize request to the Finger server, the buffer overflowed. The flood of data wiped out the return pointer back to the server and replaced it with a new instruction pointer to the malicious code

anyone could swamp email servers around the world without even knowing how to program. The Code Red worm attacked Microsoft’s web server using a buffer-overflow attack. It managed to take down the White House web server. The 2002 Beast malware permitted hackers to control the user’s computer once the

macros by default.) Developers were taught to avoid instructions that, like the insecure version of Finger exploited by the Morris Worm, do not check for buffer overflows. Nor were they ever to trust the data users inputted to applications. (The soundness of this advice will be confirmed in the next chapter.) Crucially

them. The Microsoft team used theorem provers to determine whether they could generate conclusions from the converted code that violated security rules, such as “No buffer overflows.” Thus, if the theorem prover demonstrates that the driver accepts inputs that are bigger than the data buffers allot for them, e.g., “String that

is 536 bytes long is in the buffer that is 512 bytes long”—then it will have proven that the driver is vulnerable to buffer overflows. The Microsoft team would then conclude that the code had a bug and send it back to the developer to fix. In 2004, Microsoft introduced

end-to-end internetworking system can survive only if they hardened the end points. Harden the end points they did. Consider how Linux dealt with buffer overflows. In 2002, Linux implemented ASLR, short for “address space layout randomization.” The stack, that temporary scratch pad that Robert Morris Jr. used to implant malicious

months. Economic Espionage If we classified cyberattacks by downcode, we would miss crucial distinctions between cyber-espionage, cybercrime, and cyberwar. Whether Cozy Bear used a buffer overflow or phishing to access the SolarWinds update server is irrelevant to how the United States and others should react to these attacks. The proper response

. The Morris Worm was a hyperspecialized program. It targeted only computers that contained distinctive hardware and software. The instructions Robert Morris Jr. encoded in his buffer overflow ran only on certain computers—in particular, on VAX and Sun machines. It was useless on those made by PDP, IBM, or Honeywell, which employed

that used the insecure version of Finger. If the version of Finger being used checked for buffer overflows, the exploit would fail. This is why Robert Morris used four attack vectors—because he knew that his buffer overflow would not work on many machines. The malware we have seen in this book has also

Secrets and Lies: Digital Security in a Networked World

by Bruce Schneier  · 1 Jan 2000  · 470pp  · 144,455 words

, display the SSL private key, or do all sorts of other interesting things from the previous paragraph. These techniques can also be used to exploit buffer overflows and other programming errors (see Chapter 13) to crash the Web server or, better yet, to take it over. One example: A 1998 attack against

: • In 1988, the Morris worm used a bug in the UNIX fingered program to gain root access to computers running the program. This is a buffer overflow, explained in the next section. • In 1999, someone discovered a bug in a Hotmail CGI script that allowed one user to access the e-mail

a day goes by without some new announcement about a security hole in this program. We’re already seeing the same trend with Windows 2000. BUFFER OVERFLOWS Buffer overflows (sometimes called stack smashing) are the most common form of security vulnerability in the last ten years. They’re also the easiest to exploit; more

attacks are the result of buffer overflows than any other problem. And they can be devastating; attacks that exploit this vulnerability often result in the complete takeover of the host. Many high

-profile attacks exploit buffer overflows. Since they show no sign of abating, it’s worth explaining in some detail what they are and how they work. Let’s start with

else we want. By slipping a page into her employee manual, we can give her arbitrary instructions. Essentially, this is the way to exploit a buffer overflow bug in a computer system. Computers store everything, programs and data, in memory. If the computer asks a user for an 8-character password and

an “allow access” command or even get our own code executed. The Morris worm is probably the most famous overflow-bug exploit. It exploited a buffer overflow in the UNIX fingered program. It’s supposed to be a benign program, returning the identity of a user to whomever asks. This program accepted

it’s hard to do everywhere. The problem is that with any piece of modern, large, complex code, there are just too many places where buffer overflows are possible (and they’re not all as simple as this example) that it is difficult to squash them all. It’s very difficult to

mean that people will examine it for security flaws, and it certainly doesn’t mean that experts will examine it for security flaws. Researchers found buffer overflows in the MIT code for Kerberos ten years after the code was released. Another open-source package, the Mailman program for managing mailing lists, had

all your e-shopping with your game console. There’ll be credit card numbers, electronic wallets, who knows what. Welcome to a world where a buffer overflow in Tekken 3 can compromise your financial security. This kind of function creep happens everywhere: Today’s toys are tomorrow’s critical applications. Mass-market

occur in the field of AI (a big “if”), it has the potential to revolutionize computer security. Automatic program checkers. Many security bugs, such as buffer overflows, are the result of sloppy programming. Good automatic tools that can scan computer code for potential security-related bugs would go a long way to

, though. If there’s anything the twentieth century has taught us, it’s to be parsimonious with the word “impossible.” WILL WE EVER LEARN? Consider buffer overflow attacks. These were first talked about in the security community as early as the 1960s—time-sharing systems suffered from that problem—and were probably

in the 1970s had the problem, and it was often used as a point of attack against systems. The Morris worm, in 1988, exploited a buffer overflow in the UNIX fingerd command: a public use of this type of attack. Now, over a decade after Morris and about 35 years after they

again. In 1998, over two- thirds of all CERT advisories were for vulnerabilities caused by buffer overflows. During a particularly bad fortnight in 1999, 18 separate security flaws, all caused by buffer overflows, were reported in Windows NT–based applications. During the first-week-of-March stretch I opened this book with, there were

three buffer overflows reported. And buffer overflows are just the low-hanging fruit. If we ever manage to eradicate the problem, others—just as bad—will replace them. Consider encryption algorithms. Proprietary

’s more likely that the designers will understand security. But they can’t do everything. Someone who designed a firewall product once told me about buffer overflows in his code. He said that he did all he could to ensure that there were none—and I believe that he was thorough—but

said that he couldn’t control the rest of the programmers on the team. He tried, but he couldn’t. Several serious vulnerabilities due to buffer overflows in the code have been discovered, and fixed, over the years. No one believes there aren’t more, waiting to be discovered. I’ve been

ZeroMQ

by Pieter Hintjens  · 12 Mar 2013  · 1,025pp  · 150,187 words

Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems

by Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski and Adam Stubblefield  · 29 Mar 2020  · 1,380pp  · 190,710 words

Coders at Work

by Peter Seibel  · 22 Jun 2009  · 1,201pp  · 233,519 words

Nagios: System and Network Monitoring, 2nd Edition

by Wolfgang Barth  · 19 Aug 2009  · 996pp  · 180,520 words

Masterminds of Programming: Conversations With the Creators of Major Programming Languages

by Federico Biancuzzi and Shane Warden  · 21 Mar 2009  · 496pp  · 174,084 words

Code Complete (Developer Best Practices)

by Steve McConnell  · 8 Jun 2004  · 1,758pp  · 342,766 words

Programming in Lua, Fourth Edition

by Roberto Ierusalimschy  · 14 Jul 2016  · 489pp  · 117,470 words

Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect Attacks

by Michal Zalewski  · 4 Apr 2005  · 412pp  · 104,864 words

Advanced Software Testing—Vol. 3, 2nd Edition

by Jamie L. Mitchell and Rex Black  · 15 Feb 2015

Linux Security Cookbook

by Daniel J. Barrett, Richard E. Silverman and Robert G. Byrnes  · 8 Jun 2003

Guide to LaTeX

by Helmut Kopka and Patrick W. Daly  · 15 Feb 2008

Engineering Security

by Peter Gutmann

Network Security Through Data Analysis: Building Situational Awareness

by Michael S Collins  · 23 Feb 2014  · 446pp  · 102,421 words

Beautiful security

by Andy Oram and John Viega  · 15 Dec 2009  · 302pp  · 82,233 words

Kingpin: How One Hacker Took Over the Billion-Dollar Cybercrime Underground

by Kevin Poulsen  · 22 Feb 2011  · 264pp  · 79,589 words

Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon

by Kim Zetter  · 11 Nov 2014  · 492pp  · 153,565 words

The Art of UNIX Programming

by Eric S. Raymond  · 22 Sep 2003  · 612pp  · 187,431 words

Seeking SRE: Conversations About Running Production Systems at Scale

by David N. Blank-Edelman  · 16 Sep 2018

Joel on Software

by Joel Spolsky  · 1 Aug 2004  · 370pp  · 105,085 words

The Tangled Web: A Guide to Securing Modern Web Applications

by Michal Zalewski  · 26 Nov 2011  · 570pp  · 115,722 words

Cult of the Dead Cow: How the Original Hacking Supergroup Might Just Save the World

by Joseph Menn  · 3 Jun 2019  · 302pp  · 85,877 words

Peer-to-Peer

by Andy Oram  · 26 Feb 2001  · 673pp  · 164,804 words

Hands-On RESTful API Design Patterns and Best Practices

by Harihara Subramanian  · 31 Jan 2019  · 422pp  · 86,414 words

Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice)

by Adam Goucher and Tim Riley  · 13 Oct 2009  · 351pp  · 123,876 words

Click Here to Kill Everybody: Security and Survival in a Hyper-Connected World

by Bruce Schneier  · 3 Sep 2018  · 448pp  · 117,325 words

Cyber War: The Next Threat to National Security and What to Do About It

by Richard A. Clarke and Robert Knake  · 15 Dec 2010  · 282pp  · 92,998 words

I'm Feeling Lucky: The Confessions of Google Employee Number 59

by Douglas Edwards  · 11 Jul 2011  · 496pp  · 154,363 words

Docker: Up & Running: Shipping Reliable Containers in Production

by Sean Kane and Karl Matthias  · 14 May 2023  · 433pp  · 130,334 words

Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software

by Scott Rosenberg  · 2 Jan 2006  · 394pp  · 118,929 words

Toast

by Stross, Charles  · 1 Jan 2002

Rust Programming by Example

by Guillaume Gomez and Antoni Boucher  · 11 Jan 2018  · 537pp  · 82,938 words

Cybersecurity: What Everyone Needs to Know

by P. W. Singer and Allan Friedman  · 3 Jan 2014  · 587pp  · 117,894 words

Smart Grid Standards

by Takuro Sato  · 17 Nov 2015

Webbots, Spiders, and Screen Scrapers

by Michael Schrenk  · 19 Aug 2009  · 371pp  · 78,103 words

Clean Agile: Back to Basics

by Robert C. Martin  · 13 Oct 2019  · 333pp  · 64,581 words

The Debian Administrator's Handbook, Debian Wheezy From Discovery to Mastery

by Raphaal Hertzog and Roland Mas  · 24 Dec 2013  · 678pp  · 159,840 words

Intrusion Detection With Snort, Apache, Mysql, Php, and Acid

by Rafeeq Ur Rehman  · 7 May 2003  · 257pp  · 64,973 words

Building Microservices

by Sam Newman  · 25 Dec 2014  · 540pp  · 103,101 words

Reamde

by Neal Stephenson  · 19 Sep 2011  · 1,318pp  · 403,894 words

This Machine Kills Secrets: Julian Assange, the Cypherpunks, and Their Fight to Empower Whistleblowers

by Andy Greenberg  · 12 Sep 2012  · 461pp  · 125,845 words

Dawn of the Code War: America's Battle Against Russia, China, and the Rising Global Cyber Threat

by John P. Carlin and Garrett M. Graff  · 15 Oct 2018  · 568pp  · 164,014 words

Character Limit: How Elon Musk Destroyed Twitter

by Kate Conger and Ryan Mac  · 17 Sep 2024

Docker: Up & Running: Shipping Reliable Containers in Production

by Sean P. Kane and Karl Matthias  · 15 Mar 2018  · 350pp  · 114,454 words

With a Little Help

by Cory Efram Doctorow, Jonathan Coulton and Russell Galen  · 7 Dec 2010  · 549pp  · 116,200 words

Python Web Penetration Testing Cookbook

by Cameron Buchanan, Terry Ip, Andrew Mabbitt, Benjamin May and Dave Mound  · 28 Jun 2015  · 224pp  · 45,431 words

Whiplash: How to Survive Our Faster Future

by Joi Ito and Jeff Howe  · 6 Dec 2016  · 254pp  · 76,064 words

If Anyone Builds It, Everyone Dies: Why Superhuman AI Would Kill Us All

by Eliezer Yudkowsky and Nate Soares  · 15 Sep 2025  · 215pp  · 64,699 words

The Launch Pad: Inside Y Combinator, Silicon Valley's Most Exclusive School for Startups

by Randall Stross  · 4 Sep 2013  · 332pp  · 97,325 words

The Seventh Sense: Power, Fortune, and Survival in the Age of Networks

by Joshua Cooper Ramo  · 16 May 2016  · 326pp  · 103,170 words

The Zenith Angle

by Bruce Sterling  · 27 Apr 2004  · 342pp  · 95,013 words