You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@anda5 regarding your first set of warnings - what build of your application did you submit for scanning? Debug or Release?
Regarding the PIE issue - the diagnostics is wrong. PIE applies only when linking executables, while Xamarin.Android native runtime is all shared libraries, in which case one should use the -fPIC/-fpic options, if supported by the target architecture - Xamarin.Android uses these options.
I scan the release apk, and I used Target Android version 10. Also I try to do the same scan using BugSweeper app from xamarin-forms/samples and I get the same result. Initialy i tought that if I will have the last Xamarin.Forms version it will work, but not. @grendello So you suggest that the scanning libs disgnostics are wrong?
@anda5 yes, and not only regarding PIE but also regarding e.g. _FORTIFY_SOURCE=2 - this flag is added automatically by Android NDK when bulding. RELRO is half right - currently we pass it only when building with g++ but that's going to change soon. The diagnostics about missing PIC is also incorrect, that option is also added automatically by the NDK (and we specify it ourselves to be certain, too)
@anda5 the IP address disclosure is caused by a regexp which looks for the x.x.x.x pattern, where each x is an up to 3-digit sequence. However, in our case it matches a ... version number
Another diagnostics that's not correct is the lack of stack fortification, while we build with the strong stack protector. @anda5 I'm sorry, but this report is mostly wrong.
@anda5 Static analysis is a tricky business and all and any results you get need to be examined with a thorough understanding and analysis of the reported issue. In the past I used Coverity, it was good. Note that our native code uses built-in clang static analyzers (we don't distribute the binaries we build with these analytics built in as they are very slow, but we do build them), and such analyzers do a better job of spotting both source and runtime issues since they instrument the binary code and are able to analyze the source code as it's being compiled.
If your application builds any native code, I would strongly suggest you read up on all the sanitizers here. A good idea is to use strong stack protector when building native code and also, if possible, run it under a leak detector (like valgrind)
@anda5 you're welcome! Also, for managed code you might want to get interested in Roslyn static analyzers. Xamarin.Android recently added support for Roslyn analyzers for our own code, if you want to see how it is integrated into the build system.
Activity
grendello commentedon Feb 12, 2021
@anda5 regarding your first set of warnings - what build of your application did you submit for scanning? Debug or Release?
Regarding the
PIEissue - the diagnostics is wrong.PIEapplies only when linking executables, whileXamarin.Androidnative runtime is all shared libraries, in which case one should use the-fPIC/-fpicoptions, if supported by the target architecture -Xamarin.Androiduses these options.anda5 commentedon Feb 12, 2021
I scan the release apk, and I used Target Android version 10. Also I try to do the same scan using BugSweeper app from xamarin-forms/samples and I get the same result. Initialy i tought that if I will have the last Xamarin.Forms version it will work, but not.
@grendello So you suggest that the scanning libs disgnostics are wrong?
grendello commentedon Feb 12, 2021
@anda5 yes, and not only regarding
PIEbut also regarding e.g._FORTIFY_SOURCE=2- this flag is added automatically by Android NDK when bulding.RELROis half right - currently we pass it only when building withg++but that's going to change soon. The diagnostics about missingPICis also incorrect, that option is also added automatically by the NDK (and we specify it ourselves to be certain, too)anda5 commentedon Feb 12, 2021
Look at this full scan report, maybe it helps:
app_scan.pdf
grendello commentedon Feb 12, 2021
@anda5 the
IP address disclosureis caused by a regexp which looks for thex.x.x.xpattern, where eachxis an up to 3-digit sequence. However, in our case it matches a ... version numberanda5 commentedon Feb 12, 2021
So I should open this issue to MOBSF
grendello commentedon Feb 12, 2021
Another diagnostics that's not correct is the lack of stack fortification, while we build with the strong stack protector. @anda5 I'm sorry, but this report is mostly wrong.
anda5 commentedon Feb 12, 2021
Do you know an better tool for scanning the security? It will be very helpful for me.
grendello commentedon Feb 12, 2021
@anda5 Static analysis is a tricky business and all and any results you get need to be examined with a thorough understanding and analysis of the reported issue. In the past I used Coverity, it was good. Note that our native code uses built-in clang static analyzers (we don't distribute the binaries we build with these analytics built in as they are very slow, but we do build them), and such analyzers do a better job of spotting both source and runtime issues since they instrument the binary code and are able to analyze the source code as it's being compiled.
If your application builds any native code, I would strongly suggest you read up on all the sanitizers here. A good idea is to use strong stack protector when building native code and also, if possible, run it under a leak detector (like
valgrind)anda5 commentedon Feb 12, 2021
@grendello thank you so much for investigating this, and also for the clarification.
grendello commentedon Feb 12, 2021
@anda5 you're welcome! Also, for managed code you might want to get interested in Roslyn static analyzers. Xamarin.Android recently added support for Roslyn analyzers for our own code, if you want to see how it is integrated into the build system.
[Java.Interop-Tests] Initial `dotnet test` support
[Java.Interop-Tests] Initial `dotnet test` support
[Java.Interop-Tests] Initial `dotnet test` support
[Java.Interop-Tests] Initial `dotnet test` support (#801)
abdi191188 commentedon Jul 22, 2022
@anda5 were you able to resolve this issue?
jpobst commentedon Sep 6, 2022
Sounds like this was fixed in MobSf`:
MobSF/Mobile-Security-Framework-MobSF#1676