Huge number of false positives for module S14 weak function check (radare)

[ghechenberger]

Describe the bug
The Grep commands for identifying weak functions in module S14 are very permissive, leading to a huge number of false positives if identifiers in the binary contain specific keywords like "system". This skews the statistics and hides real weak functions. As an example, the boost_filesystem file from the Boost library is used below.

To Reproduce
Steps to reproduce the behavior:

1. EMBA installation 4.1.0
2. Use libboost_filesystem.so.1.84.0 from https://freebsd.pkgs.org/14/freebsd-aarch64/boost-libs-1.84.0.pkg.html
3. Start EMBA with the following parameters: Any as long as module S14 is executed
4. See results in HTML report at html-report/s14_weak_func_radare_check/vul_func_XXX_system-libboost_filesystem.so.1.84.0.html. Many matches will look as follows, which is definitely not a common weak "system" function:

add r1, pc
blx rsym._ZNK5boost10filesystem15directory_entry12refresh_implEPNS_6system10error_codeE
ldr r0, [r4, 0x14]

Expected behavior
Identifiers just containing the keywords out-of-context should not be flagged.
The Regex used for flagging these issues should be adapted.
This may be hard, as we still want to identify legit weak function wrappers and variations.

Screenshots
N/A

Desktop

• OS: Kali Linux 2024.1
• EMBA version: v4.1.0
• Installation method: default with up to date docker image

Priority issue
Are you already a Sponsor? - N

Additional context
Add any other context about the problem here.

[github-actions]

Thank you for contributing an issue!

Welcome to the EMBA firmware analysis community!

We are glad you are here and appreciate your contribution. Please keep in mind our contributing guidelines here and here.
Also, please check existing open issues and consider to open a discussion in the dedicated discussion area.
Additionally, we have collected a lot of details around EMBA, the installation and the usage of EMBA in our Wiki.

If you like EMBA you have the chance to support us by becoming a Sponsor or buying some beer here.

To show your love for EMBA with nice shirts or other merch you can check our Spreadshop.

This is an automatic message. Allow for time for the EMBA community to be able to read the issue and comment on it.

[m-1-k-3]

Indeed the regex defined in the module are quite generic - see here

emba/modules/S14_weak_func_radare_check.sh

Line 321 in c345740

r2 -e bin.cache=true -e io.cache=true -e scr.color=false -q -c 'pI $s' "${BINARY_}" | grep -A 2 -B 20 "bl.*${FUNCTION}" 2> /dev/null >> "${FUNC_LOG}" || true

[m-1-k-3]

hmmm, somehow I am not able to reproduce this issue:

wget https://pkg.freebsd.org/FreeBSD:14:aarch64/latest/All/boost-libs-1.84.0.pkg
tar --zstd -x -f ./boost-libs-1.84.0.pkg
file usr/local/lib/libboost_filesystem.so.1.84.0
usr/local/lib/libboost_filesystem.so.1.84.0: ELF 64-bit LSB shared object, ARM aarch64, version 1 (FreeBSD), dynamically linked, for FreeBSD 14.0 (1400097), stripped

r2 -e bin.cache=true -e io.cache=true -e scr.color=false -q -c 'pI $s' usr/local/lib/libboost_filesystem.so.1.84.0 | grep -E "bl.*system"

=> no results at all
Do I miss something?

[ghechenberger]

Sorry, my fault, I screwed up the minimal example by documenting the wrong package. It seems compiler type (or settings) matter. Please try again using the libboost_filesystem from the Debian 12 package (now double-checked) here http://ftp.de.debian.org/debian/pool/main/b/boost1.81/libboost-filesystem1.81.0_1.81.0-5+deb12u1_armhf.deb

Expected output:

[+] /issue2/libboost_filesystem.so.1.81.0 (-rw-r--r-- root root) - common linux file: no - Vulnerable function: printf / Function count: 37 / networking: no
[+] /issue2/libboost_filesystem.so.1.81.0 (-rw-r--r-- root root) - common linux file: no - Vulnerable function: system / Function count: 79 / networking: no

[m-1-k-3]

looks good ... thank you

┌──(m1k3㉿kali-emba)-[~/…/testimages/web/package-collection/deb_test]
└─$ tar xvf data.tar.xz                       
./
./usr/
./usr/lib/
./usr/lib/arm-linux-gnueabihf/
./usr/lib/arm-linux-gnueabihf/libboost_filesystem.so.1.81.0
./usr/share/
./usr/share/doc/
./usr/share/doc/libboost-filesystem1.81.0/
./usr/share/doc/libboost-filesystem1.81.0/changelog.Debian.gz
./usr/share/doc/libboost-filesystem1.81.0/copyright
./usr/share/lintian/
./usr/share/lintian/overrides/
./usr/share/lintian/overrides/libboost-filesystem1.81.0
                                                                                                                                                                                                                                            
┌──(m1k3㉿kali-emba)-[~/…/testimages/web/package-collection/deb_test]
└─$ file ./usr/lib/arm-linux-gnueabihf/libboost_filesystem.so.1.81.0                                                                                                
./usr/lib/arm-linux-gnueabihf/libboost_filesystem.so.1.81.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=193a1cb205afb41343c3b03dac9a3e5902e3a44a, stripped
                                                                                                                                                                                                                                            
┌──(m1k3㉿kali-emba)-[~/…/testimages/web/package-collection/deb_test]
└─$ r2 -e bin.cache=true -e io.cache=true -e scr.color=false -q -c 'pI $s' ./usr/lib/arm-linux-gnueabihf/libboost_filesystem.so.1.81.0 | grep "bl.*system"
Cannot determine entrypoint, using 0x00006220.
bl method boost::filesystem::detail::copy(boost::filesystem::path const&, boost::filesystem::path const&, unsigned int, boost::system::error_code*)
bl method boost::filesystem::path::append_v3(char const*, char const*)
bl _ZN5boost10filesystem4path9append_v4EPKcS3_

[github-actions]

This issue is stale because it has been open for 28 days with no activity.