FLimburg837285 (Community Member) asked a question.
How to cope with or reduce high false positive rates
Hi,
in our large scale C application we gt a really high false positive rate of 80-90%.
That does seem a bit above average. Nearly all modules show green after pre-scan,
still we have a baffling high amount of false positives, many even were a corresponding and quite obvious safe guard is sitting only 2 lines above. Most false positives are in in the category of integer or buffer overflows.
.png){kind=logo}
Hi @FLimburg837285 (Community Member) ,
This is very difficult to say without more details. For example, is this a Windows or a Linux application?
I would recommend you schedule a consultation call to discuss.
You can check out this knowledge article (https://community.veracode.com/s/article/How-to-schedule-a-consultation-call) on how to schedule a consultation call with us.
Thank you,
Boy Baukema
Linux and a call has already been scheduled.
Good to hear, one of my colleagues should be able to review the configuration with you.
With Linux binaries, one of the things you may want to consider is whether this file only used as an executable, not as a library.
If so you may want to compile your application with the following linker options:
-Wl,--version-script=veracode.expmap
And a veracode.expmap that contains:
{global:main;local:*;};
Without this Veracode Static Analysis treats this as a library with many functions potentially exposed directly to arbitrary input (as this is the default with ELF binaries). With this linker option it will only look at functionality that is directly referenced from the main function.
Thank you,
Boy Baukema
How can you verify on a shell that the executable has been linked with only the main function visible?
nm -D <filename> | grep " T "
Seems to work.
Oddly, I cannot get nm -D to produce any text symbols for my test program, though I'm happy this works for you.
I'm afraid this is poorly supported by standard tools, here's something that works for me:
eu-nm -a $BINARY | grep "|FUNC" | grep -v "LOCAL |FUNC" | grep -v @ | awk '{ print $1 }'
Please note this requires installing 'elfutils' and replacing $BINARY with the path to your binary.
This lists all the symbols of the ELF file, then reduces them to only function information, then ignores standard GLIBC functions (for example "memcpy@@GLIBC_2.14" ) and finally prints only the name of the symbol.
The resulting output for a program using the exportmap looks like this for a test program:
_ZN5boost6system16generic_categoryEv
_ZNK5boost10filesystem4path11parent_pathEv
_ZNK5boost10filesystem4path8filenameEv
_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE4findEcm
_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE7compareEPKc
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev
main
And for that same program without exportmap it has 1655 entries like:
...
_Z10noenc_readP9commchainPcii
_Z10print_helpv
_Z10run_clientiPPcP7sqlite3
_Z11check_usageiPPc
_Z11fatal_errorPKc
_Z11init_clientiPPc
_Z11new_commandv
_Z11noenc_writeP9commchainPcii
_Z11sym_decryptPhiS_S_S_
_Z11sym_encryptPhiS_S_S_
....
where "_Z10print_helpv" is a 'print_help' function in this program.
Thank you,
Boy Baukema