d

 Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services

Published on 1995 - by B.P. Miller, D. Koski, C.P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl, ©B.P. Miller, D. Koski, C.P. Lee, V. Maganty, R. Murthy, A. Natarajan, and J. Steidl

We have tested the reliability of a large collection of basic UNIX utility programs, X-Window applications and servers, and network services. We used a simple testing method of subjecting these programs to a random input stream. Our testing methods and tools are largely automatic and simple to use. We tested programs on nine versions of the UNIX operating system, including seven commercial systems and the freely-available GNU utilities and Linux. We report which programs failed on which systems, and identify and categorize the causes of these failures.

The result of our testing is that we can crash (with core dump) or hang (infinite loop) over 40% (in the worst case) of the basic programs and over 25% of the X-Window applications. We were not able to crash any of the network services that we tested nor any of X-Window servers. This study parallels our 1990 study (that tested only the basic UNIX utilities); all systems that we compared between 1990 and 1995 noticeably improved in reliability, but still had significant rates of failure. The reliability of the basic utilities from GNU and Linux were noticeably better than those of the commercial systems.

We also tested how utility programs checked their return codes from the memory allocation library routines by simulating the unavailability of virtual memory. We could crash almost half of the programs that we tested in this way.

File info:

• Source: http://www.cs.wisc.edu/~bart/fuzz/

 Empirical Study of the Robustness of Windows NT Applications Using Random Testing (An)

Published on 2000 - by Justin E. Forrester, Barton P. Miller , ©Justin E. Forrester, Barton P. Miller

We report on the third in a series of studies on the reliability of application programs in the face of random input. In 1990 and 1995, we studied the reliability of UNIX application programs, both command line and X-Window based (GUI). In this study, we apply our testing techniques to applications running on the Windows NT operating system. Our testing is simple black-box random input testing; by any measure, it is a crude technique, but it seems to be effective at locating bugs in real programs.

We tested over 30 GUI-based applications by subjecting them to two kinds of random input: (1) streams of valid keyboard and mouse events and (2) streams of random Win32 messages. We have built a tool that helps automate the testing of Windows NT applications. With a few simple parameters, any application can be tested.

Using our random testing techniques, our previous UNIX-based studies showed that we could crash a wide variety of command-line and X-window based applications on several UNIX platforms. The test results are similar for NT-based applications. When subjected to random valid input that could be produced by using the mouse and keyboard, we crashed 21% of applications that we tested and hung an additional 24% of applications. When subjected to raw random Win32 messages, we crashed or hung all the applications that we tested. We report which applications failed under which tests, and provide some analysis of the failures.

File info:

• Source: http://www.cs.wisc.edu/~bart/fuzz/

 Empirical Study of the Robustness of MacOS Applications Using Random Testing (An)

Published on 2006 - by Barton P. Miller, Gregory Cooksey, Fredrick Moore, ©Barton P. Miller, Gregory Cooksey, Fredrick Moore

We report on the fourth in a series of studies on the reliability of application programs in the face of random input. Over the previous 15 years, we have studied the reliability of UNIX command line and X-Window based (GUI) applications andWindows applications. In this study, we apply our fuzz testing techniques to applications running on the Mac OS X operating system. We continue to use a simple, or even simplistic technique: unstructured black-box random testing, considering a failure to be a crash or hang. As in the previous three studies, the technique is crude but seems to be effective in locating bugs in real programs.

We tested the reliability of 135 command-line UNIX utilities and thirty graphical applications on Mac OS X by feeding random input to each.We report on application failures – crashes (dumps core) or hangs (loops indefinitely) – and, where source code is available, we identify the causes of these failures and categorize them. Our testing crashed only 7% of the command-line utilities, a considerably lower rate of failure than observed in almost all cases of previous studies.We found the GUI-based applications to be less reliable: of the thirty that we tested, only eight did not crash or hang.

Twenty others crashed, and two hung. These GUI results were noticeably worse than either of the previous Windows (Win32) or UNIX (X-Windows) studies.

File info:

• Source: http://www.cs.wisc.edu/~bart/fuzz/

 Linux Per-Process Syscall Hooking

Published on 2006 - by Pluf, ©Pluf

This document describes a new syscall hooking technique for Linux systems and exposes how it can be implemented as part of a virus or a backdoor in order to take full control over an userland application. Although there are some well- known methods for hooking functions, they are mostly based on the ELF format itself. This technique is focused on thoses pieces of code that are externally called by the main program and invoke a system call or system service.

A simple implementation of this hooking mechanism has been developed as a result of the research and it is included with the article. This code provided does not have all the features you wish but includes the required ones, is not a real backdoor but a simple proof of concept, perfect to write your own one.

File info:

• Source: www.packetstormsecurity.org

 Anti-Hacker Tool Kit: Reverse Engineering Binaries

Published on 2006-02-09 - by Mike Shema, ©McGraw-Hill Osborne Media

Your computer seems to be running slower than normal. The router shows that your computer is transmitting data out to the Internet without you knowing it. Friends are complaining about you sending them e-mails you never composed. Determined to see if you have a Trojan running on your computer, you take a look at your process list to see if there is anything out of the ordinary. Much to your dismay, you notice a program running that you have never seen before and didn’t explicitly start. You have been backdoored by malware.

There are many questions you should be asking in these situations. What does the program do? Does it use network resources? Can outside hackers now access my computer? Am I being used as a zombie for DDoS attacks? This chapter will focus on methods and tools you can use to determine what these programs do and how they do them, without having the source code. In the past, reverse engineering was something of a black art. Typically it involved some type of decompilation using a tool such as IDA or GDB to extract the assembly out of the binary, and the best you could hope for was to have that assembly converted into a low-level C code that you could use to understand what was going on. These tools have evolved, however, and you no longer need a PhD in Computer Science to be able to reverse engineer binaries. That being said, however, a brief primer will go miles in helping you understand when to use certain tools and when to use others.

File info:

• Source: www.ethicalhacker.net

 Fuzzing: Breaking software in an automated fashion

Published on 2005-12-08 - by Ilja van Sprundel, ©Ilja van Sprundel

Fuzzing is the art of automatic bug finding. This is done by providing an application with semi-valid input. The input should in most cases be good enough so applications will assume it’s valid input, but at the same time be broken enough so that parsing done on this input will fail. Such failing can lead to unexpected results such as crashes, information leaks, delays, etc.

It can be seen as part of quality assurance, although only with negative test cases. Fuzzing is mostly used to uncover security bugs, however, it can often also be used to spot bugs that aren’t security critical but which can non-the-less improve robustness.

File info:

• Source: http://events.ccc.de/

 SMIL Basics

Published on 2002 - by RealNetworks, Inc., ©RealNetworks, Inc.

When your streaming presentation contains multiple clips—such as a video and streaming text played together—you use Synchronized Multimedia Integration Language (SMIL) to coordinate the parts. Pronounced "smile," SMIL is a simple but powerful markup language for specifying how and when clips play. This chapter introduces you to SMIL, its advantages, and its syntax rules.

File info:

• Source: http://service.real.com/

 RealSystem: SMIL 2.0

Published on 2003 - by Tobias Künkel, ©Tobias Künkel

This first example shows how a simple SMIL playlist with video elements can be done. The first 60 seconds of each video are played sequentally in the region "r1". Additionally the first 30/60 seconds of video two and three are skipped.

File info:

• Source: www.streaming-media.biz

 Format String Attacks

Published on 2000 - by Tim Newsham,

I know it has happened to you. It has happened to all of us, at one point or another. You’re at a trendy dinner party, and amidst the frenzied voices of your companions you hear the words format string attack. Format string attack? What is a format string attack? you ask. Afraid of having your ignorance exposed among your peers you decide instead to break an uncomfortable smile and nod in hopes of appearing to be in the-know. If all goes well, a few cocktails will pass and the conversation will move on, and no one will be the wiser. Well fear no more! This paper will cover everything you wanted to know about format string attacks but were afraid to ask!

File info:

• Source: www.lava.net

 Exploiting non-classical format string vulnerability

Published on 2006 - by darkeagle, ©55k7 researcherz

One day, I was researching some popular Open-Source Unix daemon. And I found format string vulnerability in this daemon. There was vulnerable call of "sprintf()" function. I was trying to exploit it. But when I put some evil string like this "AAAA.%x.%x.%x.%x.%x.%x.%x.%x" to the daemon, I got this type of answer: "bla_bla_bla AAAA.addrz_addrz_addrz_2e334141". I was preparing to exploit it triviality with classical method. I added in the start two "A" to align offset and try to exploit. But when I attached to child process I was looking that EIP registry points to 0x99ffe9fa instead 0xbfffd5fa. Later I was google information about how to exploit this situation. All what I found was paper by Pascal’s method of exploiting format string. His paper wasn’t about exploiting my situation, but with help from his paper I can exploit daemon. But... His method wasn’t so unique and Pascal wrote that his method is hard to understand. So, I started to explore simply way to exploit this situation. And I found it! This paper simply describes my method. I’ll show you some examples on REAL vulnerabilities. Will show local and remote method how to exploit non-classical format string vulnerability.

Just go, yo!

File info:

• Source: www.unl0ck.net

 Quoting the Quotes

Published on 2003-11-25 - by Henrik Stuart, ©Henrik Stuart

This article describes a client-side workaround using JScript for the missing functionality in Microsoft Internet Explorer™ to add language-dependant quotation marks around, in particular, but also HTML elements.

File info:

• Source: www.codeproject.com

 Testing C Programs for Buffer Overflow Vulnerabilities

Published on 2005 - by Eric Haugh and Matt Bishop, ©Eric Haugh and Matt Bishop

Security vulnerabilities often result from buffer overflows. A testing technique that instruments programs with code that keeps track of memory buffers, and checks arguments to functions to determine if they satisfy certain conditions, warns when a buffer overflow may occur. It does so when executed with normal test data as opposed to test data designed to trigger buffer overflows. A tool using this method was developed and evaluated by testing three widely used, open source software packages. This evaluation shows that the tool is useful for finding buffer overflow flaws, that it has a low false positive rate, and compares well with other techniques.

File info:

• Source: www.isoc.org

 File Format Reversing - EverQuest II VPK

Published on 2005-09-06 - by daeken, ©OpenRCE

In this article I will cover the basics of reverse-engineering binary file formats, starting with the simple archive format used in the popular game EverQuest™ II known as VPK. This is the first of many articles I'll be writing on the subject as time goes on. You can find VPK files in any EverQuest™ II installation, and any will do for the purposes of this article. For the purposes of this article, I will assume the reader has knowledge of programming in C. The architecture being used is x86, and thus, everything is unsigned and little-endian. The tools you will need to follow along with this article are a decent hex editor (I recommend HexEditor for Mac OS X™) and a copy of Python.

File info:

• Source: www.openrce.org

 Reverse Engineering Microsoft OLE

Published on 2005-09-12 - by Joe Stewart, ©OpenRCE

For the experienced reverse-engineer, a basic analysis of what a particular piece of malware does can be a relatively quick and painless process. Simply load up the executable component into IDA or OllyDbg and let the auto-analysis match up import names with function calls. Presented with these scraps of information, a guess can be made pertaining to what function a particular subroutine performs. Labeling these subroutines creates more function cross-references that can in turn reveal more about the overall functionality of the program.

File info:

• Source: www.openrce.org

 PHP Web Application Security

Published on 2005-08-08 - by Pax Dickinson, ©Guardian Digital, Inc.

Today on Hacks From Pax we'll be discussing PHP web application security. PHP is a great language for rapidly developing web applications, and is very friendly to beginning programmers, but some of its design can make it difficult to write web apps that are properly secure. We'll discuss some of the main security gotchas when developing PHP web applications, from proper user input sanitization to avoiding SQL injection vulnerabilities.

File info:

• Source: www.linuxsecurity.com