From 786b79ca2542a9beaff62179effbc5106ea71d68 Mon Sep 17 00:00:00 2001 From: Dennis Titze Date: Thu, 7 Nov 2024 16:45:41 +0000 Subject: [PATCH] Update texts --- tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-1.md | 2 +- tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-2.md | 8 ++++++-- tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-3.md | 14 +++++++++----- 3 files changed, 16 insertions(+), 8 deletions(-) diff --git a/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-1.md b/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-1.md index 264d0912d9..922dcfd560 100644 --- a/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-1.md +++ b/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-1.md @@ -12,7 +12,7 @@ weakness: MASWE-0116 Conversely, shared libraries with the `MH_DYLIB` file type (dylibs and frameworks) are inherently position-independent and do not utilize the `MH_PIE` flag. -This test case checks if the main executable is compiled without PIE. +This test case checks if the main executable is compiled with PIE. ## Steps diff --git a/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-2.md b/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-2.md index e07ae8c469..fc03d7d7d2 100644 --- a/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-2.md +++ b/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-2.md @@ -10,7 +10,7 @@ weakness: MASWE-0116 This test case checks if the main binary or any libraries of the app are compiled without stack canaries and therefore lack [stack smashing protection](../../../Document/0x06i-Testing-Code-Quality-and-Build-Settings/#binary-protection-mechanisms), a common mitigation technique against buffer overflow attacks. -This test applies to all binaries and libraries, but is especially important for non-memory safe code like Objective-C or C/C++. +This test applies to all binaries and libraries, but is especially important for non-memory safe languages like Objective-C or C/C++. ## Steps @@ -18,9 +18,13 @@ This test applies to all binaries and libraries, but is especially important for 2. Run @MASTG-TECH-0113 on the main binary (`App.app/YourApp`) and each shared library (e.g., stored in the Frameworks folder) 3. If the output contains the symbol `__stack_chk_fail` it indicates stack canaries are enabled. +!!! note Completeness of the check + Checking for the symbol `__stack_chk_fail` only indicates that stack smashing protection is enabled somewhere in the app. Whilst stack canaries are typically enabled or disabled for the whole binary, there can be corner cases, where only parts of the application are protected. E.g., when the app developer statically links a library with enables stack smashing protection, but disables it for the whole application. + If you want to be sure specific security critical methods are protected sufficiently, you need to reverse engineer each, and check for stack smashing protection manually. + ## Observation -The output should list of symbols of the main binary and each shared library. +The output should contain a list of symbols of the main binary and each shared library. ## Evaluation diff --git a/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-3.md b/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-3.md index 2970d0522c..4dbbde4793 100644 --- a/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-3.md +++ b/tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-3.md @@ -10,9 +10,9 @@ weakness: MASWE-0116 [ARC (Automatic Reference Counting)](../../../Document/0x04h-Testing-Code-Quality/#automatic-reference-counting) is a memory management feature of the compiler for the Objective-C and Swift code. -The main binary and all libraries should have ARC enabled if they contain Objective-C or Swift code. - - For libraries written purely in Swift, ARC is enabled by default. +The main binary and all libraries should enable ARC if they contain Objective-C or Swift code. - For libraries containing Objective-C code, it can be enabled via the `-fobjc-arc` of clang. + - For libraries written purely in Swift, ARC is enabled by default. For libraries written purely in C/C++, ARC is not available. @@ -24,12 +24,16 @@ This test case checks if ARC is enabled. 1. Extract the application. 2. Run @MASTG-TECH-0113 on the main binary (`App.app/YourApp`) and each shared library (e.g., stored in the Frameworks folder) -3. If the output contains symbols indicating the usage of Objective-C (e.g., `__objc_data...`) or symbols indicating the usage of Swift (e.g., `_swift_allocObject`), check if the symbols `objc_autorelease` or `objc_retainAutorelease` exist in the app. +3. If the output contains symbols indicating the usage of Objective-C (e.g., `_objc_msgSend`) or symbols indicating the usage of Swift (e.g., `_swift_allocObject`), check if the symbols `objc_autorelease` or `objc_retainAutorelease` exist in the main binary and each shared library. + +!!! note Completeness of the check + Checking for these symbols only indicates that ARC is enabled somewhere in the app. Whilst typically ARC will be enabled or disabled for the whole binary, there can be corner cases, where only parts of the application or libraries are protected. E.g., when the app developer statically links a library that has ARC enabled, but disables it for the whole application. + If you want to be sure specific security critical methods are protected sufficiently, you need to reverse engineer each, and check for ARC manually. ## Observation -The output should list of symbols of the main binary and each shared library. +The output should contain a list of symbols of the main binary and each shared library. ## Evaluation -The test case fails any binary or library is not purely C/C++ but does not contain methods indicating ARC is present like `objc_autorelease` or `objc_retainAutorelease`. +The test case fails if any binary or library is not purely C/C++ and does not contain methods indicating ARC is present like `objc_autorelease` or `objc_retainAutorelease`.