Fresh Project Using Insecure APIs (_sscanf, _strlen, _fopen, malloc) in Binary

Hello Apple Developer Community,

I recently created a fresh project with:

No dependencies No additional written code After generating the iOS build, I navigated to the build folder:"build/ios/iphoneos/Runner.app"

Then, I ran the following otool commands to inspect the binary: otool -Iv Runner | grep -w _strlen otool -Iv Runner | grep -w _malloc

Surprisingly, I received positive results, meaning these functions are present in the binary.

My Questions:

Why is a fresh project (with no extra dependencies & No additional written code) including these APIs in the binary?

Answered by DTS Engineer in 827422022

Based on the path you posted, I suspect you’re building the app with Flutter. If so, this is something you should ask via that tool’s support channel. However, in general:

  • Determining Why a Symbol is Referenced explains how to track down which code is referencing a specific symbol.

  • I agree with endecotp that you need to think carefully about how you interpret the results of static analysis tools like this. I’ve seen tools that report that calloc is ‘good’ and malloc is ‘bad’, but that’s utter nonsense because a reasonable way to implement calloc is by combining malloc and memset.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

All of the so-called “secure” APIs are built on top of the so-called “insecure” APIs, in particular malloc.

The point is that these “insecure” APIs are only insecure if you use them wrongly. You need to trust that the people who have used malloc and strlen in e.g. the Swift or obC runtime are smarter than you and use them safely.

Based on the path you posted, I suspect you’re building the app with Flutter. If so, this is something you should ask via that tool’s support channel. However, in general:

  • Determining Why a Symbol is Referenced explains how to track down which code is referencing a specific symbol.

  • I agree with endecotp that you need to think carefully about how you interpret the results of static analysis tools like this. I’ve seen tools that report that calloc is ‘good’ and malloc is ‘bad’, but that’s utter nonsense because a reasonable way to implement calloc is by combining malloc and memset.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Fresh Project Using Insecure APIs (_sscanf, _strlen, _fopen, malloc) in Binary
 
 
Q