Skip to content

Commit

Permalink
Update texts
Browse files Browse the repository at this point in the history
  • Loading branch information
titze committed Nov 7, 2024
1 parent a5dc65b commit 786b79c
Show file tree
Hide file tree
Showing 3 changed files with 16 additions and 8 deletions.
2 changes: 1 addition & 1 deletion tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-1.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
8 changes: 6 additions & 2 deletions tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-2.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,17 +10,21 @@ 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

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 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

Expand Down
14 changes: 9 additions & 5 deletions tests-beta/ios/MASVS-CODE/MASTG-TEST-0x87-3.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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`.

0 comments on commit 786b79c

Please sign in to comment.