Exploits, Tools & Data Recovery · Bug Classes & Mitigations · Lesson 2 of 5

Logic & Permission Bugs

Bugs where memory is fine but the rules are wrong, from open doors to tricked helpers.

Right code, wrong rules

Not every serious bug involves memory. A logic bug is a mistake in the rules a program follows. Every byte lands exactly where it should, and the program does precisely what its code says. The problem is that the code says the wrong thing.

The most common kind in phone security is a missing permission check. Picture an office building with a guard who checks badges at the front door, while a side door is propped open. Nobody broke anything. Someone just forgot that the side door existed. In code, this might be a function that deletes an account or reads saved messages but never asks whether the caller is allowed to do that.

You saw a classic example in Android App Security: exported components. An activity or service marked exported can be reached by any app on the phone. If a developer exports an internal "reset account" screen and assumes only their own app will open it, any other app can open it too, and the screen's missing login check becomes a real hole.

A sneakier version is the confused deputy, a term from a 1988 paper by computer scientist Norm Hardy. A deputy is a program that holds more power than the person asking it for help. The attack doesn't break the deputy. It tricks the deputy into using its own power on someone else's behalf.

Here's an everyday version. A hotel concierge has a master key. A guest says, "I locked myself out of room 512," and the concierge opens it without checking that the guest actually is staying in 512. The concierge is the deputy, and the master key did the damage.

On a phone, the deputy is often a system app or service with special permissions. If it will save a file or send a message wherever any app asks, an app with no permissions of its own can borrow those powers. The fix is for the deputy to check the caller's rights, not just its own.

Parsers, and why safe languages don't fix logic

Messages, photos, links and files all arrive as raw data that the phone must take apart to understand. That step is called parsing, and the code that does it is a parser. Parsers are a favorite target because they handle data from strangers, often automatically.

Parsing bugs come in both kinds. Some are memory bugs, such as a parser written in C++ that writes past the end of a box when a picture claims a strange size. Others are logic bugs, where two parts of a system disagree about what the data is. You saw a high-level example in Mobile Malware. In FORCEDENTRY, a file named like a GIF was really a PDF, and iMessage chose how to handle it by its content. That sent it to a PDF parser outside the BlastDoor sandbox. The bug that let code run was a memory bug, but the routing decision is what put the dangerous parser within reach.

Logic bugs matter for a bigger reason too. In module 4 you'll see companies switching to memory-safe languages, languages that check memory use automatically so memory corruption can't happen in normal code. That's a huge win, but it doesn't touch logic bugs. A language can stop you from writing past the end of a form. It can't know that "reset account" should require a login, or that a concierge should check the guest list. Those are rules about your product, and only people can decide them.

Google noticed this pattern. In 2022 it said the vulnerabilities it sees in Android's Java code are largely logic bugs, and that they are generally lower in severity. A permission bypass usually opens one specific door, while code execution opens all of them.

Defenses for logic bugs are mostly careful engineering: clear permission checks at every entrance, exporting only what must be public, giving each component the least power it needs, design reviews that ask "who can call this?", and tests that try the side doors.