Firebase Crashlytics .so Library Not RELRO Enabled

[beastgamingx99]

#Details
While analyzing the Firebase Crashlytics library for security, I discovered that its shared object (.so) library is not compiled with RELRO (Relocation Read-Only) enabled. This omission weakens the security posture of the library by leaving the Global Offset Table (GOT) writable, potentially allowing an attacker to overwrite critical entries and hijack the control flow of the application.

Attack scenario

#Who Can Exploit the Vulnerability?

*Malicious App Developers: Apps using the Crashlytics library may be targeted by malicious apps installed on the same device.

*Advanced Attackers: Attackers who can exploit existing vulnerabilities in the app (e.g., buffer overflows, memory corruption) to achieve control over writable sections like the GOT.

#What They Gain When Doing So?

*Hijack Control Flow: By overwriting GOT entries, attackers can redirect function calls to their payloads (e.g., custom shellcode or ROP chains).

*Escalated Privileges: Exploiting the library in system apps or privileged processes could allow attackers to escalate privileges or execute arbitrary code.

*Sensitive Data Theft: Control over the application could allow attackers to access sensitive user data or bypass app security mechanisms.

*Device Compromise: In severe cases, it could lead to full device compromise, particularly if the library is used in system-critical apps or services.

#Steps to Reproduce:

*Download and integrate the Firebase Crashlytics library into an Android project.
*Extract the .so files (e.g., using apktool or similar).
*Run the following command to analyze the presence of RELRO:
readelf -l libcrashlytics.so | grep GNU_RELRO

*Observe that no RELRO protection is applied.

#Version Tested:
Crashlytics Version: 19.3.0 (part of Firebase BOM 33.7.0)
Operating System: Windows 11 using MSYS2 MINGW64

#Impact:
Without RELRO, writable sections such as the GOT are vulnerable to attacks, including GOT overwrites. This could allow an attacker to redirect program execution to malicious code or exploit other vulnerabilities in the application or system.

#Suggested Fix:
Enable RELRO during compilation by passing the appropriate linker flags:

For partial RELRO: -Wl,-z,relro
For full RELRO: -Wl,-z,relro,-z,now

#Enabling full RELRO provides additional protection by resolving all relocations at program startup and marking the GOT as read-only for the program's lifetime.

Affected Files

armeabi-v7a:

-libcrashlytics-common.so

arm64-v8a:

-libcrashlytics-trampoline.so

-libcrashlytics-handler.so

-libcrashlytics.so

-ibcrashlytics-common.so

x86_64:

-libcrashlytics-trampoline.so

-libcrashlytics-handler.so

-libcrashlytics.so

-libcrashlytics-common.so

x86:

-libcrashlytics-trampoline.so

-libcrashlytics-handler.so

-libcrashlytics.so

-libcrashlytics-common.so

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[lehcar09]

Hi @beastgamingx99, thank you for reaching out. I tried reproducing the steps you shared, however, I’m having a trouble in checking for RELRO to the .so files.

I understand your concern and that RELRO can help prevent attackers from manipulating the program's code and data. It looks to me that this is more of an improvement to our SDK. I'll go ahead and mark this as a feature request. While we are unable to promise any timeline for this, we'll definitely keep this under our radar. Thank you for raising this. We really appreciate developers who are sharing their feedback since this helps us improve our SDK.

P.S. For folks who find this useful, adding an emoji thumbs up on the original post can help us prioritize adding this to the roadmap.

[lehcar09]

Hey @beastgamingx99, according to our engineer, we have filed a ticket (b/379498315) to have this reviewed by a security team.