3

If I understand it correctly then:

  1. C function malloc provides a memory block with indeterminate values (which depend on the previous user of this memory block)
  2. Shared VPS hostings share resources such as RAM and CPU

In that case, my question is: Would be possible to exploit this fact to create a C program which would repeatedly malloc and free memory and log found memory values in order to sniff out other users' important data such as passwords etc.?

If it is not possible, why not?

If it is possible, how can we prevent it from happening?

EDIT: After a long read of VMware manuals I found this one: MANUAL

Page 5, section 2.3, list item 3, lines 6 & 7:

"In order to avoid information leaking among virtual machines, the hypervisor always writes zeroes to the host physical memory before assigning it to a virtual machine. "

So that kind of answers my question for at least one of the hypervisors. There's no way for me to verify whether it's true for all hypervisors.

Gillian
  • 492
  • 1
  • 3
  • 13
  • I'm not an expert in VPS architectures, but AFAIK, the "shared memory" in VPS means that the memory for your VPS is in a shared pool but once your machine has been allocated with f.e. 4GB those 4GB are always the same. So no, it wouldn't be possible to do that. What may be possible is to read the entire memory once your machine is created. Protections to prevent this should be implemented by the VPS provider to avoid one machine accessing memory of other machines, there is nothing you can do to protect yourself. The best you can do is clear your machine's memory as soon as you can – Mr. E Jun 19 '18 at 16:40

2 Answers2

4

C function malloc provides a memory block with indeterminate values (which depend on the previous user of this memory block)

Only on the previous usage within that program, for reasons that I will explain.

Would be possible to exploit this fact to create a C program which would repeatedly malloc and free memory and log found memory values in order to sniff out other users' important data such as passwords etc.?

No.

When a process requests a chunk of memory from the kernel, that memory is delivered empty (zeroed out). Once a process has received that memory, it will split it up and reuse portions of it for individual malloc() calls. Most implementations of malloc() do not re-zero memory between uses, and this is where the "indeterminate values" you're referring to come from.

A program that worked the way you described would not find anything interesting. At most, it might find some of its own data in memory, but it would not find data from other processes, or from other users.

  • Would you happen to have a source for your claim that kernel zeroes out the memory upon its first request? That it is impossible to find any other process' data? – Gillian Jun 19 '18 at 21:31
  • @Gillian That allocation is typically performed using `mmap()` with `MAP_ANONYMOUS`; on Linux, the documentation guarantees that "its contents are initialized to zero". For further reading, see: https://stackoverflow.com/questions/17542601/anonymous-mmap-zero-filled –  Jun 19 '18 at 21:33
  • @duskwuff And on Windows, there is a background kernel thread that does the zeroing. Linux itself will zero things by default by screwing with page tables and using the zero page. I think there's even a kernel configuration option for disabling the zeroing on ultra-constrained embedded devices where it might not be a security issue. – forest Jun 20 '18 at 02:02
1

C function malloc provides a memory block with indeterminate values (which depend on the previous user of this memory block)

Correct.

Shared VPS hostings share resources such as RAM and CPU

Do they use the same Physical CPU and RAM as the other VPS, yes.

Would be possible to exploit this fact to create a C program which would repeatedly malloc and free memory and log found memory values...

That's complicated.

You're forgetting about an extra layer, and layers create abstraction. The V in VPS obviously stands for Virtual, but to create something Virtual, we need technology to Virtualize.

In simple words, Virtualization divides your physical hardware into smaller parts that can be used by virtual machines, this is done by the Hypervisor, which uses exposed Kernel functions to expose the hardware it has reserved to the VM.

If it is not possible, why not?

It is possible if a bug exists in the hypervisor to escape from the Virtual borders it has set up for your VPS.

Simple examples like your malloc() have been used before by other processes to escape a low privileged user accounts on Linux.

This is basically what that is, but more complex, if you can escape from your VM, you'll be your Hypervisor's user and thus have access to anything that's in the other VPS hosted on the same hypervisor.

If it is possible, how can we prevent it from happening?

As an end user, there isn't much you can do, except keep an eye on websites like packetstorm and cvedetails to keep an eye for vulnerable services.

A silly example are the recent attacks on CPU architectures that allowed access to protected memory amongst other things. If someone executes that kind of attack on a VPS you're on, they can access the RAM your VPS is using as well.

The only thing you can do is wait for a patch and change all your sensitive information (passwords, keys,...) afterwards, as they may have been in memory and can be compromized.

Nomad
  • 2,359
  • 2
  • 11
  • 23
  • 2
    Would you happen to know if hypervisors usually clean up the memory blocks before they pass them to VMs? I'm assuming that hypervisors don't mind sharing other users' RAM if necessary. – Gillian Jun 19 '18 at 17:01
  • I haven't analyzed different hypervisors yet. But they should, really. If that's not the case, I would call it a vulnerability and yes, an exploit can be written to do what you asked. – Nomad Jun 19 '18 at 17:26
  • 1
    @Gillian Most hypervisors do not allow VMs to allocate or free memory. There's a single chunk of memory allocated to the VM at startup, and it is likely to be delivered empty. –  Jun 19 '18 at 20:58