What information may supply the uninitialized data to security team?

Question

When I was reversing some well known Android chat applications (I can not disclose which specific ones, but all of them where owned by companies with 1 billion+ capital and have hundreds of millions of accounts), I saw an interesting feature in C++ code.

These applications read uninitialized data and sent it to their web service.

In pseudocode, they do the following job:

static constexpr const size_t uninitialized_data_size = 1024;
auto uninitialized_data = malloc(uninitialized_data_size);
HttpPost("http://my-url.com", uninitialized_data, uninitialized_data_size);

Of course, we can think that it is just a bug... But when multiple huge companies do the same thing, I'm starting to think: why?

Does anyone have idea what information uninitialized data can supply to security team? Is it just repeated error made by accident, or they extract some useful information from uninitialized data that they send to their server on regular basis?

Answer 1

There were some cases where uninitialized memory was used as an entropy source, e.g. OpenSSL, but I doubt this is happening here. Possibly there is something not present in the snippet you posted, or it could indeed be a genuine bug.

Answer 2

I have not 100% idea how do they use this information, but what I suspect from information supplied by other participants of this conversation and also information from Internet:

• In Android JNI application, Java doesn't use malloc to allocate Java object. Instead, Java has its own memory manager. So, Java code has a very little influence on what malloc return.
• malloc prefers to use the same arena for the same thread if possible; so, in most cases other JNI calls made from other threads will not influence what does malloc returns.
• It means, that malloc will often return data allocated by the same thread. In JNI, we usually don't create long living C/C++ objects and prefer to use Java as memory manager, because it is problematic to free C++ memory in Java. finalize doesn't provide any guarantees! So, even if we will try to free C++ data associated with Java object in finalize, we can never know for sure that we'll not get memory leak, because OS will never call finalize. So, we may expect that 99% of malloc made during JNI call will call free during the same call.
• So, we can use uninitialized data to detect (with some probability) that our shared library is loaded in some unusual environment.

Lets imagine following code:

void MarkHeap()
{
    static const char *ones = "11....1"; // String that contains 1024 ones
    auto some_data = malloc(1024);
    memcpy(some_data, ones, 1024);
    free(some_data);
}

size_t CheckMarkHeap()
{
    auto some_data = malloc(100);
    size_t ones_count = 0;
    for(size_t i = 0; i < 100; ++i)
        if(some_data[i] == '1')
            ++ones_count;
    free(some_data);
    return ones_count;
}

MarkHeap();
auto ones_count = CheckMarkHeap()

Here we can expect that very often ones_count will equal to 100! We can now use this strategy to check (with some probability) if CheckMarkHeap is called soon after MarkHeap.

In situation where CheckMarkHeap calculates any kind of security token, we can afraid that anyone will try to use our own shared library to bypass our protection; in case of Android, we can extract shared library from APK and try to interpret it with Android emulator or any embedded ARM emulation library like unicorn. If we implemented MarkHeap in another shared library that doesn't draw attacker attention and somehow call it before CheckMarkHeap, we have a good chance to detect that our security library is loaded from unusual context.

Of course, we can not ban immediately for that, because any random events may affect ones_count. However, if ones_count is not 100 in more than 60% of calls, we can make any soft penalty to suspicious account (for example, ask for phone verification, SafetyNet verification, show CAPTCHA more often, send account to human moderation, etc).

Answer 3

The exact behavior would depend on the implementation details of the memory manager behind malloc(). But it is a common case that memory managers would reuse memory blocks previously released with free(). If malloc() recycles a memory block which is not zeroed (for example using memset()) before being released, the block will generally contain buffer content remaining from previously executed functions inside the process.

Given that the memory manager does not initialize blocks upon allocation and release, the implications of this pseudocode is that it will repeatedly take random memory samples (of 1k size) within the process' memory address space, which will occasionally catch some data remained from the workings of previously executed code.

Answer 4

Maybe to steal data?

When you request memory via malloc you will get a block of memory that was used by other applications or the os before. I think, it should be possible to extract valuable information (like hashes that were not properly cleaned up by password-managers and other credentials) from there, in respect to the large user-base and th computational power these companies have available.

Let's do some calculations (unfortunately in code tags, becuase RE-Ex does not have MathJax):

Let...

• n be the number of memory from which malloc can choose
• m be the size of the window we can search in
• l be the size of the searched sequence

The amount of different positions the window can have is given by n - m + 1.

The amount of positions, which will fully include a sequence of size l is m - l + 1.

Therefore the probability, that a random chosen search window will include our sequence is

p = (m - l + 1)/(n - m + 1)

We will assume,

• that the average available memory in the smartphone is n = 4GB
• the size of our search window is m = 1024
• that the length of the sequence is l = 16 (the size of an MD5-Hash)

This gives us a probability of p = (1024 - 16 + 1)/(4e9 - 1024 + 1) ~= 2.5225e-7.

Let's do some more assumptions: Suppose the messenger has 1.5 billion users (like WhatsApp has). Let's also suppose the code sends the data twice a day and one thousandth of the users have an unreserved MD5 hash somewhere in memory.

That gives us a total size of 1.5e9 / 1000 * 2 = 3e6 samples to evaluate each day.

We will approximate the expected numbers of useful hashes with the normal distribution:

sigma = sqrt(3e9*2.5225e-7*(1-2.5225e-7)) ~= 27.50909 (so the approx. should yield good results)

my = 3e9*2.5525e-7 ~= 756.75

So the company will get with an certainty of 99.73% between 701 and 812 (my-2*sigma, my+2*sigma) usable hashes each day.

Disclaimer: I am not certain how java handles memory and how plausible (and effective) this scenario is. Nor do I have used any wellfounded values - I just plugged in some pseudo-logic numbers. I give also no guarantee for the corecctness of my calculations (I never really liked statistics).

Nontheless: Feel free to play around with the values and correct me if I did some miscalculations.