Security audit report 4 insecures issues inside ipa

RomainDuclos

Hi, our app written with Xamarin.iOS 6.3 and XCode 8.3 was tested by a security check and 4 issues were found

1. fobj-arc flag is not found

   App is not compiled with Automatic Reference Counting (ARC) flag.
   ARC is a compiler feature that provides automatic memory
   management of Objective-C objects and protects from memory
   corruption vulnerabilities.

   => I tried the -gcc-flags "-fobj-orc" parameters with same result

2. Binary make use of banned API(s)

   The binary may contain the following banned API(s)
   vsnprintf, sscanf, strtok, strlen, strcat, alloca, strcpy, sprintf,
   printf, gets, vsprintf, memcpy, strncpy.

   => Any chance we can change that ?

3. Binary make use of the following Weak HASH API(s)

   The binary may use the following weak hash API(s)
   CC_MD2_Final, CC_MD5_Update, CC_MD4_Update, CC_MD4_Init,
   CC_MD2_Update, CC_SHA1_Init, CC_SHA1_Update,
   CC_MD2_Init, CC_MD4_Final, CC_MD5_Final, CC_SHA1_Final,
   CC_MD5_Init.

   => We reference an external library and I think these old crypting apis are used for crypting pdf

4. Binary make use of malloc Function

   The binary may use malloc function instead of calloc.

   =>Is-it possible to change this when converting to Objectiv-C ?

Any helps would be greatly appreciated...

Regards

MigueldeIcaza

This is not really an issue.

fobj-arc flag is not found

This is not really a security issue, but one that can improve the reliability of the application for Objective-C developers.

.NET is a managed runtime that provides a strong type system and a garbage collector, so the above is not necessary.

Binary make use of banned API(s)

This statement is incorrect. These are not banned APIs by Apple, but generally, it is a good idea to avoid those as they can often be misused. If they were banned, applications would be rejected by Apple.

Xamarin’s use of those APIs has been audited in the past and found to be correct. They are used by the low-level runtime, and generally user code runs with the safer higher level runtime implemented by .NET

Binary make use of the following Weak HASH API(s)

These methods are used for interoperability purposes with .NET libraries (strong names) that use and surface MD5 and SHA1 as a non-human editable way of specifying versions. They are not used to enforce any security.

Binary make use of malloc Function

There is nothing wrong with using malloc, like the previous list of APIs, those uses have been audited. Calloc clears the allocated memory, which helps in case buffers are reused, or to make sure that the code does not rely on uninitialized data. For .NET code this guarantee comes in a number of ways, either objects are allocated as zero, or the compiler ensures that all data has been initialized. For the low-level code, that code is limited in scope and has been audited in the past.