Google Play rolls out an "Independent security review" badge for apps
bleepingcomputer.com
bleepingcomputer.com
> Specifically, that standard is MASA (Mobile App Security Assessment), which was introduced last year as an initiative of the App Defense Alliance (ADA) to define a concrete set of requirements for mobile app security.
> The requirements concern data storage and data privacy practices, cryptography, authentication and session management, network communication, platform interaction, and code quality.
App Defense Alliance > Mobile Application Security Assessment: https://appdefensealliance.dev/masa
OWASP Mobile Application Security: https://mas.owasp.org/ :
> The OWASP Mobile Application Security (MAS) flagship project provides a security standard for mobile apps (OWASP MASVS) and a comprehensive testing guide (OWASP MASTG) that covers the processes, techniques, and tools used during a mobile app security test, as well as an exhaustive set of test cases
OWASP MAS Checklist .xlsx: https://github.com/OWASP/owasp-mastg/releases/latest/downloa...
OWASP/owasp-mastg: https://github.com/OWASP/owasp-mastg :
> The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS).
OWASP/owasp-masvs: https://github.com/OWASP/owasp-masvs :
> The OWASP MASVS (Mobile Application Security Verification Standard) is the industry standard for mobile app security.
> Debugging symbols have been removed from native binaries
What's wrong with debugging symbols, from a security perspective? What if you desire maximum inspectability of the internals?
Other than that, these guidelines seem great.
> Generally, you should provide compiled code with as little explanation as possible. Some metadata, such as debugging information, line numbers, and descriptive function or method names, make the binary or bytecode easier for the reverse engineer to understand, but these aren't needed in a release build and can therefore be safely omitted without impacting the app's functionality.
I'm not a big fan of the reasoning, as it's security through obscurity. Which is not the worst tradeoff, as many vulnerable systems hold up for years thanks to machine code obfsucation, but these days it just makes public bug bounties (and other public auditing) end up being less of an interesting prospect for improving security. Many bug bounties nowadays help participants by, for example, leaving an entire web API's documentation open to view. It's the same sort of thing as leaving source code public -- should that be a disqualifier under such guidelines?
gdb on Fedora auto-installs signed debuginfo packages with debug symbols; Fedora hosts a debuginfod server for their packages (which are built by Koji) and sets `DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/ ` : https://fedoraproject.org/wiki/Debuginfod https://fedoraproject.org/wiki/Changes/DebuginfodByDefault#S...
Without debug symbols, a debugger has to read unlabeled ASM instructions (or VM opcodes (or an LL IR)).
From "Show HN: Tetris, but the blocks are ARM instructions that execute in the browser" https://news.ycombinator.com/item?id=37086102 :
> "Ask HN: How did you learn x86-64 assembly?" (2020) re: HLA, : https://news.ycombinator.com/item?id=23931373 re: the Diaphora bindiff tool and ghidra, which has GDB support now FWIU: https://news.ycombinator.com/item?id=36454485
"Show HN: Ghidra Plays Mario" the NES ROM. https://news.ycombinator.com/item?id=37475761
(It seems like that DebuginfodByDefault FAQ is discussing the security implications of the debugger's parsing of debug symbols itself, rather that of the security of shipping debug symbols in the first place)