Fuzzing VIM

AAAAAAAAAA....: It's almost a year now I started with fuzzing and discovered multiple bugs. The most commonly software which I've fuzzed so far includes Xpdf, VIM, PuTTY, WebKit, LibreOffice, Glibc etc. In this post I'll be demonstrating fuzzing VIM (Regex engine) through AFL++ a.k.a american fuzzy lop.

Technical Details: VIM a.k.a Vi IMproved has 12 different editing modes which can be utilized for fuzzing. Vim has lots of potential for finding bugs with AFL. One of the bug which I found while fuzzing VIM was CVE-2019-20079, I would also like to thank Dominique Pelle for this.

[+] Git clone VIM
cmd$ git clone https://github.com/vim/vim.git ; cd vim

[+] Compile and Make VIM with AFL++ 
cmd$ CC=afl-clang-fast CXX=afl-clang-fast++ ./configure --with-features=huge --enable-gui=none
cmd$ make -j4 ; cd src/

[+] Feed Corpus
cmd$ mkdir corpus ; mkdir output 
cmd$ echo "a*b\+\|[0-9]\|\d{1,9}" > corpus/1 ; echo "^\d{1,10}$" > corpus/2

[+] Fuzzing VIM
cmd$ afl-fuzz -m none -i corpus -o output ./vim -u NONE -X -Z -e -s -S @@ -c ':qa!'

The above options used -u NONE and -X is to speed up vim startup. Options -e -s are used to make vim silent and to avoid 'MORE' prompt which could block VIM, the option -Z disables the external commands which makes fuzzing safer. I've also created a small bash script which automates the above tasks for you [vimfuzz.sh].

While fuzzing, fuzz it on ram file system to avoid making too much I/O something like:  sudo mount -t tmpfs -o size=6g tmpfs /home/afl-fuzz-user/afl-fuzz. Aside you can use [pack.sh] a script which contains some standard ubuntu packages so you dont get much dependence issues while compiling any target. Keep fuzzing :)

Read More

PHDays - Fuzzing 101

So, this year (2019) me along with my colleague Zubin delivered a workshop in PHDays 9 on fuzzing. This workshop was mainly focused on an introduction to fuzzing using AFL and ASAN.

The prime focus of the workshop would be around the following areas: Fuzzing using SPIKE, blind and input-based fuzzing (AFL), finding memory bugs using ASAN with AFL integration, protocol fuzzing (HTTP, FTP, SMTP). Then we concluded the workshop by showcasing multiple bugs found during their research.



Slides: Fuzzing-101_PHDays.pdf

Ubuntu OVA file: Ubuntu_Fuzzing101.ova  : Size: 4.x GB, 4GB RAM, 40 GB HD.
Username: PHDays
Password: E@sy

We have further plans to take an advanced workshop on this in other conferences. Fork this repository on GitHub. If you want to read more about fuzzing here is what I wrote while fuzzing WebKit.

Read More

Fuzzing Webkit

Summary: While fuzzing webkit the UIProcess subsystem in WebKit, as used in WebKitGTK through 2.23.90 and WebKitGTK+ through 2.22.6 and other products, does not prevent the script dialog size from exceeding the web view size, which allows remote attackers to cause a denial of service (Buffer Overflow) or possibly have unspecified other impact, related to files such as UIProcess/API/gtk/WebKitScriptDialogImpl.cpp and UIProcess/API/gtk/WebKitWebViewGtk.cpp.

System Specifications: My setup was done using Ubuntu 16.04 LTS (my base OS). You can use macOS as well as it has Xcode and Safari by default. If you are using Ubuntu in VM please allocate as much memory and CPUs as possible.

Source Code: You can download webkit source code from here or simply git:

cmd: git clone git://git.webkit.org/WebKit.git webkit 

Before you build webkit make sure to install necessary dependencies, it will require a lot of trial and error while installing the dependencies but perseverance always wins.

cmd: ./Tools/gtk/install-dependencies

Build: To build webkit in macOS use,

cmd: ./Tools/Scripts/build-webkit  

cmd:   mkdir build
          cd build
          CC=clang CXX=clang++ cmake -GNinja -DFUZZ=1 ../
          ninja

For ASAN:

Enabling ASAN or MSAN flags to see runtime bugs while building the packages.

cmd: -DCMAKE_CXX_FLAGS="-fsanitize=address  -fsanitize=leak -g"

The compilation of webkit is a time and memory consuming task, make sure you don't run out of patience. Once successfully build you can test by running safari or providing the path of any webkit application.

cmd: ./Tools/Scripts/run-safari

cmd: ./Tools/Scripts/run-webkit-app 

Start fuzzing: From the /build directory you can run fuzzer[1]

cmd: ./fuzz/cert -max_len=1000 -jobs=32 -workers=32 ../fuzz/cert_corpus/

This is one of the methods to fuzz webkit, while running the libFuzzer continuously for multiple days, I did not observe any crashes or hangs. The reason being there are many researchers out there who have fuzzed webkit and reported several bugs in past. (and I've just started..)

Now what?

I started researching more about webkit and found out that "epiphany-browser" utilizes the webkit browser engine, I thought that this browser might have been untouched in terms of fuzzing by a lot of the researchers, hence this time I used AFL to fuzz epiphany. For test-cases, I used domato from google project zero (A DOM fuzzer) to provide input to AFL

Source code: Epiphany Browser

With AFL: 

cmd: mkdir build && cd build 
        CC=afl-gcc meson --default-library=static ../
        AFL_HARDEN=1 ninja

Once done you can start fuzzing epiphany with AFL.

cmd: afl-fuzz -i in/ -o out/ binary @@ 

I let AFL running for 4 days and observed 16 crashes, among those 7 were unique crashes and 4 were hangs (Happy face). I started analyzing the observed hangs. One of the PoC from AFL freezes the epiphany browser by causing the UI process to terminate and below debug traces were left.

(epiphany:4423): Gdk-WARNING **: Native Windows wider or taller than 32767 pixels are not supported
Gdk-Message: Error 71 (Protocol error) dispatching to Wayland display

Looking at the above traces I came to the conclusion that the native UI window cannot open dialog boxes more than 32767 pixels.

Rather than using AFL PoC every time, I generated my own test-case as I just needed to pass some random characters in native UI windows to produce this hang.

<script>
   var a = '';
   for (var i = 1; i <= 5000; i++)
    {
       a += 'A';
    }
   alert(a);
</script>

You can run the above JS on a vulnerable version of epiphany browser to test this issue. I went ahead and found that WebKitScriptDialogGtk.cpp along with WebKitScriptDialogImpl.cpp &  WebKitWebViewGtk.cpp from webkit source code are responsible for this issue and figured out the below snippet of code from WebKitScriptDialogGtk.cpp was the source of the vulnerability.

static GtkWidget* webkitWebViewCreateJavaScriptDialog(WebKitWebView* webView, GtkMessageType type, GtkButtonsType buttons, int defaultResponse, const char* primaryText, const char* secondaryText = nullptr)
{
    GtkWidget* parent = gtk_widget_get_toplevel(GTK_WIDGET(webView));
    GtkWidget* dialog = gtk_message_dialog_new(WebCore::widgetIsOnscreenToplevelWindow(parent) ? GTK_WINDOW(parent) : nullptr,
        GTK_DIALOG_DESTROY_WITH_PARENT, type, buttons, "%s", primaryText);
    if (secondaryText)
        gtk_message_dialog_format_secondary_text(GTK_MESSAGE_DIALOG(dialog), "%s", secondaryText);
    GUniquePtr<char> title(g_strdup_printf("JavaScript - %s", webkitWebViewGetPage(webView).pageLoadState().url().utf8().data()));
    gtk_window_set_title(GTK_WINDOW(dialog), title.get());
    if (buttons != GTK_BUTTONS_NONE)
        gtk_dialog_set_default_response(GTK_DIALOG(dialog), defaultResponse);

    return dialog;
}

After that I submitted this bug in webkit, the issue was patched and  CVE-2019-8375 was assigned which states "This allows remote attackers to cause a denial of service (Buffer Overflow) or possibly have unspecified other impact."

Metasploit module: It is a denial of service vulnerability and you can simply use RemoteHTTPServer to write a quick MSF module for this.
In the past, I have created BFuzz (DOM Fuzzer) which automates the task of generating multiple test-cases using domato, which can be further used to fuzz browsers of your choice.

However, there are still 7 unique crashes and 3 hangs which I haven't analyzed yet, that may be covered in one of my upcoming blog posts.

Read More

null-pointer dereference in poppler library - CVE-2018-19149

Hi Internet,

Summary: While fuzzing evince v3.28.4, on linux 4.15.0-38-generic (Ubuntu 18.04 LTS), a null-pointer dereference was observed, initially this was reported to evince but the evince team advised that the issue is in poppler, the library used by evince to render PDF, poppler version: 0.62.0-2ubuntu2.2 is vulnerable to null-pointer dereference, however the issue is already fixed in poppler 0.70, but this will still crash your evince v3.28.4 if poppler is not updated to v.0.70. Fuzzing result showing a very important vulnerability in a package currently shipped by a major Linux distribution is still of interest, even if that Linux distribution does not package the latest released upstream version.

Initially, I started fuzzing with evince which is a document reader which comes by default with most of the linux distribution. Also created a malformed PDF files to provide input to AFL, after a successfully compile of evince with afl-gcc, the final command was,

It took three days to get 21 crashes in which 6 unique crashes where observed, while analyzing the crash with triage_crashes which is one of the component which comes with AFL for analyzing crashes, I observed a null-PTR.

So basically a null-PTR is a type of error which causes a SIGSEGV, segmentation fault to the program, and this usually happens when a program or binary try to read or write to the memory with null-PTR.

I went ahead and reported this to GNOME, because evince is one of there asset, the team says "The issue is in Poppler, the library used by Evince to render PDF" arggh!, so stupid am I, I taught `libpoppler-glib.so` is one of the shared object in evince but didn't know that poppler is a PDF rendering library which comes by default in most of the PDF reader in linux distribution, and there is a standalone repo out there for poppler.

Also, GNOME evince team says "it seems it has already been addressed. See https://gitlab.freedesktop.org/poppler/poppler/merge_requests/93, Nevertheless, if the issue is still present, please file a bug in https://gitlab.freedesktop.org/poppler/poppler/"

Okay no worries, I still went ahead and file a bug in poppler, but the team over there asked me what poppler version am i using, and it was version 0.62.0-2ubuntu2.2 and they said the issue is already fixed in poppler version 0.70 After I read this, I was like....

Img Src: https://knowyourmeme.com/photos/1189534-canada

Pheww!, does that mean, my three days of fuzzing just went = to 0 OR am I actually missing something over here ?

I went back to the stack-trace read it again and also check whether am I fuzzing all the latest build of the binary for sure I was fuzzing the latest build of evince but not poppler. Hmmmmmm! I knew my fuzzing system was fully updated but still just to cross check, I did full apt-get update and upgrade but my poppler version remains the same all the time which is 0.62.0-2ubuntu2.2 strange.

I need a guidance over here, and didn't knew what to do ahead, so I contacted MITRE for this and went for a nap, they suggested - "That a fuzzing result showing a very important vulnerability in a package currently shipped by a major Linux distribution is still of interest, even if that Linux distribution does not package the latest released upstream version. For example, an out-of-bounds write finding is still very useful in that case, but not out-of-bounds read, NULL pointer dereference,divide-by-zero, etc."

Ohhh, I see so the latest version of poppler is still not shipped for most of the linux distribution out there, now i understood the entire concept, later MITRE also helped me by assigning a CVE to this issue which is CVE-2018-19149 - Poppler before 0.70.0 has a NULL pointer dereference in _poppler_attachment_new when called from poppler_annot_file_attachment_get_attachment.

An upstream bug is filed in Ubuntu launchpad to track this issue. 

PS: Its not about collecting CVE's, CVE's are just a reference number to an issue you can point for a vulnerability when you show case it somewhere, rather than pointing it to various post. (Personal opinion).

Lessons learned from this:
1. I didn't know poppler is a library which is used by evince and other PDF reader to render PDF's.
2. I understood how to create a malformed PDF to provide input to AFL while fuzzing.
3. The reply from MITRE helped me to resolve my query.
4. During all this, I also got my hands on hongfuzz

Hope you like the read, view this on oss-security mailing list.

Thank you
Dhiraj

Read More