A Bug Hunter's Diary: A Guided Tour. Through the Wilds of Software Security. Author: Tobias Klein. Label: No Starch Press. Release Date: Number Of Pages. A Bug Hunter's Diary: A Guided Tour Through the Wilds of Software Security kindle pdf book macbook mobile. A Bug Hunter's Diary: A Guided Tour Through the. Code Issues 2 Pull requests 2 Projects 0 Pulse · Resources/soundofheaven.info soundofheaven.info Loading latest commit This file is too big to show.
|Language:||English, Spanish, Japanese|
|Genre:||Academic & Education|
|ePub File Size:||25.52 MB|
|PDF File Size:||9.18 MB|
|Distribution:||Free* [*Regsitration Required]|
Certain pages from this book are designed for use in a group setting and. Chapter 1. Creativity and Problem Solving. How English Works (A Grammar. English] A bug hunter's diary: a guided tour through the wilds of software , soundofheaven.info ; iDefense Labs Vulnerability. A Bug Hunter's Diary follows security expert Tobias Klein as he tracks down and Print Book and FREE Ebook, $ Ebook (PDF, Mobi, and ePub), $
Next, I study the different ways that the input data can travel through the software, while looking for any potentially exploitable code that acts on the data. The exploitation process, illustrated in Figure , was as follows: Addison-Wesley Professional, HTTP request sent, awaiting response This is the preferred way to compile vlc if you want to do it on Windows.
Finally, I had all information I needed to start auditing the method for security bugs. User-controlled argument of NewObject after defining a new breakpoint Step 5: Reverse Engineer the Object Methods To recap, I found an obvious vulnerability that happens while the ActiveX control processes the user-supplied string value that gets passed to NewObject.
Figure illustrates the code path to reach the vulnerable function. As I said before, the user- controlled wide-character data is stored in this new buffer as a char- acter string with a maximum length of bytes. Listing shows that the sprintf function at address. As shown in Figure , the stack buffer SubKey has a fixed size of bytes. If the information from the disassembly shown in Listing is combined with the information on the stack layout of the vulnerable function, the call to sprintf can be expressed with the C code in Listing If cbData is filled with the maximum amount of user-controlled data bytes , a total of bytes of data will be copied into the stack buffer.
Diagram of the stack buffer overflow that occurs when an overly long string is passed to NewObject 5. All I had to do was tweak the length of the string argument supplied to NewObject to overflow the stack buffer and gain control of the return address of the current stack frame.
So I had to provide bytes of dummy data to fill the stack and reach the saved return address. The follow- ing 4 bytes of the user-controlled data should then overwrite the value of the saved return address on the stack. The original wwwserv. The bug could be easily exploited for arbitrary code execution using the well-known heap spraying technique. But hey, fuzzing is not as cool as reading assembly, right? I chose another disclosure process for this bug. I contacted iDefense on April 8, It accepted my submission and informed Cisco of the issue.
While Cisco was working on a new version of the ActiveX control, another security researcher named Ela- zar Broad rediscovered the bug in June He also informed Cisco but then disclosed the bug publicly in the process known as full disclo- sure. All in all it was a great mess, but in the end Elazar and I made the Web a safer place. Figure shows the timeline of the vulnerability fix. Timeline from discovery of the WebEx Meeting Manager vulnerability until the release of the security advisory Notes 1.
For more information on cross-site scripting, refer to https: My security advisory that describes the details of the WebEx Meeting Manager vulnerability can be found at http: Prepare a VMware guest for kernel ppor ted by avast! Pr debugging. Generate a list of the drivers and hout this chapter was device objects created by avast!
Check the device security settings. After downloading and installing the latest version of avast! Profes- sional6 in the VMware guest system, I used DriverView7 to generate a list of the drivers that avast! One of the benefits of DriverView is that it makes identification of third-party drivers easy.
As illustrated in Figure 6 -1, avast! I chose the first one on the list, called Aavmker4. A list of the avast!
The illustrated assembly snippet of DriverEntry can be translated into the following C code: Navigating to the security settings of the AavmKer4 device in WinObj To view the security settings of the device in WinObj, I right- clicked the device name, chose Properties from the option list, and then chose the Security tab.
The device object allows every system user Everyone group to read from or to write to the device see Fig- ure 6 This means that every user of the system is allowed to send data to the IOCTLs implemented by the driver, which is great—this makes this driver a valuable target!
After looking at the ntddk. So the assignment can be expressed as the following: Then at address. Assignment in C: Symbol file could not be found. Defaulted to export symbols for Aavmker4.
Then a value, located at offset 0x60 of the IRP structure, is referenced see. This structure is defined in ntddk. Step 5: The way the system describes these buffers depends on the data transfer type. Below is an example of a reference to the input buffer in the dis- assembly of Aavmker4. At address. Step 6: The length of the input data at address.
If so, the parsing of the input data continues: ECX gets assigned the value 0x21a see. The anatomy of the bug, diagrammed in Figure , is as follows: If so, proceed to step 3.
If so, proceed to step 4. The erroneous memcpy call is executed. The memory is corrupted. To gain control over EIP, all I had to do was overwrite this function pointer and then wait for it to be called. I wrote the following POC code to manipulate the function pointer: Unable to open device. The POC code that I wrote to manipulate the function pointer at. Then, in line 72, the address of the function pointer is calculated; this is overwritten by the manipulated memcpy call.
This buffer holds the IOCTL input data, which is filled with the hexa- decimal value 0x41 see line Then a pointer to another data array is copied into the input data buffer see line In the disassembly of the driver, this pointer is referenced at address. I filled the whole buffer with its own valid user space address see line Then in lines and , the two expected patterns are copied into the data buffer see.
The device of the driver is then opened for reading and writing see line , and the malicious IOCTL request is sent to the vulnerable kernel driver see line This message might immediately reappear. So how could I find out if the function pointer was successfully manipulated? Well, all I had to do was trigger the antivirus engine by opening an arbitrary executable.
I opened Internet Explorer and got the following message in the debugger: Access violation - code c!!! The instruction pointer appeared to be under my full con- trol. To verify this, I asked the debugger for more information: Frame IP not in any known module. Following frames may be wrong. The exploitation process, illustrated in Figure , was as follows: Is the length of the input data 0x?
If so, proceed to step 2. The user space buffer data gets referenced.
Are the expected patterns found at data and data? Diagram of my exploitation of the avast! The destination address for the memcpy call gets referenced.
The manipulated function pointer gives full control over EIP. Wow, that was really fast for a commercial software vendor! Do not allow unprivileged users to read from or write to these devices.
You can find a download link for a vulnerable trial version of avast! Profes- sional 4. See Mark E. Russinovich and David A. Solomon, Microsoft Windows Internals: Red- mond, WA: Microsoft Press, Windows Development: Windows Driver Kit: Kernel- Mode Driver Architecture: Standard Driver Routines: DriverEntry at http: WinObj is available at http: The Windows Driver Kit can be downloaded at http: Kernel-Mode Driver Architecture: DispatchDeviceControl available at http: Kernel Data Types: System-Defined Data Structures: IRP available at http: Design Guide: Writing WDM Drivers: Handling IRPs: My security advisory that describes the details of the avast!
The bug was easy to trigger, and I wrote a POC code that allows an unprivileged local user to crash the system via ker- nel panic. As usual, I then tried to develop an exploit to see if the bug allows arbitrary code execution. At this point, things got a bit more complicated.
To develop the exploit code, I needed a way to debug the OS X kernel. Source code file xnu This system call has the following prototype: In particular, many operating characteristics of character special files e.
The argument d must be an open file descriptor. An ioctl request has encoded in it whether the argument is an "in" parameter or "out" parameter, and the size of the argument argp in bytes. The request and argp arguments of ioctl correspond to the kernel function arguments cmd and data. I had found what I was looking for: Trace the Input Data After I found the locations in the kernel where IOCTL requests are handled, I traced the input data through the kernel functions while looking for potentially vulnerable locations.
While reading the code, I stumbled upon some locations that looked intriguing. The following listing shows the relevant lines from the source code of the XNU kernel. Then in line , the value of t is compared with nlinesw. If this is done, t will have a negative value due to the type con- version in line Listing illustrates how t can become negative: After the type conver- sion in line 33, the bit patterns, as well as the decimal value of t, are printed to the console.
See Sec- tion A. If t is negative, the check in line of the kernel code will return FALSE because the signed int variable nlinesw has a value greater than zero. If that happens, the user-supplied value of t gets further pro- cessing. In line , the value of t is used as an index into an array of function pointers. Since I could control the index into that array, I could specify an arbitrary memory location that would be executed by the kernel. This leads to full control of the kernel execution flow.
Thank you, Apple, for the terrific bug. The function pointer array linesw gets referenced. The user-controlled value of t is used as an array index for linesw. Description of the vulnerability that I discovered in the XNU kernel of OS X Because the value of t is supplied by the user see 2 , it is pos- sible to control the address of the value that gets copied into EIP. Trigger the bug to crash the system denial of service.
Prepare a kernel-debugging environment. Connect the debugger to the target system. Get control over EIP. Listing shows the source code of the POC I devel- oped to cause a crash.
POC code poc. Crashing a Mac OS X system with only 11 lines of code: I then compiled and tested the POC code as an unprivileged user: Wed Oct 18 I rebooted the system and opened that file. Return Address 4 potential args on stack 0xe3a Could I also execute arbitrary code in the privileged context of the OS X kernel?
To answer that question, I had to peer inside the inner workings of the kernel. Therefore, I had to find another way to debug the kernel. Instructions for building such a debugger host system are described in Section B. DA [ether] on eth0? That gave me the following output on the screen of the MacBook: Debugger called: Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details. The OS X sys- tem was frozen at that time, so I continued the execution of the ker- nel with the following debugger command: Now everything was set up for remotely debugging the kernel of the Mac OS X target system.
Next, I looked at the register values: The next instruction modifies this value by a left shift of 5 bits. So where did the value of EBX come from? The value 0xe was the result of a left shift of my supplied input value by 5 bits.
As expected, I was able to control the memory location used to find the new value for the EIP register. I could try to solve the math- ematical problem, or I could brute force the value.
I decided to go with the easy option and wrote the following program to brute force the value: I then tried to manipulate EIP to make it point to address 0x To achieve this, I had to find a memory location in the kernel that pointed to that value. To find suitable memory locations in the kernel, I wrote the following gdb script: I wanted to find a memory location that pointed to the value 0x, so I used the script in the following way: I picked the first one from the list, A Bug Older Than 4.
At this point I was able to control EIP, but exploiting the bug to achieve arbitrary code execution at the kernel level was still a challenge. I solved this problem by heap spray- ing the kernel with my privilege escalation payload and a reference to this payload. I achieved this by exploiting a memory leak in the kernel of OS X. This value was then copied into EIP and. If so, the user-derived data will not be processed any further.
This little change was enough to successfully rectify the vulnerability. If the user-derived data is greater than 0x, the function returns with an error see line So Theo was right—the bug was indeed already fixed in Timeline from the time I notified Apple until I released a security advisory Notes 1.
The vulnerable source code revision The source code of the fixed XNU version My security advisory that describes the details of the Mac OS X kernel vul- nerability can be found at http: The initial FreeBSD version of tty. I was very excited. Ever since Apple announced the iPhone, I had wanted to see if I could find a bug in the device, but until last week I had never had access to one.
But where to start? The first thing I did was make a list of installed applications and libraries that seemed most likely to have bugs. The MobileSafari browser, the MobileMail app, and the audio libraries were at the top of the list. I decided that the audio libraries were the most promising targets since these libraries do a lot of parsing and are heavily used on the phone, so I tried my luck on them.
Build a simple fuzzer and fuzz the phone. Three frameworks available on the phone provide different levels of sound functionality: In addition, the iPhone runs an audio daemon called mediaserverd, which aggregates the sound output of all applica- tions and governs events such as volume and ringer-switch changes. The fuzzer that I built does the following: On a Linux host: Prepares the test cases by mutating a sample target file. Serves these test cases via a web server. On the iPhone: Opens the test cases in MobileSafari.
Monitors mediaserverd for faults. In the event a fault is uncovered, logs the findings. Repeats these steps. I created the following simple, mutation-based file fuzzer to pre- pare the test cases on a Linux host: The code I wrote to prepare test cases on the Linux host fuzz. After writing the fuzzer, I compiled it: I chose the standard iPhone ringtone, named Alarm. The output shows that file offset 4 file offsets are counted start- ing with 0 was replaced with the expected value 0xff.
Next, I cre- ated a bash script to automate the file mutation: The bash script I created to automate file mutation go. Starting at file offset 0 see line 7 , the first 4 bytes of the target file see line 10 are each replaced with a 0xff see line When executed, the script produced the following output: As the output shows, the fuzzer worked as expected and modi- fied the appropriate byte in each test-case file.
I copied the modified and unmodified alarm ringtone files into the web root directory of the Apache webserver that I had installed on the Linux host. I changed the file extension of the alarm ring- tone from. As illustrated in Figure , the unmodified target file Alarm. I then pointed the browser to the URL of the first modified test-case file, named file0. Playing the unmodified Figure Playing the modified test-case Alarm. I was able to prepare audio-file test cases via mutation, launch MobileSafari, and instruct it to load the test cases.
At this point, I wanted to find a way to automatically open the test-case files in MobileSafari one by one while monitoring mediaserverd for faults.
I created this small Bash script to do the job on the phone: Code to automatically open test cases while monitoring mediaserverd for faults audiofuzzer. Fuzzing the iPhone can be tedious, since some components, including mediaserverd, are prone to hangs. The two process IDs differ when mediaserverd has encountered a fault and restarted while processing one of the test cases.
After I implemented this little script, I created 1, mutations of the Alarm. From time to time the phone crashed due to memory leaks. Every time that happened, I had to reboot the phone, extract the filename of the last processed test case from the access logfile of the web server, adjust line 18 of Listing , and continue fuzzing.
Fuzzing the iPhone can be such a pain. In addi- tion to the memory leaks that froze the phone, I also found a bunch of crashes due to memory corruption. This is M attempting to play the test-case files 40, 41, important because the ARM assem and To analyze the crashes, I rebooted language is bly vastly differe the phone and attached the GNU debug- from Intel as nt sembly.
Mon Dec 8 Reading symbols for shared libraries The debugger produced the following result: To further analyze the crash, I printed the current call stack: ParseHeader 2 0x in?? Cannot access memory at address 0x72 This output was intriguing. The address of stack frame 2 had an unusual value 0x , which seemed to indicate that the stack had become corrupted.
I used the following command to print the last instruction that was executed in MP4AudioStream:: ParseHeader see stack frame 1: ParseHeader was a call to memcpy , which must have caused the crash. At this time, the bug had exhibited all the characteristics of a stack buffer overflow vulnerability see Section A.
I stopped the debugging session and rebooted the device. After the phone started, I attached the debugger to mediaserverd again, and this time I also defined a breakpoint at the memcpy call in MP4AudioStream:: ParseHeader in order to evaluate the function arguments supplied to memcpy: I opened test case number 40 file ParseHeader The arguments of memcpy are usually stored in the registers r0 destination buffer , r1 source buffer , and r2 bytes to copy.
I asked the debugger for the current values of those registers. I found them right at the beginning of the file in little-endian notation: I contin- ued the execution of mediaserverd and got the following output in the debugger: It seemed that the size argument supplied to memcpy was too big, so the function tried to copy audio-file data beyond the end of the stack.
At this point I stopped the debugger and opened the test-case file that had actually caused the crash file I consulted the QuickTime File Format Specifica- tion7 to determine the role of that byte within the file structure. The byte was described as part of the atom size of a movie header atom, so the fuzzer must have changed the size value of that atom.
As I men- tioned before, the size supplied to memcpy was too big, so mediaserverd had crashed while trying to copy too much data onto the stack.
To avoid the crash, I set the atom size to a smaller value. I changed the manipulated value at file offset 40 back to 0x00 and the byte value at offset 42 to 0x Here is the original test-case file 40 file This time the program counter instruction pointer was manipu- lated to point to address 0x I then stopped the debugging session and started a new one while again setting a breakpoint at the memcpy call in MP4AudioStream:: The first stack frame on the list was the one I was looking for.
I used the following command to display information about the current stack frame of MP4AudioStream:: Locals at 0xbf8, Saved registers: I then continued the execution of the process: ParseHeader function expects to find its saved program counter.
When the function tried to return to its caller function, the manipulated value was assigned to the instruction pointer pc register. Specifically, the value 0x was copied into the instruction pointer instead of the file value 0x due to the instruction alignment of the ARM CPU instruction align- ment on a bit or bit boundary. My extremely simple fuzzer had indeed found a classic stack buf- fer overflow in the audio libraries of the iPhone.
I then changed the underlined value above to 0x and named the new file poc. I attached the debugger to mediaserverd again and opened the new poc. Cannot access memory at address 0x Yay! At this point I had full control over the program counter. More surprising: Figure shows a time- line of how the vulnerability was addressed. My security advisory that describes the details of the iPhone vulnerability can be found at http: Today the most relevant ones are stack buffer overflows and heap buffer overflows.
A buffer overflow happens if more data is copied into a buffer or array than the buffer or array can handle. As the name implies, stack buffer overflows are happening in the stack area of a process memory. The stack is a special memory area of a process that holds both data and metadata associated with procedure invocation. If more data is stuffed in a buffer declared on the stack than that buffer can handle, adjacent stack memory may be overwritten. If the user can control the data and the amount of data, it is possible to manipulate the stack data or meta- data to gain control of the execution flow of the process.
Every function of a process that is executed is represented on the stack. The organization of this information is called a stack frame. A stack frame includes the data and metadata of the function, as well as a return address used to find the caller of the function.
When a func- tion returns to its caller, the return address is popped from the stack and into the instruction pointer program counter register. If you can overflow a stack buffer and then overwrite the return address with a value of your choosing, you get control over the instruction pointer when the function returns.
There are a lot of other possible ways to take advantage of a stack buffer overflow for example, by manipulating function pointers, func- tion arguments, or other important data and metadata on the stack. Example program stackoverflow. The first command-line argument line 15 is used as a parameter for the function called overflow. In overflow , the user- derived data is copied into a stack buffer with a fixed size of 12 bytes see lines 6 and 8.
If we supply more data than the buffer can hold more than 12 bytes , the stack buffer will overflow, and the adjacent stack data will be overwritten with our input data. Figure A-1 illustrates the stack layout right before and after the buffer overflow.
The stack grows downward toward lower memory addresses , and the return address RET is followed by another piece of metadata called the saved frame pointer SFP. Below that is the buf- fer that is declared in the overflow function.
In contrast to the stack, which grows downward, the data that is filled into a stack buffer grows toward higher memory addresses. If the func- tion then returns, we control the value of RET, which gives us control over the instruction pointer EIP register. Stack frame illustrating a buffer overflow Example: As Figure A-2 shows, I got the same result as under Linux: Figure A Numerous books and white papers are available on this topic.
The Art of Exploitation, 2nd edition No Starch Press, , or you can type buffer overflows into Google and browse the enormous amount of mate- rial available online. Typically, a process, a thread, or the kernel cannot read from or write to a memory location on the zero page. Listing A-2 shows a simple example of what happens if the zero page gets referenced due to a programming error.
This leads to a classic NULL pointer dereference when the program tries to read a value from memory page zero. Access violation - code c first chance First chance exceptions are reported before any exception handling. This exception may be expected and handled. You can get more information on the cause of the crash by using the debugger command! Depending on the particular programming error, NULL pointer dereferences can also lead to arbitrary code execution. There are two types of conversion: In programming languages like C, implicit type conversion occurs when the compiler automatically converts a variable to a differ- ent type.
This usually happens when the initial variable type is incom- patible with the operation you are trying to perform. Implicit type conversions are also referred to as coercion. Explicit type conversion, also known as casting, occurs when the programmer explicitly codes the details of the conversion.
This is usu- ally done with the cast operator. Here is an example of an implicit type conversion coercion: Type conversions can be very subtle and cause a lot of security bugs. Many of the vulnerabilities related to type conversion are the result of conversions between unsigned and signed integers.
Below is an example: Can you spot the bug? In line 14, a length value is read in from user input and stored in the signed int variable length. Since length gets assigned the value 0xffffffff and this value is much bigger than 12, it may seem obvious that the string will not be printed.
How did this happen? On a bit machine, an unsigned int has a range of 0 to and a signed int has a range of — to The unsigned int value 0xffffffff is represented in binary as see Figure A If you interpret the same bit pattern as a signed int, there is a change in sign that results in a signed int value of —1.
If the MSB is 0, the number is positive, and if it is set to 1, the number is negative. If the unsigned int value is in the range 0x to 0xffffffff, the resulting signed int will become negative see Figure A Integer type conversion: Its purpose is to redirect position-independent address calculations to an absolute location, so it stores the absolute location of function- call symbols used in dynamically linked code.
When a program calls a library function for the first time, the runtime link editor rtld locates the appropriate symbol and relocates it to the GOT.
Listing A-4 illustrates this process. Example code used to demonstrate the function of the Global Offset Table got. I compiled the program with debugging symbols and started it in the debugger see Section B. Much as the GOT redi- rects position-independent address calculations to absolute locations, the PLT redirects position-independent function calls to absolute locations.
This is where rtld gets called to locate the referenced printf symbol. First, I defined a breakpoint just before the second call to printf: I then started the program: The same address in the PLT was indeed called: It now points directly to the printf library function in libc.
For a real-life example of this exploitation technique, see Chapter 4. To determine the GOT address of a library function, you can either use the debugger, as in the previous example, or you can use the objdump or readelf command: Offset Info Type Sym.
Value Sym. For a complete list of available commands, see the Solaris Modular Debugger Guide. General Commands Command Description:: If the target is currently running or it is a corefile, mdb will restart the program if possible. Breakpoints Command Description address:: Running the Debuggee Command Description: Will step into subfunctions.
Will not enter subfunctions. Other Commands Command Description:: Click Open Executable on the File menu to start a new user-mode process and debug it. File4 Attach to a Process Click Attach to a Process on the File menu to debug a user-mode application that is currently running.
Breakpoints Command Description bp address Sets a new breakpoint at the address of the breakpoint location that is specified in the command. Running the Debuggee Command Description t Executes a single instruction or source line and, option- ally, displays the resulting values of all registers and flags.
Examining Data Command Description dd address Displays the contents of address as double-word val- ues 4 bytes. Depending on the architecture the pointer size is 32 bits or 64 bits. Other Commands Command Description!
I set up a debugging environment with VMware2 and WinDbg3 by following these steps: Configure the VMware guest system for ut this section, I us remote kernel debugging. VM Step 2: I then clicked the Add button to add a new serial port and chose the configuration settings shown in Figures B-1 and B Output to named pipe Figure B Configuration settings for the new serial port Step 2: New boot menu option Step 3: To do this, I created a batch file with the content shown in Figure B Figure B Attaching the kernel debugger WinDbg B.
For a complete list of available commands, see the gdb online documentation. General Commands Command Description run arguments Starts debugged program with arguments. Running the Debuggee Command Description stepi Executes one machine instruction. Information Commands Command Description info registers Lists registers and their contents. Install an ancient Red Hat 7. Get the necessary software packages. Prepare the debugging environment. I prepared the Linux debugging host to research the kernel bug described in Chapter 7, so I downloaded the XNU version I also copied the XNU source code into the search path of the debugger: See the Solaris Modular Debugger Guide at http: There are still a few download mirror sites available where you can get the Red Hat 7.
Here are a few, as of this writing: The standard gdb version from GNU can be downloaded at http: The XNU version The most prevalent ones are these: There are also various heap mitigation techniques heap cookies, randomization, safe unlinking, etc. The many mitigation techniques could easily fill another book, so I will focus on the most prevalent ones, as well as on some tools used to detect them.
NOTE There is a continuous race between exploit mitigation techniques and ways of bypassing them. Even systems using all of these mechanisms may be successfully exploited under certain circumstances. Address Space Layout Randomization ASLR ASLR randomizes the location of key areas of a process space usu- ally the base address of the executable, the position of the stack, the heap, the libraries, and others to prevent an exploit writer from pre- dicting target addresses.
Say you find a write4 primitive vulnerability that presents you with the opportunity to write 4 bytes of your choosing to any memory location you like. That gives you a powerful exploit if you choose a stable memory location to overwrite.
Before the return address is processed, the validity of the cookie or canary is checked, and the data in the stack frame is reorganized to protect the pointers and arguments of the function. If you find a stack buffer overflow in a function that is protected by this mitigation technique, exploitation can be tough.
Many modern operating systems take advantage of the NX bit. Mitigations can be controlled by system policy, by special APIs, and by compile-time options. There are different ways to opt a process in to DEP. Windows supports four system-wide configurations for hardware-enforced DEP. It is important to note that pro- tection is significantly weaker if not all modules of a process opt in to ASLR. In practice, the effectiveness of mitigations like DEP and ASLR is heavily dependent on how completely each mitigation technology has been enabled by an application.
Microsoft has also released a tool called BinScope Binary Analyzer,8 which analyzes binaries for a wide variety of security protections with a straightforward, easy-to-use interface. RELRO has two different modes: The entire GOT is re mapped as read-only.
I used Debian Linux 6. Test Case 1: Test Case 2: A zone is a virtualized operating system environment created within a single instance of the Solaris Operating System.
When you create a zone, you produce an application execution environment in which processes are isolated from the rest of the system. This isolation should prevent processes that are running in one zone from moni- toring or affecting processes that are running in other zones.
Terminology There are two different kinds of zones: The global zone represents the conventional Solaris execution environ- ment and is the only zone from which non-global zones can be con- figured and installed.
By default, non-global zones cannot access the global zone or other non-global zones. All zones have a security boundary around them and are confined to their own subtree of the filesystem hierarchy. Every zone has its own root directory, has sepa- rate processes and devices, and operates with fewer privileges than the global zone. Sun and Oracle were very confident about the security of their Zones technology when they rolled it out: By running network x8 0- Image sol-1 services in a zone, you limit the damage possible in the -g a1 -x 86 -dvd.
The privileges available within a zone are a subset of those available in the system as a whole. Privilege restriction prevents a zone from performing operations that might affect other zones.
The set of privileges limits the capabilities of privileged users within the zone. To display the list of privileges available within a zone, use the 14 ppriv utility. The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws.
Dafydd Stuttard. The Art of Deception: Controlling the Human Element of Security. Kevin D. The Art of Exploitation, 2nd Edition. Jon Erickson. Michael Sikorski. Read more. Product details Paperback: No Starch Press; 1 edition October 11, Language: English ISBN Don't have a Kindle?
Try the Kindle edition and experience these great reading features: Share your thoughts with other customers. Write a customer review. Read reviews that mention bug hunter hunter diary bug hunting tobias klein software security source code lessons learned type conversion media player vlc media null pointer security vulnerabilities open source ffmpeg multimedia multimedia library stack overflow input data operating systems guided tour thought process.
Top Reviews Most recent Top Reviews. There was a problem filtering reviews right now. Please try again later. Kindle Edition Verified Purchase. This book is really good for getting a feel for the mindset and process required for vulnerability hunting. He goes over fuzzing techniques, where to look for weak points in application code, and much more.
However, the author is German and the laws in Germany are restrictive against redistributing "hacker code. Personally for me this was a big drawback, as I find reading source code the best way to learn techniques like these. Paperback Verified Purchase. Well its a good book, not excellent because has not steps to do things or present the same case on differents views like "case study" if the book show "how to do.. One person found this helpful. If you're technically-inclined, a security researcher, or just someone who is interested in computer security, chances are you'll love this book.
It goes into detail about each vulnerability, in a unique format, explaining the technical details and just about everything you'd need to know. A geek's diary if there ever was one. Hard to put this one down. Recommended read!
Finding vulnerabilities in software is hard, and although there are a lot of sources for learning the theory of how to do it, this book actually walks you step by step through how the author found some in a variety of software. This is the only book of it's kind at least as of Bug Hunting is Addicting. If you're interested in bug hunting, this is the book you want.
A Bug Hunter's Diary is the perfect followup, showing you the thought process behind bug hunting. After you pick up this book, you'll want to start searching for your own bugs - and you'll likely find some too! This is a good look at the thought process involved when looking for bugs in software. The book does not go into all the details, though. This makes it good when trying to teach the process.
Other materials can be used to show detailed tool and techniques. This is a very good book. But make sure you have great coding skills in order to take advantage of all that the book can offer.
I'm not a coder myself, so I'll have to improve those skills, and get back an re-read this book. Excellent book, easy to read, interesting content.
It is inspiring for writing better and resisitant code. See all 32 reviews. Amazon Giveaway allows you to run promotional giveaways in order to create buzz, reward your audience, and attract new followers and customers. Learn more about Amazon Giveaway.
This item: Set up a giveaway. Customers who bought this item also bought. The Shellcoder's Handbook: