getsentry
Adjust compiler settings to best practices
Description
Hello, during the last pen test of our app, the testers noticed that some compiler settings do not comply with best practices.
Debugging symbols: During the compilation process of the app, debugging symbols are not removed. This makes it easier for potential attackers to reverse engineer the app by exposing internal information about the app. To remove debugging symbols, the following 3 options should be set to “Yes” for the release version in the build settings of the Xcode project:
- Strip Debug Symbols During Copy:
- `COPY_PHASE_STRIP = YES`
- Strip Linked Product:
- `STRIP_INSTALLED_PRODUCT = YES`
- Deployment Postprocessing:
- `DEPLOYMENT_POSTPROCESSING = YES`
Stack Canaries: The stack canaries are deactivated. This facilitates the use of so-called buffer overflows, with which it is possible to change the behavior of the application at runtime. Using the compiler option fstack-protector-all activates the stack canaries.
- Stack canaries
- `OTHER_CFLAGS[arch=*] = “-fstack-protector-all”`
Request: Is there something against completing these pen test recommendations in the release configuration of the SDK?
Hello @omninode, thanks for reaching out.
This makes it easier for potential attackers to reverse engineer the app
This is not a concern since our SDK is open source, but I do agree we don't need to ship it with debug symbols, in order to save some bytes.
How are you using Sentry (SPM, cocoapods, pre-build framework)?
Stack Canaries
Im not familiar with this, we need to investigate.
Hi,
on behalf of @omninode, who is on vacation this week: we're using Sentry via SPM.
kind regards, Steffen
We're gonna investigate if stripping debug symbols has a potential to deteriorate ability to symbolicate Sentry stack frames.
We're currently not planning to auto-enable stack canaries for all builds. If you want/need to use it, you currently need to build the SDK yourself with the desired compiler flags and settings.
Hello, Any plans for merging this PR in production. I am getting same issue raised by pen testers. P.S using SDK via SPM
No, sorry @aadeshAvoma, we don't have an update for this issue or an ETA yet.
@philipphofmann Could you please advise on the recommended approach to mitigate this security concern raised during our penetration testing, other than forking and applying a local fix? It would also be greatly appreciated if this could be acknowledged as an issue, so that it may be considered for prioritization in your task list.
@philipphofmann Could you please advise on the recommended approach to mitigate this security concern raised during our penetration testing, other than forking and applying a local fix? It would also be greatly appreciated if this could be acknowledged as an issue, so that it may be considered for prioritization in your task list.
I wonder why this is flagged as a security concern, all these affect our generated SDK. So yes, it would be easier to reverse engineer the Sentry SDK, but that doesn't affect your app which is using Sentry. (Sentry is open source, so there is no risk for any RE here)
Also, if you have STRIP_INSTALLED_PRODUCT in your application configuration you will strip everything after linking.
You can also use https://docs.emergetools.com/docs/strip-binary-symbols to manually strip everything from your dependencies
As for fstack-protector-all, seems interesting, but it creates a larger binary and possibly run slower.
Looks like we will need to test it
Closing this issue since:
- Settings in the SDK should not affect security within another app.
- I see that
COPY_PHASE_STRIPandSTRIP_INSTALLED_PRODUCTare already enabled when building the SDK for release.
Regarding the stack protection flag, I created another issue to follow this up: #6699