Today I would like to share some insights on the bug CVE-2015-7292 affecting Amazon Fire Phone that I discovered some months ago and resp. disclosed to the Amazon Security Team for remediation.

Amazon has already patched the vulnerability and rolled out the update so I can freely disclose details. Due to Fire Phone’s automatic update system , which runs automatically in background, the majority of the devices will be patched much quicker than on other mobile phones.

We already demoed the vulnerability at HITB GSEC without disclosing details since it was still under remediation by Amazon.

Current State of Privilege Escalation on Android - HITB GSEC 2015

The kernel sources for this and other Amazon devices is available for auditing in various places, including the Amazon website. Here for example

As soon as I got my hands on the source code, I looked for some customization in the kernel and a device called /dev/hv caught my attention. It turns out this device is reachable from the application sandbox. Needless to say, I headed straight to the underlying the code.

After not too much digging I found the code inside drivers/staging/havok/havok.c . This code will handle the usual "fops" actions that you have on this kind of devices, read, write, ioctl ...

This device seems a customization added by Amazon to introduce another logging component in the kernel (is that a good idea?).

The vulnerability was obvious to spot, actually it would be hard to find a simpler one on modern Android devices:

static ssize_t havok_write(struct file *filp, const char *buffer,
            size_t length, loff_t *offset)
    char tbuf[32];
    unsigned int cmd;
    pid_t pid;

    if (copy_from_user(tbuf, buffer, length))
        return length;

If you didn’t catch it right away, notice that the tbuf is just 32 bytes, but the copy_from_user has a unbounded length that is actually set when you do a write on that character device.

So you can overflow the tbuf buffer, obtaining a traditional “text book” stack based buffer overflow.

If you write more than the expected length, you can corrupt the adjacent memory. Unfortunately this device is world writable, and the Amazon Fire OS is a customized Android 4.4 version, so you can’t expect that SELinux is very strong and that will save your day, protecting you from an attacker with code execution within some sandboxed environment, such as APP, or browser.

You can click here to check a video demo on YouTube:

Video Demo

You can reproduce the issue just by peforming this command as a poc


You will see the kernel panic and the device reboot, because the poc overwrote the buffer, corrupting the content right after.

Luckily for Amazon users, there’s still a mitigation holding, which is a stack cookie that prevents easy exploitation, requiring another infoleak bug to leak the canary.

Those bugs are actually real in the linux kernel in the forms of out of bound read or even arbitrary memory read, and in OEM customized code are obviously more abundant than in the kernel core, which is just a subset.

If you examine the compiled vulnerable kernel you will see the standard canary pattern, with the canary placed after the tbuf buffer to protect the data after on the stack, and then checked at function exit. I don’t have handy now that kernel image so I will not post the disassembled code, but feel free to check that a stack canary it’s really there.


  • 2015/9/7 The bug is reported to with 30 days deadline since the fix was trivial.
  • 2015/9/8 The bug is received and put into Amazon investigation queue.
  • 2015/9/9 The bug is aknowledged and I started discussing with Amazon Security Team.
  • 2015/9/29 Video call with Amazon Security Team, we agreed to postpone indefinetly the disclosure, since they are not simply fixing the issue, but reworking the entire code.
  • 2015/10/15 The bug/issue is mentioned at HITB GSEC, with a PoC, but no details are disclosed.
  • 2015/10/23 A regression is found in the product after the changes, so it’s not possible yet to ship the update. In the meanwhile I try to request a CVE from MITRE.
  • 2015/11/4 Testing seems to proceed, but I haven’t got any response back from MITRE. Amazon Security team will try to ask a CVE for the issue, hoping for a faster MITRE response.
  • 2015/11/20 After at least 3 or 4 total (me plus the team) unsuccessful tries, MITRE assigned us CVE-2015-7292
  • 2015/12/18 Carriers found an additional issue in the changes
  • 2016/01/08 The update testing is finally complete and it will be distributed.

Take aways:

  • OEM customizations are bad and source of vulnerabilities. See our talk here for more
  • Amazon Automatic background updates (similar to Chrome Desktop Browser actually) can be, in my opinion, potentially good also applied to the Mobile ecosystem, since it automatically upgrade your phone. Which is good especially for unexperienced users, or simply users that doesn’t care.
  • MITRE and CVE is really a ancient style and inefficient system for vulnerability enumeration. If you are not a big player, good luck getting a CVE without doing backflips. For this issue Amazon helped, otherwise I would have given up getting a CVE since I don’t personally care about them. But they are good for the community, for sharing and to clearly define the case at hand. Imagine how many potential CVE went untracked simply because MITRE is ignoring people and the system is not scaling. I think the security community can and should do better than this.