Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday August 12 2019, @12:37PM   Printer-friendly
from the yes-it's-defcon-week dept.

Submitted via IRC for AnonymousCoward

SELECT code_execution FROM * USING SQLite: Eggheads lift the lid on DB security hi-jinks

At the DEF CON hacking conference in Las Vegas on Saturday, infosec gurus from Check Point are scheduled to describe a technique for exploiting SQLite, a database used in applications across every major desktop and mobile operating system, to gain arbitrary code execution.

In a technical summary provided to The Register ahead of their presentation, Check Point's Omer Gull sets out how he and his colleague Omri Herscovici developed techniques referred to as Query Hijacking and Query Oriented Programming, in order to execute malicious code on a system. Query Oriented Programming is similar in a way to return oriented programming in that it relies on assembling malicious code from blocks of CPU instructions in a program's RAM. The difference is that QOP is done with SQL queries.

[...] It must be stressed, though, that to pull off Check Point's techniques to hack a given application via SQLite, you need file-system access permissions to alter that app's SQLite database file, and that isn't always possible. If you can change a program's database file, you can probably get, or already have achieved, code execution on the system by some other means anyway.

Nonetheless, it's a fascinating look into modern methods of code exploitation, and a neat set of discoveries.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Tuesday August 13 2019, @06:26AM (1 child)

    by Anonymous Coward on Tuesday August 13 2019, @06:26AM (#879517)

    Hmmm... there are a few things out of place here:

    1) SQLite databases shouldn't be shared beween applications, it seems that developers are actually doing this. SQLite can't be blamed for being misused.
    2) SQLite database file permissions should restrict only to readonly access or write access only to the user/program that owns the database file. OSes have file permissions for a reason, seems like someone doesn't care for them. If you open something globally accessable you should validate your input, before using it. Again, wrong permissions are a bug, not a feature.

    that having said:

    3) How does this work with in-memory databases? If it doesn't work with in-memory databases, it proves my points above.

  • (Score: 0) by Anonymous Coward on Tuesday August 13 2019, @07:46AM

    by Anonymous Coward on Tuesday August 13 2019, @07:46AM (#879531)

    You can share SQLite files between instances of different applications just fine. In fact, it is the preferred format for archiving databases and other relational data. In addition, it has widespread usage as various application file formats as an alternative to rolling your own or using a zip file full of other files. Not to mention both use cases are explicitly mentioned and supported in the official documentation.

    Second, there are plenty of abuses that this can be leveraged to use in a single process. The most obvious being persistence across reboots, poisoning forked workers, or evading cleaning attempts. And that doesn't get into what the same user can do on many systems. Additionally, you really only need to get ACE in one process, as long as it is the right one.

    Third, you could also use this to poison :memory: databases too. The barrier is much higher, but it is worth noting that not all of the methods require direct memory manipulation of the victim.