Stack smashing protection has not been implemented in components included in the application. When an application is compiled with stack smashing protection, a known value or "canary" is placed on the stack directly before the local variables to protect the saved base pointer, saved instruction pointer, and function arguments. The value of the canary is verified upon the function return to see if it has been overwritten. The compiler uses a heuristic to intelligently apply stack protection to a function, typically functions using character arrays.
One thing to note: it is possible that an included, pre-compiled binary does not have these protections and it is possible that a third party would have to correct the problem.
This is a very simple best practice that hardens your app with little to no downside. Memory corruption vulnerabilities can be very hard to track down, but can be extremely severe.
One thing to note: it is possible that an included binary does not have these protections and it is possible that a third party would have to correct the problem. In a rare edge case, Xamarin does include a library called libxamarin-app.so that is not compiled with SSP but may not be vulnerable because it is an empty file. Users should validate that it is in fact empty before hiding that specific result.
Steps to Reproduce
This test checks if the individual components inside the compiled binary used stack canaries to prevent buffer overflows.
Business Impact
This app does not protect against a specific type of attack that can expose the app to an attacker performing custom actions. These custom actions could potentially give them access to sensitive information from the app or the device.
Remediation Resources
iOS
In XCode, under the Build Settings for the app, go to the "Other C Flags" section and add in -fstack-protector-all. More reading can be done on Apple's developer library
Android
Because the Android NDK handles this automatically, it may be worthwhile to switch over to using that capability to manage native libraries. More information can be found at https://developer.android.com/ndk.
If using the provided NDK is not an option, then the issue is likely in the compiler settings for the native libraries that caused the vulnerability to pop up. Make sure that the -fstack-protector-all, -fpic, and -fstack-protector-strong flags are all set in the build.gradle file (typically in the cmake/cppFlags).
The third possibility is that there is a third party library causing this problem. As an example the hybrid framework Flutter will not compile using stack canaries because of the way Dart mitigates buffer overflows. The libraries and their mitigations should be evaluated and handled according to the company's security standards.
Finding Description
Stack smashing protection has not been implemented in components included in the application. When an application is compiled with stack smashing protection, a known value or "canary" is placed on the stack directly before the local variables to protect the saved base pointer, saved instruction pointer, and function arguments. The value of the canary is verified upon the function return to see if it has been overwritten. The compiler uses a heuristic to intelligently apply stack protection to a function, typically functions using character arrays. One thing to note: it is possible that an included, pre-compiled binary does not have these protections and it is possible that a third party would have to correct the problem. This is a very simple best practice that hardens your app with little to no downside. Memory corruption vulnerabilities can be very hard to track down, but can be extremely severe. One thing to note: it is possible that an included binary does not have these protections and it is possible that a third party would have to correct the problem. In a rare edge case, Xamarin does include a library called
libxamarin-app.sothat is not compiled with SSP but may not be vulnerable because it is an empty file. Users should validate that it is in fact empty before hiding that specific result.Steps to Reproduce
This test checks if the individual components inside the compiled binary used stack canaries to prevent buffer overflows.
Business Impact
This app does not protect against a specific type of attack that can expose the app to an attacker performing custom actions. These custom actions could potentially give them access to sensitive information from the app or the device.
Remediation Resources
iOS
In XCode, under the Build Settings for the app, go to the "Other C Flags" section and add in
-fstack-protector-all. More reading can be done on Apple's developer libraryAndroid
Because the Android NDK handles this automatically, it may be worthwhile to switch over to using that capability to manage native libraries. More information can be found at https://developer.android.com/ndk.
If using the provided NDK is not an option, then the issue is likely in the compiler settings for the native libraries that caused the vulnerability to pop up. Make sure that the
-fstack-protector-all,-fpic, and-fstack-protector-strongflags are all set in thebuild.gradlefile (typically in thecmake/cppFlags).The third possibility is that there is a third party library causing this problem. As an example the hybrid framework Flutter will not compile using stack canaries because of the way Dart mitigates buffer overflows. The libraries and their mitigations should be evaluated and handled according to the company's security standards.
Risk and Regulatory Information
Severity: low CVSS: 1.6
Application
See more detail in the NowSecure Report