2

I was browsing the ld.so man page and I saw an entry about Secure-Execution mode:

 **Secure-execution mode**

   For  security  reasons,  if the dynamic linker determines that a binary
       should be run in secure-execution mode, the effects of some environment
       variables  are  voided  or  modified, and furthermore those environment
       variables are stripped from the environment, so that the  program  does
       not  even see the definitions.  Some of these environment variables af‐
       fect the operation of the dynamic linker itself, and are described  be‐
       low.    Other  environment  variables  treated  in  this  way  include:
       GCONV_PATH,  GETCONF_DIR,  HOSTALIASES,  LOCALDOMAIN,   LOCPATH,   MAL‐
       LOC_TRACE,  NIS_PATH,  NLSPATH,  RESOLV_HOST_CONF, RES_OPTIONS, TMPDIR,
       and TZDIR.

I noticed that it mentions GCONV_PATH, which I also noticed that the scripts used to exploit the recent polkit vulnerability CVE-2021-4034 utilize GCONV environment variables.

I am wondering if this would have been a valid mitigation, if the processes involved was running in this secure execution mode?

Sir Muffington
  • 1,447
  • 2
  • 9
  • 22
linuxuser8
  • 21
  • 1

1 Answers1

3

No. In fact, pkexec already does run in that mode, since it's a setuid binary. The reason why is that the vulnerability results in the GCONV_PATH environment variable getting set after ld.so already stripped the environment variables in that list.