thejh

diff -rupN afl-0.31b/afl-fuzz.c afl-0.31b-modded/afl-fuzz.c
--- afl-0.31b/afl-fuzz.c	2014-09-12 08:33:20.000000000 +0200
+++ afl-0.31b-modded/afl-fuzz.c	2014-09-29 13:35:15.876019069 +0200
@@ -19,12 +19,14 @@
  */
 
 #define AFL_MAIN
+#define _GNU_SOURCE
 
 #include "config.h"

thejh

  400545:	48 8b 55 f8          	mov    rdx,QWORD PTR [rbp-0x8]
  400549:	64 48 33 14 25 28 00 	xor    rdx,QWORD PTR fs:0x28
  400550:	00 00 
  400552:	74 05                	je     400559 <main+0x33>
  400554:	e8 a7 fe ff ff       	call   400400 <__stack_chk_fail@plt>

thejh

I made a PoC that shows one possible way to exploit this. Use a Tahoe-LAFS instance that is connected to the testnet, browse to different URLs in the testnet, then navigate the same tab to this URL:

http://localhost:3456/file/URI%3ACHK%3A6hxsjrbtiyjohpj7i7bn6dqixi%3Ail3humxxej53gg6bpr3l5ecxrqdg6wnd5ceuq33vqtrivvrhlfeq%3A1%3A6%3A1262/@@named=/historysteal.html

Click anywhere on the page. The following attack will happen:

-------------------------
The evil HTML file opens itself in a second tab using "window.open(location.toString(), 'foo')" (requires a click to bypass popup blockers). Then the evil HTML file in the second tab can
access the first tab using "window.opener". The evil second tab does this again and again:

thejh

#define _GNU_SOURCE
#include <jh.h>
#include <string.h>
#include <arpa/inet.h>
#include <assert.h>
#include <fcntl.h>

   /* Table of CRCs of all 8-bit messages. */
   unsigned long crc_table[256];
   

thejh

#define _GNU_SOURCE
#include <dlfcn.h>
#include <string.h>

int system(const char *cmd) {
  static int (*realsystem)(const char *);
  if (!realsystem) realsystem = dlsym(RTLD_NEXT, "system");
  if (strchr(cmd, ';') || strchr(cmd, '`') || strstr(cmd, "&&") || strstr(cmd, "../")) {
    return 1;
  }

thejh

When unpacking packages, there's a race that allows putting lib*.so files w=
ith standard permissions
into all kinds of places where they shouldn't be. How to exploit:

 - let your app move its "lib" directory away (or delete it if it's empty)
 - let your app create a new "lib" directory (owned by the app)
 - run something like this in the background while the user is installing a=
n update containing evil shared objects:

       while ls -ld lib|grep app_68 > /dev/null; do true; done; mv lib lib-=

thejh

Android reuses UIDs, and IMO, it shouldn't do that, at least not without having rebooted once.
Reasons:

 - the deinstallation process doesn't kill all processes with the UID of the app, and neither does
   the installation process - therefore, an app can gain higher privileges by tricking the user
   into uninstalling it and then installing another app with higher privileges
 - there are app-writable filesystems which aren't protected against suid executables, so an app
   could drop a suid-shell in one of those filesystems and thereby allow other malicious apps to
   obtain full access to whatever app will be the next one to get assigned the uid (all filesystems
   without nosuid, except for rootfs, seem to be temporary, so a reboot should wipe all suid executables)

thejh

thejh

EDIT: changed the domain names for public disclosure

Have a look at /data/data/com.android.browser/databases/webview.db, table "password".

columns: _id, host, username, password

"host" contains protocol and hostname concatenated without any delimiter. What this means:

 - login to https://example.org/ with valid username and password
 - go to http://sexample.org/

thejh

Content-Type: multipart/mixed; boundary="LpQ9ahxlCli8rRTG"
Content-Disposition: inline


--LpQ9ahxlCli8rRTG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello,
two more pretty interesting issues (verified both on my phone):