02/05/2016

QSEE privilege escalation vulnerability and exploit (CVE-2015-6639)

In this blog post we'll discover and exploit a vulnerability which will allow us to gain code execution within Qualcomm's Secure Execution Environment (QSEE). I've responsibly disclosed this vulnerability to Google and it has been fixed - for the exact timeline, see the "Timeline" section below.

 The QSEE Attack Surface

 

As we've seen in the previous blog post, Qualcomm's TrustZone implementation enables the "Normal World" operating system to load trusted applications (called trustlets) into a user-space environment within the "Secure World", called QSEE.

This service is provided to the "Normal World" by sending specific SMC calls which are handled by the "Secure World" kernel. However, since SMC calls cannot be invoked from user-mode, all communication between the "Normal World" and a trustlet must pass through the "Normal World" operating system's kernel.

Having said that, regular user-space processes within the "Normal World" sometimes need to communicate with trustlets which provide specific services to them. For example, when playing a DRM protected media file, the process in charge of handling media within Android, "mediaserver", must communicate with the appropriate DRM trustlet in order to decrypt and render the viewed media file. Similarly, the process in charge of handling cryptographic keys, "keystore",  needs to be able to communicate with a special trustlet ("keymaster") which provides secure storage and operation on cryptographic keys.

So if communicating with trustlets requires the ability to issue SMCs, and this cannot be done from user-mode, then how do these processes actually communicate with the trustlets?

The answer is by using a Linux kernel device, called "qseecom", which enables user-space processes to perform a wide range of TrustZone-related operations, such as loading trustlets into the secure environment and communicating with loaded trustlets.



However! Although necessary, this is very dangerous; communication with TrustZone exposes a large (!) attack surface - if any trustlet that can be loaded on a particular device contains a vulnerability, we can exploit it in order to gain code execution within the trusted execution environment. Moreover, since the trusted execution environment has the ability to map-in and write to all physical memory belonging to the "Normal World", it can also be used in order to infect the "Normal World" operating system's kernel without there even being a vulnerability in the kernel (simply by directly modifying the kernel's code from the "Secure World").

Because of the dangers outlined above, the access to this device is restricted to the minimal set of processes that require it. A previous dive into the permissions required in order to access the driver has shown that only four processes are able to access "qseecom":
  • surfaceflinger (running with "system" user-ID)
  • drmserver (running with "drm" user-ID)
  • mediaserver (running with "media" user-ID)
  • keystore (running with "keystore" user-ID)

This means that if we manage to get a hold of any of these four processes, we would then be able to directly attack any trustlet of our choice, directly bypassing the Linux kernel in the process! In fact, this is exactly what we'll do - but we'll get to that later in the series.

For this blog post, let's assume that we already have code-execution within the "mediaserver" process, thus allowing us to directly focus on the attack surface provided by trustlets. Here's an illustration to help visualise the path of the exploit chain we'll cover during the series and the focus of this post:



Vulnerability Scope


I haven't been able to confirm the exact scope of this issue. I've statically checked quite a few devices (such as the Droid Turbo, Nexus 6, Moto X 2nd Gen), and they were all vulnerable. In fact, I believe the issue was very wide-spread, and may have affected most Qualcomm-based devices at the time.

So why was this issue so prevalent? As we'll see shortly, the vulnerability is contained in a trustlet and so does not rely on the TrustZone kernel (which tends to change substantially between SoCs), but rather on code which is designed to be able to execute in the same manner on many different devices. As such, all devices containing the trustlet were made vulnerable, regardless of their SoC.

Also note that on some devices the vulnerable code was present but appeared slightly different (it may have been an older version of the same code).  Those devices are also vulnerable, although the indicators and strings you might search for could be slightly different. This means that if you're searching for the exact strings mentioned in this post and don't find them, don't be dissuaded! Instead, reverse-engineer the trustlet using the tools from the previous blog post, and check for yourself.

Enter Widevine


Previously, we decided to focus our research efforts on the "widevine" trustlet, which enables playback of DRM encrypted media using Widevine's DRM platform. This trustlet seems like a good candidate since it is moderately complex (~125KB) and very wide-spread (according to their website, it is available on over 2 billion devices).

After assembling the raw trustlet, we are left with an ELF file, waiting to be analysed. Let's start by taking a look at the function registered by the trustlet in order to handle incoming commands:



As we can see, the first 32-bit value in the command is used to specify the command code, the high-word of which is used to sort the commands into four different categories.

Taking a peek at each of the category-handling functions reveals that the categories are quite rich - all in all, there are about 70 different supported commands - great! However, going over 70 different commands would be a pretty lengthy process - perhaps we can find a shortcut that'll point us in the right direction? For example, maybe there's a category of commands that were accidentally left in even though they're not used on production devices?

Since the libraries which are used to interact with the trustlets are also proprietary, we can't look through the source code to find the answers. Instead, I wrote a small IDAPython script to lookup all the references to "QSEECom_send_cmd", the function used to send commands to trustlets, and check what the "command-code" value is for each reference. Then I simply grouped the results into the categories above, producing the following results:


So... Nobody is using 5X commands. Suspicious!

Sifting through the functions in the 5X category, we reach the following command:



Pretty straight-forward: copies the data from our request buffer into a "malloc"-ed buffer (note that the length field here is not controlled by us, but is derived from the real buffer length passed to QSEOS). Then, the function's flow diverges according to a flag in our request buffer. Let's follow the flow leading to "PRDiagVerifyProvisioning":



Finally, we found a vulnerability!

After some simple validation (such as checking that the first DWORD in the command buffer is indeed zero), the function checks the value of the fourth DWORD in our crafted command buffer. As we can see above, setting that value to zero will lead us to a code-path in which a fully-controlled copy is performed from our command buffer into some global buffer, using the third DWORD as the length argument. Since this code-path only performs the vulnerable memcpy and nothing else, it is much more convenient to deal with (since it doesn't have unwanted side-effects), so we'll stick to this code-path (rather than the one above it, which seems more complex).

Moreover, you might be wondering what is the "global buffer" that's referred to in the function above. After all, it looks a little strange - it isn't passed in to the function at any point, by is simply referred to "magically", by using the register R9.

Remember how the trustlets that we analysed in the previous blog post had a large read-write data segment? This is the data segment in which all the modifiable data of the trustlet is stored - the stack, the heap and the global variables. In order to quickly access this segment from any location in the code, Qualcomm decided to use the platform-specific R9 register as a "global register" whose value is never modified, and which always points to the beginning of the aforementioned segment. According to the ARM AAPCS, this is actually valid behaviour:


What now?


Now that we have a primitive, it's time to try and understand which pieces of data are controllable by our overflow. Again, using a short IDAPython script, we can search for all references to the "global buffer" (R9) which reside after the overflown buffer's start address (that is, after offset 0x10FC). Here are the results:


Disappointingly, nearly all of these functions don't perform any "meaningful" operations of the controllable pieces of data. Specifically, the vast majority of these functions simply store file-system paths in those memory locations, which imply no obvious way to hijack control flow.

Primitive Technology


Since there aren't any function pointers or immediate ways to manipulate control flow directly after the overflown buffer, we'll need to upgrade our buffer overflow primitive into a stronger primitive before we can gain code execution.

Going through the list of functions above, we come across interesting block of data referred to by several functions:

As you can see above, the block of 0x32 DWORDs, starting at offset 0x169C, are used to store "sessions".  Whenever a client sends commands to the Widevine trustlet, they must first create a new "session", and all subsequent operations are performed using the specific session identifier issued during the session's creation. This is needed, for example, in order to allow more than a single application to decrypt DRM content at the same time while having completely different internal states.

In any case, as luck would have it, the sessions are complex structures - hinting that they may be used in order to subtly introduce side-effects in our favour. They are also within our line-of-fire, as they are stored at an offset greater than that of the overflown buffer. But, unfortunately, the 0x32 DWORD block mentioned above only stores the pointers to these session objects, not the objects themselves. This means that if we want to overwrite these values, they must point to addresses which are accessible from QSEE (otherwise, trying to access them will simply result in the trustlet crashing).


Finding Ourselves


In order to craft legal session pointers, we'll need to find out where our trustlet is loaded. Exploring the relevant code reveals that QSEOS goes to great lengths in order to protect trustlets from the "Normal World". This is done by creating a special memory region, referred to as "secapp-region", from which the trustlet's memory segments are carved. This area is also protected by an MPU, which prevents the "Normal World" from accessing it in any way (attempting to access those physical addresses from the "Normal World" causes the device to reset).

On the other hand, trustlets reside within the secure region and can obviously access their own memory segments. Not only that, but in fact trustlets can access all allocated memory within the "secapp" region, even memory belonging to other trustlets! However, any attempt to access unallocated memory within the region results in the trustlet immediately crashing.

...Sounds like we're beginning to form a plan!

We can use the overflow primitive in order to overwrite a session pointer to a location within the "secapp" region. Now, we can find a command which causes a read attempt using our poisoned session pointer. If the trustlet crashes after issuing the command, we guessed wrong (in that case, we can simply reload the trustlet). Otherwise, we found an allocated page in the "secapp" region.


But... How do we know which trustlet that page belongs to?

We already have a way to differentiate between allocated and unallocated pages. Now, we need some way to distinguish between pages based on their contents.

Here's an idea - let's look for a function that behaves differently based on the read value in a the session pointer:


Okay! This function tries to access the data at session_pointer + 0xDA. If that value is equal to one, it will return the value 24, otherwise, it will return 35.

This is just like finding a good watermelon; by "tapping" on various memory locations and listening to the "sound" they make, we can deduce something about their contents. Now we just need to give our trustlet a unique "sound" that we can identify by tapping on it.

Since we can only listen to differences between one and non-one values, let's mark our trustlet by creating a unique pattern containing ones and zeros within it. For example, here's a pattern which doesn't occur in any other trustlet:


Now, we can simply write this pattern to the trustlet's data segment by using over overflow primitive, effectively giving it its own distinct "sound".

Finally, we can repeat the following strategy until we find the trustlet:
  • Randomly tap a memory location in the "secapp" region:
    • If it sounds "hollow" (i.e., the trustlet crashes) - there's nothing there, so reload our trustlet
    • Otherwise, tap the sequence of locations within the page which should contain our distinct marking pattern. If it sounds like the pattern above, we found our trustlet

Of course, inspecting the allocation scheme used by QSEOS could allow us to speed things further by only checking relevant memory locations. For example, QSEOS seems to allocate trustlets consecutively, meaning that simply scanning from the end of the "secapp" region to its beginning using increments of half the trustlet's size will guarantee a successful match.


A (messy) write primitive


Now that we have a way to find the trustlet in the secure region, we are able to craft "valid" session pointers, which point to locations within the trustlet. Next up, we need to find a way to create a write primitive. So... are there any functions which write controllable data into a session pointer?

Surprisingly, nearly all functions that do write data to the session pointer do not allow for arbitrary control over the data being written. Nonetheless, one function looks like it could be of some help:

This function generates a random DWORD to be used as a "nonce", then checks if enough time elapsed since the previous time it was called. If so, it adds the random value to the session pointer by calling "addNonceToCache".

First of all, since the "time" field is saved in the global buffer after our overflown buffer, we can easily clear it using our overflow primitive, thus removing the time limitation and allowing us to call the function as frequently as we'd like. Also, note that the generated nonce's random value is written into a buffer which is returned to the user - this means that after a nonce is generated, the caller also learns the value of the nonce.

Let's take a peek at how the nonces are stored in the session pointer:


So there's an array of 16 nonces in the session object - starting at offset 0x88. Whenever a nonce is added, all the previous nonce values are "rolled over" one position to the right (discarding the last nonce), and the new nonce is written into the first location in the nonce array.

See where we're going with this? This is actually a pretty powerful write primitive (albeit a little messy)!

Whenever we want to write a value to a specific location, we can simply set the session pointer to point to that location (minus the offset of the nonces array). Then, we can start generating nonces, until the least-significant byte (this is a little-endian machine) in the generated nonce matches the byte we would like to write. Then, once we get a match, we can increment the session pointer by one, generate the next byte, and so forth.



This allows us to generate any arbitrary value with an expectancy of only 256 nonce-generation calls per byte (since this is a geometric random variable). But at what cost?

Since the values in the nonce cache are "rotated" after every call, this means that we mess-up the 15 DWORDs after the last written memory location. We'll have to work our way around that when we design the exploit.

 Writing an exploit

We finally have enough primitives to craft a full exploit! All we need to do is find a value that we can overwrite using the messy write primitive, which will allow us to hijack the control flow of the application.

Let's take a look at the function in charge of handling the "6X" category of commands:



As you can see, the function calls the requested commands by using the command ID specified as an index into an array stored in the global buffer. Each supported command is represented by a 12-byte entry in the array, containing four pieces of information:
  • The command code (32-bits)
  • A pointer to the handling function itself (32-bits)
  • The minimal input length (16-bits)
  • The minimal output length (16-bits)

If this information is valid, the function pointer is executed, passing in the user's input buffer as the first argument and the output buffer as the second argument.

If we choose an innocuous 6X command, we can overwrite the corresponding entry in the array above so that its function pointer will be directed at any piece of code we'd like to execute. Then, simply calling this command will cause the trustlet to execute the code at our controlled memory location. Great!

We should be wary, however, not to choose a function which lies directly before an "important" command that we might need later. This is because our messy write primitive will destroy the following 15 DWORDs (or rather, the next 5 array entries). Let's take a look at the function which populates the entries in the command array:


There are six consecutive entries corresponding to unused functions. Therefore, if we choose to overwrite the entry directly before them, we'll stay out of trouble.

 

Universal Shellcode Machine


Although we can now hijack the control flow, we still can't quite execute arbitrary code within QSEE yet. The regular course of action at point would probably be to find a stack-pivot gadget and write a short ROP chain which will enable us to allocate shellcode - however, since the trustlets' code segments aren't writeable, and the TrustZone kernel doesn't expose any system call to QSEE to allow the allocation of new executable pages, we are left with no way to create executable shellcode.

So does this mean we need to write all our logic as a ROP chain? That would be extremely inconvenient (even with the aid of automatic "ROP"-compilers), and might even not be possible if the ROP gadgets in the trustlet are not Turing-Complete.

Luckily, after some careful consideration, we can actually avoid the need to write longer ROP chain. If we think of our shellcode as a Turing Machine, we would like to create a "Universal Turing Machine" (or simulator), which will enable us to execute any given shellcode as if it were running completely within QSEE.

Given a piece of code, we can easily simulate all the control-flow and logic in the "Normal World", simply by executing the code fully in the "Normal World". But what about operations which behave differently in a QSEE-context? If we think about it, there are only a few such operations:
  • Reading and writing memory
  • Calling system calls exposed by the TrustZone kernel
These operations must execute within QSEE. However, we can actually execute both of these operations in QSEE by writing one small ROP chain!

All we need is a single ROP chain which will:
  • Hijack control flow to a separate stack
  • Prepare arguments for a function call
  • Call the wanted QSEE function
  • Return the result to the user and restore execution in QSEE
As you can see, all this chain do is to enable us to execute any given QSEE function using any supplied arguments. But how can we use it to simulate the special operations?

Well, since all system-calls in QSEE have matching calling-stubs in each trustlet, we can use our ROP chain to execute any system call with ease. As for memory accesses - there is an abundance of QSEE functions which can be used as read and write gadgets. Hence, both operations are simple to execute using our short ROP chain.

This leaves us with the following model:


This also means that executing arbitrary shellcode in QSEE doesn't require any engineering effort! All the shellcode developer needs to do is to delegate memory accesses and system calls to specific APIs exposed by the exploit. The rest of the shellcode's logic can remain unchanged and execute completely in the "Normal World". We'll see an example of some shellcode using this model shortly.

Finding a stack pivot


In order to execute a ROP chain, we need to find a convenient stack-pivot gadget. When dealing with large or medium-sized applications, this is not a daunting task - there is simply enough code for us to find at least one gadget that we can use.

However, since we're only dealing with ~125KB of code, we might not be that lucky. Not only that, but at the point at which we hijack the control flow, we only have control over the registers R0 and R1, which point to the input and output buffers, respectively.

After fully disassembling the trustlet's code we are faced with the harsh truth - it seems as though there is no usable stack pivot using our controlled registers. So what can we do?

Recall that ARM opcodes can be decoded in more than one way, depending on the value of the T bit in the CPSR. When the bit is set, the processor is executing in "Thumb" mode, in which the instruction length is 16-bits. Otherwise, the processor is in "ARM" mode, with an instruction length of 32-bits.

We can easily switch between these modes by using the least-significant bit of the PC register when performing a jump. If the least-significant bit is set, the T bit will be set, and the processor will switch to "Thumb" mode. Otherwise, it will switch to ARM mode.

Looking at the trustlet's code - it seems to contain mostly "Thumb" instructions. But perhaps if we were to forcibly decode the instructions as if they were "ARM" instructions, we'd be able to find a hidden stack pivot which was not visible beforehand.

Indeed, that is the case! Searching through the ARM opcodes reveals a very convenient stack-pivot:


By executing this opcode, we will be able to fully control the stack pointer, program counter and other registers by using the values stored in R0 - which, as we saw above, points to the fully user-controlled input buffer. Great!

As for the rest of the ROP chain - it is pretty standard. In order to execute a function and return all we need to do is build a short chain which:
  • Sets the low registers (R0-R3) and the stack arguments to the function's arguments
  • Set the link register to point to the rest of our chain
  • Jump to the function's start address
  • When control is returned via the crafted LR value, store the return value in user-accessible memory location, such as the supplied output buffer
  • Restore the stack pointer to the original location and return to the location from which control was originally hijacked
You can find the complete ROP chain and gadgets in the provided exploit code, but I imagine it's exactly what you'd expect.

Putting it all together


At long last, we have all the pieces needed to create a fully functional exploit. Here's a short run-down of the exploit's stages:
  • Find the Widevine application by repeatedly "tapping" the secapp region and "listening"
  • Create a "messy" write gadget using the nonce-generation command
  • Overwrite an unused 6X command entry using the write gadget to direct it to a stack-pivot
  • Execute any arbitrary code using a small ROP chain under the "Universal Shellcode Machine"



The Exploit


As always, the full exploit code is available here:

https://github.com/laginimaineb/cve-2015-6639

I've also included a sample shellcode using the model described earlier. The shellcode reads a file from TrustZone's secure file-system - SFS. This file-system is encrypted using a special hardware key which should be inaccessible to software running on the device - you can read more about it here. Regardless, running within the "Secure World" allows us to access SFS fully, and even extract critical encryption keys, such as those used to decrypt DRM content.

In fact, this is all it takes:


Also, please note that there are quite a few small details that I did not go into in this blog post (for brevity’s sake, and to keep it interesting). However, every single detail is documented in the exploit's code. So by all means, if you have any unanswered questions regarding the exploit, I encourage you to take a look at the code and documentation.

What's next?


Although we have full code-execution within QSEE, there are still some things beyond our reach. Specifically, we are limited only to the API provided by the system-calls exposed by the TrustZone kernel. For example, if we were looking to unlock a bootloader, we would probably need to be able to blow the device's QFuses. This is, understandably, not possible from QSEE.

With that in mind, in the next blog post, we'll attempt to further elevate our privileges from QSEE to the TrustZone kernel!

Timeline 

  • 27.09.2015 - Vulnerability disclosed
  • 27.09.2015 - Initial response from Google
  • 01.10.2015 - PoC sent to Google
  • 14.12.2015 - Vulnerability fixed, patch distributed

I would also like to mention that on 19.10.2015 I was notified by Google that this issue has already been internally discovered and reported by Qualcomm. However, for some reason, the fix was not applied to Nexus devices.

Moreover, there are quite a few firmware images for other devices (such as the Droid Turbo) that I've downloaded from that same time period that appeared to still contain the vulnerability! This suggests that there may have been a hiccup when internally reporting the vulnerability or when applying the fix.

Regardless, as Google has included the issue in the bulletin on 14.12.2015, any OEMs that may have missed the opportunity to patch the issue beforehand, got another reminder.

212 comments:

  1. Do you know where Widevine is located on a Motorola Droid Maxx? Or at least how to locate it?

    ReplyDelete
    Replies
    1. This comment has been removed by the author.

      Delete
    2. I'd be really really surprised... There are a lot of paths, the location changes across OEMs and devices. Try these paths: /firmware/vendor, /vendor/, /firmware/image, /system/firmware/, /system/vendor/

      Delete
    3. It has it, however I can not find it. All the other TrustZone apps are stored in /firmware/image, however I do not see Widevine there.

      Delete
    4. Those are part of an image shipped with the device, called NON-HLOS. Anyway, just run "find" and look for widevine.mdt (make sure you have root privs before)

      Delete
    5. Yep, definitely can't find it. Find output (Minus the few directory not found in /proc):
      http://pastebin.com/1AyHcYQC

      Delete
  2. Ah, that's surprising - only device I've seen without it. Here's something else you can try: QC added the PRDiag commands to other trustlets as well, so you can search to see if any of them are vulnerable using "grep -r PRDiag /"

    ReplyDelete
    Replies
    1. The only one with PRDiag is tzapps.

      Delete
    2. Will the same code work? Or will it need adapted? (Besides the widevine path part)

      Delete
    3. Also, my phone apparently still has support for widevine though. The .jar for it is there.

      Delete
  3. The same vuln should work, but you'll need a new exploit (since the wv sessions won't be there, etc.).

    ReplyDelete
    Replies
    1. Alright! Thanks again.

      Delete
    2. If you would be so kind as to email me and give me some pointers, that would be great. Here's my email:
      bfox200012@gmail.com

      Delete
    3. Actually, upon looking at tzapps, it seems that tzapps IS widevine..

      Delete
    4. Or maybe not..it does have a lot of widevine references though.

      Delete
  4. Would this work on the LG G5? (If this is a really stupid question I'm sorry I'm very new to this)
    If you have the time to explain how to use this to a beginner, please email me at fredo0429@gmail.com

    ReplyDelete
    Replies
    1. I think it would, but I've never checked it specifically. Feel free to search for "PRDiag" in the firmware image to make sure.

      Delete
    2. PLEASE try this if you can! And how do I search for PRDiag? Sorry just don't understand that haha.
      Also if you do get this to work on the G5, $2,500 is yours ;)

      Delete
  5. Can we use this to achieve root on devices with Marshmallow?

    ReplyDelete
    Replies
    1. Sure, the Android version doesn't really matter - QSEE can infect any running kernel.

      See the next blog post: http://bits-please.blogspot.com/2016/05/war-of-worlds-hijacking-linux-kernel.html

      Delete
  6. Is this SFS encryption used on modemst1 and modemst2 to encrypt NV values?

    ReplyDelete
    Replies
    1. Great question!

      I did some research in the past into the modemst1 and modemst2 filesystems, but this was a long time ago and probably not 100% accurate (since reversing QDSP6 is hard and time-consuming).

      IIRC, the modemst filesystems use something called EFS2 which relies on a processor-specific hardware key. SFS uses a hardware-key from the application processor, but EFS uses a hardware-key from the baseband processor.

      Delete
    2. Cheers for your reply,

      You mentioned SFS uses a HBK, would this be the same key that is used to encrypt the device when encryption is enabled? It was my understanding that the Crypto Core0 only had access to the key, much like a TPM it would never expose the key.

      Indeed modem reversing is hard, the architecture is a little like ARM, in your experience, how much trust does the modem have? Can the modem access the QFPROM region? Or configure the XPU?

      Delete
    3. I don't think SFS uses the same key used for device encryption (the patent mentions the device-specific hardware key "52" in regards to SFS). Also, yes - the hardware keys are supposed to be accessible only to the Crypto Core (although this could be something interesting to research in order to make sure).

      As for the modem - I've done quite a lot of research into it and the MBA module; both seem to have very little amounts of "trust" - no XPU or QFPROM access.

      On the other side, the TrustZone kernel should be able to configure the XPUs, which would enable access to the modem's memory from the TZ kernel (however, I haven't been able to access any XPU-protected region from the TZ kernel yet - I have no idea how the XPUs work and reversing the responsible TZ code takes a long time).

      Delete
    4. This comment has been removed by the author.

      Delete
    5. Cheers for your reply, indeed some more research does need to completed.

      A little off topic, will you be at BlackHat this year? I'd love to meet you!

      Delete
    6. I might get around to it later this year, it does sound like an interesting thing to check out.

      Also, unfortunately I won't make it to BH this year since it overlaps the exam season, but I'd love to chat as well. Perhaps I'll see you later in another con?

      Delete
  7. How did you map out/get symbols for the various widevine command codes? aka how did you produce widevine_commands.h?

    ReplyDelete
    Replies
    1. By reversing Widevine's code. There are quite a few logs left in the code which helped, but there are three functions that I couldn't figure out (or were unused), but maybe their names exist in older versions of Widevine (I didn't check). Also - some commands didn't have names in the Widevine application itself, but did have names in the calling libraries (like the OEMCrypto* family of functions).

      Delete
  8. Hey..Question if you don't mind..What would I be looking for in tzapps to exploit it in a similar manner to this?

    ReplyDelete
  9. Hey, I downloaded the newest drivers of qcom-shamu from https://developers.google.com/android/nexus/drivers#dragonmxc89f and found there is no difference below the key code you mentioned here, seems like this is not fixed?

    ReplyDelete
    Replies
    1. It's fixed in the official firmware images (see https://developers.google.com/android/nexus/images) and in the OTA images.

      I think the page you linked is used to provide firmware images for AOSP - but you're right - it looks like Google forgot to apply the patch there (so users of CM/other AOSP-based ports of Nexus 6 would still be vulnerable). Would you like to file a security report with Google? Here's a link: https://code.google.com/p/android/issues/entry?template=Security%20bug%20report

      Delete
    2. This comment has been removed by the author.

      Delete
    3. thanks laginimaineb, I also downloaded shuma images and OTA from https://developers.google.com/android/nexus/images and found the code is still same, did you review the widevine from these images? or do you know how it was fixed? thanks :)

      Delete
    4. I tested https://dl.google.com/dl/android/aosp/shamu-ota-mob30i-c0bdba8e.zip and https://dl.google.com/dl/android/aosp/shamu-lrx21o-factory-e028f5ea.tgz

      Delete
    5. also the modified date of the widevine from above images is prior to 14.12.2015(Vulnerability fixed, patch distributed)

      Delete
    6. Sorry for the late response! Only got around to it now...

      Anyway, I think you're right, apparently the fix wasn't applied to the Nexus 6 after all. Thank you for your vigilance! This is really surprising, especially since I initially reported it to Google with regards to the Nexus 6 specifically, and the fix should have been included in the January 2016 update.

      I don't quite understand why this happened... The duo article covering the vulnerability (https://duo.com/blog/sixty-percent-of-enterprise-android-phones-affected-by-critical-qsee-vulnerability) states that 60% of Android devices are still vulnerable, so it seems like this vulnerability is here to stay for a while.

      Could you please update me as to whether or not you are reporting this to Google? Obviously this needs to be fixed.

      Delete
    7. thanks laginimaineb, I have notified Google, they are reviewing it, keep you posted

      Delete
    8. Google is still reviewing:(

      Delete
    9. This comment has been removed by the author.

      Delete
    10. Hi laginimaineb,

      pls refer to https://dl.google.com/dl/android/aosp/shamu-mob30w-factory-21715256.zip for the bug fix:)

      Delete
  10. Hi again. Sorry for bugging you before, but I have found the Widevine location for the LG G5. It is located in "/system/vendor/firmware/widevine.mdt".

    What exactly do I do with this?

    ReplyDelete
    Replies
    1. Also, I keep getting this error whenever I try and run the code: "[-] Failed to load Widevine: Bad file descriptor"

      Delete
    2. Make sure you changed the widevine path in the exploit (IIRC in defs.h) to that path, and that you're running as either media or root

      Delete
    3. Ah OK, I will change that :)

      Unfortunately root is not available for my device at this time, how can I run it as media?

      Delete
    4. Ah OK, I will change that :)

      Unfortunately root is not available for my device at this time, how can I run it as media?

      Delete
    5. For that you'll need a mediaserver vulnerability. I'm releasing one for all Android devices and versions soon.

      Delete
    6. Awesome! Thanks, you're the best :)

      Delete
    7. Awesome! Thanks, you're the best :)

      Delete
  11. This comment has been removed by the author.

    ReplyDelete
  12. Hi laginimaineb! Thanks for your great articles. Could you explain how did you find the value SECURE_APP_REGION_START and size of the whole secapp region available for memory allocation for the trustlets, please? Is this values are same for all Qualcomm's SoCs?
    What is the probability of allocation of the same memory region after trustlet to be crashed while searching location of the trustlet ?

    ReplyDelete
  13. Hi, To enable Widevine Level 1 on HDMI is it mandatory have to HDCP enabled and provisioned on the Qualcomm processor?

    Cheers,
    Sundeep

    ReplyDelete
  14. Hi laginimaineb,

    Thanks for the awesome article!

    The firmware image you linked on the previous article (https://dl.google.com/dl/android/aosp/shamu-lmy48m-factory-336efdae.tgz) now points to patched version of the firmware.
    I am trying to reproduce this exploit and could you please share the exact vulnerable firmware image that you used? Thanks alot!

    ReplyDelete
  15. Hi laginimaineb,

    I have following three questions. Could you please answer them for me?

    1. Does this trusted app running in secure wold has page tables? if so, is it 2 level page table?
    2. Do you know how MMU translates the virtual address to physical address in QSEE? Incase of TLB miss, it checks TTBR to find second level page table and from second level page table, it finds the physical address?
    3. RAM is divided into secure RAM (for secure world) and non secure RAM (non secure world), right? Is it possible to find the physical address range of secure RAM?

    Thanks a lot,
    Karthik

    ReplyDelete
    Replies
    1. 1. It does, but I haven't looked at them in depth. You can use my TZ kernel exploit to read TTBR0 and dump the translation table.

      2.It's the exact same process as listed in the ARM VMSA.

      3. Yes, but do you mean pages that are marked secure or simply the secapp region? In any case, you can find secapp by looking at the kernel dtb, and you can find the TZ monitor memory ranges by looking at the TZ ELF (TZ monitor uses a flat translation table so no need to translate VAs to PAs)

      Delete
  16. Nice writing! You mentioned "in fact trustlets can access all allocated memory within the "secapp" region, even memory belonging to other trustlets!".

    However, in your slides "https://microsoftrnd.co.il/Press%20Kit/BlueHat%20IL%20Decks/GalBeniamini.pdf", you mentioned that "Trustlets cannot access the memory of other loaded trustlets", "Even if they know their loading address within “secapp”".

    So I wonder, indeed can the trustlets for Qualcomm implementation can access the memory of other trustlets or not?
    Thanks.

    ReplyDelete
    Replies
    1. Hi CrazyGalaxy,

      Thanks for reading! As mentioned in the BlueHat IL presentation, trustlets can't access one another's memory ranges, as I later discovered when I was writing the TrustZone kernel exploit. However, the reason I got it wrong in this blog post was that probing the memory ranges in "secapp" didn't always crash, even for addresses that *weren't* in the current trustlet. In hindsight, I think this is because of shared data structures that were located in "secapp", and were readable by the trustlet.

      All the best,
      Gal.

      Delete
  17. The exploit code in the Github is written for device Nexus 6, lmy48m, right?

    If reproducing the exploit on other devices like Nexus 5, what parameters need to be updated?
    Only SECURE_APP_REGION_START and SECURE_APP_REGION_SIZE, or a lot of others? Thanks.

    ReplyDelete
    Replies
    1. This comment has been removed by the author.

      Delete
    2. I also changed the DATA_SEGMENT_OFFSET and DATA_SEGMENT_SIZE (need to -1). But still does not work.

      It seems it cannot find the widevine application in memory:

      [+] Crashed in linear scan, jumping ahead
      [-] Failed to find application
      : No such file or directory

      Delete
    3. Hi CrazyGalaxy,

      Yes, you would need to adjust the rest of the symbols (see symbols.h) to match the exact version of the Widevine trustlet that you're trying to exploit. Other than that, as you've stated above, you'll need to set the secure apps region bounds to match the ones defined in your kernel's dtb.

      All the best,
      Gal.

      Delete
  18. Has anyone had luck with this exploit on MSM8909? Seems PRDiag is missing

    ReplyDelete
  19. How to Clear TPM Security Processor Firmware The term TPM stands for Trusted Platform Module. If our PC is TPM enabled then it is our first priority to update our security processor. Windows Defender Security Centre regularly sends us the priority message to update the TPM firmware. It can also say us to update the TPM security processor firmware.

    ReplyDelete
  20. Hello! Do you use Twitter? I’d like to follow you if that would be okay. I’m absolutely enjoying your blog and look forward to new posts.

    NFR live stream
    Watch NFR live Online
    NFR live stream 2018
    NFR Live on CBS Sports Network

    ReplyDelete
  21. When a car or truck turning at an intersection they would look if a vehicle is nearby or not, as a usual habit driver looks for large vehicles like other cars. If he doesn’t see any other large vehicle, he presumes no one on the back and slows the car to change the road. What he fails to see is a motorcycle on the back as its very small for the vehicles he is most used to see on the road. So, here is what a motorcyclist should do to avoid such an incident. - Motorists

    ReplyDelete
  22. Very Awesome write up !!! You have provided best efforts Here Thank You for This
    Great Blog Post. I am going to Bookmark your Blog for Further Visit.

    Walmartone Login
    Mysubwaycard
    Mygiftcardsite
    Freedom APK
    Walmart Credit Card Login
    Tell Subway

    ReplyDelete
  23. Well !!! This is very awesome Happy Easter 2019 Images and good written article Good Friday 2019 Images you have provided here all the Information and facts Kentucky Derby 2019 are always truthful and great. Thanks for this awesome article

    ReplyDelete
  24. Hey, thanks for posting amazing articles. These blogs would definitely help us keep posted about new trends in the market. Thansk for sharing
    Dentist in Kanpur

    ReplyDelete

  25. Hey, thanks for posting amazing articles. These blogs would definitely help us keep posted about new trends in the market. Thanks for sharing
    Best Unisex Hair Salon in Lucknow

    ReplyDelete
  26. Nice Blog, Thank you so much for sharing such an amazing blog with us. Visit
    Dynamic Website Designing Company in Delhi

    ReplyDelete
  27. Visit for the services of Shipping, Freight Forwarders and Logistics Companies at Y & H Cargo India.
    Shipping Company in India

    ReplyDelete
  28. Nice Blog, Get the best Audio and Sound Engineering courses by Spin gurus.
    Music Production Course

    ReplyDelete
  29. Thank you so much for sharing such a valuable blog with us.
    Best Performing Mutual Fund

    ReplyDelete
  30. excellent put up, very informative. I wonder why the opposite experts of this sector do not understand this. You must continue your writing. I’m sure, you’ve a great readers’ base already!

    Happy Easter Images 2019
    Happy Easter Pics 2019 For Facebook
    Happy Easter Bunny Images 2019 For Facebook
    Happy Easter Wallpaper 2019 For Facebook
    Happy Easter Background 2019 For Facebook

    ReplyDelete
  31. Sanal para birimi olan bitcoin, bir çok ödeme kanallarını geride bırakarak en fazla tercih edilen yöntem olarak 2018 yılına damgasını vurmuştu. Özellikle sürekli artış göstermesi bir çok yatırımcının ilgisini çekerken son dönemlerdeki ciddi düşüş grafiği Bitcoin’e yatırım yapanlara büyük sıkıntılar da yaşatmaya başladı ancak hala oldukça popüler olan bitcoin sayesinde tamamen gizli ve güvenli bir şekilde bakiye yüklemek ve para çekmek oldukça kolay.

    ReplyDelete
  32. Amazing Blog, Thank you so much for sharing such an amazing blog. Visit Ogeninfo for the creative and Dynamic Website Designing Services in Delhi.
    Website Designing Company in Delhi

    ReplyDelete
  33. Thanks dear for sharing such amazing information. Visit for retirement planning calculator

    ReplyDelete
  34. Amazing blog, Visit Y&H Cargo India for Shipping and Freight Forwarding Services.
    Logistics Company in Delhi

    ReplyDelete
  35. Thanks for this informative blog sharing with us, Visit Mutual Fund Wala to get Investment Schemes and Mutual Fund Advisors.
    Mutual Fund Advisor

    ReplyDelete
  36. Nice Post thanks for sharing it s very useful. This Blog gives me so much information….
    Web Development Company in Delhi

    ReplyDelete

  37. La veilleuse coranique bluetooth avec sa télécommande pour offrir.
    Cadeau ramadam idéal
    La veilleuse coranique personnalisée pas cher
    Veilleuse coranique pas cher
    Veilleuse coranique pas cher

    Découvrez La veilleuse coranique Munawara
    Video de la Veilleuse coranique munawara
    Veilleuse coranique munawara


    Je travailles sur un projet de fabrication de cornes de gazelle personnalisée
    cornes de gazelle marocaine
    cornes de gazelle algerienne
    Merci de laisser ce lien c'est sympa...

    Le casque vapeur hair steamer permet de lutter contre la sécheresse, la chute des cheveux et leur mauvaise santé , dans le confort de votre domicile. Le hair steamer est un casque vapeur qui apporte une dose d'hydratation pour les cheveux crépus.
    Hair steamer vapohair
    Lee hair steamer casque vapeur est recommendé par fes femmes aux cheveux crépus
    Casque vapeur
    La casque vapeur hair steamer apporte beaucoup de bienfait au cheveux crépus de type afro Hair.
    hair steamer Casque vapeur hydratation cheveux crépus
    hair steamer casque vapeur

    ReplyDelete
  38. Your work is very good and I appreciate you and hopping for some more informative posts brat diet

    ReplyDelete
  39. Cool work dude.

    https://bomberfriendsmodapk.net/

    ReplyDelete
  40. Nice article keep it up like this in your future.I hope you do best afford and make future bright.
    Best website designing company in Kashmiri Gate

    ReplyDelete
  41. Normally I do not read post on blogs, but I would like to say that this write-up very forced me to try and do so! Your writing style has been surprised me. Thank you, very nice article.

    Passover Images 2019
    Passover Images 2019 For Facebook
    Happy Passover Images 2019
    Passover Images 2019 HD
    Passover Images 2019 Free Download

    ReplyDelete
  42. I feel happy about and learning more about this topic. keep sharing your information regularly for my future reference. This content creates new hope and inspiration within me. Thanks for sharing an article like this. the information which you have provided is better than another blog.
    IELTS Coaching in Dwarka
    Best IELTS Coaching in Dwarka

    ReplyDelete
  43. Your blog was really impressive and meaningful. Thank you so much for sharing
    love problem solution in delhi

    ReplyDelete
  44. Thanks for sharing this great article..Its really nice and useful for us.

    Website Designing Company in Delhi

    ReplyDelete
  45. What is the best App Store alternative?

    Install Tutuapp, the free platform to download games and apps on iOS.

    ReplyDelete
  46. Amazing Post! That is a great and so creative idea. Thank you for sharing
    Question and Answer Submission Site List

    ReplyDelete
  47. Article really helped me a lot. Thanks so much for sharing this blog. Mobile Apps Development Company Delhi

    ReplyDelete
  48. Good Job and thanks for the post.
    aos tv

    ReplyDelete
  49. Live TV App - AOS TV with all categories channels and channels from around the world.

    ReplyDelete
  50. blockchain technology can resist cyber attack but there is a lot do protect from cyber criminala attacks. learn more in bitcoin online course

    ReplyDelete
  51. Watch Free Live TV from around the world on hd streamz

    ReplyDelete
  52. really amazing article. really nice way of define the things. Android App Development Company in Delhi

    ReplyDelete
  53. You Have Good Knowledge on this topic and you explained things very Well till the end, Thanks for Article bro!
    Angularjs Training in Bangalore , Angular 2 Training in bangalore

    ReplyDelete
  54. Thanks for sharing such a nice Blog.I like it.

    mcafee.com/activate
    norton.com/setup

    ReplyDelete
  55. There is no doubt in the app you can easily download the app the most exciting features are waiting for you can easily go with TutuApp. There are nothing extra features required in this app because the most important items are already available in his update versions. Download Latest Version. Also love Snaptube For PC

    ReplyDelete
  56. KineMaster for Android, free and safe download. KineMaster apk latest version: Mobile video editing at its finest.
    kinemaster for pc

    ReplyDelete
  57. Having a website for any kind of business is a must in today’s competitive scenario but what about having an attractive design of the website that directly appeals the senses of the user. Get in touch with Jeewangarg – The Best Website Designing Company in Delhi to get the Appealing Website Designs.

    ReplyDelete
  58. I’m waiting for your next post, because I got lots of valuable information by this. Get Vinyl Signage Printing and Commercial Vehicle Wrap by Kalakutir Pvt Ltd.
    Commercial Vehicle Wrap

    ReplyDelete
  59. Thanks for sharing this post, this is really very nice informative post. Here we are presenting netcreativemind.com
    SEO SEM Specialist Recruiters | SEO/SEM Placement Consultant
    SEO SEM Specialist
    Information security Placement Consultants
    Data Analyst Recruitment Agency

    ReplyDelete
  60. QuickBooks Diagnostic Tool is a great tool to solve network issues, data file damages and several other problems that commonly occur in QuickBooks.

    ReplyDelete
  61. For Best private ambulance call at Almas ambulance service in Delhi. We help patients to get best medical care on right time by our ambulance service.
    http://www.almasambulance.com
    International air ambulance
    Air ambulance Kolkata
    Air ambulance guwahati
    Air ambulance patna
    Air ambulance ranchi
    Air ambulance srinagar
    Air ambulance Delhi

    ReplyDelete
  62. Nice Blog, keep it up for more updates about this type of blog.Carolina Classics is the manufacturer of best F-100 Classic Ford Truck Parts| Buy Ford F100 truck parts online at Carolina Classics. Classic Ford Truck Parts
    F-100 Ford Truck Parts
    Classic Ford Truck Body Parts

    ReplyDelete
  63. Thanks For sharing this informative post. Here we are presenting Let's Life Breathe.
    5 Best Tips to Beat Pollen Allergies - BreatheFresh

    ReplyDelete
  64. That was such an awesome content to read and going through it.Thanks for such a good information.our product related for servo voltage stabilizer and transformer manufecturer company in Delhi Our company is also Step Down Transformer Manufecturer in Delhi.

    Servo Stabilizer Manufacturer in india
    what is Step Down Transformer
    Distribution Transformers Manufacturer in india
    Step Down Transformer

    ReplyDelete
  65. Corpac is India’s No.1 Professional PP Corrugated Sheets Manufacturers, suppliers and Currently being exported to countries like Qatar, New Zealand, Germany, Philippines, UK and Spain, this product is achieving new growth with over 10 years Experience. Corrugated plastic sheets are very versatile material that can be used in a variety of applications around the homes, companies and also for craft projects, call 9899362119." We manufacture Polypropylene Corrugated Sheets and fabricated products under one roof. We market our products not only in India but export to various countries across the world.

    ReplyDelete
  66. Given article is very helpful and very useful for my admin, and pardon me permission to share articles here hopefully helped :

    Cara Mengobati Kaligata Secara Alami Dan Cepat

    ReplyDelete
  67. Given article is very helpful and very useful for my admin, and pardon me permission to share articles here hopefully helped :

    Cara Mengobati Kista Payudara Secara Alami
    Cara Mengatasi Gatal Selangkangan Secara Alami

    ReplyDelete
  68. Thanks for sharing the useful information. This is a nice blog. Web Designing Company in Delhi

    ReplyDelete
  69. I Personally Like Your Post, You Have Shared Good Article. It Will Help Me In Great Deal.

    samsung contact number
    samsung support number

    ReplyDelete
  70. QuickBooks Error 103 appears when the QuickBooks is not accepting the login request and you need to update your login details in QuickBooks online. To resolve Error 103 QuickBooks contact QuickBooks Tech Support Number 1-877-263-2742.
    QuickBooks Error 103 | Quicken Error CC-585


    ReplyDelete
  71. Hey,
    Thanks for sharing this helpful & wonderful post. i really appreciate your hard work. this is very useful & informative for me.
    thanks for sharing with us. thanks a lot.
    Regards

    FutureTricks

    ReplyDelete
  72. We are so much interested to get good values about this blog. They were all trying to know the importance of new schools. Then every student will get good education from the school.
    flipkart customer care
    flipkart big billion days
    flipkart helpline
    flipkart app download
    flipkart no cost emi | bajaj finserv emi card
    flipkart buyback guarantee
    flipkart seller support number
    flipkart internship
    flipkart smartbuy
    Download flipkart app For PC/Laptop Windows 10/7/8.1/8/XP

    ReplyDelete
  73. Nice blog, Get you website designing responsive and creative and also digital marketing services at ogen info system Delhi, India.
    SEO Service in Delhi

    ReplyDelete
  74. This comment has been removed by the author.

    ReplyDelete
  75. Thanks for Shearing this information. this is a very useful for everyone.
    mobile application development service in USA

    ReplyDelete
  76. Thank you for bestowing this information which will enlighten many of us. It’s really helpful for me and the one who wants to know more about mobile app development company.

    ReplyDelete

  77. I am very grateful you did share your knowledge here. It is an excellent post
    clipping path service|Photo Retouching services|Vector Tracing

    ReplyDelete