Software Exploit Development – Fuzzing with AFL


It’s quite impressive to look back in the past to the early days of software vulnerabilities and observe the ongoing dance between new  mitigation and new exploitation techniques. Powerful fuzzing tools are now common place and operated on a daily basis by IT corporations and security labs; either to find crashes in their software or others’ program, seeking workable exploit out of it. New research is continuously presented to mitigate new procedures while multiple organizations develop new counter-mitigation tricks. In this post, we’ll overview the entire software exploitation process: from fuzzing with American Fuzzy Lop (AFL) to exploit development with gdb-peda and pwntools. For this purpose, we will develop a quick 64-bit program exhibiting a glaring buffer overflow vulnerability. We will then fuzz it to find that vulnerability, analyze the results and development an exploit for it. A video is also available.

The Vuln1 Vulnerable Program

While we could use a known vulnerable program online, we decide to craft our own quick C program so we can understand all its facets. The program below uses two characters buffers of 32 characters; one to hold the username and the other one to hold a password. To manage user input, we used the well-known insecure gets() function, which fails to check buffer boundaries and leads to buffer overflows.

Once executed, the program first asks for a username and a password. The inputs are stored in the login and passwd variables. Their value are then compared with the expected value using strcmp(). If the credentials entered are “root” and “1qazxsw2”, then a “Access Granted.” message is printed out to the console, otherwise “Access Denied.” is shown to the user and the program exits.

To simplify the exploitation process of this exercise, we will compile this program with absolutely no memory protection, i.e. NX will be disabled and no stack canary. NX is usually enabled to prevent code to be executed directly from the stack, which there is no need for other than exploitation purposes. As for stack canaries, they can detect stack overflows by adding an extra value to the software stack. If this value is not found when the function returns, an exception is thrown to prevent further execution. Nowadays, these protection schemes are enabled in a vast majority of cases, but we adopt simplicity rather than realism for this post. Disabling these protection mechanism can be achieved using the following GCC command:

The  -fno-stack-protector will disable the stack canaries while the  -z execstack makes both the heap and stack executable. To verify that these options have not been included, we can use a nifty tool call checksec which is included with pwntools, which will will present later in this post. By executing  checksec vuln1 we confirm that both the stack canaries and NX bit are disabled:

Checksec reports on 2 additional security mechanisms other than the stack canaries and No-eXecute bit. While these concepts are out of scope for this post, we will simply present them

With our target created, we are now ready to start fuzzing it to uncover the buffer overflow it contains.

Fuzzing with AFL

AFL is a popular open-source and free fuzzer that has been leveraged to discover vulnerabilities in a large set of applications and libraries. Before starting AFL, we need to instrumentalize our target using the afl-gcc compiler. The AFL compiler will add code around the source in order to maximize coverage. To compile the source code with AFL, use the same command used above to compile Vuln1 using afl-gcc rather than gcc or use the associated Makefile

The resulting binary is the one that will be used with AFL, but when analyzing the crash later one, we will do it with the gcc compiled binary. Until then, let’s learn how to use AFL to assess the Vuln1 program.

A critical aspect of fuzzing is to craft meaningful test cases, e.g. inputs that will maximize code coverage by exploring all potential paths of the targeted program. The vuln1 program is simple and only has 3 paths:

  1. Username is invalid;
  2. Username is valid, but password in invalid;
  3. Username and password are valid.

In order to reach these 3 paths, we will design our test cases appropriately by creating 3 files. The first file will have 2 lines, none of them containing the appropriate credentials, the second file will have the right username, but an invalid password and the third file will have both correct credentials. AFL will read the contents of each file and feed each line to the stdin of Vuln1. Create a directory called testcases and in it, create 3 files representing these cases. The name of the files does not matter.

test1.txt test2.txt test3.txt

After creating these 3 files, create another directory called results, which will contains the results of the fuzzing run. At this point you’re ready to start AFL using afl-fuzz, the actual fuzzing program. You can do so with the following command:

Where -t ./testcases specifies the directory containing the testcases, -o ./results specifies the output directory and ./vuln1 is that target program. If you run AFL for the first time, you’ll likely be greeted with the following warning:

Core_pattern file warning when running AFL
AFL Warns that the core_pattern file must be changed.

Just follow the instruction given and you’ll get rid of this message. Simply a shell as root using  sudo bash and type the suggested command, i.e.

Retry to start AFL using the same command and you should have no issue this time. A screen will appear and present you with quite a few statistics. This AFL Readme file explains all of these fields very well, and should definitively be read and well understood. For now, let’s focus on the “Overall Results” section.

Fuzzing Vuln1 with AFL - Results
Results of Fuzzing the Vuln1 Program

Two rows of this section are particularly interesting in this example:

  • Total paths; and
  • Unique crashes.

Notice that after a few seconds, the total paths field is 3, which is what we expected based on the code of vuln1. As such, once we reached 3 paths, we can stop AFL by pressing Ctrl-C, as it will not find anything new. In the real world, we have no idea how many paths may be possible. As such AFL provides color codes to help you assess if it’s time to stop. Another field that can help is the last path found. When no new paths have been found after a while, AFL may have cover most of the code it can find and is unlikely to find anything new. Finally, the most interesting field is the unique crashes, which indicates that some of the inputs, stored in the results directory, have successfully crashed the program and should be investigated. We have 2 files in the results/crashes directory:

Each file contains the input that crashed the program so you can reproduce the event and investigate to see if the crash is exploitable.

We can confirm the crash and observe an segmentation fault by piping the contents of the crash to our vuln1 program:

The next step is to analyze the crash data and determine if it can be converted into an exploitable vulnerability. Spoiler alert: it can.


This short post is a simple introduction to AFL, a powerful fuzzer that can be leveraged on source code and binaries to find potential vulnerabilities. This step is usually the first step in exploit development. In the next post, we’ll use PEDA to analyze the results found here and determine it exploitability.


See Also

  • Related YouTube Video: Software Exploitation Research: Fuzzing with AFL

Further Reading

Repost: Stack-based Buffer Overflow Vulnerabilities in Embedded Systems

The buffer overflow attack vector is well documented in desktop and server class machines using the von Neumann memory model, but little has been published on buffer overflow vulnerabilities in Harvard architectures.


I have not written or contributed to the enclosed research paper. I’m simply reposting it here because it’s interesting and for some reason, appears available only via Google cache. So before it disappear from results, I’m reposting it here.

This paper discusses a technique to conduct buffer overflows on processors using the Harvard architecture. In this architecture, the stack starts at the beginning of the memory and grows up, versus Von Neumann architectures in which it grows down.


Most small embedded devices are built on Harvard class microprocessor architectures
that are tasked with controlling physical events and, subsequently, critical infrastructures. The Harvard architecture separates data and program memory into independent address spaces, as opposed to the von Neumann architecture that uses a unified memory system with a single address space for both data and program code. The buffer overflow attack vector is well documented in desktop and server class machines using the von Neumann memory model, but little has been published on buffer overflow vulnerabilities in Harvard architectures. In this paper we show that stack-based buffer overflow vulnerabilities exist in embedded control devices based on the Harvard class architecture. We demonstrate how a reversal of stack growth direction can greatly simplify the attack and allow for easier access to critical execution controls. We also examine popular defense techniques employed in server and desktop environments and the applicability of those defenses toward Harvard class machines.
Link: Kristopher Watts & Paul Oman, University of Idaho, Stack-based Buffer Overflow Vulnerabilities in Embedded Systems

Starting in Exploit Writing – Day 06


Time for tutorial 6 (yeah I skipped #5, as I got the gist of it). After 6 days, I really got the hang of buffer overflows…too bad they aren’t much in use anymore, but everyone has to start somewhere. So below is EIP and SEH being overflowed with 0x0041, indicating that our “A” where translated to Unicode characters.

Buffer Overflow in Trilogic Player
EIP is being overflowed by 0x0041, indicading a buffer overflow with Unicode characters

Mona locates the Metasploit pattern overwriting SEH at 536. So our payload will be something like

And everything falls in place;

Overwriting nSEH and SEH in Trilogic
Both nSEH and SEH are overwritten with the expected values.

This is where it gets tricky. When following the tutorial, I was never able to see that EIP contained 0x00440044. It actually contained 0x00440045 after moving after the Access Violation exception. I can clearly see that SEH has been overwritten with 0x00420042 and 0x00430043. Fortunately according to one comment, I’m not the only one. When I tried to put 534 bytes of junk rather than 536, I end up with 0x0042004D in EIP (difference of 8). I don’t get why it does that.

At least I’m confident I understand the concepts, but that’s pretty much useless if I cannot put it into practice. For this example, mona can find POP-POP-RET addresses that will work when translated to Unicode. From my understanding, [nSEH] will be useless in Unicode-based exploit, simply because there’s no easy way to have a jump matching Unicode encoding. As such, we’ll need to jump to a register which contains a address close to our shell code and either 1) make sure no instruction between the address and shell code will break the exploit or 2) modify the register (add/sub) to have it jump into a NOP slide to our shell code…and then we have to figure out the shell code, but from what I read, talented people have already took care of this for us.

Useful sites (a.k.a shit I need to read):


Starting in Exploit Writing – Day 05


Today we’ll be studying “egg hunters” as of part 4 of the FuzzySecurity tutorials. Basically this technique is useful when the buffer remaining for your shell code is too small to do anything useful. So far we’ve been lucky and we had huge buffers to inject the shell code, but some time, you may be left with a couple of bytes only. With a “egg hunter”, instead of storing your shell code, you store a small function that will look for “magic bytes” in memory. Your shell code somewhere else in executable memory and tagged with these “magic bytes” so that your egg hunter finds it and executes it. Pretty straight forward.

Exploiting Kolibri Web Server

So my goal today was to test out the egg hunter example from the tutorial. However I got cocky and try to exploit the web server by smashing SEH rather than a normal buffer overflow. Everything went fine until I had to call the address containing the POP-POP-RET.

SEH Exploitation of the Kolibri Web Server
Exploitation of Kolibiri Web Server using the SEH Techique

The problem I’m running into is when looking for a “POP POP RET”, all the results are within Kolibri.exe, and all addresses starts with a null byte, i.e. “\x08\x89\x51\x00”. That means our payload will terminate at the null byte. I thought this wouldn’t be much of a problem, since [SEH] is an address anyway, the only difficulty would be that I may have to put the payload in the buffer prior to the [nSEH], and have a short jmp into the buffer placed into the [nSEH]. Now for some reason, it seems that SEH catches the exception, but never jumps to my POP-POP-RET address; it just terminates the program.

Pop-Pop-Ret Instructions from Kolibri Web Server
All the Pop-pop-ret instructions are located in Kolibri.exe and contains a null byte.

So I got stuck here for today. More to follow tomorrow

Starting in Exploit Development – Day 04


Today, instead of following the FuzzySecurity tutorial, I’ve decided to solidify what I have learned so far by exploiting another FTP Server, this way we won’t yet stray far from the tutorial. We’ll exploit the PCMAN FTP 2.07 server.

The exploit is a buffer overflow in about any command send to the FTP server. We’ll attempt to exploit the STOR command. To do so, we basically reconstruct the Python script we’ve used in day 1:

Note that we are using a buffer of 3000 bytes. I’ve first attempted a payload size of 2000, but it failed to crash the server. At 3000, it was successful as you can see below:

Buffer Overflow in PCMAN FTP 2.07
We successfully smashed EIP with a payload of 3000 bytes in the STOR command.

Let’s replace our payload by a Metasploit pattern to find the offsets using !mona findmsp:

Mona showing at which offset EIP is overwritten
Mona found that EIP is being overwritten at offset 2006

Also interesting, is that SEH is not being overwritten here, so we cannot use the technique learned yesterday. The offset found, we can now start shaping our payload:

And we’ll test it to confirm everything is going smoothly:

EIP overwritten with "B"s
Our payload works, now we simply have to put the addresses and shell code needed

Ah ! Perfecto ! Now let’s figure out an address we can use to jump at [ESP]. We’ll do this using !mona jmp -r esp:

Search results for "jmp esp" in PCMAN 2.07
Search results for “jmp esp” instructions in memory for PCMAN FTP Server 2.07

Ideally, I would have like to find a “jmp esp” within the application itself, but all of them contained invalid bytes, so I’ll just use one from the Windows DLLs:

We’ll use the same payload as before, i.e. the windows\shell_bind_tcp as we are only interested in training purposes, so our final code will look like this:

And voila! I sometimes runs into issue when running the shell code on the target machine and it seems due to bad bytes in the shell, so this is something I’ll need to check out, i.e. how to determine which bytes should be avoided in the shell code. I usually fix it by regenerating a new payload in Metasploit. In any case, we have out shell:

Listening on port 4444
The exploit binded a shell on port 4444
Remote Shell from Exploiting PCMAN FTP 2.07
We successfully open a remote shell from the exploit in PCMAN FTP 2.07

All right, so now, we should be able to exploit basic buffer overflows from any simple program. Let’s move on…

Starting in Exploit Development – Day 03


Today I’ve followed part 3 of the FuzzySecurity tutorial, which went pretty smoothly now that all the VMs and software have been setup and fixed. In the end, I was successful in binding a shell to a port. Yet, I had the feeling that I often have when learning by tutorial: it works now, but would I actually be able to replicate this while exploiting another application? And what really happened? I mean I have loaded my shell code, but yet, I don’t have a clear understanding of what SEH really is. So after completing the tutorial, I actually took time to try to figure out what exactly happened.

The Structure Exception Handler (SEH)

The SEH is a Windows native mechanism to handle both hardware and software exceptions in Windows at both kernel and user spaces. So when the normal flow of an application is interrupted, the SEH comes in to handle the management of the interruption. Basically, this is the native component of Windows which triggers the try…catch… statement you use in your programs. So how does SEH works?

SEH3 Stack Layout
The overall layout of the SEH in the stack (by Igor Skochinsky – 2006)

As depicted above, the SEH is a linked list in memory, in which each nodes contains 2 pointers; one pointer to the next node in the list and one pointer to the function who handles this specific exception. There is a node for each exception handled by the current function. These nodes are basically all your “catch (FileNotFoundException)…catch(NullPointerException)” etc…. Each node of the linked list stores the pointer to the Structure Exception Handler and a pointer to the next Structure Exception Handle. The root node, the default exception handler is actually stored in the stack. So in this tutorial, when we smash the stack, we gain control of those 2 pointers, which we will use to jump to our shell code.

So in this case, what is happening is that we smash the stack with “A”s, overwriting EIP with an invalid pointer (0x41414141). Since this is not a valid value, an “Illegal Instruction”/”Access Violation” exception is thrown and thus triggers the SEH handler code. This means the code pointed by the “SEH Handler” [SEH] part of the stack will be called, which is actually a call to the next node in the SEH linked list.

By writing an address pointing to “POP POP RET” instructions at [SEH] and having it executed them, we will load the stack address of [nSEH] into EIP and as such, execute the op code at [nSEH]. So if we insert a short JMP to the address of our shell code (0xEB06 [shellcode]) at the address pointed by [nSEH], we’re done.

This technique won’t work with SafeSEH and SEHOP.

Moving on with Exploiting DVDX Player

You should have no issue generating the Playlist file to overflow the EIP register and trigger a exception.

Crashing EIP of DVDX Player
Crashing DVDX Player by overflowing EIP with a specially crafted playlist

Then by replacing the long string of “A” by a Metasploit pattern and !mona findmsp, we can find the offsets, as in past tutorials;

Offsets calculated by Mona when exploiting DVDX Player
Mona located the Metasploit pattern overwritting the SEH record at 608 bytes and 1384 bytes for our payload

Since we’re interested in exploiting SEH in this tutorial, we’re interested at which offset  the SEH is being overwritten by the Metasploit pattern. In this case, it’s overwritten at 608 bytes and we have 1384 bytes of buffer for our shell code. That means that the nSEH is at 608 bytes and SEH at 612: “A”*608 + [nSEH] + [SEH] + [Shellcode].

To link with what we’ve read in the first section, here is what happens: Our string of 608 “A” will crash the EIP and cause an exception, jumping directly to the contents of [SEH]. [SEH] must contain an address. [SEH] is located at [ESP]+8 at execution. Remember that the ESP is an indirect pointer to the top of the stack, and the stack grows downwards. By POPping two times and returning, we will load the stack address of [nSEH] into the EIP and execute whatever instruction at this address. To be perfectly honest, I’ll need to further understand this part….

Accordingly, we will look in memory for a “POP POP RET” combination using “!mona seh“. Mona will return quite a few results. We will prefer results located in DLLs owned by DVDX Player, since they are OS-independent.

Using Mona to locate POP-POP-RET to defeat SEH
Mona returns multiple POP-POP-RET combination to defeat SEH.

We’ve picked up 0x640345e7 (“\xe7\x45\x03\x64”) since it’s located within DVDX Player and contains no invalid bytes. We now got the [SEH] part of our payload:

Now for [nSEH], we’ll need to put a “jmp [offset]” instruction in it.  Our shell code begins right after the [SEH] (4 bytes) and our jmp instruction is 2 bytes. The short jump op code is 0xEB, followed by the number of bytes to jump from EIP, i.e. 6 bytes. So the instruction to insert at [nSEH] is “\xeb6\x90\x90”:

All that is left is the shellcode, which is a quick NOP slide and a shell bind. Done! Excited, I plug the payload into DVDX Player and fail miserably to have have the shell code executed. I used the same shell code as the previous tutorial in an attempt to minimize the number of things that can go wrong. By doing so, everything went wrong. Well not exactly everything, but the previous shell code had byte “0x1A” in it, which created additional READ exception in the code once the shell code loaded. So I regenerated the code without bytes 0x00, 0x0A, 0x0D and 0x1A and everything went perfect. Or almost. When running the shell code, Windows asked me to unblock port 4444 to listen to inbound connection. I guess using a reverse shell or a “download and execute” is quieter…

Windows Asking to Unblock DVDX Player
Using a shell_bind_tcp payload will result in Windows asking you to unblock the application you are exploiting.

I wonder if anything I wrote made any sense since I’ve been so focus into this exploit today. The ascii diagram from FuzzySecurity summarize the principle well enough:

Summary of the SEH Exploitation Technique
Summary of the SEH Exploitation Technique from FuzzySecurity (c) b33f
Well enough for today, my frontal lobe is overheating. More tomorrow…

[1] “Structured Exception Handling.” Windows Dev Center. (accessed March 15, 2014).

[2] Skochinsky, Igor. “Reversing Microsoft Visual C++ Part I: Exception Handling.” OpenRCE. (accessed March 15, 2014).

[3] Mariani, Brian. “Structured Exception Handler Exploitation.” Exploit-db. (accessed March 15, 2014).

Starting in Exploit Development – Day 02


Using Kali and Virtual Box Guest Additions

Hopeful that I’ll waste a lot less time than yesterday, I’ve setup a Kali virtual machine. I had one problem while installing: as soon as the actual installation started, I had a “The failing step is ‘Install the System'” error message. This was solved when I created a 15GB Virtual Hard Drive (VHD) rather than a 10GB Virtual Box Drive. I also had to setup Kali so it works with VirtualBox Guest Additions. You’ll first need to update the sources in /etc/apt/sources.list by including the second repositorty(;

Once done, update the package lists by running apt-get update and then install the the linux-headers for Kali:

Finally, install the guest additions as described in the Kali FAQ [1]….and realize it doesn’t work. According to the log file, 2 errors occured:

This can be solved by using the latest version of VirtualBox. Once I’ve upgraded to 4.3.8, I was able to compile the Guest additions with no trouble.

The Fun Finally Begins…Exploitin’

Continuing Part 2 of Fuzzy Security exploit tutorial. So now, I can finally use the pattern_create.rb script to find out at which position in the payload I need to put the return address in EIP. In the latest version of Metasploit, pattern_create.rb is in the following directory:

After creating the pattern and putting it in the python script, the EIP registers overflows with value 0x69413269, which correspond to offset 247 of the payload.  So far so good.

Metasploit Pattern in EIP
Metasploit Pattern in EIP
Offset Required to Overwrite EIP
Using to find the offset of the Metasploit pattern required to overwrite EIP

Once confirmed, then we need to redirect the program’s execution flow to the ESP, the stack pointer, according to tutorial of Fuzzy Security. Good enough, but why ? Well the ESP always points to the top of the stack, which contains an address. If you look at the screenshot above, you’ll notice that the address contained in ESP, 0x00C7FC2C contains our “C”s, i.e. a value we control as well.

ESP Overwritten with "C"s
ESP Overwritten with “C”s, indicating we can place our shellcode at ESP

So if we replace those “C”s with our shellcode, our objective will be to find a way to jump to the address contained in ESP. To do so, we will find an “jmp esp” instruction in memory, and put the address of the instruction in EIP – the register that contains the address of the next instruction to execute.Use “mona jmp -r esp” to locate the JMP instruction. Once Mona is finished, select View -> Log to see the result.

Pointers to a "jmp esp" instruction
Results of the search for pointers to a “jmp esp” instruction

The results I have differs from the one of the tutorials. Shouldn’t be an issue, so I’ll take the one in “ntdll.dll” (0x7C91FCD8) as it seems to be a stable DLL. In little endian form, it becomes “\xD8\xFC\x91\x7C”. To test if it works, you’ll need a breakpoint at whatever address you are pointing, otherwise the execution flow will just land somewhere in memory. To add a breakpoint, right click in the CPU view, select “Go to” -> “Expression” and in the window, type your address (big endian). After you clicked OK, you should land on your address. Then press F2 to toggle the breakpoint at this location.

Following an address in memory using Immunity Debugger
Right click on the main CPU view, select “Go To”, “Expression” and type the address.

So we have verified it worked, we can now move on. I won’t fray to far from the tutorial and just generate a local shell bind payload on port 13373. To do, we’ll need the following Metasploit tool:

Basically what this command does is generate the shellcode for binding a shell on port 13373. It then encodes it in bytes without using bytes 00, 0A and 0C. “\x00” is a terminator value for strings. If included in the shellcode, it will break the code. The same goes with 0A and 0D, which are the “New Line” and “Carriage Return” values (i.e. chr(10), chr(13)). The “-t py” option specifies that the output will be formatted in Python. I thought I could almost conclude this session, but of course, I had to hit one more hiccup. After running the exploit, the debugger throw an “Illegal Instruction” exception at 0x00C7FC28, where the first byte of the shell code is.

I’ve wonder many minutes about this issue. I’ve decided to just plain follow the tutorial and choose the same port, 9988 and regenerate the shell code. To my astonishment, the new shell code worked! The first byte is different, but I’m still not sure why the new code works while the other don’t. More to follow…

In any case, the exploit worked and opened port 9988 on the target machine, which can be connected with netcat.

[1] “Kali Linux Virtual Box Guest.” Kali Linux Official Documentation. (accessed March 14, 2014).

Starting in Exploit Development – Day 01


I’ve always seen exploit research and development has the pinnacle of computer security, the ultimate black art of hacking, probably because writing exploit requires full understanding of low-level memory and CPU operations. And given the complexity required nowadays to not only find a vulnerability, but actually exploit it, given protection such as DEP, ASLR and EMET, keeps amazing me. Just tonight, a Chinese team successfully pwned Safari and Flash at the annual Pwn2Own[1]. They could have make serious money on the black market with these two exploits. So I asked myself recently: why don’t I start learning exploit development? There’s certainly a future in it.

As such, I’ll be starting at the bottom and follow the Fuzzy Security tutorials, which seems quite detailed. Today, I’ll be following part 1 and part 2, using a virtualized Windows XP 32-bit box. I’ve downloaded Immunity Debugger and and Metasploit, filling out those pesky registration form. Of course if you are not aware yet, use FakeNameGenerator and 10 Minute Mail, which work for all these sites. I’ve skipped since it wasn’t available for download anymore. You’ll also need Python 2.7+ for Immunity Debugger.

Basically, I have a quick setup of 2 virtual machines; one runs Windows 7 64-bit with Metasploit 4.8.2-1 and Python 2.7.6, the one is a Windows XP SP3 32-bit machine with Immunity Debugger, the script and the vulnerable FreeFloat FTP. With VirtualBox, I’ve set a Host-Only Adapter on both machines on the same virtual network. Copy the into the C:\Program Files\Immunity Inc\Immunity Debugger\PyCommands folder. If you’re using something else than Backtrack or Kali, you’ll need to download and install a Ruby interpreter and the Development Kit to use the pattern_create.rb of Metasploit. When installing Ruby, make sure you select “Add Ruby executables to the environment path”. Finally, once you have, you need the “bundler” package for Metasploit. Within the Development Toolkit, run the “devkitvars.bat” file. This will add the DevKit to your PATH. Simply type “gem install bundler” and you should be on your way. Or so I thought…

Metasploit then complains it cannot find the rake-10.1.0 sources….What a pain.  That’s because the version or Ruby I’ve install contains Rack version 10.1.1 instead of version 10.1.0. To install the correct version use the following;

This will install the correct version. Unfortunately, the same problems happens with additional packages. After trying to install each of them manually, I got tired of it, so I try the “bundle install” command, which needs to be execute from “C:\metasploit\ruby\bin” folder;

WTF? I’m pretty sure I’ve just install this…whatever, let’s try again…

Dammit…After some Googling I find a forum post that recommends to try a few commands to clean the packages:

After a few seconds, seems that new packages are installed. I’m hopeful that I can finally start exploiting stuff…

At this point, I just give up and install every damn packages I need manually. After 10 minutes of this I just rage quit when the network_interface-1.0.0 package kept failing to install. I’ve downloaded an ISO of Kali. The only success I had tonight was overflowing the EIP register…guess I have a long way to go…

Overflow of EIP

[1] Mimoso, Michael. “Keen Team of China Takes Down Safari and Flash at Pwn2Own.” Threatpost English Global. (accessed March 13, 2014).

Firefox Javascript Vulnerability


Once again, Javascript is the source of a new exploit that has been recently discovered on Firefox1. The vulnerability can be exploited by crafting malicious Javascript code on a Firefox 3.5 browser and leads to the execution of arbitrary code on the user’s machine. This is due to a vulnerability in the JIT engine of Firefox and affects machine running a x86, SPARC or arm architectures.

The vulnerability resolves around the return value of the escape function in the JIT engine. It’s exploited using the <font> tag. The code for the exploit is public and can be found at milw0rm. The exploit use a heap spraying technique to execute the shellcode.

A fix should be available soon, but the best solution is always to disable Javascript, although a lot of sites rely on it to operate. Another way is to use the NoScript plug-in, which let you enable and disable scripts easily according to a whitelist/blacklist system.

See also:

Mozilla Firefox Memory Corruption Vulnerability”, Secunia, July 14, 2009, accessed on 2009-07-15

Exploit 9137”, SBerry, July 13, 2009, accessed on 2009-07-15

Stopgap Fix for Critical Firefox 3.5 Security Hole”, Brian Krebs, The Washington Post, July 14, 2009, accessed on 2009-07-15

Critical JavaScript vulnerability in Firefox 3.5”, Mozilla Security Blog, July 14, 2009, accessed on 2009-07-15

1 “Mozilla Foundation tackles Firefox bug”, Nick Farell, The Inquirer, Wednesday, 15, July, 2009, accessed on 2009-07-15