Baron Samedit is displayed for invalid GLIBC versions

[Reelix]

On running in a certain case, CVE-2021-3156 is recommended.

   [+] [CVE-2021-3156] sudo Baron Samedit

   Details: https://www.qualys.com/2021/01/26/cve-2021-3156/baron-samedit-heap-based-overflow-sudo.txt
   Exposure: less probable
   Tags: mint=19,ubuntu=18|20, debian=10
   Download URL: https://codeload.github.com/blasty/CVE-2021-3156/zip/main```

GLIBC version

ldd --version | grep GLIBC
ldd (Ubuntu GLIBC 2.23-0ubuntu3) 2.23

CVE-2021-3156 requires libc 2.26+ as shown over at https://github.com/worawit/CVE-2021-3156/blob/main/exploit_nss.py#L112

As such, this should never have been recommended.

[bcoles]

CVE-2021-3156 requires libc 2.26+ as shown over at https://github.com/worawit/CVE-2021-3156/blob/main/exploit_nss.py#L112

glibc 2.26+ is required only for the tcache technique.

While blasty's exploit probably won't work with Ubuntu's glibc 2.23-0ubuntu3 this is due to lacking offsets rather than due to the version of glibc.

The situation is a little more complex than simply checking for glibc 2.26+. There are several different exploitation techniques for this vulnerability and many exploits.

worowit's exploit you've linked to uses the tcache technique which requires glibc 2.26+. That is a different exploit to the recommended exploit (by blasty) which uses the userspec overwrite technique and does not require a version of glibc with support for tcache.

worowit also has a userspec variant which does not require tcache:

• https://github.com/worawit/CVE-2021-3156/blob/main/exploit_userspec.py

Similarly, the sudo_baron_samedit Metasploit module for Baron Samedit has been tested and is known to work with various versions of glibc before 2.26 (it wraps worawit's exploits):

• https://github.com/rapid7/metasploit-framework/blob/66da3148d6d8d7304ca7ff975ea6f04fd5f26857/modules/exploits/linux/local/sudo_baron_samedit.rb#L64-L70

It makes sense to have matches for both exploits. linux-exploit-suggester will recommended both blasty's and worawit's exploits:

• https://github.com/mzet-/linux-exploit-suggester/blob/a1b33c8064788ae25d7eae14d3b69c5e2c741d2c/linux-exploit-suggester.sh#L1446-1454

As such, this should never have been recommended.

It is significantly easier to check only the version of sudo, as version matching is somewhat complicated by distros using their own versioning scheme and back porting. The vulnerability exists within sudo and there is some leeway in the glibc version. Sometimes the offsets remain the same between versions or require only minimal adjustment to get working. For example, the offsets for Ubuntu 18.04.5 (Bionic Beaver) - sudo 1.8.21, libc-2.27 and Ubuntu 20.04.1 (Focal Fossa) - sudo 1.8.31, libc-2.31 are identical, despite the minor version of sudo having incremented by 10 revisions and the minor version of libc having incremented by 4 revisions). It is significantly more useful to have these exploits recommended than not recommended at all, even with the risk of false positives.

Also, the exploit repositories contain brute-force scripts which can be used to exploit systems for which the version of glibc has not been previously tested/confirmed as usable.

[Reelix]

While blasty's exploit probably won't work with Ubuntu's glibc 2.23-0ubuntu3 this is due to lacking offsets rather than due to the version of glibc.

It is significantly easier to check only the version of sudo, as version matching is somewhat complicated by distros using their own versioning scheme and back porting.

Both are extremely valid points, and that was a very well-written response overall!

As such, this seems to be user error far more than script error, and I shall be marking this as closed!