buffer overflow

Hacking Exposed: Network Security Secrets and Solutions
by Stuart McClure , Joel Scambray and George Kurtz
Published 15 Feb 2001

Composition Countermeasure U Password See “Brute Force Countermeasure,” earlier in this chapter. ] Local Buffer Overflow Popularity: 10 Simplicity: 9 Impact: 10 Risk Rating: 10 Local buffer overflow attacks are extremely popular. As discussed in the “Remote Access” section earlier, buffer overflow vulnerabilities allow attackers to execute arbitrary code or commands on a target system. Most times, buffer overflow conditions are used to exploit SUID root files, enabling the attackers to execute commands with root privileges. We already covered how buffer overflow conditions allow arbitrary command execution (see “Buffer Overflow Attacks” earlier). In this section, we discuss and give examples of how a local buffer overflow attack works.

…

P:\010Comp\Hacking\262-3\ch10.vp Thursday, August 09, 2001 12:37:35 PM 211 HackingGeneric / Hacking Windows Color profile: CMYK Exposed printer profile Composite Default screen 212 2000: Network Security Secrets & Solutions / Scambray & McClure / 9262-3 / Chapter 10 Hacking Exposed Windows 2000: Network Security Secrets & Solutions Now that we’ve laid 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 buffer overflow exploit against IIS 4, discovered by eEye Digital Security in June 1999 and, as you see in this section, eEye has continued this streak with IIS 5 in grand form. Of course, critical to understanding these exploits is a basic comprehension of how buffer overflows work. A detailed examination of practical buffer overflow exploitation is outside of the scope of the discussion here but, in essence, buffer overflows occur when programs don’t adequately check input for appropriate length.

…

In this section, we discuss and give examples of how a local buffer overflow attack works. In May 1999, Shadow Penguin Security released an advisory related to a buffer overflow condition in libc relating to the environmental variable LC_MESSAGES. 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.

The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities
by Justin Schuh
Published 20 Nov 2006

You can also find 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 area. When an overflow is triggered, the excess data corrupts program information adjacent to the target buffer, often with disastrous consequences. Buffer overflows are the most common type of memory corruption. If you’re not familiar with how these bugs are exploited, they almost seem to defy logic and somehow grant an attacker complete access to a vulnerable system.

…

Although this is a high-level view of how process memory is organized, it shows how the impact of a buffer overflow vulnerability varies 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 buffer overflow to exploit. This section covers the basics of the runtime program stack and then shows how attackers exploit stack-based buffer overflows. * * * The Stack ADT From a general computer science perspective, a stack is an abstract data type (ADT) used for the ordered storage and retrieval of a series of data elements.

…

The user, rtype, and addinfo variables are only 32 bytes long, so if the client supplies any of those fields with a string larger than 32 bytes, a buffer overflow occurs. sprintf() The sprintf() functions have accounted for many security 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 %f) can also result in buffer overflows. If users can partially or fully control the format argument, another type of bug could occur, known as “format string” vulnerabilities.

Gray Hat Python: Python Programming for Hackers and Reverse Engineers
by Justin Seitz
Published 15 Feb 2009

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 is attached, 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.

…

We are going to focus on bugs that are typically 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 this concept would be to think of a buffer as a bucket that can hold a gallon of water.

…

In some operating systems, other events can be trapped as well, such as thread and process creation or the loading of a dynamic library at runtime. We will cover these special 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 are able to build a handler that automatically gathers all of the relevant information without having to interact with it.

The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws
by Dafydd Stuttard and Marcus Pinto
Published 30 Sep 2007

If you intend to 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 overflowed, resulting in adjacent memory being overwritten with the user's data. Depending on 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.

…

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 on the Internet? 4. Why would the following fuzz string fail to identify many instances of format string vulnerabilities? %n%n%n%n%n%n%n%n%n%n%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.

…

vii Contents at a Glance viii Contents Introduction xxiii Chapter 1 Web Application (In)security 1 The Evolution of Web Applications 2 Common Web Application Functions 4 Benefits of Web Applications 5 Web Application Security 6 "This Site Is Secure" 7 The Core Security Problem: Users Can Submit Arbitrary Input 9 Key Problem Factors 10 The New Security Perimeter 12 The Future of Web Application Security 14 Summary 15 Chapter 2 Core Defense Mechanisms 17 Handling User Access 18 Authentication 18 Session Management 19 Access Control 20 Handling User Input 21 Varieties of Input 21 Approaches to Input Handling 23 Boundary Validation 25 Multistep Validation and Canonicalization 28 Handling Attackers 30 Handling Errors 30 Maintaining Audit Logs 31 Alerting Administrators 33 Reacting to Attacks 34 X Contents Chapter 3 Chapter 4 Contents xi Chapter 5 Bypassing Client-Side Controls 117 Transmitting Data Via the Client 118 Hidden Form Fields 118 HTTP Cookies 121 URL Parameters 121 The Referer Header 122 Opaque Data 123 The ASP.NET ViewState 124 Capturing User Data: HTML Forms 127 Length Limits 128 Script-Based Validation 129 Disabled Elements 131 Capturing User Data: Browser Extensions 133 Common Browser Extension Technologies 134 Approaches to Browser Extensions 135 Intercepting Traffic from Browser Extensions 135 Decompiling Browser Extensions 139 Attaching a Debugger 151 Native Client Components 153 Handling Client-Side Data Securely 154 Transmitting Data Via the Client 154 Validating Client-Generated Data 155 Logging and Alerting 156 Summary 156 Questions 157 Chapter 6 Attacking Authentication 159 Authentication Technologies 160 Design Flaws in Authentication Mechanisms 161 Bad Passwords 161 Brute-Forcible Login 162 Verbose Failure Messages 166 Vulnerable Transmission of Credentials 169 Password Change Functionality 171 Forgotten Password Functionality 173 "Remember Me" Functionality 176 User Impersonation Functionality 178 Incomplete Validation of Credentials 180 Nonunique Usernames 181 Predictable Usernames 182 Predictable Initial Passwords 183 Insecure Distribution of Credentials 184 Implementation Flaws in Authentication 185 Fail-Open Login Mechanisms 185 Defects in Multistage Login Mechanisms 186 Insecure Storage of Credentials 190 xii Contents Securing Authentication 191 Use Strong Credentials 192 Handle Credentials Secretively 192 Validate Credentials Properly 193 Prevent Information Leakage 195 Prevent Brute-Force Attacks 196 Prevent Misuse of the Password Change Function 199 Prevent Misuse of the Account Recovery Function 199 Log, Monitor, and Notify 201 Summary 201 Questions 202 Chapter 7 Attacking Session Management 205 The Need for State 206 Alternatives to Sessions 208 Weaknesses in Token Generation 210 Meaningful Tokens 210 Predictable Tokens 213 Encrypted Tokens 223 Weaknesses in Session Token Handling 233 Disclosure of Tokens on the Network 234 Disclosure of Tokens in Logs 237 Vulnerable Mapping of Tokens to Sessions 240 Vulnerable Session Termination 241 Client Exposure to Token Hijacking 243 Liberal Cookie Scope 244 Securing Session Management 248 Generate Strong Tokens 248 Protect Tokens Throughout Their Life Cycle 250 Log, Monitor, and Alert 253 Summary 254 Questions 255 Chapter 8 Attacking Access Controls 257 Common Vulnerabilities 258 Completely Unprotected Functionality 259 Identifier-Based Functions 261 Multistage Functions 262 Static Files 263 Platform Misconfiguration 264 Insecure Access Control Methods 265 Attacking Access Controls 266 Testing with Different User Accounts 267 Testing Multistage Processes 271 Testing with Limited Access 273 Testing Direct Access to Methods 276 Testing Controls Over Static Resources 277 Contents xiii Testing Restrictions on HTTP Methods 278 Securing Access Controls 278 A Multilayered Privilege Model 280 Summary 284 Questions 284 Chapter 9 Attacking Data Stores 287 Injecting into Interpreted Contexts 288 Bypassing a Login 288 Injecting into SQL 291 Exploiting a Basic Vulnerability 292 Injecting into Different Statement Types 294 Finding SQL Injection Bugs 298 Fingerprinting the Database 303 The UNION Operator 304 Extracting Useful Data 308 Extracting Data with UNION 308 Bypassing Filters 311 Second-Order SQL Injection 313 Advanced Exploitation 314 Beyond SQL Injection: Escalating the Database Attack 325 Using SQL Exploitation Tools 328 SQL Syntax and Error Reference 332 Preventing SQL Injection 338 Injecting into NoSQL 342 Injecting into MongoDB 343 Injecting into XPath 344 Subverting Application Logic 345 Informed XPath Injection 346 Blind XPath Injection 347 Finding XPath Injection Flaws 348 Preventing XPath Injection 349 Injecting into LDAP 349 Exploiting LDAP Injection 351 Finding LDAP Injection Flaws 353 Preventing LDAP Injection 354 Summary 354 Questions 354 Chapter 10 Attacking Back-End Components 357 Injecting OS Commands 358 Example 1: Injecting Via Perl 358 Example 2: Injecting Via ASP 360 Injecting Through Dynamic Execution 362 Finding OS Command Injection Flaws 363 Finding Dynamic Execution Vulnerabilities 366 xiv Contents Preventing OS Command Injection 367 Preventing Script Injection Vulnerabilities 368 Manipulating File Paths 368 Path Traversal Vulnerabilities 368 File Inclusion Vulnerabilities 381 Injecting into XML Interpreters 383 Injecting XML External Entities 384 Injecting into SOAP Services 386 Finding and Exploiting SOAP Injection 389 Preventing SOAP Injection 390 Injecting into Back-end HTTP Requests 390 Server-side HTTP Redirection 390 HTTP Parameter Injection 393 Injecting into Mail Services 397 E-mail Header Manipulation 398 SMTP Command Injection 399 Finding SMTP Injection Flaws 400 Preventing SMTP Injection 402 Summary 402 Questions 403 Chapter 11 Attacking Application Logic 405 The Nature of Logic Flaws 406 Real-World Logic Flaws 406 Example 1: Asking the Oracle 407 Example 2: Fooling a Password Change Function 409 Example 3: Proceeding to Checkout 410 Example 4: Rolling Your Own Insurance 412 Example 5: Breaking the Bank 414 Example 6: Beating a Business Limit 416 Example 7: Cheating on Bulk Discounts 418 Example 8: Escaping from Escaping 419 Example 9: Invalidating Input Validation 420 Example 10: Abusing a Search Function 422 Example 11: Snarfing Debug Messages 424 Example 12: Racing Against the Login 426 Avoiding Logic Flaws 428 Summary 429 Questions 430 Chapter 12 Attacking Users: Cross-Site Scripting 431 Varieties of XSS 433 Reflected XSS Vulnerabilities 434 Stored XSS Vulnerabilities 438 DOM-Based XSS Vulnerabilities 440 XSS Attacks in Action 442 Real-World XSS Attacks 442 Contents xv Payloads for XSS Attacks 443 Delivery Mechanisms for XSS Attacks 447 Finding and Exploiting XSS Vulnerabilities 451 Finding and Exploiting Reflected XSS Vulnerabilities 452 Finding and Exploiting Stored XSS Vulnerabilities 481 Finding and Exploiting DOM-Based XSS Vulnerabilities 487 Preventing XSS Attacks 492 Preventing Reflected and Stored XSS 492 Preventing DOM-Based XSS 496 Summary 498 Questions 498 Chapter 13 Attacking Users: Other Techniques 501 Inducing User Actions 501 Request Forgery 502 UI Redress 511 Capturing Data Cross-Domain 515 Capturing Data by Injecting HTML 516 Capturing Data by Injecting CSS 517 JavaScript Hijacking 519 The Same-Origin Policy Revisited 524 The Same-Origin Policy and Browser Extensions 525 The Same-Origin Policy and HTML5 528 Crossing Domains with Proxy Service Applications 529 Other Client-Side Injection Attacks 531 HTTP Header Injection 531 Cookie Injection 536 Open Redirection Vulnerabilities 540 Client-Side SQL Injection 547 Client-Side HTTP Parameter Pollution 548 Local Privacy Attacks 550 Persistent Cookies 550 Cached Web Content 551 Browsing History 552 Autocomplete 552 Flash Local Shared Objects 553 Silverlight Isolated Storage 553 Internet Explorer userData 554 HTML5 Local Storage Mechanisms 554 Preventing Local Privacy Attacks 554 Attacking ActiveX Controls 555 Finding ActiveX Vulnerabilities 556 Preventing ActiveX Vulnerabilities 558 Attacking the Browser 559 Logging Keystrokes 560 Stealing Browser History and Search Queries 560 xvi Contents Enumerating Currently Used Applications 560 Port Scanning 561 Attacking Other Network Hosts 561 Exploiting Non-HTTP Services 562 Exploiting Browser Bugs 563 DNS Rebinding 563 Browser Exploitation Frameworks 564 Man-in-the-Middle Attacks 566 Summary 568 Questions 568 Chapter 14 Automating Customized Attacks 571 Uses for Customized Automation 572 Enumerating Valid Identifiers 573 The Basic Approach 574 Detecting Hits 574 Scripting the Attack 576 JAttack 577 Harvesting Useful Data 583 Fuzzing for Common Vulnerabilities 586 Putting It All Together: Burp Intruder 590 Barriers to Automation 602 Session-Handling Mechanisms 602 CAPTCHA Controls 610 Summary 613 Questions 613 Chapter 15 Exploiting Information Disclosure 615 Exploiting Error Messages 615 Script Error Messages 616 Stack Traces 617 Informative Debug Messages 618 Server and Database Messages 619 Using Public Information 623 Engineering Informative Error Messages 624 Gathering Published Information 625 Using Inference 626 Preventing Information Leakage 627 Use Generic Error Messages 628 Protect Sensitive Information 628 Minimize Client-Side Information Leakage 629 Summary 629 Questions 630 Chapter 16 Attacking Native Compiled Applications 633 Buffer Overflow Vulnerabilities 634 Stack Overflows 634 Heap Overflows 635 Contents xvii "Off-by-One" Vulnerabilities 636 Detecting Buffer Overflow Vulnerabilities 639 Integer Vulnerabilities 640 Integer Overflows 640 Signedness Errors 641 Detecting Integer Vulnerabilities 642 Format String Vulnerabilities 643 Detecting Format String Vulnerabilities 644 Summary 645 Questions 645 Chapter 17 Attacking Application Architecture 647 Tiered Architectures 647 Attacking Tiered Architectures 648 Securing Tiered Architectures 654 Shared Flosting and Application Service Providers 656 Virtual Hosting 657 Shared Application Services 657 Attacking Shared Environments 658 Securing Shared Environments 665 Summary 667 Questions 667 Chapter 18 Attacking the Application Server 669 Vulnerable Server Configuration 670 Default Credentials 670 Default Content 671 Directory Listings 677 WebDAV Methods 679 The Application Server as a Proxy 682 Misconfigured Virtual Hosting 683 Securing Web Server Configuration 684 Vulnerable Server Software 684 Application Framework Flaws 685 Memory Management Vulnerabilities 687 Encoding and Canonicalization 689 Finding Web Server Flaws 694 Securing Web Server Software 695 Web Application Firewalls 697 Summary 699 Questions 699 Chapter 19 Finding Vulnerabilities in Source Code 701 Approaches to Code Review 702 Black-Box Versus White-Box Testing 702 Code Review Methodology 703 Signatures of Common Vulnerabilities 704 Cross-Site Scripting 704 xviii Contents Chapter 20 Contents xix Technical Challenges Faced by Scanners 778 Current Products 781 Using a Vulnerability Scanner 783 Other Tools 785 Wikto/Nikto 785 Firebug 785 Hydra 785 Custom Scripts 786 Summary 789 Chapter 21 A Web Application Hacker's Methodology 791 General Guidelines 793 1 Map the Application's Content 795 1.1 Explore Visible Content 795 1.2 Consult Public Resources 796 1.3 Discover Hidden Content 796 1.4 Discover Default Content 797 1.5 Enumerate Identifier-Specified Functions 797 1.6 Test for Debug Parameters 798 2 Analyze the Application 798 2.1 Identify Functionality 798 2.2 Identify Data Entry Points 799 2.3 Identify the Technologies Used 799 2.4 Map the Attack Surface 800 3 Test Client-Side Controls 800 3.1 Test Transmission of Data Via the Client 801 3.2 Test Client-Side Controls Over User Input 801 3.3 Test Browser Extension Components 802 4 Test the Authentication Mechanism 805 4.1 Understand the Mechanism 805 4.2 Test Password Quality 806 4.3 Test for Username Enumeration 806 4.4 Test Resilience to Password Guessing 807 4.5 Test Any Account Recovery Function 807 4.6 Test Any Remember Me Function 808 4.7 Test Any Impersonation Function 808 4.8 Test Username Uniqueness 809 4.9 Test Predictability of Autogenerated Credentials 809 4.10 Check for Unsafe Transmission of Credentials 810 4.11 Check for Unsafe Distribution of Credentials 810 4.12 Test for Insecure Storage 811 4.13 Test for Logic Flaws 811 4.14 Exploit Any Vulnerabilities to Gain Unauthorized Access 813 5 Test the Session Management Mechanism 814 5.1 Understand the Mechanism 814 5.2 Test Tokens for Meaning 815 5.3 Test Tokens for Predictability 816 xx Contents 5.4 Check for Insecure Transmission of Tokens 817 5.5 Check for Disclosure of Tokens in Logs 817 5.6 Check Mapping of Tokens to Sessions 818 5.7 Test Session Termination 818 5.8 Check for Session Fixation 819 5.9 Check for CSRF 820 5.10 Check Cookie Scope 820 6 Test Access Controls 821 6.1 Understand the Access Control Requirements 821 6.2 Test with Multiple Accounts 822 6.3 Test with Limited Access 822 6.4 Test for Insecure Access Control Methods 823 7 Test for Input-Based Vulnerabilities 824 7.1 Fuzz All Request Parameters 824 7.2 Test for SQL Injection 827 7.3 Test for XSS and Other Response Injection 829 7.4 Test for OS Command Injection 832 7.5 Test for Path Traversal 833 7.6 Test for Script Injection 835 7.7 Test for File Inclusion 835 8 Test for Function-Specific Input Vulnerabilities 836 8.1 Test for SMTP Injection 836 8.2 Test for Native Software Vulnerabilities 837 8.3 Test for SOAP Injection 839 8.4 Test for LDAP Injection 839 8.5 Test for XPath Injection 840 8.6 Test for Back-End Request Injection 841 8.7 Test for XXE Injection 841 9 Test for Logic Flaws 842 9.1 Identify the Key Attack Surface 842 9.2 Test Multistage Processes 842 9.3 Test Handling of Incomplete Input 843 9.4 Test Trust Boundaries 844 9.5 Test Transaction Logic 844 10 Test for Shared Hosting Vulnerabilities 845 10.1 Test Segregation in Shared Infrastructures 845 10.2 Test Segregation Between ASP-Hosted Applications 845 11 Test for Application Server Vulnerabilities 846 11.1 Test for Default Credentials 846 11.2 Test for Default Content 847 11.3 Test for Dangerous HTTP Methods 847 11.4 Test for Proxy Functionality 847 11.5 Test for Virtual Hosting Misconfiguration 847 11.6 Test for Web Server Software Bugs 848 11.7 Test for Web Application Firewalling 848 Contents xxi 12 Miscellaneous Checks 849 12.1 Check for DOM-Based Attacks 849 12.2 Check for Local Privacy Vulnerabilities 850 12.3 Check for Weak SSL Ciphers 851 12.4 Check Same-Origin Policy Configuration 851 13 Follow Up Any Information Leakage 852 Index 853 Introduction This book is a practical guide to discovering and exploiting security flaws in web applications.

Secrets and Lies: Digital Security in a Networked World
by Bruce Schneier
Published 1 Jan 2000

Now, over a decade after Morris and about 35 years after they were first discovered, you’d think the security community would have solved the problem of security vulnerabilities based on buffer overflows. Think 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.

…

Hardly 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.

…

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 known by the security literati even earlier. Early networked computers 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 were first discovered, you’d think the security community would have solved the problem of security vulnerabilities based on buffer overflows.

Reversing: Secrets of Reverse Engineering
by Eldad Eilam
Published 15 Feb 2005

Knuth, 177, 187 assembler program, 11 Index assemblies (.NET), 426, 453 assembly language AT&T Unix notation, 49 code examples, 52–53 defined, 10–11, 44 flags, 46–47 instructions, 47–51 Intel notation, 49 machine code, 11 operation code (opcode), 11 platforms, 11 registers, 44–46 AT&T Unix assembly language 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 binary file comparison programs, 242 binary search algorithm, 177 binary searching, 32 binary trees, 32, 552, 554 BIOS/firmware malware, 279–280 ble instruction, 432 blt instruction, 432 bne instruction, 432 Boomerang IA-32 decompiler, 477 box instruction, 432 br instruction, 432 branch prediction, 67–68 branchless logic conditional instructions, 513–515 defined, 509 pure arithmetic, 510–512 break conditions in loops, 506–507 breaking copy protection technologies attacks, 324 challenge response, 315–316 class breaks, 312–313 cracking, 357–358 crypto-processors, 318–319 Defender crackme program, 415–416 dongle, 316–317 encryption, 318 hardware-based, 316–317 media-based, 314–316 objectives, 312 online activation, 315–316 requirements, 313 ripping algorithms, 365–370 serial numbers, 315 563 564 Index breaking copy protection technologies (continued) server-based software, 317 StarForce suite (StarForce Technologies), 345 trusted components, 312 Uncrackable Model, 314 breakpoint interrupt, 331 BreakPoint Software Hex Workshop, 131–132 breakpoints, 331–332 brute-forcing the Defender crackme program, 409–414 BSA and IDC Global Software Piracy Study, Business Software Alliance and IDC, 310 bugs (overflows) heap overflows, 255–256 integer overflows, 256–260 stack overflows, 245–255 string filters, 256 Business Software Alliance, BSA and IDC Global Software Piracy Study, 310 Byte magazine, 311 bytecodes defined, 12 difference from binary code, 61 interpreters, 61–62 just-in-time compilers (JiTs), 62 reversing strategies, 62–63 virtual machines, 12–13, 61 C C programming language, 34–35 C# programming language, 36–37, 428 C++ programming language, 35 CALL instruction, 51, 487, 540 call instruction, 431 calling conventions cdecl, 540 defined, 540 fastcall, 541 stdcall, 541 thiscall, 541 calling functions, 487 carry flag (CF), 520–521 cases Felten vs.

…

system (00401102) esp,0x4 edi esp,0x64 It is safe to say that regardless of intrinsic string-manipulation functions, any case where a function loops on the address of a stack-variable such as the one obtained 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 to be as simple as it seems. Sure, it would take a really careless developer to 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.

…

This trick works for functions that use stack parameters for returning values to their callers, and is typically implemented by having the caller pass a 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, which would get the function to overwrite a memory address chosen by the attacker (because the function takes that address and writes to it). By being able to 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 overflow bug.

Fancy Bear Goes Phishing: The Dark History of the Information Age, in Five Extraordinary Hacks
by Scott J. Shapiro

While Finger allows for a request up to 512 bytes long, it does not check to see if the request is over the limit. When a longer string is entered, Finger still tries to jam the oversize information into the data buffer. Like ten 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 computer’s memory known as the stack. The stack is like the scratch paper at the back of a math notebook. If the math problem is long, students will often dog-ear the page they are working on and turn to the back of the notebook to do the intermediary calculations.

…

Normally, overwriting the return instruction pointer would be catastrophic—it would crash the program because the computer would not know what to do after it 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 supersize request that was 536 bytes long. The first 512 bytes filled the data buffer set up by the Finger server. This part of the request was mostly garbage—just a meaningless binary sequence.

…

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 a new tool, called Static Driver Verification (SDV), using these theorem provers and distributed it with the Windows Driver Development kit.

Advanced Software Testing—Vol. 3, 2nd Edition
by Jamie L. Mitchell and Rex Black
Published 15 Feb 2015

When the function is done executing, that return address is picked up and the thread of execution jumps to there. If the buffer overflows and that address is overwritten, the system will almost always crash because the next execution step is not actually executable. But suppose the buffer overflow is done skillfully by a hacker? They can determine the right length to overflow the buffer so they can put in a pointer to their own code. When the function returns, rather than going back to where it was called from, it goes to the line of code the hacker wants to run. Oops! You just lost your computer. Anytime you have a data transfer between systems, buffer overflow can be a concern—especially if your organization did not write the connecting code.

…

Strong password control processes should be mandatory, with testing regularly occurring to make sure they are enforced. All sensitive data in the binaries and all data files should be encrypted. Temporary files should be obfuscated and deleted after use. 4.2.1.2 Buffer Overflow It seems like every time anyone turns on their computer nowadays, they are requested to install a security patch from one organization or another. A good number of these patches are designed to fix the latest buffer overflow issue. A buffer is a chunk of memory that is allocated by a process to store some data. As such, it has a finite length. The problems occur when the data to be stored is longer than the buffer.

…

Table of Contents Jamie Mitchell’s Acknowledgements Rex Black’s Acknowledgements Introduction 1 The Technical Test Analyst’s Tasks in Risk-Based Testing 1.1 Introduction 1.2 Risk Identification 1.3 Risk Assessment 1.4 Risk Mitigation or Risk Control 1.5 An Example of Risk Identification and Assessment Results 1.6 Risk-Aware Testing Standard 1.7 Sample Exam Questions 2 Structure-Based Testing 2.1 Introduction 2.1.1 Control Flow Testing Theory 2.1.2 Building Control Flow Graphs 2.1.3 Statement Coverage 2.1.4 Decision Coverage 2.1.5 Loop Coverage 2.1.6 Hexadecimal Converter Exercise 2.1.7 Hexadecimal Converter Exercise Debrief 2.2 Condition Coverage 2.3 Decision Condition Coverage 2.4 Modified Condition/Decision Coverage (MC/DC) 2.4.1 Complicating Issues: Short-Circuiting 2.4.2 Complicating Issues: Coupling 2.5 Multiple Condition Coverage 2.5.1 Control Flow Exercise 2.5.2 Control Flow Exercise Debrief 2.6 Path Testing 2.6.1 Path Testing via Flow Graphs 2.6.2 Basis Path Testing 2.6.3 Cyclomatic Complexity Exercise 2.6.4 Cyclomatic Complexity Exercise Debrief 2.7 API Testing 2.8 Selecting a Structure-Based Technique 2.8.1 Structure-Based Testing Exercise Debrief 2.9 A Final Word on Structural Testing 2.10 Sample Exam Questions 3 Analytical Techniques 3.1 Introduction 3.2 Static Analysis 3.2.1 Control Flow Analysis 3.2.2 Data Flow Analysis 3.2.2.1 Define-Use Pairs 3.2.2.2 Define-Use Pair Example 3.2.2.3 Data Flow Exercise 3.2.2.4 Data Flow Exercise Debrief 3.2.2.5 A Data Flow Strategy 3.2.3 Static Analysis to Improve Maintainability 3.2.3.1 Code Parsing Tools 3.2.3.2 Standards and Guidelines 3.2.4 Call Graphs 3.2.4.1 Call-Graph-Based Integration Testing 3.2.4.2 McCabe’s Design Predicate Approach to Integration 3.2.4.3 Hex Converter Example 3.2.4.4 McCabe Design Predicate Exercise 3.2.4.5 McCabe Design Predicate Exercise Debrief 3.3 Dynamic Analysis 3.3.1 Memory Leak Detection 3.3.2 Wild Pointer Detection 3.3.3 Dynamic Analysis Exercise 3.3.4 Dynamic Analysis Exercise Debrief 3.4 Sample Exam Questions 4 Quality Characteristics for Technical Testing 4.1 Introduction 4.2 Security Testing 4.2.1 Security Issues 4.2.1.1 Piracy 4.2.1.2 Buffer Overflow 4.2.1.3 Denial of Service 4.2.1.4 Data Transfer Interception 4.2.1.5 Breaking Encryption 4.2.1.6 Logic Bombs/Viruses/Worms 4.2.1.7 Cross-Site Scripting 4.2.1.8 Timely Information 4.2.1.9 Internal Security Metrics 4.2.1.10 External Security Metrics 4.2.1.11 Exercise: Security 4.2.1.12 Exercise: Security Debrief 4.3 Reliability Testing 4.3.1 Maturity 4.3.1.1 Internal Maturity Metrics 4.3.1.2 External Maturity Metrics 4.3.2 Fault Tolerance 4.3.2.1 Internal Fault Tolerance Metrics 4.3.2.2 External Fault Tolerance Metrics 4.3.3 Recoverability 4.3.3.1 Internal Recoverability Metrics 4.3.3.2 External Recoverability Metrics 4.3.4 Compliance 4.3.4.1 Internal Compliance Metrics 4.3.4.2 External Compliance Metrics 4.3.5 An Example of Good Reliability Testing 4.3.6 Exercise: Reliability Testing 4.3.7 Exercise: Reliability Testing Debrief 4.4 Efficiency Testing 4.4.1 Multiple Flavors of Efficiency Testing 4.4.2 Modeling the System 4.4.2.1 Identify the Test Environment 4.4.2.2 Identify the Performance Acceptance Criteria 4.4.2.3 Plan and Design Tests 4.4.2.4 Configure the Test Environment 4.4.2.5 Implement the Test Design 4.4.2.6 Execute the Test 4.4.2.7 Analyze the Results, Tune and Retest 4.4.3 Time Behavior 4.4.3.1 Internal Time Behavior Metrics 4.4.3.2 External Time Behavior Metrics 4.4.4 Resource Utilization 4.4.4.1 Internal Resource Utilization Metrics 4.4.4.2 External Resource Utilization Metrics 4.4.5 Compliance 4.4.5.1 Internal Compliance Metric 4.4.5.2 External Compliance Metric 4.4.6 Exercise: Efficiency Testing 4.4.7 Exercise: Efficiency Testing Debrief 4.5 Maintainability Testing 4.5.1 Analyzability 4.5.1.1 Internal Analyzability Metrics 4.5.1.2 External Analyzability Metrics 4.5.2 Changeability 4.5.2.1 Internal Changeability Metrics 4.5.2.2 External Changeability Metrics 4.5.3 Stability 4.5.3.1 Internal Stability Metrics 4.5.3.2 External Stability Metrics 4.5.4 Testability 4.5.4.1 Internal Testability Metrics 4.5.4.2 External Testability Metrics 4.5.5 Compliance 4.5.5.1 Internal Compliance Metric 4.5.5.2 External Compliance Metric 4.5.6 Exercise: Maintainability Testing 4.5.7 Exercise: Maintainability Testing Debrief 4.6 Portability Testing 4.6.1 Adaptability 4.6.1.1 Internal Adaptability Metrics 4.6.1.2 External Adaptability Metrics 4.6.2 Replaceability 4.6.2.1 Internal Replaceability Metrics 4.6.2.2 External Replaceability Metrics 4.6.3 Installability 4.6.3.1 Internal Installability Metrics 4.6.3.2 External Installability Metrics 4.6.4 Coexistence 4.6.4.1 Internal Coexistence Metrics 4.6.4.2 External Coexistence Metrics 4.6.5 Compliance 4.6.5.1 Internal Compliance Metrics 4.6.5.2 External Compliance Metrics 4.6.6 Exercise: Portability Testing 4.6.7 Exercise: Portability Testing Debrief 4.7 General Planning Issues 4.8 Sample Exam Questions 5 Reviews 5.1 Introduction 5.2 Using Checklists in Reviews 5.2.1 Some General Checklist Items for Design and Architecture Reviews 5.2.2 Deutsch’s Design Review Checklist 5.2.3 Some General Checklist Items for Code Reviews 5.2.4 Marick’s Code Review Checklist 5.2.5 The Open Laszlo Code Review Checklist 5.3 Deutsch Checklist Review Exercise 5.4 Deutsch Checklist Review Exercise Debrief 5.5 Code Review Exercise 5.6 Code Review Exercise Debrief 5.7 Sample Exam Questions 6 Test Tools and Automation 6.1 Integration and Information Interchange between Tools 6.2 Defining the Test Automation Project 6.2.1 Preparing for a Test Automation Project 6.2.2 Why Automation Projects Fail 6.2.3 Automation Architectures (Data Driven vs.

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
Published 29 Mar 2020

This approach does not lead to a particularly high degree of confidence. It’s quite possible, and in many cases likely, that behavior not covered by testing or in-depth code review will harbor bugs. It’s telling that well-understood common classes of software vulnerabilities like SQL injection, cross-site scripting (XSS), and buffer overflows have maintained leading positions in “top vulnerability” lists.2 Absence of evidence is not evidence of absence. On the other end of the spectrum, you might perform analyses based on provably sound, formal reasoning: the system and the claimed properties are modeled in a formal logic, and you construct a logical proof (typically with the help of an automated proof assistant) that the property holds for the system.3 This approach is difficult and involves a lot of work.

…

These include the following: W^X Breaks the common exploitation trick of mmaping with PROT_EXEC by copying shellcode and jumping into that memory. This mitigation does not incur a CPU or memory performance hit. Scudo Allocator A user-mode secure heap allocator. SafeStack A security mitigation technique that protects against attacks based on stack buffer overflows. Complexity Versus Understandability As a defensive measure, we explicitly chose to implement our CA with limited functionality compared to the full range of options available in the standards (see “Designing Understandable Systems”). Our primary use case was to issue certificates for standard web services with commonly used attributes and extensions.

…

C++: Valgrind or Google Sanitizers C++ allows for low-level memory management. As we mentioned earlier, memory management errors are a leading cause of security issues, and can result in the following failure scenarios: Reading unallocated memory (before new or after delete) Reading outside of the allocated memory (buffer overflow attack scenario) Reading uninitialized memory Memory leaks when a system loses the address of allocated memory or doesn’t deallocate unused memory early Valgrind is a popular framework that allows developers to catch those sorts of errors, even if unit tests don’t catch them. Valgrind has the benefit of providing a virtual machine that interprets a user’s binary, so users don’t need to recompile their code to use it.

Beautiful security
by Andy Oram and John Viega
Published 15 Dec 2009

As Beautiful Security went to press, I read that a piece of software capable of turning on microphones and cameras and stealing data has been discovered on more than 1,200 computers in 103 countries, particularly in embassies and other sensitive government sites. On another front, a court upheld the right of U.S. investigators to look at phone and Internet records without a warrant (so long as one end of the conversation is outside the U.S.). And this week’s routine vulnerabilities include a buffer overflow in Adobe Acrobat and Adobe Reader—with known current exploits—that lets attackers execute arbitrary code on your system using your privileges after you open their PDF. Headlines are actually not good indicators of trends, because in the long run history is driven by subtle evolutionary changes noticed only by a few—such as the leading security experts who contributed to this book.

…

As one example, the ISS scanner would connect to the finger service on a remote system to collect remote system information. However, the scanning software had a classic problem in one of its security tests: the program did not check the length of the returned information and blindly copied it into a fixed-size buffer. This resulted in a garden-variety buffer overflow on the program’s stack. Knowing this about the scanner, and knowing the architecture of the system the scanner was running on, I set up malicious servers to exploit this opportunity. When the company I was employed by would receive their annual audit, as a part of evaluation the auditors would run network vulnerability scans from laptops they brought in and connected to the internal network.

…

The executives could justifiably claim that vulnerabilities found on our internal systems (living behind firewalls and other defensive technologies) were not as severe a risk to the corporation as disclosure of sensitive information to competitors by the auditors themselves—made possible by the “security software” they used. Functional fixation might cause one to forget to check the security of the security-checking software itself. Modern anti-virus software, unfortunately, has been found to include all sorts of common programming vulnerabilities, such as local buffer overflows, unchecked execution capabilities, and lack of authentication in auto-update activities. This security software, therefore, can also become the opening for attackers rather than the defense it was intended for. PSYCHOLOGICAL SECURITY TRAPS 15 The preceding examples are straightforward examples of functional fixation and can be attributed to the same naïveté I discussed in the section on learned helplessness.

Linux Security Cookbook
by Daniel J. Barrett , Richard E. Silverman and Robert G. Byrnes
Published 8 Jun 2003

ngrep prints a hash character (#) for each packet that matches the filter expression: only those packets that match the regular expression are printed in detail. Use the -q option to suppress the hashes. To search for binary data, use the -X option with a sequence of hexadecimal digits (of any length) instead of a regular expression. This can detect some kinds of buffer overflow attacks, characterized by known signatures of fixed binary data. ngrep matches data only within individual packets. If strings are split between packets due to fragmentation, they will not be found. Try to match shorter strings to reduce (but not entirely eliminate) the probability of these misses.

…

It sniffs packets from the network and analyzes them according to a collection of well-known signatures characteristic of suspicious or hostile activities. This may remind you of an anti-virus tool, which looks for patterns in files to identify viruses. By examining the protocol information and payload of each packet (or a sequence of packets) and applying its pattern-matching rules, Snort can identify the telltale fingerprints of attempted buffer overflows, denial of service attacks, port scans, and many other kinds of probes. When Snort detects a disturbing event, it can log network trace information for further investigation, and issue alerts so you can respond rapidly. 9.20.4 See Also snort(8). The Snort home page is http://www.snort.org.

…

For example, the message that your network interface is in "promiscuous mode" is tagged as a kernel message, even though it means someone could be using your machine as a packet sniffer. Likewise, if a system daemon emits a complaint about a ridiculously long name, perhaps filled with control characters, someone might be trying to exploit a buffer overflow vulnerability. Vigilance requires the examination of a wide range of messages. Even messages that are not directly associated with security can provide a valuable context for security events. It can be reassuring to see that the kernel's "promiscuous mode" message was preceded by a note from a system administrator about using Ethereal to debug a network problem.

Masterminds of Programming: Conversations With the Creators of Major Programming Languages
by Federico Biancuzzi and Shane Warden
Published 21 Mar 2009

One of them is logic errors of one sort, so that there’s something that you can say to the program and it makes a mistake and it gives you privileges or does things it’s just not supposed to do at all. The other is the whole buffer overflow stuff, which is implementation errors of various sorts that are exploitable, actual bugs that people didn’t think about. And I think most of those just shouldn’t be there. Low-level languages support buffer overflow with careless programming of various sorts, so it’s not easy to get right. I thought there was a time when it was rumored that Microsoft for what became Vista was just going to rewrite all the C and C++ into C#, and at that point you weren’t going to get buffer overflows, because you can’t get buffer overflows. But of course that didn’t work out.

…

It incorporated some of the first OO ideas long before OO was invented, and did them better than most OO systems do now. It looked fresh in 1986 and still does over 20 years later. So why do we still have many graphical tools that are inferior to Sketchpad today? Why do we still have buffer overflow errors—a prolific source of loopholes for malware—in operating systems today? Why do we still use languages like C and C++ that don’t understand the concept of bounded arrays and so facilitate buffer overflow errors? Sure, C++ can define bounded arrays, but programmers still use naked pointers far too much. It’s all ignorance, laziness, or arrogance on the part of developers. Computing is difficult, and it is impossible to avoid logical mistakes in complicated systems, but there is no excuse for still making this kind of rookie mistake after all these years.

…

Here it really helps that you can write very compact code in Python—writing 100 lines of Python to run an experiment once and then starting over is much more efficient than writing a 1,000-line framework for experimentation in Java and then finding out it solves the wrong problem! From a security point of view, what does Python offer to the programmer? Guido: That depends on the attacks you’re worried about. Python has automatic memory allocation, so Python programs aren’t prone to certain types of bugs that are common in C and C++ code like buffer overflows or using deallocated memory, which have been the bread and butter of many attacks on Microsoft software. Of course the Python runtime itself is written in C, and indeed vulnerabilities have been found here over the years, and there are intentional escapes from the confines of the Python runtime, like the ctypes module that lets one call arbitrary C code.

Kingpin: How One Hacker Took Over the Billion-Dollar Cybercrime Underground
by Kevin Poulsen
Published 22 Feb 2011

Across the floor, more tables were cluttered with vintage computer gear, odd electronics, lock-picking tools, T-shirts, books, and copies of 2600: The Hacker Quarterly. Max spotted Elias Levy, a famous white-hat hacker, and pointed him out to Kimi. Levy, aka Aleph One, was the moderator of the Bugtraq mailing list—the New York Times of computer security—and the author of a seminal tutorial on buffer overflows called “Smashing the Stack for Fun and Profit” that had appeared in Phrack. Max didn’t dare approach the luminary. What would he say? Max wasn’t the only law enforcement mole at Def Con, of course. From its humble beginnings in 1992 as a one-off conference pulled together by a former phone phreak, Def Con had grown into a legendary gathering that drew nearly two thousand hackers, computer security professionals, and hangers-on from around the world.

…

Max was still plugged into the white-hat scene, and he was on the private mailing lists where security holes often appeared for the first time. He had machines scanning the Internet day and night for servers running vulnerable software, just to see what he’d turn up. He was scanning for a Windows server-side buffer overflow when he made the discovery that would lead to his public entry into the carding scene. His scanning put him inside a Windows machine that, on closer inspection, was in the back office of a Pizza Schmizza restaurant in Vancouver, Washington; he knew the place, it was near his mother’s house. As he looked around the computer, he realized the PC was acting as the back-end system for the point-of-sale terminals at the restaurant—it collected the day’s credit card transactions and sent them in a single batch every night to the credit card processor.

…

He found no smoking gun. Could he really have brought an informant into the inner circle of his new crime site? The problem was that there was no reliable test to determine if Johnson, or anyone else, was working for the government. Max wanted one badly—a jurisprudence security hole, like the buffer overflow in BIND, that he could use over and over again on anyone he suspected. If (is_snitch(Gollumfun)) ban(Gollumfun);. He confided in David Thomas, not realizing that Thomas had already put Iceman on his mile-long enemies list. At one point in checking him out, he sent us some PayPal fulls that were valid, which I pegged as illegal.

Hands-On RESTful API Design Patterns and Best Practices
by Harihara Subramanian
Published 31 Jan 2019

Denial-of-service attack A denial-of-service (DoS) attack is intended to make the targeted machine reach its maximum load (capacity to serve requests) quickly by sending numerous false requests so the target system denies further genuine requests. Flood attacks and buffer overflow attacks are two categories of DoS. With flood attacks, the attacker saturates the target server by generating enormous traffic to the server, causing the target server to end up in DoS. On the other hand, a buffer overflow attack is intended to target a machine and make that machine consume all available memory or hard disk space, or cause high usage of the CPU. This result in various consequences, such as the system becoming slow to respond or sluggish in its behavior, and there may even be a situation in which the targeted system will crash, creating potentially catastrophic results.

…

API design and development flaws Missing or not adhering to API security principles and best practices may lead to defects that expose business-critical data. Another aspect of design and development is to keep APIs as simple as possible, as complexity may lead to less coverage and vulnerability. Poor user input validation, SQL injection loopholes, and buffer overflows are a few other causes. Chapter 2, Design Strategy, Guidelines, and Best Practices, discussed various aspects of design strategies and RESTful API design practices. Understanding and implementing those design principles and practices in APIs helps reduce design and development flaws. Poor system configuration Even the best design and development is not necessarily enough to safeguard a system if the system configurations (where the APIs are) do not adhere to security compliance.

…

A few of the tools are listed in the following table (both commercial and open source versions): Tool Type Providers Nmap OpenSSL Pure Hacking Nessus Cain and Abel Torrid Networks Metasploit THC Hydra SecPoint Wireshark w3af Veracode Let's summarize this section by stating that pen tests for APIs should expose API vulnerabilities before real attackers find them, and move on to fuzz tests. Fuzz tests Fuzz testing, also known as fuzzing, is one of the most widely used testing practices in the quality assurance phase. It involves massive amounts of random data (noise or fuzz) as input to the target system with the intention of targeting APIs to exhibit buffer overflow or any other unwanted behaviors, or even to provoke the system to crash. Barton Miller at the University of Wisconsin introduced fuzz testing (in 1988, as part of his Operating System Utility Program Reliability – The Fuzz Generator project) to reveal any security loopholes and coding errors in APIs, software, networks, and operating systems.

Network Security Through Data Analysis: Building Situational Awareness
by Michael S Collins
Published 23 Feb 2014

Effective security analysis requires collecting data from widely disparate sources, each of which provides part of a picture about a particular event taking place on a network. To understand the need for hybrid data sources, consider that most modern bots are general purpose software systems. A single bot may use multiple techniques to infiltrate and attack other hosts on a network. These attacks may include buffer overflows, spreading across network shares, and simple password cracking. A bot attacking an SSH server with a password attempt may be logged by that host’s SSH logfile, providing concrete evidence of an attack but no information on anything else the bot did. Network traffic might not be able to reconstruct the sessions, but it can tell you about other actions by the attacker—including, say, a successful long session with a host that never reported such a session taking place, no siree.

…

Read the original papers on NIDS by Paxson and Roesch and you’ll see that they were thinking about hand-crafted attacks on systems that they’d be able to defend by looking for people trying to log in as root or admin. There was a functionality change around 2001, which was the beginning of a very nasty worm-heavy era in defense. Worms like Code Red and Slammer caused widespread havoc by spreading actively and destructively choking bandwidth. The Code Red v1 and v2 worms both exploited a buffer overflow in Microsoft IIS in order to subvert IIS processes and launch an attack against the White House. The orignal Code Red worm contained a payload looking like the following: GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801 %u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff %u0078%u0000%u00=a HTTP/1.0 IDS at the time detected Code Red by looking for that specific payload, and a couple of weeks later, an updated version of the worm using the same exploit was launched.

…

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801 %u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff %u0078%u0000%u00=a HTTP/1.0 As a buffer overflow, the Code Red worms needed to pad their contents in order to reach a specific memory location; the worms were often differentiated by the presence of an X or an N in the buffer. The thing is, the buffer contents are irrelevant to the execution of the worm; an attacker could change them at will without changing the functionality.

Nagios: System and Network Monitoring, 2nd Edition
by Wolfgang Barth
Published 19 Aug 2009

In order for the user nagios to be able to run the plugin with root permissions, the plugin must belong to the user root and the SUID bit must be set. If you install the plugins from a current tarball, the permissions will be set correctly. Several distributions disable the SUID bit, as it represents a potential danger—it is possible that general root permissions may slip in via buffer overflows in uncleanly programmed code. Here the program owner must be changed manually to the user root so that the SUID bit can be set with chmod. When this is done, only the group nagios, apart from root, is allowed to run the plugin: linux:nagios/libexec # chown root.nagios check_dhcp linux:nagios/libexec # chmod 4750 check_dhcp linux:nagios/libexec # ls -l check_dhcp -rwsr-x--- 1 root nagios 115095 Jan 8 12:15 check_dhcp The chown command assigns the plugin to the user root and to the group nagios, to whom nobody else should belong apart from the user nagios itself.

…

Here is the example of a server on which the plugin check_disk (see 7.1 Free Hard Drive Capacity from page 158) is required to monitor nine file systems: command[check_disk_a]=path/to/check_disk -w 5% -c 2% -p /net/linux01/a command[check_disk_b]=path/to/check_disk -w 4% -c 2% -p /net/linux01/b command[check_disk_c]=path/to/check_disk -w 5% -c 2% -p /net/linux01/c command[check_disk_d]=path/to/check_disk -w 5% -c 2% -p /net/linux01/d command[check_disk_root]=path/to/check_disk -w 10% -c 5% -p / command[check_disk_usr]=path/to/check_disk -w 10% -c 5% -p /usr command[check_disk_var]=path/to/check_disk -w 10% -c 5% -p /var command[check_disk_home]=path/to/check_disk -w 10% -c 5% -p /home command[check_disk_tmp]=path/to/check_disk -w 10% -c 5% -p /tmp To avoid all this work, NRPE can also be configured so that parameters may be passed on to check_nrpe: dont_blame_nrpe=1 ... command[check_disk]=path/to/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ In order for this to work, the NRPE configure script must be run with the option --enable-command-args. The reason for this inconvenient procedure is that passing parameters on is a fundamental risk, since it cannot be ruled out that a certain choice of parameters could cause an (as yet unknown) buffer overflow, allowing the target system to be penetrated. If you still decide on this, despite all the security risks, you should use a TCP wrapper (see 10.2.2 inetd configurationt, page 217), to ensure that only the Nagios server itself is allowed to send commands to NRPE. If the plugin provides the corresponding options, there is sometimes a third method, however: the above-mentioned problem can also be solved by getting check_disk, if necessary, to test all file systems with one single command: user@linux:nagios/libexec$ .

…

extTable.extEntry.extResult contains the return value of the command executed, and extTable.extEntry.extOutput contains the text output. With the exec directive you can thus query everything that a local script or program can find out. This could be a security problem, however: if the programs used are susceptible to buffer overflows, this feature could be misused as a starting point for a denial-of-service attack. Monitoring hard drive capacity The disk directive is suitable for monitoring file systems. The keyword disk is followed by the path for a mount point, and then the minimum hard drive space in KB or in percent that should be available.

Cult of the Dead Cow: How the Original Hacking Supergroup Might Just Save the World
by Joseph Menn
Published 3 Jun 2019

He was thinking of himself as a computer game programmer when he read papers by Mudge and others about finding software flaws that could be exploited, and he became entranced with the idea. Among the more promising classes of screwups in programming was a failure to stop what were called buffer overflows. If the coder did not properly limit the amount of data that could be taken into a buffered area of memory, a hacker could enter too much and overflow it, making the excess data delete something in nearby storage. In some cases, that would allow the hacker to take control of the machine. Buffer overflows had been found in a number of high-performance systems, though not the early versions of Windows. Christien found an overflow in Internet Explorer 4, the browser that Microsoft improperly bundled with Windows in 1997 in order to beat pioneer Netscape.

…

Despite his youth, the group took Christien along for hangout sessions at New Hack City, home to the cDc servers. Mudge impressed him while playing quarters by rolling the coins off his nose before they bounced into a beer glass. As an MIT junior, Christien took a class on social issues in computing that turned out to be mostly about security. An early assignment was to look into buffer overflows, and the instructor put up a slide of one attributed to Dildog. “This is going to be much easier than I thought,” Christien said to himself. The L0pht invited him to join in late 1998, after Christien graduated, and it used money from the sale of its security tools to pay him to write the next version of its best-known program, the L0phtCrack password breaker.

Click Here to Kill Everybody: Security and Survival in a Hyper-Connected World
by Bruce Schneier
Published 3 Sep 2018

Adrian Kingsley-Hughes (19 Dec 2017), “Apple seems to have forgotten about the whole ‘it just works’ thing,” ZDNet, http://www.zdnet.com/article/apple-seems-to-have-forgotten-about-the-whole-it-just-works-thing. 20And NASA had a famous quality control process: National Research Council (1996), “Case study: NASA space shuttle flight control software,” in Statistical Software Engineering, National Academies Press, https://www.nap.edu/read/5018/chapter/4. 21NASA still has crazily conservative: Martha Wetherholt (1 Sep 2015), “NASA’s approach to software assurance,” Crosstalk, http://static1.1.sqspcdn.com/static/f/702523/26502332/1441086732177/201509-Wetherholt.pdf. 21An example is something called: Peter Bright (25 Aug 2015), “How security flaws work: The buffer overflow,” Ars Technica, https://arstechnica.com/information-technology/2015/08/how-security-flaws-work-the-buffer-overflow. 21We don’t know what percentage: Eric Rescorla (1 Jan 2005), “Is finding security holes a good idea?” IEEE Security & Privacy 3, no. 1, https://dl.acm.org/citation.cfm?id=1048817. Andy Ozment and Stuart Schechter (1 Jul 2006), “Milk or wine: Does software security improve with age?”

…

NASA still has crazily conservative quality assurance standards. And even for relatively high-quality software systems like Windows, macOS, iOS, and Android, you’re still installing patches all the time. Some bugs are also security vulnerabilities, and some of those security vulnerabilities can be exploited by attackers. An example is something called a buffer overflow bug. It’s a programming mistake that allows an attacker, in some cases, to force the program to run arbitrary commands and take control of the computer. There are lots of areas of potential mistakes like this, some easier to make than others. Here, numbers are hard to pin down. We don’t know what percentage of bugs are also vulnerabilities and what percentage of vulnerabilities are exploitable, and there is legitimate academic debate about whether these exploitable bugs are sparse or plentiful.

…

Abbott Labs, 38, 41 Access Now, 214 accountability, 112, 128, 147 ACLU, 223 ad blockers, 16 African Union, 89 airline safety, 144 airplanes: bugs in, 41 remote control of, 1–2, 16 air traffic control, 210 Alexa (Amazon’s virtual assistant), 4, 61 Alexander, Keith, 118 algorithms: accurate inputs required by, 84 autonomous, 7, 82–87 data needed by, 84 hacking of, 83–84 machine learning, 82–83, 85, 111–12 physical agency of, 83 and robots, 86–87 security standards for, 111–12, 148 speed of, 84–85 Alibaba website, 169 Alphabet (Google’s parent company), 57 Alphonso, 58 Amazon, 57, 61, 62 Amnesia IoT botnet, 37 Amnesty International, 223 Anderson, Ross, 185 Andromeda botnet, 52 Angry Birds, 58 anonymity, 52, 53, 110, 199–200 Apple, 57, 60, 78, 174, 196 Applied Cryptography (Schneier), 32 Arab Spring, 67 arbitration agreements, 129 Arthur Andersen, 127 artificial intelligence (AI), 7, 86–87, 95, 148, 149, 219 Ashley Madison, hacking of, 78 AT&T, 113 Atomic Energy Commission (AEC), 149 attack vs. defense, 160–79 attack as US priority in, 73 attack easier than defense, 219 attacks changing in, 32–33 “defense dominant” strategy, 160 design for security vs. surveillance, 167–70 fixing vulnerabilities in, 162–67 in law enforcement, 173–76 offensive autonomous attack software, 85 and relationship between government and industry, 176–79 security as, 10, 16, 26–28 zero days in, 162, 163, 165 attribution, 52–55 in cyberattacks, 72, 203 detection evasion, 55 main points of, 54 authentication, 45–51 continuous, 47 differential, 47, 49 hub-and-spoke model of, 50 and identification, 51 and identity theft, 50–51, 171 and impersonation, 51 in Internet+, 49–51 methods of, 46 standards of, 109, 169 trade-off between security and usability in, 47 two-factor, 47, 49, 200 automobiles: aging, 39–40 bugs in, 41 driverless, 4, 205 industry regulation of, 182, 186 international markets for, 186, 187 Internet connection in, 6 manufacturer support of, 39–40 remote hacking of, 1, 3, 16 repair manuals for, 139 safety of, 139, 182 security standards for, 151 availability, attacks on, 78–82 Azimuth, 162 baby monitors, 133–35 backdoors, 26, 87, 88, 172, 174, 193–98, 220 Baker, Stewart, 204 balkanization, 157 banks, data manipulation attacks on, 81–82 Baratov, Karim, 30 Beckstrom, Rod, 19 Belan, Alexsey, 30 Bell, Alexander Graham, 152 best efforts, 122 Beyond Fear (Schneier), 211 “big data,” 57 biometrics, authentication via, 46, 47 Bismarck, Otto von, 220 bitcoin, 15, 74, 75, 77, 198, 218 blackouts, 29, 90 Blade Runner (film), 218 Blaster worm, 94 Bluetooth, 50, 58, 79 Bohm, Nick, 220 Border Gateway Protocol (BGP), 22, 23, 24, 115 Boston Marathon bombing (2013), 95, 202 Boston MBTA, 42 botnets, 26, 75, 77, 95, 139 Bowman Dam, Rye, New York, 79 breach disclosure laws, 137–38 bribery, 183 Brightest Flashlight, 58 BT, 113 Buckshot Yankee, 66 Budapest Convention on Cybercrime, 157 buffer overflow bug, 21 bug bounties, 36 bugs, 20–21, 41 CALEA (Communications Assistance for Law Enforcement Act) [1994], 168, 170 California, “Teddy Bears and Toasters” bill in, 187–88 Calo, Ryan, 149 Cameron, David, 197 Campos, Hugo, 63 CAN-SPAM Act (2003), 154 Caproni, Valerie, 193 “Capture the Flag” (hacking sport), 85 Carbon Black, 74 Carson, Rachel, Silent Spring, 183 caveat emptor, 131 Cellebrite, 174 cell towers, 32–33 fake, 168–70 Center on Privacy and Technology, 224 CEO fraud, 75 Challenger, 29 Check Point (Israeli company), 87 Cheney, Dick, 76, 93, 94 Chertoff, Michael, 198 Child Online Protection Act (1998), 154, 192–93 child porn, 183 China: and African Union headquarters, 89 censorship in, 67–68 and cybercrime law, 156, 158 cyberespionage by, 66, 67, 81 eavesdropping on communications, 195–96 hacking by, 45 intellectual property theft by, 66, 72–73 social control in, 67–68 China Telecom, 113 chips: general-purpose, 6 vulnerabilities in, 21 CIA, 73, 77, 165–67 Cisco Internet switches, 170 cities, smart sensors in, 4, 6 Citizen Lab, 64 Clapper, James, 66, 81 Clark, David, 23 class-action lawsuits, 129 class breaks: hacking via, 33, 95 use of term, 31–32 click fraud, 16, 75 cloud computing, 7, 190 Code for America, 223 Cogent ISP, 115 Cohen, Julie, 154 Comcast, 62, 113 Comey, James, 193–94 Commission on Enhancing National Cybersecurity, 180–81 complexity, 11, 27 and accidents, 80 theory of, 210 and unpredictability, 211 Computer Fraud and Abuse Act (1986), 42 computers: extensibility of, 24–26 as ubiquitous, 1–5, 19 vulnerabilities in, 30–32 confidentiality, threats to, 78–81 Consumers Union, 136, 145 copy protection, 25, 41, 62, 131, 154, 155, 205 Core Infrastructure Initiative, 115 corporations: CEO fraud in, 75 consumers controlled by, 59–64 data sought by, 57 infrastructure controlled by, 117 insecurity favored by, 56 profit maximization by, 118 regulation evaded by, 154–55 surveillance capitalism in, 57–59, 65, 209 CrashOverride, 2, 4–5 credential stealing, 45–47 credit card fraud, 16, 100 crime rate, public toleration of, 92 crimeware-as-a-service (CaaS), 76 cryptanalysis, differential, 33 cryptocurrencies, 172, 198 Cuban Missile Crisis (1962), 95 “cyber,” as umbrella term, 183–84 cyberattacks, 68–74, 116, 203, 217 Cyberbit (Israel), 65 cybercrime, 74–77, 156, 158 cyberdefense: “active,” 203 national agency for, 148 cyberespionage, see espionage Cyber Grand Challenge, 85 cyber incident data repository, 177 cyber peace, 213–14 cyberphysical systems, 7 cyber resilience, 211–12 cybersecurity, see Internet+ security Cybersecurity Improvement Act (2017), 180, 208 Cyber Shield Act (2017), 136 cyberstalking, 76 Cyber Threat Alliance, 177 cyberwar, 68–74 arms race in, 73, 116, 212–14 attribution in, 72 autonomous weapons in, 86 cyberespionage vs., 72 cyber mercenaries in, 70 limited response in, 71 “preparing the battlefield,” 69 and unpeace, 71–74 cyberweapons: in armed conflict, 72 autonomous, 86 instability of, 72, 212 manufacturers, 65 nonproliferation standards for, 158 theft of, 73 Daniel, Michael, 164 Darknet, 198 DARPA (US Defense Advanced Research Projects Agency), 85 data: accuracy of, 84 in adversarial machine learning, 84 anonymity of, 110 as byproduct, 57 “Collect it all,” 118 deletion of, 110 encryption of, 109, 171 integrity of, 80, 81, 109 jurisdiction over, 146 limits on collection of, 109 metadata, 174 natural bias of, 84 ownership of, 109 personal, control of, 62–63, 64, 109–11 sharing of, 177–79 storage and processing of, 174 Data and Goliath (Schneier), 110, 172 databases: encryption of, 171 threats to, 79, 80, 81 data brokers, 58 Data Encryption Standard (DES), 32, 33 DDoS (distributed denial-of-service) attack, 29, 130, 202 Deepwater Horizon disaster, 124 “defense dominance,” 160 see also attack vs. defense Democratic National Committee, Russian attacks on (2016), 30, 45, 78, 80 denial of service, 29, 79, 81, 130, 202 Department of Homeland Security, 117, 138 Derechos Digitales, Chile, 214 detection evasion, 55 Digital HKS, Harvard, 224 Digital Millennium Copyright Act (DMCA), 41–42, 62, 154, 193, 205–6, 220 digital rights management (DRM), 25, 62, 205 Digital Security Helpline, 214 DNSChanger malware, 37 Doctorow, Cory, 163 Dodd-Frank Act (2010), 126 Domain Name Service, 24, 115 security (DNSSEC), 24 domino effect, 210 “Don’t Panic,” 174 drones, 7, 80, 91, 95, 151, 200 Dyn, botnet attack against, 94, 202 Edgehill program (UK), 168 Electronic Communications Privacy Act (1986), 153 Electronic Frontier Foundation, 32, 223 Who Has Your Back?

The IDA Pro Book
by Chris Eagle
Published 16 Jun 2011

Stack Frame Breakdown While stack-protection mechanisms are rapidly becoming standard features in modern operating systems, 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 interested in knowing exactly how many bytes you need to write into the buffer until you can control various variables within the function’s stack frame, including the function’s saved return address.

…

The fundamental problem is that there is no way to determine, at runtime, the size of any array. In this instance, strcpy has no means to determine whether the capacity of 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 from in the preceding example) a particular symbol: Example 15-4. Enumerating a function’s callers #include <idc.idc> static list_callers(bad_func) { auto func, addr, xref, source; func = LocByName(bad_func); if (func == BADADDR) { Warning("Sorry, %s not found in database", bad_func); } else { for (addr = RfirstB(func); addr !

…

In fact, given Microsoft’s well-known Patch Tuesday cycle of publishing updates, large numbers of security researchers prepare to sit down and do just that once every month. Considering that entire books exist on the topic,[187] there is no way that we can do justice to vulnerability analysis in a single chapter in a book 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 with IDA Vulnerability researchers take many different approaches to discovering new vulnerabilities in software. When source code is available, it may be possible to utilize any of a growing number of automated source code–auditing tools to highlight potential problem areas within a program.

Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon
by Kim Zetter
Published 11 Nov 2014

Bencsáth sent the dropper to the Symantec team, who determined that it was indeed exploiting a zero-day buffer-overflow vulnerability in the TrueType font-parsing engine for Windows. The font-parsing engine was responsible for rendering fonts on-screen. When font code for a character appeared in a Word document, the engine consulted the proper font file to determine how the character should look. But in this case when the engine tried to read the font code, a vulnerability in the parsing engine triggered the exploit instead. The exploit was quite “badass,” in the words of one researcher, because a normal exploit attacking a buffer-overflow vulnerability generally got hackers only user-level access to a machine, which meant they needed a second vulnerability and exploit to get them administrative-level privileges to install their malicious code undeterred.24 But this exploit cut through layers of protection to let them install and execute malicious code at the kernel level of the machine without interference.

…

The exploit was quite “badass,” in the words of one researcher, because a normal exploit attacking a buffer-overflow vulnerability generally got hackers only user-level access to a machine, which meant they needed a second vulnerability and exploit to get them administrative-level privileges to install their malicious code undeterred.24 But this exploit cut through layers of protection to let them install and execute malicious code at the kernel level of the machine without interference. Buffer-overflow vulnerabilities that could be exploited at the kernel level are rare and difficult to exploit without causing the machine to crash, but the Duqu exploit worked flawlessly. It was several orders of magnitude more sophisticated than the .LNK exploit Stuxnet had used. The .LNK exploit had been copied by cybercriminals in no time after Stuxnet was exposed in July 2010, but this one would take months before anyone would successfully replicate it.25 The exploit was notable in itself, but the attackers had also embedded a couple of Easter eggs in their code—perhaps to taunt victims.

…

Resource 207 contained the code that Stuxnet 2009 used to trick the Autorun feature in Windows machines to spread itself via USB flash drives. But it also contained this overlooked exploit that was now in the new attack code. The exploit gave the attackers escalated privileges on infected machines by exploiting a buffer-overflow vulnerability in the wallpaper feature of Windows. The vulnerability had been a zero day when the attackers created the exploit in February 2009, but by the time they released Stuxnet four months later that June, Microsoft had patched the hole.3 When it came time to release the next version of Stuxnet in March 2010, the attackers had eliminated this exploit, along with the Autorun code, and replaced it with the .LNK exploit and two other privilege-escalation exploits that were still zero days at the time.

Paper Machines: About Cards & Catalogs, 1548-1929
by Markus Krajewski and Peter Krapp
Published 18 Aug 2011

Z693.3.C37K7313 2011 025.3′109—dc22 2010053622 10 9 8 7 6 5 4 3 2 1 Contents 1 From Library Guides to the Bureaucratic Era: An Introduction 2 Temporary Indexing I Around 1800 3 9 25 The First Card Index? 27 Addressing Ideas 27 Data Streams 32 Copy Error: The Josephinian Card Index Floods 35 Canals 37 The Algorithm 38 Error: Buffer Overflow 42 Paper Flow: Taming, Duration 43 Revolution on Playing Cards 45 4 Thinking in Boxes 34 49 The Scholar’s Machine 50 Genealogy: Johann Jacob Moser and Jean Paul 53 Elsewhere 56 Banknotes 58 Balance Sheet 62 In Praise of the Cross-Reference 63 On the Gradual Manufacturing of Thoughts in Storage 5 American Arrival 69 Do Not Disturb—William Croswell 69 Early Fruits and Dissemination 78 65 1 vi Contents II Around 1900 85 6 Institutional Technology Transfer 87 Reformation: Dewey’s Three Blessings for America Transfer: Library Bureau 90 Library Supplies 90 Standardization 91 Corporate Genealogy 92 The Transfer 95 Product / System / Manufacturing 100 Digression: Foreign Laurels 102 Industry Strategy 104 7 8 Transatlantic Technology Transfer 107 Supplying Library Supplies 108 The Library Ge-stell 108 Punch Card 110 The Bridge Enters the Office: World Brain 113 Paper Slip Economy 87 123 System / Organization 125 Universal / Card / Machine 127 Invalidation 131 The War of the Cards: Copyrighting the “Card Index”™ Depiction / Decision 135 Summary: Order / Cleanup 139 Afterword to the English Edition Notes 145 References 181 Index 207 143 133 1 From Library Guides to the Bureaucratic Era: An Introduction We wanted to play bureaucratic music.

…

The performance of every scriptor is accounted for in a “list of the number of books described in summer 1780.”87 Adam Bartsch, author of the instructions, chalks up the biggest contribution according to this interim balance, with 4,637 works in 5,372 volumes. In the end, the Josephinian catalog represents the entire library on approximately 300,000 cards, including a distinctive reference system—successfully meeting the first partial goal of registering all titles. 42 Chapter 3 Error: Buffer Overflow The further cataloging plan anticipates using the standardized and sorted paper slips as a basis for bound alphabetical and subject catalogs. “From just these slips of paper, which are to be carefully stored, and to which one must apply the utmost care so that, being cut up, they are not scattered, one could, in time, generate a subject catalog without having to undertake the laborious work of a renewed description of the library’s books.”88 However, work on a bound catalog never begins.

Cybersecurity: What Everyone Needs to Know
by P. W. Singer and Allan Friedman
Published 3 Jan 2014

As we explore later in the Part II section on hactivists, the Anonymous group used this kind of attack to penetrate the security firm HB Gary and share its embarrassing secrets with the world. Beyond attacking applications, attackers can also exploit vulnerabilities in code at the system level. A common vulnerability is the buffer overflow. Computers use memory to store data and instructions. If a program can be tricked into writing inputted data that is larger than expected, it can spill over the allocated “buffer,” or storage area, and overwrite the space where the computer stores the next instruction to be executed. If that newly written memory space is then read and interpreted by the computer, the program can break or follow the attacker’s instructions.

…

During the initial stages of the crisis in Syria in 2011, supporters of the Syrian regime shared DDoS tools to attack critics of the government and news organizations that covered the growing violence. The bottom line is that vulnerabilities exist on every type of information system in cyberspace. Despite how scary they sound, many of them are not new. For instance, the common buffer overflow attack was first developed in the 1970s and almost brought down the adolescent Internet in the 1980s. By 1996, a detailed how-to guide appeared in a hacker’s magazine. As threats evolve, so too must our responses to them. Some can be mitigated with small changes in behavior or tweaks in code, while whole classes of vulnerabilities can be prevented only by developing and implementing new technologies.

…

tp=&arnumber=4591703&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2F.abs_all.jsp%3Farnumber%3D4591703. supporters of the Syrian regime OpenNet Initiative, “Syrian Electronic Army,” http://opennet.net/syrian-electronic-army-disruptive-attacks-and-hyped-targets, accessed April 2013. the adolescent Internet in the 1980s C. Cowan, P. Wagle, C. Pu, et al., “Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade,” in DARPA Information Survivability Conference and Exposition, 2000. DISCEX ’00. Proceedings, vol. 2, 2000, http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=821514. a detailed how-to guide Aleph One, “Smashing the Stack for Fun and Profit,” Phrack Magazine 7, issue 49 (August 11, 1996), http://www.phrack.org/issues.html?

The Tangled Web: A Guide to Securing Modern Web Applications
by Michal Zalewski
Published 26 Nov 2011

Common Problems Unique to Server-Side Code The following issues are commonly encountered in the server-hosted portion of any web application and, by virtue of being tied to specific programming languages or software components, are unlikely to occur on the client side. Buffer overflow A condition where a program allows more information to be stored in a particular memory region than there is space to accommodate the incoming data, leading to the unexpected overwrite of other vital data structures. Buffer overflows happen chiefly in low-level programming languages, such as C or C++, and in these languages, they can be frequently leveraged to execute attacker-supplied code. Command injection (SQL, shell, PHP, and so on) A problem where, due to insufficient input filtering or output escaping, attacker-controlled strings may be unintentionally processed as statements in an interpreted language used by the application.

…

See Safari (Apple), Type-Specific Content Inclusion, Content Rendering with Browser Plug-ins, Sun Java, Cross-Domain Content Inclusion application/binary, Detection for Non-HTTP Files application/javascript document type, Plaintext Files application/json document type, Plaintext Files, Unrecognized Content Type application/mathml+xml document type, Audio and Video application/octet-stream document type, Special Content-Type Values, Detection for Non-HTTP Files application/x-www-for-urlencoded, Forms and Form-Triggered Requests Arce, Ivan, Information Security in a Nutshell Arya, Abhishek, Character Set Inheritance and Override asynchronous XMLHttpRequest, Interactions with Browser Credentials Atom, RSS and Atom Feeds authentication, in HTTP, HTTP Cookie Semantics Authorization header (HTTP), HTTP Authentication authorization, vs. authentication, HTTP Cookie Semantics B background parameter for HTML tags, Type-Specific Content Inclusion background processes, in JavaScript, Content-Level Features \ (backslashes) in URLs, browser acceptance of, Fragment ID backslashes (\) in URLs, browser acceptance of, Fragment ID ` (backticks), as quote characters, Understanding HTML Parser Behavior, The Document Object Model backticks (`), as quote characters, Understanding HTML Parser Behavior, The Document Object Model Bad Request status error (400), 300-399: Redirection and Other Status Messages bandwidth, and XML, XML User Interface Language Barth, Adam, Nonconvergence of Visions, Frame Descendant Policy and Cross-Domain Communications, XDomainRequest, Other Uses of the Origin Header, Sandboxed Frames, URL- and Protocol-Level Proposals Base64 encoding, Header Character Set and Encoding Schemes basic credential-passing method, HTTP Authentication Bell-La Padula security model, Flirting with Formal Solutions, Flirting with Formal Solutions Berners-Lee, Tim, Tales of the Stone Age: 1945 to 1994, Tales of the Stone Age: 1945 to 1994, The First Browser Wars: 1995 to 1999, Hypertext Transfer Protocol, Hypertext Markup Language, Document Parsing Modes and semantic web, Document Parsing Modes World Wide Web browser, Tales of the Stone Age: 1945 to 1994 World Wide Web Consortium, The First Browser Wars: 1995 to 1999 binary HTTP, URL- and Protocol-Level Proposals bitmap images, browser recognition of, Plaintext Files blacklists, Same-Origin Policy for XMLHttpRequest, Same-Origin Policy for XMLHttpRequest, New and Upcoming Security Features malicious URLs, New and Upcoming Security Features of HTTP headers in XMLHttpRequest, Same-Origin Policy for XMLHttpRequest BMP file format, Type-Specific Content Inclusion BOM (byte order marks), Character Set Handling Breckman, John, Referer Header Behavior browser cache, Caching Behavior, Caching Behavior, Caching Behavior information in, Caching Behavior poisoning, Caching Behavior browser extensions and UI, Pseudo-URLs browser market share, May 2011, Global browser market share, May 2011 browser wars, The First Browser Wars: 1995 to 1999, A Glimpse of Things to Come browser-managed site permissions, Extrinsic Site Privileges browser-side scripts, Browser-Side Scripts buffer overflow, Common Problems Unique to Server-Side Code bugs, preventing classes of, Enlightenment Through Taxonomy Bush, Vannevar, Toward Practical Approaches byte order marks (BOM), Character Set Handling C cache manifests, URL- and Protocol-Level Proposals cache poisoning, Access to Internal Networks, Vulnerabilities Specific to Web Applications Cache-Control directive, Resolution of Duplicate or Conflicting Headers, Caching Behavior cache.

Nagios: System and Network Monitoring
by Wolfgang Barth
Published 25 May 2006

Granting the plugin root permissions There is a further restriction to the check_dhcp: it requires full access to the network interface and must therefore run with root privileges. It should, however, be executed—like all other plugins—by the user nagios. The program is accordingly transferred to the user root, and the SUID bit is set with chmod. Such s-bits are always a potential danger, since buffer overflows could be used to obtain general root privileges if code has been written carelessly. For this reason, the chmod command is chosen so that, apart from root, only the group nagios is given the permission to execute the plugin: linux:nagios/libexec # chown root.nagios check_dhcp linux:nagios/libexec # chmod 4750 check_dhcp linux:nagios/libexec # ls -l check_dhcp -rwsr-x--- 1 root nagios 115095 Jan 8 12:15 check_dhcp The chown command assigns the plugin to the user root and to the group nagios, to whom nobody else should belong apart from the user nagios itself.

…

Here is the example of a server on which the plugin check_disk (see Section 7.1 from page 134) is required to monitor nine file systems: command[check_disk_a]=path/to/check_disk -w 5% -c 2% -p /net/linux01/a command[check_disk_b]=path/to/check_disk -w 4% -c 2% -p /net/linux01/b command[check_disk_c]=path/to/check_disk -w 5% -c 2% -p /net/linux01/c command[check_disk_d]=path/to/check_disk -w 5% -c 2% -p /net/linux01/d command[check_disk_root]=path/to/check_disk -w 10% -c 5% -p / command[check_disk_usr]=path/to/check_disk -w 10% -c 5% -p /usr command[check_disk_var]=path/to/check_disk -w 10% -c 5% -p /var command[check_disk_home]=path/to/check_disk -w 10% -c 5% -p /home command[check_disk_tmp]=path/to/check_disk -w 10% -c 5% -p /tmp To avoid all this work, NRPE can also be configured so that parameters may be passed on to check_nrpe: 8 9 The check_users command is explained in Section 7.6 from page 144, check_load is explained in Section 7.3 from page 137, and Section 7.4 from page 138 deals with check_procs. . . . provided you have followed the instructions in the book. 171 10 The Nagios Remote Plugin Executor (NRPE) dont_blame_nrpe=1 ... command[check_disk]=path/to/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ In order for this to work, the NRPE configure script must be run with the option --enable-command-args. The reason for this inconvenient procedure is that passing parameters on is a fundamental risk, since it cannot be ruled out that a certain choice of parameters could cause an (as yet unknown) buffer overflow, allowing the target system to be penetrated. If you still decide on this, despite all the security risks, you should use a TCP wrapper (see Section 10.2.2, page 169), to ensure that only the Nagios server itself is allowed to send commands to NRPE. If the plugin provides the corresponding options, there is sometimes a third method, however: the above-mentioned problem can also be solved by getting check_disk, if necessary, to test all file systems with one single command: user@linux:nagios/libexec$ .

…

extTable.extEntry.extResult contains the return value of the command executed, and extTable.extEntry.extOutput contains the text output. With the exec directive you can thus query everything that a local script or program can find out. This could be a security problem, however: if the programs used are susceptible to buffer overflows, this feature could be misused as a starting point for a denial-of-service attack. Monitoring hard drive capacity The disk directive is suitable for monitoring file systems. The keyword disk is followed by the path for a mount point, and then the minimum hard drive space in kBytes or in percent that should be available.

Cyber War: The Next Threat to National Security and What to Do About It
by Richard A. Clarke and Robert Knake
Published 15 Dec 2010

You have no way of knowing, but now your new friend in Belarus is logging your every keystroke. What happens when you log into your bank account or to the Virtual Private Network of your employer, the Really Big Defense Company? You can probably guess. The most common software error for years, and one of the easiest to explain, is something called “buffer overflow.” Code for a webpage is supposed to be written in such a way that when a user comes to that webpage, the user can only enter a certain amount of data, like a user name and password. It’s supposed to be like Twitter, a program where you can enter, say, no more than 140 characters. But if the code writer forgets to put in the symbols that limit the number of characters, then a user can put in more.

…

A botnet usually has one or more controller computers, which are being directly employed by the operator behind the botnet to give orders to the secretly controlled devices. The computers on botnets are frequently referred to as “zombies.” Botnets are used, among other purposes, to conduct floods of messages (see DDOS). Buffer Overflow: A frequent error in computer code writing that allows for unauthorized user access to a network. The error is a failure to limit the number of characters that can be entered by a non-trusted user, thus allowing such a user to enter instructions to the software system. For example, a visitor to a webpage may go to a section of the page where he should only be able to enter his address and instead enters instructions that allow him to gain the same access as the network’s administrator.

Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect Attacks
by Michal Zalewski
Published 4 Apr 2005

Vulnerability to timing attacks is a property of the design of many components involved, whereas to implant a trojan requires either a software bug or an end-user error. Similarly, and with few exceptions, you won’t find the slightest mention in SotW of the widely exploited software bugs—or even generic software bug classes such as “buffer overflows.” If you are not already familiar with the common computer security threats and would like to gain that knowledge, you will need to accompany yourself on your journey through this book with the perusal of less exciting material available on the Internet and in other books, and in particular with material pertaining to the specific operating systems that you use.

…

The bots followed the links, each of the links simulating vulnerabilities. Although these exploits did not affect my server, they could easily compromise specific scripts or the entire web server on a remote system by causing the script to execute arbitrary commands, to write to arbitrary files, or, better yet, to suffer a buffer overflow problem: sjc-fe6-1.sjc.lycos.com: GET /cgi-bin/script.pl?p1=;attack HTTP/1.0 212.135.14.10: GET /cgi-bin/script.pl?p1=$(attack) HTTP/1.0 bigip1-snat.sv.av.com: GET /cgi-bin/script.pl?p1=../../../../attack HTTP/1.0 [...] Bots also happily connected to the non-HTTP ports I prepared for them and started a conversation by sending the data I supplied in URLs, thus making it possible to attack even services other than just web servers: GET /attack?

Engineering Security
by Peter Gutmann

If you’re not terribly interested in this sort of thing then you can skip ahead to “Problems” on page 4. Rather than including a long section that covers all of the things that the book contains, I’m going to talk about the things that it doesn’t contain. You’ll notice that there’s very little on secure coding practices, problems like buffer overflows, SQL injection, cross-site scripting, and similar issues. That’s because there are already, quite literally, shelves full of books that cover these areas, in some cases in great detail (books like The Art of Software Security Assessment, Secure Coding in C and C++, and Writing Secure Code range in size from six hundred to over eleven hundred pages long).

…

Projection bias has repeatedly hit security applications, which make the assumption that once the peer has authenticated (or otherwise apparently proven) themselves, their goals must match those of the user, programmer, or local system. In other words an entity like a remote SSH client would never dream of first authenticating itself and only then launching a buffer overflow or malformed-packet attack. As a result applications perform rigorous (or in the case of some SSH implementations at least half-hearted) data checking up until the authentication phase, but very little checking afterwards, making themselves trivially vulnerable to any data formatting attacks that follow.

…

A final problem caused by the lack of specific knowledge of the threats out there is an almost fatalistic acceptance of the view that the hacker will always get through 39 For US readers, that’s about 25 furlongs. Security and Rationality 171 [249][398][396]. Even here though, the threat model is unrealistic: hackers get in by breaking “128-bit encryption”, not by using a phishing attack or exploiting a buffer overflow in a web browser. Hand-in-hand with this is the belief that “I’m of no interest to hackers” (which also rates an honourable mention in the Six Dumbest Ideas in Computer Security [399]) since hackers would only target “interesting people” or “important computers”, and even if they did want to target arbitrary individuals the chances of getting hit are “astronomically remote in comparison to your chances of a burglary” [393].

Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
by Scott Rosenberg
Published 2 Jan 2006

And Lisa Dusseault, a leader in the world of open source calendar standards, would share managing the growing crew of programmers with Katie Parlante. The number of meetings at which Kapor’s presence was required grew, and his audible exhalations at those meetings grew louder and more frequent. He would make a “T” for “time-out” sign with his hands. “Sorry. I’m experiencing buffer overflow,” he would confess, and every geek in the room understood what he meant: There’s more coming at me than I can handle. He wasn’t the sort of boss to lose his temper; that set him apart from most other tech industry titans (Bill Gates’s tantrums are the stuff of legend, and so are Steve Jobs’s).

…

A missing hyphen in its guidance control program. In June 1996, the European Space Agency’s $500 million unmanned Ariane 5 rocket exploded forty seconds after liftoff because of a bug in the software that controlled its guidance system. (It tried to convert a 64-bit variable to a 16-bit variable, but the number was too high, a buffer overflowed, and the system froze.) From 1985 to 1987 a radiation therapy machine named the Therac-25 delivered massive X-ray overdoses to a half-dozen patients because of software flaws. During the 1991 Gulf War, a battery of American Patriot missiles failed to fire against incoming Scud missiles; the enemy missile hit a U.S. barracks, leaving twenty-eight dead.

Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice)
by Adam Goucher and Tim Riley
Published 13 Oct 2009

This testing also helps to account for differences between function implementations in various spreadsheet programs, some of which could lead to unexpected or empty arguments being passed to the underlying parser. Random Fuzzing In contrast to generic and customized fuzzing, random fuzzing works with unstructured or irregular input. One of the bugs I found while testing Gnumeric was a crash triggered by an overly long input line from a text file. Though it sounds like a buffer overflow, it was actually caused by the invocation of a message box that warned when Gnumeric was truncating data to fit the current worksheet. The problem is that the program was actually attempting to display the warning message while converting the file on the command line—where no GUI was present.

…

Since then, many equivalent tools were developed, all sharing similar concepts and even similar names. A tool that can be recommended nowadays is Splint. It’s name stands for Secure Programming Lint, because in addition to the traditional semantic checks, it can also detect security-related issues such as null pointer dereferences, memory management errors, buffer overflows, dangerous aliasing, possible infinite loops, and other suspicious statements. Splint is a very sensitive tool. It will not only report dozens of possible problems for a piece of good-looking code, but it also may sometimes have problems with parsing more complex files; therefore, it often makes sense to isolate and separately check the parts of code you want to review.

Python Web Penetration Testing Cookbook
by Cameron Buchanan , Terry Ip , Andrew Mabbitt , Benjamin May and Dave Mound
Published 28 Jun 2015

There's more… In this recipe, we've shown how to test a target web server for the XST vulnerability and test how it handles various HTTP methods. This script could be extended further by expanding the example HTTP method array to include various other valid and invalid data values; perhaps you could try sending Unicode data to test how the web server handles unexpected character sets or send a very long HTTP method and to test for buffer overflows in custom web servers. A good resource for this data is to check back to the fuzzing scripts in Chapter 3, Vulnerability Identification, for example, using payloads from Mozilla's FuzzDB. Fingerprinting servers through HTTP headers The next part of the HTTP protocol that we will be concentrating on are the HTTP headers.

Clean Agile: Back to Basics
by Robert C. Martin
Published 13 Oct 2019

How many people have been killed because the software in their cars failed to heed the pressure of the driver’s foot on the brake pedal? We don’t know for sure, but the answer is many. In one 2013 case Toyota paid millions in damages because the software contained “possible bit flips, task deaths that would disable the fail-safes, memory corruption, single-point failures, inadequate protections against stack overflow and buffer overflow, single-fault containment regions, [and] thousands of global variables” all within “spaghetti code.”1 1. Safety Research & Strategies Inc. 2013. Toyota unintended acceleration and the big bowl of “spaghetti” code [blog post]. November 7. Accessed at http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code.

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
Published 15 Oct 2018

First, it simply asked nicely—exploiting the trust that then existed on the nascent internet and attempting to run a “remote shell” on a new computer, a tool designed to allow users to execute commands across the network if they weren’t physically present. If the network administrator had locked down that function, the worm then tried a “buffer overflow” attack, overwhelming the login system with a 536-byte string of characters, the maximum-size entry the system could execute. That command caused the system to freeze up and, in its confusion, to effectively forget what it was supposed to do—and allow the worm to set up a remote shell. Last, if the first two efforts failed, the program tried to break the user password on the mail program.46 To Morris, the worm was just another chapter in his proclivity for annoying but harmless computer pranks.

…

See Gadahn, Adam BAE Systems, 122 Bagle virus, 119, 281 Bali nightclub bombing of 2002, 26 Baoerjin, Bill, 129 Baratov, Karim, 302, 303, 305 Barlow, John Perry, 72, 97, 98 BASIC (programming language), 74 BAW filters, 258 Baxter, Richard, 97 Beeson, Chris, 103, 120 Behavioral Analysis Unit, 328 Belan, Alexsey, 302–304, 306, 388 Bell Telephone Company, 85 Bemer, Bob, 41 Bezos, Jeff, 344 BG Group, 163 Biden, Joe, 23, 384 BIG BANG, 358 bin Laden, Osama, 2, 5, 6, 14, 154 Bitcoin, 59, 180, 292 Black Mirror (TV series), 35 Black September, 8 Black Vine, 350, 354, 356–360 BlackBerry, 2, 172 Blackshades, 270n Blair, Tony, 2, 3 blended terror attacks, 4, 56 Blinken, Tony, 366 blue boxes, 79 Blue Cross Blue Shield, 348 Boeing, 129, 146, 274, 276 Bogachev, Evgeniy Mikhailovich, “Slavik,” 285–298, 300, 301, 306, 3847, 388, 392 Bolten, Josh, 168 Bossert, Tom, 401 Boston Marathon bombing, 251, 254n botnets, 290, 390; in DDoS attacks, 225, 230, 392; dismantling, 298–299, 299n, 300; Estonia attacked by, 135; GameOver Zeus, 36, 290–301, 306, 324, 382, 387; Georgia attacked by, 158; intelligence capabilities, 297; IoT devices in, 394; Kelihos, 293–294, 299n; loss calculations and, 143n; Mirai, 391, 396; rental of, 117; spam and, 117; Zeus and, 285 Bowden, Mark, 159 Bowman dam, 229, 231 Brennan, John, 191, 241, 385 Breyer, Stephen, 66, 199, 270 Brin, Sergey, 181 Brinkema, Leonie M., 29 Brinser, Gordon, 263–264 Brobot, 230 Broderick, Matthew, 86, 90 Bron, Alexey, “thehead,” 288 Brunner, John, 82 Bryant, Bob, “Bear,” 100 Bryant, Robert, 198 bubble chart, 176, 325 BUCKSHOT YANKEE, 160 budget freezes, 202 buffer overflow attacks, 91 bug bounty programs, 394 bulk acoustic wave filters (BAW filters), 258. See also film bulk acoustic resonators bulletproof hosting, 115, 116 Bunnell, Stevan, 114 “Burning Chrome” (Gibson), 34 Bush, George H. W., 76, 136, 268 Bush, George W., 138, 155–156, 173, 188, 340–341 Business Club, 290–292, 295–297 Business Executives for National Security, 196 Butler, Max, “Iceman,” 122 C-17 transport plane, 272–274, 277 Cafe Milano, 211–214 Calce, Michael, “Mafiaboy,” 107–109 Call of Duty (video game), 14 “Call to Jihad” (al-Awlaki), 12 Callahan, Michael, 186 Campbell, John, “Soup,” 105 CarderPlanet, 114, 279, 281 carders, 114 CardersMarket, 122 carding scheme, 115 Carnegie Mellon, 80, 150 CAs.

Intrusion Detection With Snort, Apache, Mysql, Php, and Acid
by Rafeeq Ur Rehman
Published 7 May 2003

alert ip any any -> 192.168.1.0/24 any (content-list: \ "porn"; msg: "Porn word matched";) You can also use the negation sign ! with the file name if you want to generate an alert for a packet where no strings match. 3.6.7 The dsize Keyword The dsize keyword is used to find the length of the data part of a packet. Many attacks use buffer overflow vulnerabilities by sending large size packets. Using this keyword, you can find out if a packet contains data of a length larger than, smaller than, or equal to a certain number. The following rule generates an alert if the data size of an IP packet is larger than 6000 bytes. alert ip any any -> 192.168.1.0/24 any (dsize: > 6000; \ msg: "Large size IP packet detected";) 3.6.8 The flags Keyword The flags keyword is used to find out which flag bits are set inside the TCP header of a packet.

If Anyone Builds It, Everyone Dies: Why Superhuman AI Would Kill Us All
by Eliezer Yudkowsky and Nate Soares
Published 15 Sep 2025

The leftover 24 letters overflow the storage space that the programmer set aside for the user’s name and get written into parts of computer memory that the programmer assumed the user could never touch. Eight of those letters overwrite the piece of memory that tells the computer which piece of code to run next. Pick the right weird letters, and now the computer is running code it was never supposed to. This can often be parlayed into control of the whole computer system. “Buffer overflow attacks,” they’re called. An attack like that sends a computer system down a weird pathway of cause and effect, an “execution path” that isn’t like the system’s normal behavior and that no normal input would hit upon in a billion years. Very literally so; if a programmer tests 280-letter names at random then almost every possibility will be nonsense and cause the computer to innocently crash.

The Art of UNIX Programming
by Eric S. Raymond
Published 22 Sep 2003

A user-defined environment variable can be useful for situations in which, for whatever reason, it would be inconvenient to have to change an application dotfile or supply command-line options (perhaps it is expected that the application will normally be used inside a shell wrapper or within a makefile). A particularly important context for this sort of use is debugging. Under Linux, for example, manipulating the variable LD_LIBRARY_PATH associated with the ld(1) linking loader enables you to change where libraries are loaded from — perhaps to pick up versions that do buffer-overflow checking or profiling. In general, a user-defined environment variable can be an effective design choice when the value changes often enough to make editing a dotfile each time inconvenient, but not necessarily every time (so always setting the location with a command-line option would also be inconvenient).

…

* * * [123] Outside the Unix world, this three-orders-of-magnitude improvement in hardware performance has been masked to a significant extent by a corresponding drop in software performance. [124] The severity of this problem is attested to by the rich slang Unix programmers have developed for describing different varieties: ‘aliasing bug’, ‘arena corruption’, ‘memory leak’, ‘buffer overflow’, ‘stack smash’, ‘fandango on core’, ‘stale pointer’, ‘heap trashing’, and the rightly dreaded ‘secondary damage’. See the Jargon File for elucidation. Interpreted Languages and Mixed Strategies Languages that avoid manual memory management do it by having a memory manager built into their runtime executable somewhere.

Whiplash: How to Survive Our Faster Future
by Joi Ito and Jeff Howe
Published 6 Dec 2016

We have come a long way from Caesar’s cipher, but even today we rely on the dubious notion that the key, the secret that allows us to decrypt a message, can be kept secure and private—that we have the strength to protect our secrets. In contrast, the history of system security is relatively new. It wasn’t until 1988, when Robert Tappan Morris (son of the legendary cryptographer and National Security Agency director Robert Morris) used a buffer overflow to spread the first malware, that people understood that computers were indeed vulnerable to attacks. We have, thus, built a castle in the sand. More troubling yet is that instead of changing our strategy—instead of embracing the inevitable defeats and learning how to contain and limit the damage they cause—we just add more sand to the castle, falling prey again to the illusion of the wall so strong that nothing, not even our blinkered adherence to outdated presumptions, can defeat it In July 2014 Wall Street sent an ominous document to lawmakers in Washington.

Webbots, Spiders, and Screen Scrapers
by Michael Schrenk
Published 19 Aug 2009

For this reason, a proactive webbot designer verifies that the form handler hasn't changed since the webbot was written. * * * [19] Servers routinely restrict the length of a GET request to help protect the server from extremely long requests, which are commonly used by hackers attempting to compromise servers with buffer overflow exploits. Chapter 6. MANAGING LARGE AMOUNTS OF DATA You will soon find that your webbots are capable of collecting massive amounts of data. The amount of data a simple automated webbot or spider can collect, even if it runs only once a day for several months, is colossal. Since none of us have unlimited storage, managing the quality and volume of the data our programs collect and store becomes very important.

Toast
by Stross, Charles
Published 1 Jan 2002

The on-screen fractal was getting to me: the giggles kept rising until they threatened to break out. The whole situation was hilarious: here we were trapped in the basement of a police station owned by zombies working for a newborn AI, which was playing cheesy psychedelic videos to us in an attempt to perform a buffer-overflow attack on our limbic systems; the end of this world was a matter of hours away and— Eve said something that made me laugh. I came to an unknown time later, lying on the floor. My head hurt ferociously where I’d banged it on a table leg, and my rib cage ached as if I’d been kicked in the chest.

Rust Programming by Example
by Guillaume Gomez and Antoni Boucher
Published 11 Jan 2018

Brace yourselves, explanations are coming: if let Some(ref mut piece) = self.current_piece { It's simple pattern matching. If self.current_piece is Some, then we enter the condition and the value contained by Some that is bound into the piece variable: while shift_y < piece.states[piece.current_state as usize].len() && piece.y + shift_y < self.game_map.len() { This loop and its condition allow us to avoid a buffer overflow error by checking whether we're not outside of the game map limit for the current rotation (that is, self.current_state). The same goes for the inner loop (which iterates over the blocks of a line): while shift_x < piece.states[piece.current_state as usize][shift_y].len() && (piece.x + shift_x as isize) < self.game_map[piece.y + shift_y].len() as isize { It is in this loop that we write the blocks of the current tetrimino into the game map: if piece.states[piece.current_state as usize][shift_y][shift_x] !

Guide to LaTeX
by Helmut Kopka and Patrick W. Daly
Published 15 Feb 2008

If the whole text is not yet complete, one can try giving \clearpage for now in order to clear the blocked floats and then decide on a better ordering when the text is finalized. pool size Most likely there are too many command definitions and/or labels, or their names are too long. Try shortening the names. This error may also occur if a closing right brace } has been forgotten in the argument of a counter command such as \setcounter or in a \newenvironment or \newtheorem command. save size This buffer overflows when commands, environments, and the scope of declarations are nested too deeply. For example, if the argument of a \multiput command contains a picture environment, which in turn possesses a \footnotesize declaration with another \multiput command, and so on. Such a nesting must be simplified, unless the real problem is a forgotten closing brace } that merely makes the structure appear so complex. !

…

W., 605 abstract, 55 abstract environment, 55, 516 \abstractname, 460, 512 accents in tabbing environment, 83 in other languages, 24 mathematical, 129 Acrobat, 16, 236, 237, 242, 247, 249 Acrobat Distiller, 237, 239 \Acrobatmenu (hyperref), 247, 342 \acute, 129, 263, 512 \Acute (AMS), 263, 512 \addButton (pdfscreen), 342 \addcontentsline, 59, 60, 174, 427, 436, 512 \adddialect (babel), 255 \addlanguage (babel), 255 \address, 351, 352, 353, 356, 512 \addtime (slides), 327, 512 \addtoartlength (seminar), 332 \addtocontents, 59, 60, 174, 427, 436, 513 \addtocounter, 21, 110, 115, 182, 183, 418, 513 \addtolength, 184, 200, 453, 513 \addtoslidelength (seminar), 332 \addtoslidereset (seminar), 337 INDEX \addvspace, 185, 513 Adobe Systems Inc., 25, 231, 236, 249, 387, 504 \AE, 24, 513 \ae, 24, 513 Afrikaans, 252 afterpage package, 171, 394 \aleph, 127, 513 align environment (AMS), 270, 274, 516 align page style (seminar), 335 alignat environment (AMS), 270, 275, 516 aligned environment (AMS), 276, 516 \allinethickness (eepic), 306 \allowdisplaybreaks (AMS), 278, 513 alltt environment, 111, 392, 517 alltt package, 111, 392 allversions* environment (seminar), 336 \Alph, 73, 114, 183, 278, 513 \alph, 73, 114, 183, 191, 192, 513 alpha bibliography style, 311 \alpha, 125, 513 alphabetic page numbering, 45 \alsoname, 460, 513 \amalg, 126, 513 American Mathematical Society, 151, 257 American spelling, 195 amsart class, 258 amsbook class, 258 amsbsy package, 144, 192, 258–9 amscd package, 258, 263, 282 amsfndoc.tex, 257 amsfonts package, 126, 284–5, 422, 494 AMS-LATEX, 257–85 \Acute, 263, 512 align environment, 270, 274, 516 alignat environment, 270, 275, 516 aligned environment, 276, 516 \allowdisplaybreaks, 278, 513 609 arrows, extended, 262 \Bar, 263, 515 \binom, 264, 525 binomials, 264 Bmatrix environment, 266, 517 bmatrix environment, 266, 517 \boldsymbol, 144, 258, 526 \boxed, 142, 270, 526 \Breve, 263, 526 cases environment, 277, 517 CD environment, 282 \cfrac, 265, 527 \Check, 263, 528 CM fonts, 283 commutative diagrams, 282 Cyrillic fonts, 283, 497 \dbinom, 265, 531 \ddddot, 263, 532 \dddot, 263, 532 \Ddot, 263, 532 \DeclareMathOperator, 268, 282, 534 \dfrac, 264, 537 \displaybreak, 278, 538 \Dot, 263, 539 dots, 263 \dots, 263, 539 \dotsb, 264, 539 \dotsc, 264, 539 \dotsi, 264, 539 \dotsm, 264, 539 \eqref, 278, 541 equation* environment, 272 falign environment, 270, 275, 518 fonts, 283–5 fractions, 264 continued, 265 user-defined, 265 function names, 267 defining, 268 gather environment, 270, 273, 519 gathered environment, 276, 519 \genfrac, 265, 545 \Grave, 263, 546 610 INDEX \Hat, 263, 546 \hdotsfor, 267 \idotsint, 260, 548 \iiiint, 260, 551 \iiint, 260, 551 \iint, 260, 551 \intertext, 259, 550 \leftroot, 269, 554 limits multiline, 261 special, 261 \lVert, 270, 557 \lvert, 270, 557 math symbols, 285 \mathbb, 284 matrix, 266 matrix environment, 266, 519 \medspace, 269, 560 \mod, 268, 560 \mspace, 269, 560 multiline equations, 270–7 page breaks, 278 multiple integrals, 260 multline environment, 270, 271, 520 \multlinegap, 271, 561 \negmedspace, 269, 561 \negthickspace, 269, 561 \negthinspace, 269, 561 \notag, 271, 565 \numberwithin, 277, 565 options, 279 \overleftarrow, 262, 566 \overleftrightarrow, 262, 566 \overrightarrow, 262, 567 \overset, 262, 567 pmatrix environment, 266, 521 \pmb, 258, 570 \pod, 268, 570 \raisetag, 271 roots, 269 \rVert, 270, 576 \rvert, 270, 576 \shoveleft, 271 \shoveright, 271 \sideset, 262, 579 smallmatrix environment, 267 \smash, 269, 580 split environment, 270, 272, 276, 521 subarray environment, 261, 522 subequations environment, 277, 522 \substack, 261, 581 \tag, 271, 573, 583 \tbinom, 265, 583 \text, 259, 583 \tfrac, 264, 586 theorems, 280 \theoremstyle, 281 \thickspace, 269, 586 \thinspace, 269, 586 \Tilde, 263, 587 \underleftarrow, 262, 589 \underleftrightarrow, 262, 589 \underrightarrow, 262, 589 \underset, 262, 590 upright references, 282 \uproot, 269, 590 \varinjlim, 268, 591 \varliminf, 268, 591 \varlimsup, 268, 591 \varprojlim, 268, 591 \Vec, 263, 592 vertical bars, 270 Vmatrix environment, 266, 524 vmatrix environment, 266, 524 \xleftarrow, 263, 594 \xrightarrow, 263, 594 amsldoc.tex, 257, 282 amsmath package, 192, 258 amsopn package, 258, 267–8 amsproc class, 258 amssymb package, 284, 285 AMS-TEX, 257 amstex format, 257 amstext package, 258–9 amsthm package, 81, 258, 280–2, 395 \and, 53, 513 INDEX \angle, 127, 513 ANSI coding, 26, 462 apalike package, 220 appendix, 57 appendix environment, 516 \appendix, 57 \appendixname, 460, 513 Apple Macintosh coding, 26, 462 \approx, 126, 514 Arabic page numbering, 45 \arabic, 73, 75, 77, 78, 114, 183, 191, 277, 514 \arc (eepic), 306 \arccos, 128, 514 \arcsin, 128, 514 \arctan, 128, 514 \arg, 128, 514 argument, command, 18 array environment, 95, 107, 134, 146, 147, 149, 150, 266, 394, 417, 418, 425, 428, 429, 516 array package, 107, 394 \arraycolsep, 98, 149, 514 \arrayrulewidth, 98, 514 arrays, 133–6 \arraystretch, 98, 514 arrows, 127 extended (AMS), 262 Arseneau, Donald, 112, 224 article class, 37, 41, 55, 113, 131, 173, 191, 218, 225, 277, 391, 397, 454, 459, 471 article.cls, 397, 430 article.sty (LATEX 2.09), 430 \articlemag (seminar), 332 ascii, 5, 14, 17, 228, 231, 382, 487 \askforoverwritefalse (DocStrip), 465 \ast, 126, 514 \asymp, 126, 514 \AtBeginDocument, 444, 472, 514 \AtEndDocument, 444, 514 \AtEndOfClass, 444, 515 \AtEndOfPackage, 444, 515 \atop (TEX), 137, 146, 147, 189 attributes, font, 64–5, 368–72 defaults, 372 \author, 52, 53, 54, 69, 431, 515 611 .aux file, 209, 210, 214, 396, 397, 418, 427, 430, 436 auxiliary file, 214 avant package, 234 AvantGarde, PostScript font, 234, 504 axioms, 80 b5paper option, 38 \b ( accent), 24, 515 ¯ babel package, 252–6 babel.def (babel), 253 babel, multilingual LATEX, 216, 252–6, 385, 460 background package, 345–6 \backgroundcolor (pdfscreen), 342 \backmatter, 57, 210, 515 \backslash, 127, 132, 515 Bahasa, 252 bakoma fonts, 506 bakomaextra.map, 506 \bar, 129, 263, 515 \Bar (AMS), 263, 515 Barroca, Leonor, 159 baseline, 46, 63 \baselineskip, 63, 362, 369, 515 \baselinestretch, 46, 47, 63, 515 Basque, 252 \batchinput (DocStrip), 466 .bbl file, 219, 224, 310, 397 Beccari, Claudio, 605 \begin, 19, 64, 416–18, 516 \belowdisplayshortskip, 149, 524 \belowdisplayskip, 149, 524 Berry naming scheme, 504 Berry, Karl, 381, 504, 605 \beta, 125, 524 \bf (LATEX 2.09), 65, 367, 485 \bfdefault, 233, 372, 524 \bfseries, 19, 20, 64, 371, 416, 524 \bgadd (background), 346 \bgaddcenter (background), 346 \bgclear (background), 346 .bib file, 309, 397 \bibitem, 217, 219–21, 322, 395, 429–31, 524 bibliographic database, 219, 309–21 abbreviations, 320 612 INDEX creating, 311 cross-referencing, 316, 317 entry type, 311, 312, 314 field, 312 abbreviations, 319 ignored, 312 list of, 314, 316 names, 317, 318 optional, 312, 314 required, 312, 314 special formats, 317 titles, 318, 319 journal abbreviations, 322 structure, 311 template, 311, 320 bibliography, 216 abbrv, 311 abbrvnat, 221, 311 alpha, 311 author–year style, 220–4 BIBTEX, 217, 219, 224, 309–21 customizing, 223, 321–2 entry, 217 format, see style multiple, 224 numerical, 219 open style, 39 plain, 219, 310 plainnat, 219, 221, 311 reference in text, 219, 310 style, 219, 221, 310 unsrt, 310 unsrtnat, 221, 311 \bibliography, 210, 219, 224, 309, 310, 397, 524 \bibliographystyle, 219, 221, 224, 310, 397, 524 \bibname, 460, 525 BIBTEX, 15, 217, 219, 224, 309–21, 382, 388, 397, 430 writing styles for, 321 Biemesderfer, C., 605 \Big (TEX), 148, 525 \big (TEX), 148, 525 \bigcap, 128, 525 \bigcirc, 126, 525 \bigcup, 128, 525 \Bigg (TEX), 148, 525 \bigg (TEX), 148, 525 \bigodot, 128, 525 \bigoplus, 128, 525 \bigotimes, 128, 525 \bigskip, 33, 525 \bigskipamount, 525 \bigsqcup, 128, 525 \bigtriangledown, 126, 525 \bigtriangleup, 126, 525 \biguplus, 128, 525 \bigvee, 128, 525 \bigwedge, 128, 525 binary operator symbols, 125 \binom (AMS), 264, 525 binomial coefficient, 137, 264 blank, 11, 22 after command, 19, 22, 27, 186 at beginning of line, 22, 29 forced, 22 multiple, 11, 22 protected, 22, 29 rubber, 30 suppression of, 22 blank line for new paragraph, 22 .blg file, 397 Blue Sky Research, 382, 506 bm package, 144, 394 \bm, 144, 394 Bmatrix environment (AMS), 266, 517 bmatrix environment (AMS), 266, 517 \bmod, 129, 268, 526 body, 47 bold face in formulas, 143, 394 \boldmath, 143, 144, 150, 151, 373, 394, 433, 526 \boldsymbol (AMS), 144, 258, 526 book class, 37, 41, 55, 57, 113, 130, 173, 183, 187, 191, 218, 224, 225, 277, 391, 459 bookman package, 234 Bookman, PostScript font, 234, 504 \boolean (ifthen), 194, 195, 360, 451, 453 \bot, 127, 526 \botfigrule, 173, 526 bottom margin, 48 \bottombuttons (pdfscreen), 342 \bottomfraction, 172, 526 INDEX bottomnumber, 171, 526 Botway, L., 605 \bowtie, 126, 526 box, 85–94 calling, 87 framed, 86 lowering, 87 LR, 85, 87 nested, 92 paragraph, 85 parbox, 88 positioning horizontal, 86 vertical, 88, 89, 92 raising, 87 rule, 85, 91 saving, 87 style parameters, 93 TEX primitive, 85 vertical, 88 \Box, 126, 127, 526 boxed formula, 142, 270 \boxed (AMS), 142, 270, 526 bp (big point), 21, 155, 158 Braams, Johannes, 252, 464 \brace (TEX), 192 \brack (TEX), 192 bracket symbol, see symbols Breton, 252 \breve, 129, 263, 526 \Breve (AMS), 263, 526 British spelling, 195 bsr-interpolated.map, 506 bsr.map, 506 .bst file, 220, 221, 310, 321, 397 btxdoc.tex, 321 btxhak.tex, 321 Bulgarian, 252 \bullet, 126, 526 \c (¸ accent), 24, 526 calc package, 394 calligraphic letters, 125, 284 \cap, 126, 527 \caption, 60, 108, 169, 173, 174, 177, 178, 182, 213, 427, 436, 527 \captionslang (non-standard), 255, 460, 527 613 Carlisle, David, 154, 159, 193, 215, 330, 480 cases environment (AMS), 277, 517 Catalan, 252, 462 catalogue.html, 13 \cbinput (chapterbib), 224 cbunit environment (chapterbib), 224 \cc, 353, 527 cc (cicero), 21 \ccname, 353, 460, 527 CD environment (AMS), 282 \cdot, 126, 527 \cdots, 123, 134, 137, 263, 527 center environment, 67, 69, 79, 98, 176, 289, 516 centered text, 67 centering and indenting, 67–9 \centering, 67, 69, 79, 178, 458, 527 \centerline (TEX), 67, 176, 408, 527 \centerslidefalse (seminar), 334 \centerslidetrue (seminar), 334 centertags option, 272, 279 .cfg file, 253, 384, 385, 397, 472 \cfoot (fancyhdr), 44 \cfrac (AMS), 265, 527 \changes (doc), 470 chapter counter, 57, 181, 183 chapter opening page, 39 \chapter, 44, 55, 58, 449, 527 \chapter*, 55, 527 chapterbib package, 224 \chaptername, 460, 528 character spacing, see spacing character specification, 66 decimal, 66 hexadecimal, 66 octal, 66 \CharacterTable (doc), 471 \chead (fancyhdr), 44 \check, 129, 263, 528 \Check (AMS), 263, 528 \CheckCommand, 430, 445, 528 \CheckCommand*, 445 \CheckSum (doc), 471 chemical formulas, 143 Chen, Pehong, 228 614 INDEX \chi, 125, 528 chicago package, 220 Chinese, 6 \choose (TEX), 137, 146, 147, 189, 192 \circ, 126, 528 \circle, 416 \circle (eepic), 305 \circle (picture), 295, 299, 300, 431, 528 \circle* (eepic), 305 \circle* (picture), 295, 528 \cite, 219, 310, 312, 314, 395, 429, 430, 528 \citeauthor (natbib), 222 \citep (natbib), 219, 221, 310, 528 \Citet (natbib), 222 \citet (natbib), 219, 221, 310, 528 \citeyear (natbib), 222 \ClassError, 446, 528 classes.dtx, 463 \ClassInfo, 447, 529 \ClassWarning, 446, 529 \ClassWarningNoLine, 446, 529 Clausen, Joern, 25 \cleardoublepage, 34, 171, 420, 529 \clearpage, 34, 84, 171, 209, 420, 428, 529 forbidden, 84 \cline, 97, 102, 106, 529 .clo file, 384, 385, 397 \closing, 353, 529 .cls file, 384, 385, 398, 484 \clubsuit, 127, 529 cm (centimeter), 21 cm-super fonts, 506 \CodelineIndex (doc), 469 \CodelineNumbered (doc), 470 Codepages, IBM, 26, 462 color package, 153, 166, 324, 325, 335, 338, 345, 439 \color (color), 167, 335, 529 color.cfg, 166 \colorbox (color), 167, 335, 529 colors, 166–8 column breaking, 34 column separation two-column pages, 40 column separation symbol, 97, 139 \columnsep, 40, 51, 52, 395, 530 \columnseprule, 40, 52, 395, 530 \columnwidth, 51, 173 command *-form, 18 distinguishing from text, 11 followed by blank, 19, 186 invisible, 201 levels, 438 multi-character, 17 name, 17 single character, 17 syntax, 18 two-character, 17 command characters, printing of, 23 command, user-defined, 185–92 examples TEX as LATEX, 189 equation numbering, 190 footnotes, 190 framing text, 189 followed by blank, 186 for math and text, 186 general comments, 200 nested, 204 order of, 203 scope of, 202 global, 202 local, 202 storing, 200 unwanted spacing, 201 with arguments, 187, 188 calling, 188 with optional argument, 189 without arguments, 185, 187 calling, 186 comment, 118 character, 118 comment environment (verbatim), 111, 118, 396 commenting out, 118 compatibility mode, 392, 398, 418, 484 Comprehensive TEX Archive Network, see CTAN compressed graphics files, 166 INDEX Computer Modern fonts, 8, 64, 283, 369, 488–97, 499 PostScript version, 235, 505 conditional text, 193 config.cms, 235 config.ps, 233, 235 configuration file, local color, 166 graphics, 164 hyperref, 246 hyphen, 253, 385 LATEX installation, 384 ltxdoc, 397, 447, 472 pdfscreen, 343 seminar, 339, 340 configuring LATEX, 384 \cong, 126, 530 constant, see formula \contentsline, 530 \contentsname, 459, 530 continued fraction, 146, 149, 265 continuing dots, 123, 263 \coprod, 128, 530 copyright sign, 23, 503 \copyright, 23, 503, 530 \copyrightspace, 391 \cornersize (fancybox), 94 \cos, 128, 530 \cosh, 128, 530 \cot, 128, 530 \coth, 128, 530 counter value, 183 multiple printing, 183 printing, 183 counter, LATEX, see LATEX counter counter, user-defined, 182 auto. reset, 182 changing, 182 creation, 182 incrementing, 182 setting, 182 Courier, PostScript font, 234, 379, 504 Croatian, 252 cross-reference, 213–16 external document, 215 to bibliography, 219 to counters, 182, 213 615 to equations, 131, 139, 213, 278 to figures, 177, 213 to lists, 213 to pages, 213 to sections, 56, 213 to tables, 177, 213 to text, 213 to theorems, 213 variable, 215 \csc, 128, 530 CTAN, 381, 389 \cup, 126, 530 \CurrentOption, 359, 443, 530 cyracc.def, 284 Cyrillic fonts, 6, 283, 379, 497 transliteration, 284 Czech, 252 \d (. accent), 24, 531 \dag, 23, 531 dagger, 23 \dagger, 126, 531 Dahlgren, Mats, 178 Daly, Patrick W., 220, 321 Danish, 252 DANTE, German-speaking TEX Users, 251 dash, 23 as hyphen, 23 as minus sign, 23 \dashbox (picture), 291, 292, 300, 531 dashjoin environment (epic), 302, 304 \dashline (epic), 302, 303 \dashlinestretch (epic), 305 \dashv, 126, 127, 531 database, see bibliographic database \date, 52, 54, 69, 353, 358, 363, 531 \datelang (non-standard), 255, 461, 531 .dat file, 253 \day (TEX), 27, 460 \dbinom (AMS), 265, 531 \dblfigrule, 173, 531 \dblfloatpagefraction, 172, 531 \dblfloatsep, 172, 532 616 INDEX \dbltextfloatsep, 172, 532 \dbltopfraction, 172, 532 dbltopnumber, 172, 532 DC fonts, see EC fonts dcolumn package, 107, 394 dd (didôt), 21 \ddag, 23, 532 \ddagger, 126, 532 \ddddot (AMS), 263, 532 \dddot (AMS), 263, 532 \ddot, 129, 263, 532 \Ddot (AMS), 263, 532 \ddots, 123, 532 de Boer, Ingo H., 15 DEC Multinational coding, 462 declaration, 20 local, 20 scope of, 20 \DeclareBoldMathCommand (bm), 394 \DeclareErrorFont, 376, 423, 424, 532 \DeclareFixedFont, 66, 361, 373, 533 \DeclareFontEncoding, 376, 378, 379, 533 \DeclareFontEncodingDefaults, 376, 533 \DeclareFontFamily, 376, 378, 423, 533 \DeclareFontShape, 377, 378, 423, 533 \DeclareFontSubstitution, 376, 533 \DeclareGraphicsExtensions (graphics), 165, 533 \DeclareGraphicsRule (graphics), 165, 533 \DeclareInputMath (inputenc), 461 \DeclareInputText (inputenc), 461 \DeclareMathAccent, 375, 423, 534 \DeclareMathAlphabet, 191, 374, 375, 416, 423, 534 \DeclareMathDelimiter, 375, 534 \DeclareMathOperator (AMS), 268, 282, 534 \DeclareMathRadical, 375, 534 \DeclareMathSizes, 375, 534 \DeclareMathSymbol, 375, 534 \DeclareMathVersion, 374, 422, 423, 535 \DeclareOldFontCommand, 373, 535 \DeclareOption, 359, 421, 442, 535 \DeclareOption*, 359, 443, 535 \declarepostamble (DocStrip), 465 \declarepreamble (DocStrip), 465 \DeclareRobustCommand, 445, 535 \DeclareRobustCommand*, 445, 535 \DeclareSymbolFont, 374, 423, 424, 535 \DeclareSymbolFontAlphabet, 375, 424, 536 \DeclareTextAccent, 379, 536 \DeclareTextAccentDefault, 380, 536 \DeclareTextCommand, 379, 417, 536 \DeclareTextCommandDefault, 380, 536 \DeclareTextComposite, 379, 422, 536 \DeclareTextCompositeCommand, 379, 536 \DeclareTextFontCommand, 373, 536 \DeclareTextSymbol, 379, 536 \DeclareTextSymbolDefault, 380, 537 \def (TEX), 439, 445, 450 .def file, 153, 253, 376, 378, 379, 385, 392, 398 \definecolor (color), 167, 345, 537 \deg, 128, 537 dehyphn.tex, 256 dehypht.tex, 256 delarray package, 108, 394 \DeleteShortVerb (shortvrb), 111, 393, 468, 537 \Delta, 125, 537 \delta, 125, 537 \depth, 86, 90, 537 \DescribeEnvironment (doc), 468 \DescribeMacro (doc), 468 description environment, 69, 70, 74, 79, 230, 419, 420, 517 INDEX design size, 501 \det, 128, 129, 280, 537 determinant, 133–6 \dfrac (AMS), 264, 537 \DH, 503, 537 \dh, 503, 538 diacritical marks, see accents \Diamond, 126, 127, 538 \diamond, 126, 538 \diamondsuit, 127, 538 \dim, 128, 538 \DisableCrossrefs (doc), 470 \discretionary, 35, 538 \displaybreak (AMS), 278, 538 displayed formula, 119 displayed text centered, 67 indented, 67 left or right justified, 67 nested, 68 displaymath environment, 120, 517 \displaystyle, 142, 146, 150, 264, 538 \div, 126, 538 \DJ, 503, 538 \dj, 503, 538 doc package, 392, 399, 441, 467–73 doc.dtx, 468 DocBook DTD, 479 \DocInput, 467 DocStrip, 321, 398, 464–7 docstrip.dtx, 467 docstrip.tex, 385, 391, 465 document class, 37 options, 120 document environment, 12, 517 Document Type Definition, 479 document, major subdivisions, 52–7 documentation browser, 383 integrated, 463, 467 with doc, 467–73 documentation of packages, 13 \documentclass, 12, 37, 41, 398, 416, 422, 443, 538 \documentstyle (LATEX 2.09), 418, 422, 483 617 dollar sign, 23, 27 \DoNotIndex (doc), 470 \dot, 129, 263, 539 \Dot (AMS), 263, 539 \doteq, 126, 539 \dotfill, 30, 84, 86, 135, 539 \dots, 124, 539 \dots (AMS), 263, 539 \dotsb (AMS), 264, 539 \dotsc (AMS), 264, 539 \dotsi (AMS), 264, 539 \dotsm (AMS), 264, 539 dottedjoin environment (epic), 302, 304 \dottedline (epic), 302, 303 double dagger, 23 \doublebox (fancybox), 94, 539 \doublerulesep, 98, 539 \Downarrow, 127, 132, 539 \downarrow, 127, 132, 539 Downes, Michael, 257 draft option, 39 Drakos, Nikos, 476 drawjoin environment (epic), 302, 304 \drawline (epic), 161, 302, 303 \drawlinestretch (epic), 305 driver, printer, 15, 153, 389, 391, 398, 453, 488, 497 .drv file, 463, 464 DTD, 479 DocBook, 479 TEI, 479, 480 .dtx file, 13, 384, 389, 398, 463, 465 Duchier, Denys, 464 Dutch, 252 .dvi file, 14, 27, 153, 161, 236, 305, 393, 403, 477 dvipdf, graphics option, 154 dvipdfm, PDF driver, 162, 237, 305, 346, 387, 389 dvipdfm, graphics option, 154, 237 dvips, graphics option, 154 dvips, printer driver, 15, 162, 167, 168, 231, 236, 305, 332, 333, 335, 337, 387, 389, 476 dvipsone, graphics option, 154 dviwin, graphics option, 154 618 INDEX e.tex, 394, 413 EC fonts, 393, 499–503 calling, 501 character assignments, 500 special character commands, 503 with NFSS, 379 \edef (TEX), 450 eepic package, 305–6 eepicemu package, 305 Eijkhout, Victor, 450, 605 electron volt, symbol, 30, 192 electronic documents, 340, 475 electronic projection, 323 electronic publishing, 236 \ell, 127, 539 \ellipse (eepic), 306 ellipsis, 123 \else (TEX), 451 em dash, 23 \em, 20, 62, 65, 433, 485, 539 em, 21 emacs, 382 email addresses, 112 \emblema (pdfscreen), 341 \emph, 62, 65, 372, 540 empty page style, 42, 327, 335, 352, 452 \emptyset, 127, 540 emTEX for DOS, 382 emtex, graphics option, 154 en dash, 23 \EnableCrossrefs (doc), 470 encapsulated PostScript, see PostScript \encl, 353, 540 \enclname, 353, 460, 540 encoding, see font encoding commands in NFSS, 379 encoding scheme OML, 491, 495 OMS, 491, 495 OMX, 491, 496 OT1, 490, 492, 506 OT2, 283, 497 T1, 500, 501, 503, 506 TS1, 502, 506 encoding, font attribute, 368 \encodingdefault, 372, 501 end of line, as a blank, 22 \end, 19, 64, 416, 540 \endbatchfile (DocStrip), 465 \end{document}, 12, 517 \endfirsthead (longtable), 108, 540 \endfoot (longtable), 108, 540 \endhead (longtable), 108, 540 \endinput (TEX), 451 \endlastfoot (longtable), 108, 540 \endpostamble (DocStrip), 465 \endpreamble (DocStrip), 465 English, 252 english.ldf, 255 \enlargethispage, 34, 419, 540 \enlargethispage*, 34, 540 \ensuremath, 186, 187, 188, 418, 450, 541 enumerate environment, 69, 70, 71, 72, 74, 79, 213, 394, 419, 420, 517 enumerate package, 74, 394 enumn counter, 73, 181 environment, 19, 516 command name as, 20, 517 global, 20 math, 119 nameless, 20, 62, 63 environment environment (doc), 469 environment, user-defined, 195–200 general comments, 200 scope of, 202 global, 202 local, 202 storing, 200 with arguments, 198, 199 calling, 198 with optional argument, 199 without arguments, 196, 197 calling, 196 epic package, 302–5 .eps file, 155 epsf package, 159 \epsf (epsfig), 159 epsfig package, 159 \epsfig (epsfig), 159 \epsfxsize (epsfig), 159 INDEX \epsfysize (epsfig), 159 \epsilon, 125, 541 eqnarray environment, 120, 138, 142, 213, 270, 420, 517 eqnarray* environment, 120, 138, 142, 270, 518 \eqref (AMS), 278, 541 \equal (ifthen), 194, 363 equation, see formula equation counter, 181, 277 equation environment, 120, 124, 213, 271, 276, 518 equation number, 120, 271 changing hierarchy, 277 right or left, 39, 120, 131, 271 subnumbered, 277 user-defined, 191 vertically centered, 142, 272 equation* environment (AMS), 272 equations, set of, 133–6 \equiv, 126, 541 error messages basic structure for TEX, 403 continue program, 402 emergency stop, 413 error indicator, 402 error line, 402, 405 from LATEX, 404–7 from TEX, 401–4 from TEX macros, 407 going to deeper levels, 404 list hard-to-find errors, 435 LATEX font errors, 422–4 LATEX font warnings, 433 LATEX general errors, 415–20 LATEX general warnings, 429–31 LATEX package errors, 421–2 LATEX package warnings, 432 TEX, 424–9 TEX warnings, 433–5 mathematical, 413, 414 multi-file, 414 propagation, 409–10 stop program with I\stop, 403, 410 with editor, 403 619 with X, 403, 410 unknown file name, 412, 417 user response call editor, 403 continue program, 402 correction, 403 deletion, 403 help, 403 recommendation, 407 errorcontextlines counter, 404 eso-pic package, 346 Esperanto, 252, 462 Esser, Thomas, 381 Estonian, 252 \eta, 125, 541 eucal package, 284–5 eufrak package, 285 \EUR (europs), 25, 541 euro symbol, 24–5, 387, 462, 503 PostScript fonts, 25, 387 \euro (eurosym), 25, 28, 541 \EURofc (europs), 25, 541 eurofont.exe, 387 European Commission, 25 European paper sizes, 12 europs package, 25, 387 eurosans package, 25, 387 eurosym package, 25, 28 \evensidemargin, 48, 49, 361, 453, 541 ex, 21 \ExecuteOptions, 165, 443, 453, 541 executivepaper option, 38 exercises Chapter 2, 27, 28 Chapter 3, 40, 45, 47–9, 54, 57, 58, 60 Chapter 4, 68, 69, 72, 74, 78, 84, 93, 103, 105, 110, 111, 116, 118 Chapter 5, 121, 124, 129, 130, 132, 135–7, 141, 149, 150 Chapter 6, 157, 159, 168 Chapter 8, 183, 187, 192, 200 Chapter 9, 208, 212, 218, 219 Chapter 13, 290, 293, 295, 297, 301 \exists, 127, 541 620 INDEX \exp, 128, 541 \expandafter (TEX), 451 explicit names, changing, 459 exponents, 121 exscale package, 392 Extended Computer fonts, see EC fonts \externaldocument (xr), 215, 243 \extracolsep, 96, 110, 455, 541 \extrarowheight (array), 107 \extraslang (non-standard), 255 \extraslideheight (seminar), 336 \f@baselineskip, 376 \f@encoding, 376 \f@family, 376 \f@series, 376 \f@shape, 376 \f@size, 376 Fairbairns, Robin, 47 falign environment (AMS), 270, 275, 518 family, font attribute, 64, 368 \familydefault, 372 fancy page style, 43 fancybox package, 94–5, 334, 338, 345 \fancyfoot (fancyhdr), 44 fancyhdr package, 43–5, 249, 335, 454 \fancyhead (fancyhdr), 44 \fancyhf (fancyhdr), 44 \fancypage (fancybox), 95, 542 \fancypagestyle (fancyhdr), 45 \fancyput (fancybox), 338 \fbox, 86, 92–4, 115, 142, 334, 542 \fbox (picture), 298 \fboxrule, 93, 94, 164, 334, 542 \fboxsep, 93, 94, 164, 298, 334, 542 \fcolorbox (color), 167, 335, 542 .fdd file, 398 .fd file, 233, 234, 283, 376, 378, 385, 398, 424, 490 \fi (TEX), 451 figure, see float figure counter, 181 figure caption, see float, caption figure environment, 60, 108, 169, 173, 182, 213, 417, 419, 430, 518 figure* environment, 169, 518 \figurename, 459, 542 figures, list of, 59 file including, 448 inputting safely, 447 listing, 447 transcript, 14, 50, 208, 211, 399, 401, 447 file transfer protocol, see FTP file types .aux, 209, 210, 214, 396, 397, 418, 427, 430, 436 .bbl, 219, 224, 310, 397 .bib, 309, 397 .blg, 397 .bst, 220, 221, 310, 321, 397 .cfg, 253, 384, 385, 397, 472 .clo, 384, 385, 397 .cls, 384, 385, 398, 484 .dat, 253 .def, 153, 253, 376, 378, 379, 385, 392, 398 .drv, 463, 464 .dtx, 13, 384, 389, 398, 463, 465 .dvi, 14, 27, 153, 161, 236, 305, 393, 403, 477 .eps, 155 .fdd, 398 .fd, 233, 234, 283, 376, 378, 385, 398, 424, 490 .fmt, 398 .gif, 476 .glo, 230, 398, 470 .gls, 399, 470 .gz, 166 .html, 476 .idv, 478 .idx, 226–8, 399, 470 .ilg, 399 .ind, 228, 399 .ins, 389, 399, 463 .ist, 385, 399, 470 .jpeg, 162 .jpg, 162 .ldf, 253 .lof, 59, 179, 399, 436 INDEX .log, 14, 246, 399, 401, 403, 414, 429 .lot, 59, 399, 436 .map, 234 .mbs, 321, 322 .mf, 389, 400, 488, 498, 506 .pbm, 476 .pdf, 162, 237 .pfa, 389 .pfb, 234, 389, 506 .pk, 233, 234, 236, 388, 400, 488, 498, 504 .png, 162 .ppm, 478 .ps, 232, 236 .sty, 9, 12, 41, 384, 385, 463, 484 .tcx, 481 .tex, 14, 17, 208, 209, 391, 396, 400, 403, 436 .tfm, 234, 400, 487, 498, 503, 506 .tiff, 162 .tif, 162 .toc, 59, 400, 436 .txt, 384 .vf, 234, 236, 400, 488, 504 .zip, 166 \file (DocStrip), 465 filecontents environment, 432, 448, 518 filecontents* environment, 449, 518 \filedate (doc), 471 fileerr.dtx, 394 \fileinfo (doc), 471 \filename (doc), 471 \fileversion (doc), 471 \fill, 22, 30, 32, 96, 110, 184, 455, 542 filler, with dots, rules, spacing, 30 final option, 39 \Finale (doc), 469, 473 Finnish, 252 \firsthline (array), 107 firstpage page style, 362 fixed length, 21 flafter package, 171, 392 \flat, 127, 542 621 fleqn option, 39, 120, 124, 149, 271, 280 float, 110, 169–77 caption, 173 width, 174 causing buffer overflow, 428 double columns, 169 examples, 109, 174–7 figure title, 173 head and foot text, 109 numbering, 173 placement, 109, 169–71 style parameter, 171 table title, 173 float package, 179–80 floatfig package, see floatflt floatflt package, 178–9 floatingfigure environment, 178 floatingtable environment, 179 \floatname (float), 179 \floatpagefraction, 172, 542 \floatplacement (float), 180 \floatsep, 172, 542 \floatstyle (float), 180 \flushbottom, 48, 542 flushleft environment, 67, 79, 518 flushright environment, 67, 79, 518 \flushright, 117 Flynn, Peter, 605 .fmt file, 398 \fnsymbol, 114, 183, 190, 543 font slides class, 324 amsfonts, 283–5 attribute, 64–5, 368–72 defaults, 372 encoding, 368 family, 64, 368 internals, 376 series, 64, 368 shape, 64, 368 size, 64, 369 bitmaps, 488 character assignment cmcsc10 (small caps), 492 cmex10 (var. symbols), 496 cmmi10 (math text), 495 622 INDEX cmr10 (standard), 492 cmsy10 (math symbols), 495 cmti10 (text italic), 493 cmtt10 (typewriter), 493 EC fonts, 500 TC fonts, 502 wncyr10 (Cyrillic), 497 classification, 489 commands, 65, 370 Computer Modern, 8, 64, 283, 369, 488–97, 499 Cyrillic, 283, 379, 497 decorative, 494 design size, 501 EC, 393, 499–503 calling, 501 with NFSS, 379 encoding, 487 euro, PostScript, 25, 387 eurosym, 25 extended, 498–503 Extended Computer, see EC families, 489 file names, 490 LATEX, 65, 494 LATEX 2.09 commands, 485 line spacing for additional, 562 loading, 66 logos, 494 magnification, 66 math, 491 symbols, 374 math alphabets, 133, 258, 373 NFSS, 367–72, 376–9 pixel, 8 PostScript, 233–6, 378, 503–5 standard, 65, 367 standard line spacing, 63 TC, 24, 393, 501 text, 490 TrueType, 238 type 1, 8, 25, 231, 238, 387, 498, 503 type 3, 8, 234, 238 virtual, 488, 503 font definition files, 236, 376, 398 font environment, 64 font size, 62 changing, 62, 367 class option, 37 declarations, 63 in formulas, 146 standard line spacing, 63 font size commands (LATEX 2.09), 485 font style commands (LATEX 2.09), 485 fontenc package, 378–9, 392, 501 \fontencoding, 368, 370, 543 \fontfamily, 368, 369, 370, 543 fontmath.cfg, 385 fontmath.ltx, 385 \fontseries, 368, 369, 370, 543 \fontshape, 368, 369, 370, 372, 543 \fontsize, 368, 369, 370, 543 fontsmpl package, 394 fonttext.cfg, 385 fonttext.ltx, 385 foot, 42, 44, 47, 50, 85, 249, 335, 347, 362, 435, 453 customizing, 43, 454 \footheight (LATEX 2.09), 604 footnote, 112–16 change markers, 114 forbidden mode, 114 in minipages, 113, 115 in tables, 116 marker without text, 114 non-standard, 113 standard, 113 forbidden, 113 standard marker, 113 style parameter, 117 text external to forbidden mode, 114 footnote counter, 113, 181, 190 \footnote, 112, 113, 114, 116, 543 \footnotemark, 114, 115, 543 \footnoterule, 118, 543 \footnotesep, 117, 544 \footnotesize, 63, 371, 428, 544 \footnotetext, 110, 114, 115, 544 \footrulewidth (fancyhdr), 44 \footskip, 48, 50, 453, 544 \forall, 127, 544 \foreignlanguage (babel), 254, 544 format file, 6, 384, 398, 440 INDEX formula, 119 arrays, 133–6, 266 blanks within, 120 bold face in, 143, 258, 394 chemical, 143 constants, 120 continued fraction, 146, 149, 265 continuing dots, 123, 263 displayed, 119 centered, 39, 120, 280 flush left, 39, 120, 280 indented, 40 ellipsis, 123 exponent, 121 extra TEX commands, 137 fine-tuning, 145–8 bracket sizing, 148 font size, 146–7 horizontal spacing, 145, 269 font size in, 146 detailed, 147 simplified, 146 fraction, 122 framed, 142 function names, 128, 267 Greek letters, 125 horizontal spacing, 145, 269 in text, 119 index, 121 integral, 123 limits for 2 sizes, 128 multiline, 261 positioning, 123, 128 with functions, 129 lowering in, 121 math style parameters, 148 matrix, 133–6, 266 multiline, 120, 138–41 bracket sizing, 140, 148 breaking, 138 centered, 138 column separation, 138 left part, 140 numbered, 139 page breaks, 278 with AMS, 270–7 numbered, 120 623 overbrace, 136 overlining, 136 raising in, 121 root, 122, 269 side-by-side, 142 subnumbered, 277 summation, 123 symbols in, see symbols text within, 133, 259 underbrace, 136 underlining, 136 variables, 120 fpTEX for Windows, 381, 385 \frac, 122, 146, 189, 264, 544 fractions, 122 with AMS, 264 fragile commands, 440, 444 \frame, 299, 300, 544 \framebox, 86, 90, 93, 94, 106, 189, 272, 300, 544 \framebox (picture), 291, 292, 298, 544 framed formulas, see boxed formula framed table, 100 framed text, 86 French, 252 french package, 251 \frenchspacing, 29, 545 frhyphen.tex, 256 \from (DocStrip), 465 \fromname, 363 \frontmatter, 57, 210, 545 \frown, 126, 545 ftnright package, 394 FTP, 475 fullpage package, 452, 465 function names, 128 defining, 268 with AMS, 267 \fussy, 36, 545 Galician, 252, 462 \Gamma, 125, 545 \gamma, 125, 545 gather environment (AMS), 270, 273, 519 gathered environment (AMS), 276, 519 624 INDEX Gaulle, Bernard, 251 \gcd, 128, 129, 280, 545 \gdef (TEX), 450 \ge, 126, 545 \generate (DocStrip), 465 \genfrac (AMS), 265, 545 geometry package, 49–51, 452 \geq, 126, 545 German, 252 spelling reform, 35 german package, 251, 252, 360 \GetFileInfo (doc), 441, 471, 472 \gets, 127, 545 \gg, 126, 545 gglo.ist, 399, 470 Ghostscript, 236, 476 GhostView, 164, 232, 239 GIF images, 476, 478 .gif file, 476 gind.ist, 399, 470 Girou, Denis, 330 .glo file, 230, 398, 470 glossary, 230 \glossary, 230, 398, 420, 428, 545 \glossaryentry, 230, 398, 545 \glossaryname, 460 .gls file, 399, 470 Goossens, M., 605 graphics importing files, 154 rotation, 156 scaling, 156 graphics package, 153, 155–7 graphics.cfg, 164 \graphicspath (graphics), 165 graphicx package, 157–9 graphpap package, 301, 392 \graphpaper, 392 \graphpaper (graphpap), 301, 546 \grave, 129, 263, 546 \Grave (AMS), 263, 546 Greek, 252 Greek letters, 125 grfguide.tex, 154 \grid (epic), 302, 303 \guillemotleft, 503, 546 \guillemotright, 503, 546 \guilsinglleft, 503, 546 \guilsinglright, 503, 546 Guntermann, Klaus, 343 Gurari, Eitan M., 477 .gz file, 166 gzip program, 166 h.tex, 394, 413 \H (˝ accent), 24, 546 Haralambous, Y., 605 Hargreaves, K.

Coders at Work
by Peter Seibel
Published 22 Jun 2009

My definition of fragile code is, suppose you want to add a feature—good code, there's one place where you add that feature and it fits; fragile code, you've got to touch ten places. Seibel: So when there's a security breach that turns out to be due to a buffer overflow, what do you say to the criticism that C and C++ are partly responsible—that if people would use a language that checked array bounds or had garbage collection, they'd avoid a lot of these kinds of problems? Thompson: Bugs are bugs. You write code with bugs because you do. If it's a safe language in the sense of run-time-safe, the operating system crashes instead of doing a buffer overflow in a way that's exploitable. The ping of death was the IP stack in the operating system. It seems to me that there'd be more pings of death.

The Zenith Angle
by Bruce Sterling
Published 27 Apr 2004

It was rage. He could see that rage within himself as if watching it through a telescope. It was black and hard and dense, like a neutron star. He was someone who read manuals, wore glasses, and typed on a keyboard. About the most violent thing he ever did in his cyberwarrior life was to look for a buffer overflow. But rage was growing in him, because rage was a native part of his soul. Rage grew there in the entirely natural way that grief would grow in a widower. Van had nothing to say to her about this. He couldn’t any more wrap his tongue around that than he could lick broken glass. Dottie looked over his shoulder.

The Seventh Sense: Power, Fortune, and Survival in the Age of Networks
by Joshua Cooper Ramo
Published 16 May 2016

That prize: Sergey Bratus, Julian Bangert, Alexandar Gabrovsky, et al., “Composition Patterns of Hacking,” in Cyberpatterns 2012: Proceedings of the First International Workshop on Cyberpatterns; Unifying Design Patterns with Security, Attack and Forensic Patterns, athttp://tech.brookes.ac.uk/CyberPatterns2012/Cyberpatterns2012Proceedings.pdf. Even the best programmers: For a good explanation of how a machine’s code can be turned against itself, see Sergey Bratus, Michael E. Locasto, Meredith L. Patterson, et al., “Exploit Programming: From Buffer Overflows to ‘Weird Machines’ and Theory of Computation,” ;login: 36, no. 6 (December 2011): 13–21. The piece was published in memory of Len Sassman, one of the leading thinkers of the Language Security, or LangSec, movement, who died in 2011. Many of his talks, still available online, reflect an unusually powerful mix of philosophical and technical considerations about modern computing systems.

The Launch Pad: Inside Y Combinator, Silicon Valley's Most Exclusive School for Startups
by Randall Stross
Published 4 Sep 2013

When PG and Morris started Viaweb, Morris was so averse to publicity after the worm that he insisted that a pseudonym be used for his biography on the company Web site: he was “John McArtyem,” whose real identity was easily seen in the “rtm” in the “rtm@viaweb.com” e-mail address that was displayed. http://ycombinator.com/viaweb/com.html. Many years later, Morris softened a little bit, allowing PG to refer elliptically to the worm incident in the biography provided for Morris on YC’s Web site: “In 1988 his discovery of buffer overflow first brought the Internet to the attention of the general public.” YC Web site, http://ycombinator.com/people.html. 9. PG, “How Y Combinator Started,” YC Web site, March 15, 2012, http://ycombinator.com/start.html. 10. PG, “How to Start a Startup,” March 2005, http://paulgraham.com/start.html.

Joel on Software
by Joel Spolsky
Published 1 Aug 2004

Because otherwise, you see, a clever hacker will read my code and notice that I'm only allocating 1000 bytes and hoping it will be enough, and they'll find some clever way to trick me into strcatting an 1100-byte string into my 1000 bytes of memory, thus overwriting the stack frame and changing the return address so that when this function returns, it executes some code that the hacker himself wrote. This is what they're talking about when they say that a particular program has a buffer overflow susceptibility. It was the number one cause of hacks and worms in the olden days before Microsoft Outlook made hacking easy enough for teenagers to do. OK, so all those programmers are just lame-asses. They should have figured out how much memory to allocate. But really, C does not make this easy on you.

Building Microservices
by Sam Newman
Published 25 Dec 2014

This really is basic stuff, but it is surprising how often I see critical software running on unpatched, old operating systems. You can have the most well-defined and protected application-level security in the world, but if you have an old version of a web server running on your machine as root that has an unpatched buffer overflow vulnerability, then your system could still be extremely vulnerable. Another thing to look at if you are using Linux is the emergence of security modules for the operating system itself. AppArmour, for example, allows you to define how your application is expected to behave, with the kernel keeping an eye on it.

With a Little Help
by Cory Efram Doctorow , Jonathan Coulton and Russell Galen
Published 7 Dec 2010

Been wire-tapping him ever since." 2917 I nodded. "Smart." 2918 "Second thing I did was start to do some hardcore analysis of that patchkit he wrote --" I held my hand up automatically to preserve the fiction that I'd written it, but she just glared at me. "That he wrote. And I discovered that there's a subtle error in it, a buffer overflow in the networking module that allows for arbitrary code execution." 2919 I swallowed. BIGMAC had loaded a backdoor into his patchkit, and we'd installed it on the better part of 14 billion CPUs. 2920 "Has anyone exploited this bug yet?" 2921 She gave me a condescending look. 2922 "How many systems has he compromised?"

Docker: Up & Running: Shipping Reliable Containers in Production
by Sean P. Kane and Karl Matthias
Published 15 Mar 2018

Most scheduler systems run their own software on each node and expect to talk to Docker over the Unix domain socket. If you do need to expose the daemon to the network, you can do a few things to tighten Docker down in a way that makes sense in most production environments. But no matter what you do, you are relying on the Docker daemon itself to be resil‐ ient against threats like buffer overflows and race conditions, two of the more com‐ mon classes of security vulnerabilities. This is true of any network service. The risk is perhaps a little higher from Docker because it has the ability to control most of your applications, and because of the privileges the daemon requires, it has to be run as root.

Programming in Lua, Fourth Edition
by Roberto Ierusalimschy
Published 14 Jul 2016

String Manipulation When a C function receives a string argument from Lua, there are only two rules that it must observe: not to pop the string from the stack while using it and never to modify the string. Things get more demanding when a C function needs to create a string to return to Lua. Now, it is up to the C code to take care of buffer allocation/deallocation, buffer overflows, and other tasks that are difficult in C. So, the Lua API provides some functions to help with these tasks. The standard API provides support for two of the most basic string operations: substring extraction and string concatenation. To extract a substring, remember that the basic operation lua_pushlstring gets the string length as an extra argument.

This Machine Kills Secrets: Julian Assange, the Cypherpunks, and Their Fight to Empower Whistleblowers
by Andy Greenberg
Published 12 Sep 2012

The group didn’t use its skills for evil or illegality. But nor did they hide their uncanny ability to demolish common programs’ security. At first, companies tried not to acknowledge them. Soon, they had no choice. In 1997, for instance, the L0pht members found a vulnerability known as a buffer overflow in Internet Explorer. Exploiting that flaw meant that any user tricked into clicking on a booby-trapped link could have his or her computer immediately hijacked. As Dildog wrote in the advisory L0pht published, “Click on the link. Become aware of what happens to your machine. Freak out and beg Microsoft to make the bad man stop.”

Docker: Up & Running: Shipping Reliable Containers in Production
by Sean Kane and Karl Matthias
Published 14 May 2023

Most scheduler systems run their services on each node and expect to talk to Docker over the Unix domain socket instead of over a network port. If you do need to expose the daemon to the network, you can do a few things to tighten Docker down in a way that makes sense in most production environments. But no matter what you do, you are relying on the Docker daemon itself to be resilient against threats like buffer overflows and race conditions, two of the more common classes of security vulnerabilities. This is true of any network service. The risk is a lot higher with the Docker daemon because it is normally run as root, it can run anything on your system, and it has no integrated role-based access controls. The basics of locking Docker down are common with many other network daemons: encrypt your traffic and authenticate users.

Code Complete (Developer Best Practices)
by Steve McConnell
Published 8 Jun 2004

If a string is intended to represent a restricted range of values (such as a financial transaction ID or something similar), be sure that the string is valid for its intended purpose; otherwise reject it. If you're working on a secure application, be especially leery of data that might attack your system: attempted buffer overflows, injected SQL commands, injected HTML or XML code, integer overflows, data passed to system calls, and so on. Check the values of all routine input parameters. Checking the values of routine input parameters is essentially the same as checking data that comes from an external source, except that the data comes from another routine instead of from an external interface.

…

Are all exceptions at the appropriate levels of abstraction for the routines that throw them? Does each exception include all relevant exception background information? Is the code free of empty catch blocks? (Or if an empty catch block truly is appropriate, is it documented?) Security Issues Does the code that checks for bad input data check for attempted buffer overflows, SQL injection, HTML injection, integer overflows, and other malicious inputs? Are all error-return codes checked? Are all exceptions caught? Do error messages avoid providing information that would help an attacker break into the system? Additional Resources cc2e.com/0875 Take a look at the following defensive-programming resources: Security Howard, Michael, and David LeBlanc.

ZeroMQ
by Pieter Hintjens
Published 12 Mar 2013

Do we formally split components into “clients” and “servers” and mandate that servers cannot disappear? What, then, if we want to connect servers to servers? Do we try to reconnect every few seconds? How do we represent a message on the wire? How do we frame data so it’s easy to write and read, safe from buffer overflows, and efficient for small messages, yet adequate for the very largest videos of dancing cats wearing party hats? How do we handle messages that we can’t deliver immediately? Particularly if we’re waiting for a component to come back online? Do we discard messages, put them into a database, or put them into a memory queue?

I'm Feeling Lucky: The Confessions of Google Employee Number 59
by Douglas Edwards
Published 11 Jul 2011

Marissa set the agenda, determining which products to discuss and who should be at the meeting to present the case for or against proposed changes. Marissa was twenty-four. A slim, blond Wisconsinite, she was well versed in UI issues and she never met a problem she didn't try to fix—immediately. Her mind worked so quickly that her buffer overflowed, filling all available conversational space with a flurry of words. She would download what she was thinking, punctuate it with an ellipsis laugh, and then preemptively address all objections or alternative viewpoints that could conceivably be expressed. It took me a while to get used to, even though I had dwelt among New Yorkers.

The Debian Administrator's Handbook, Debian Wheezy From Discovery to Mastery
by Raphaal Hertzog and Roland Mas
Published 24 Dec 2013

Knowing What To Expect A vulnerability in a web application is often used as a starting point for cracking attempts. What follows is a short review of possible consequences. QUICK LOOK Filtering HTTP queries Apache 2 includes modules allowing filtering incoming HTTP queries. This allows blocking some attack vectors. For instance, limiting the length of parameters can prevent buffer overflows. More generally, one can validate parameters before they are even passed to the web application and restrict access along many criteria. This can even be combined with dynamic firewall updates, so that a client infringing one of the rules is banned from accessing the web server for a given period of time.

Peer-to-Peer
by Andy Oram
Published 26 Feb 2001

The history of cryptography provides a cautionary tale here. System designers have realized the limits of theoretical cryptography for providing practical security. Cryptography is not pixie dust to spread liberally and without regard over network protocols, hoping to magically achieve protection from adversaries. Buffer overflow attacks and unsalted dictionary passwords are only two examples of easy exploits. A system is only as secure as its weakest link. The same assertion holds for decentralized peer-to-peer systems. A range of techniques exists for solving accountability and resource allocation problems. Particularly powerful are reputation and micropayment techniques, which allow a system to collect and leverage local information about its users.

Smart Grid Standards
by Takuro Sato
Published 17 Nov 2015

The storage of reporting The general queue of entries for a report handler are shown in Figure 3.26. Table 3.2 The format of reporting Attribute name BRCB Opt Flds Rpt ID — Opt Flds — Sq Num sequence-number (BOOLEAN) = TRUE Sub Sq Num More Segments Follow Dat Set data-set-name = TRUE Buf Ovfl buffer-overflow = TRUE Conf Rev conf-revision = TRUE Entry Time Of Entry report-time-stamp = TRUE Entry ID entry ID = TRUE Entry Data [1..n] Data Ref data-reference = TRUE Value — Reason Code reason-for-inclusion Power Grid 119 Logical Node (LLN0) Client Buffered-report-control-block (1) BRCBRef RptEna DatSet GI BufTm TrgOps intgPd RptID OptFlds BRCName RptEna RptID OptFlds stVal changed and it produces internal notification sequence-number report-time-stamp reason-for-inclusion data-set-name data-reference Data Set MyLD/LLN0.TestRpt -MyLD/XCBR1.Pos.stVal -MyLD/XCBR1.Pos.q -MyLD/XCBR1.Pos.t -MyLD/XCBR1.Pos.origin -MyLD/XCBR1.Pos.ctlNum -MyLD/XCBR1.Pos.stSeld -MyLD/XCBR1.BlkOpn.stVal -MyLD/XCBR1.BlkOpn.q -MyLD/XCBR1.BlkOpn.t DatSet GI BufTm TrgOps SetRCBValue data-change quality-change data-update Integrity general-interrogation IntgPd (2) “MyReport” Squence4 Figure 3.25 12:00:00 data-change MyLD/XCBR1.Pos.stVal Procedures for report generation Value of stVal “TestRpt” Smart Grid Standards 120 Previously formatted and transmitted 36 23 90 13 Oldest Entry Not formatted or transmitted 2 1 EntryID 12 31 14 Newest Entry Based upon last set of Next Entry for notifications received formatting and transmission Figure 3.26 General queue of entries for report handler 3.6.2.2 Service Tracking for Control-Block-Related Services This clause introduces a general model for control block, as used later on for service definitions of control-block-based services.

Character Limit: How Elon Musk Destroyed Twitter
by Kate Conger and Ryan Mac
Published 17 Sep 2024

Saturn would have to wait—again. 23 > Mudge Hired by Dorsey in November 2020 to become its head of security, Peiter Zatko was better known by his hacker moniker, Mudge, and had earned renown in the tight-knit security community in the 1990s for research into a type of security vulnerability known as a buffer overflow. While many hackers shared Dorsey’s anarchistic skepticism of the government, Zatko realized that he could advocate for broader security reforms by working with the feds than by peppering them with attacks from the shadows. He took a job at the Defense Department’s research wing, DARPA, and worked with Bill Clinton’s administration to mitigate cyberattacks.

Seeking SRE: Conversations About Running Production Systems at Scale
by David N. Blank-Edelman
Published 16 Sep 2018

To compensate, many load balancers ship with a C-based plug-in system that allows developers to augment existing functionality through modules. These plug-in systems address many concerns, but they come with substantial, unnecessary downsides when compared to using an embedded scripting language. Without built-in memory safety, C is prone to memory faults (e.g., buffer overflow and segmentation faults), making it inherently unsafe. In contrast, a scripting language, such as Lua, can be sandboxed with strict runtime and memory guarantees. When writing a C module, developers can’t ignore lower-level details that aren’t immediately relevant to the logic at hand, a problem scripting languages don’t have.

The C++ Programming Language
by Bjarne Stroustrup
Published 2 Jan 1986

The output operations that a programmer can add are not members, so they cannot be vviirrttuuaall either. One reason for this is to achieve close to optimal performance for simple operations such as putting a character into a buffer. This is 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 exact type isn’t known, correct output cannot be achieved simply by defining a << for each new type. Instead, a virtual output function can be provided in the abstract base: The C++ Programming Language, Third Edition by Bjarne Stroustrup.

UNIX® Network Programming, Volume 1: The Sockets Networking API, 3rd Edition
by W. Richard Stevens, Bill Fenner, Andrew M. Rudoff
Published 8 Jun 2013

Section 11.8 freeaddrinfo Function 321 #include <netdb.h> const char *gai_strerror(int error); Returns: pointer to string describing error message Constant Description EAI_AGAIN EAI_BADFLAGS EAI_FAIL EAI_FAMILY EAI_MEMORY EAI_NONAME EAI_OVERFLOW EAI_SERVICE EAI_SOCKTYPE EAI_SYSTEM Temporary failure in name resolution Invalid value 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 getaddrinfo. 11.8 freeaddrinfo Function All the storage returned by getaddrinfo, the addrinfo structures, the ai_addr structures, and the ai_canonname string are obtained dynamically (e.g., from malloc).

Reamde
by Neal Stephenson
Published 19 Sep 2011

Most T’Rain players used it. The add-on worked by sending messages back and forth, consisting of invitations to participate in group raids and the like. Most of these were pure text, but it was possible to attach images and other files to such invitations, and therein lay the security hole: REAMDE took advantage of a buffer overflow bug in Outlook to inject malicious code into the host operating system and establish root-level control of the computer, whereupon it could do anything it wanted, including encrypting the contents of all connected drives. First, though, it sent the virus onward to everyone in the victim’s T’Rain contact list.