Binaries produced by .Net Maui compile on Android does not enable security flags

[paul-kiar]

Description

When you build a .Net Maui project it generates binaries that do not have all the security flags turned on.

Steps to Reproduce

Reproduction steps

Create a new project
Select .Net Maui App
Select .Net 9.0 
Choose Release mode
Build 
Find the output APK
Use apktool to extract the APK
Use checksec tool to verify flags on the .so files inside the APK

Expected that security flags are set on the output binaries

Actually the flags are:

Partial RELRO

No Canary found

NX enabled

DSO

No RPATH

No RUNPATH

Link to public reproduction project repository

No response

Version with bug

8.0.92 SR9.2

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

No response

Affected platforms

Android

Affected platform versions

All

Did you find any workaround?

No response

Relevant log output

[jonpryor]

What is checksec, and how does this issue overall differ from:

• Shared Library Binary Analysis #6258
• Stack protection disabled in Library Analysis #8053
• MobSF static analysis #8181

[jonpryor]

If checksec refers to checksec.sh on trapkit.de, then:

% checksec.sh --file libxamarin-app.so
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Partial RELRO   No canary found   NX enabled    DSO             No RPATH   No RUNPATH   libxamarin-app.so

then this is expected; libxamarin-app.so only has one function, which does not contain arrays, and thus there is nothing to have a stack canary; see also: #8053 (comment)

checksec.sh also doesn't like our AOT-generated binaries, e.g.

% checksec.sh --file libaot-System.Private.CoreLib.dll.so 
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Partial RELRO   No canary found   NX enabled    DSO             No RPATH   No RUNPATH   libaot-System.Private.CoreLib.dll.so

[paul-kiar]

Yes it is the checksec.sh script that generates this report as you found.

It is on all binaries generated by maui

The output for a release build library that is in our APK is the same:

Partial RELRO | No Canary found | NX enabled | DSO | No RPATH | No RUNPATH | No Symbols | No | 0 | 0 | ./libaot-Apm.Mobile.Inspections.dll.so

This file is 520kb, there is not just one function in this binary.

[paul-kiar]

After reading #6258, #8053, #8181 yes it appears that they are similar. My search failed to find these bugs (probably because my search terms are all in the pictures).

Full RELRO
Stack Canary
Fortify Source

Is there a way in maui to enable these protections in AOT libraries?

[jonpryor]

@paul-kiar wrote:

This file is 520kb, there is not just one function in this binary.

Consider again libaot-System.Private.CoreLib.dll.so, which is 4.2MB in size:

% checksec.sh --file libaot-System.Private.CoreLib.dll.so
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
Partial RELRO   No canary found   NX enabled    DSO             No RPATH   No RUNPATH   libaot-System.Private.CoreLib.dll.so

What does it have?

% nm -D libaot-System.Private.CoreLib.dll.so
000000000043a3e8 D mono_aot_file_info

In fact, there are no functions in this binary. It has one symbol, which is Data (D). This is not executable code, from the dlopen() perspective; executable code would be T. libaot-Apm.Mobile.Inspections.dll.so is in the same scenario: it's AOT data for use by MonoVM's JIT. It has no native callable functions. It has nothing which requires a canary.

Canaries are desirable for (1) executable code, which (2) has on-stack arrays that can be overwritten:

void this_could_use_a_canary (void)
{
    char buf[1];
    sprintf (buf, "%s", "hello");
}

If you're not executable code, there's nowhere for the canary to go.

If you don't have an on-stack buffer, the canary is pointless; the purpose of the canary is to track buffer overruns within the function, and if you don't have a buffer, what is there to overrun?

@paul-kiar asked

Is there a way in maui to enable these protections in AOT libraries?

No.