{
	"id": "95441695-324f-4996-8507-73955fec4875",
	"created_at": "2026-05-05T02:44:53.447706Z",
	"updated_at": "2026-05-05T02:46:36.691311Z",
	"deleted_at": null,
	"sha1_hash": "d91ec1e5429dacc20f1ec03c351ecce3c4d6b826",
	"title": "SELECT code_execution FROM * USING SQLite;",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 141333,
	"plain_text": "SELECT code_execution FROM * USING SQLite;\r\nBy Omri Herscovici\r\nPublished: 2019-08-10 · Archived: 2026-05-05 02:33:37 UTC\r\nGaining code execution using a malicious SQLite database\r\nResearch By: Omer Gull\r\ntl;dr\r\nSQLite is one of the most deployed software in the world. However, from a security perspective, it has only been examined\r\nthrough the lens of WebSQL and browser exploitation. We believe that this is just the tip of the iceberg.\r\nIn our long term research, we experimented with the exploitation of memory corruption issues within SQLite without\r\nrelying on any environment other than the SQL language. Using our innovative techniques of Query Hijacking and Query\r\nOriented Programming, we proved it is possible to reliably exploit memory corruptions issues in the SQLite engine. We\r\ndemonstrate these techniques a couple of real-world scenarios: pwning a password stealer backend server, and achieving\r\niOS persistency with higher privileges.\r\nWe hope that by releasing our research and methodology, the security research community will be inspired to continue to\r\nexamine SQLite in the countless scenarios where it is available. Given the fact that SQLite is practically built-in to every\r\nmajor OS, desktop or mobile, the landscape and opportunities are endless. Furthermore, many of the primitives presented\r\nhere are not exclusive to SQLite and can be ported to other SQL engines. Welcome to the brave new world of using the\r\nfamiliar Structured Query Language for exploitation primitives.\r\nMotivation\r\nThis research started when omriher and I were looking at the leaked source code of some notorious password stealers. While\r\nthere are plenty of password stealers out there (Azorult, Loki Bot, and Pony to name a few), their modus operandi is mostly\r\nthe same:\r\nA computer gets infected, and the malware either captures credentials as they are used or collects stored credentials\r\nmaintained by various clients.\r\nIt is not uncommon for client software to use SQLite databases for such purposes.\r\nAfter the malware collects these SQLite files, it sends them to its C2 server where they are parsed using PHP and stored in a\r\ncollective database containing all of the stolen credentials.\r\nSkimming through the leaked source code of such password stealers, we started speculating about the attack surface\r\ndescribed above.\r\nCan we leverage the load and query of an untrusted database to our advantage?\r\nSuch capabilities could have much bigger implications in countless scenarios, as SQLite is one of the most widely deployed\r\npieces of software out there.\r\nA surprisingly complex code base, available in almost any device imaginable. is all the motivation we needed, and so our\r\njourney began.\r\nSQLite Intro\r\nThe chances are high that you are currently using SQLite, even if you are unaware of it.\r\nTo quote its authors:\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 1 of 19\n\nSQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database\r\nengine. SQLite is the most used database engine in the world. SQLite is built into all mobile phones and most computers and\r\ncomes bundled inside countless other applications that people use every day.\r\nUnlike most other SQL databases, SQLite does not have a separate server process. SQLite reads and writes directly to\r\nordinary disk files. A complete SQL database with multiple tables, indices, triggers, and views is contained within a single\r\ndisk file.\r\nAttack Surface\r\nThe following snippet is a fairly generic example of a password stealer backend.\r\nGiven the fact that we control the database and its content, the attack surface available to us can be divided into two parts:\r\nThe load and initial parsing of our database, and the SELECT query performed against it.\r\nThe initial loading done by sqlite3_open is actually a very limited surface; it is basically a lot of setup and configuration\r\ncode for opening the database. Our surface is mainly the header parsing which is battle-tested against AFL.\r\nThings get more interesting as we start querying the database.\r\nUsing SQLite authors’ words:\r\n“The SELECT statement is the most complicated command in the SQL language.”\r\nAlthough we have no control over the query itself (as it is hardcoded in our target), studying the SELECT process carefully\r\nwill prove beneficial in our quest for exploitation.\r\nAs SQLite3 is a virtual machine, every SQL statement must first be compiled into a byte-code program using one of the\r\nsqlite3_prepare* routines.\r\nAmong other operations, the prepare function walks and expands all SELECT subqueries. Part of this process is verifying\r\nthat all relevant objects (like tables or views) actually exist and locating them in the master schema.\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 2 of 19\n\nsqlite_master and DDL\r\nEvery SQLite database has a sqlite_master table that defines the schema for the database and all of its objects (such as\r\ntables, views, indices, etc.).\r\nThe sqlite_master table is defined as:\r\nThe part that is of special interest to us is the sql column.\r\nThis field is the DDL (Data Definition Language) used to describe the object.\r\nIn a sense, the DDL commands are similar to C header files. DDL commands are used to define the structure, names, and\r\ntypes of the data containers within a database, just as a header file typically defines type definitions, structures, classes, and\r\nother data structures.\r\nThese DDL statements actually appear in plain-text if we inspect the database file:\r\nDuring the query preparation, sqlite3LocateTable()  attempts to find the in-memory structure that describes the table we are\r\ninterested in querying.\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 3 of 19\n\nsqlite3LocateTable() reads the schema available in sqlite_master, and if this is the first time doing it, it also has a callback\r\nfor every result that verifies the DDL statement is valid and build the necessary internal data structures that describe the\r\nobject in question.\r\nDDL Patching\r\nLearning about this preparation process, we asked, can we simply replace the DDL that appears in plain-text within the file?\r\nIf we could inject our own SQL to the file perhaps we can affect its behaviour.\r\nBased on the code snippet above, it seems that DDL statements must begin with “create “.\r\nWith this limitation in mind, we needed to assess our surface.\r\nChecking SQLite’s documentation revealed that these are the possible objects we can create:\r\nThe CREATE VIEW command gave us an interesting idea. To put it very simply, VIEWs are just pre-packaged SELECT\r\nstatements. If we replace the table expected by the target software with a compatible VIEW, interesting opportunities reveal\r\nthemselves.\r\nHijack Any Query\r\nImagine the following scenario:\r\nThe original database has a single TABLE called dummy that is defined as:\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 4 of 19\n\nThe target software queries it with the following:\r\nWe can actually hijack this query if we craft dummy as a VIEW:\r\nThis “trap” VIEW enables us to hijack the query – meaning we generate a completely new query that we totally control.\r\nThis nuance greatly expands our attack surface, from the very minimal parsing of the header and an uncontrollable query\r\nperformed by the loading software, to the point where we can now interact with vast parts of the SQLite interpreter by\r\npatching the DDL and creating our own views with sub-queries.\r\nNow that we can interact with the SQLite interpreter, our next question was what exploitation primitives are built into\r\nSQLite? Does it allow any system commands, reading from or writing to the filesystem?\r\nAs we are not the first to notice the huge SQLite potential from an exploitation perspective, it makes sense to review prior\r\nwork done in the field. We started from the very basics.\r\nSQL Injections\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 5 of 19\n\nAs researchers, it’s hard for us to even spell SQL without the “i”, so it seems like a reasonable place to start. After all, we\r\nwant to familiarize ourselves with the internal primitives offered by SQLite. Are there any system commands? Can we load\r\narbitrary libraries?\r\nIt seems that the most straightforward trick involves attaching a new database file and writing to it using something along\r\nthe lines of:\r\nWe attach a new database, create a single table and insert a single line of text. The new database then creates a new file (as\r\ndatabases are files in SQLite) with our web shell inside it.\r\nThe very forgiving nature of the PHP interpreter parses our database until it reaches the PHP open tag of “\u003c?”.\r\nWriting a webshell is definitely a win in our password stealers scenario, however, as you recall, DDL cannot begin with\r\n“ATTACH”\r\nAnother relevant option is the load_extension function. While this function should allow us to load an arbitrary shared\r\nobject, it is disabled by default.\r\nMemory Corruptions In SQLite\r\nLike any other software written in C, memory safety issues are definitely something to consider when assessing the security\r\nof SQLite.\r\nIn his great blog post, Michał Zalewski described how he fuzzed SQLite with AFL to achieve some impressive results: 22\r\nbugs in just 30 minutes of fuzzing.\r\nInterestingly, SQLite has since started using AFL as an integral part of their remarkable test suite.\r\nThese memory corruptions were all treated with the expected gravity (Richard Hip and his team deserve tons of respect).\r\nHowever, from an attacker’s perspective, these bugs would prove to be a difficult path to exploitation without a decent\r\nframework to leverage them.\r\nModern mitigations pose a major obstacle in exploiting memory corruption issues and attackers need to find a more flexible\r\nenvironment.\r\nThe Security Research community would soon find the perfect target!\r\nWeb SQL\r\nWeb SQL Database is a web page API for storing data in databases that can be queried using a variant of SQL through\r\nJavaScript.The W3C Web Applications Working Group ceased working on the specification in November 2010, citing a lack\r\nof independent implementations other than SQLite.\r\nCurrently, the API is still supported by Google Chrome, Opera and Safari.\r\nAll of them use SQLite as the backend of this API.\r\nUntrusted input into SQLite, reachable from any website inside some of the most popular browsers, caught the security\r\ncommunity’s attention and as a result, the number of vulnerabilities began to rise.\r\nSuddenly, bugs in SQLite could be leveraged by the JavaScript interpreter to achieve reliable browser exploitation.\r\nSeveral impressive research reports have been published:\r\nLow hanging fruits like CVE-2015-7036\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 6 of 19\n\nUntrusted pointer dereference fts3_tokenizer()\r\nMore complex exploits presented in Blackhat 17 by the Chaitin team\r\nType confusion in fts3OptimizeFunc()\r\nThe recent Magellan bugs exploited by Exodus\r\nInteger overflow in fts3SegReaderNext()\r\nA clear pattern in past WebSQL research reveals that a virtual table module named ”FTS” might be an interesting target for\r\nour research.\r\nFTS\r\nFull-Text Search  (FTS) is a virtual table module that allows textual searches on a set of documents.\r\nFrom the perspective of an SQL statement, the virtual table object looks like any other table or view. But behind the scenes,\r\nqueries on a virtual table invoke callback methods on shadow tables instead of the usual reading and writing on the database\r\nfile.\r\nSome virtual table implementations, like FTS, make use of real (non-virtual) database tables to store content.\r\nFor example, when a string is inserted into the FTS3 virtual table, some metadata must be generated to allow for an efficient\r\ntextual search. This metadata is ultimately stored in real tables named “%_segdir” and “%_segments”, while the content\r\nitself is stored in “”%_content” where “%” is the name of the original virtual table.\r\nThese auxiliary real tables that contain data for a virtual table are called “shadow tables”\r\nDue to their trusting nature, interfaces that pass data between shadow tables provide a fertile ground for bugs. CVE-2019-\r\n8457,- a new OOB read vulnerability we found in the RTREE virtual table module, demonstrates this well.\r\nRTREE virtual tables, used for geographical indexing, are expected to begin with an integer column. Therefore, other\r\nRTREE interfaces expect the first column in an RTREE to be an integer. However, if we create a table where the first\r\ncolumn is a string, as shown in the figure below, and pass it to the rtreenode() interface, an OOB read occurs.\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 7 of 19\n\nNow that we can use query hijacking to gain control over a query, and know where to find vulnerabilities, it’s time to move\r\non to exploit development.\r\nSQLite Internals For Exploit Development\r\nPrevious publications on SQLite exploitation clearly show that there has always been a necessity for a wrapping\r\nenvironment, whether it is the PHP interpreter seen in this awesome blog post on abusing SQLite tokenizers or the more\r\nrecent work on Web SQL from the comfort of a JavaScript interpreter.\r\nAs SQLite is pretty much everywhere, limiting its exploitation potential sounded like low-balling to us and we started\r\nexploring the use of SQLite internals for exploitation purposes.\r\nThe research community became pretty good at utilizing JavaScript for exploit development. Can we achieve similar\r\nprimitives with SQL?\r\nBearing in mind that SQL is Turing complete ([1], [2]), we started creating a primitive wish-list for exploit development\r\nbased on our pwning experience.\r\nA modern exploit written purely in SQL has the following capabilities:\r\nMemory leak.\r\nPacking and unpacking of integers to 64-bit pointers.\r\nPointer arithmetics.\r\nCrafting complex fake objects in memory.\r\nHeap Spray.\r\nOne by one, we will tackle these primitives and implement them using nothing but SQL.\r\nFor the purpose of achieving RCE on PHP7, we will utilize the still unfixed 1-day of  CVE-2015-7036.\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 8 of 19\n\nWait, what? How come a 4-year-old bug has never been fixed? It is actually an interesting story and a great example of our\r\nargument.\r\nThis feature was only ever considered vulnerable in the context of a program that allows arbitrary SQL from an untrusted\r\nsource (Web SQL), and so it was mitigated accordingly.\r\nHowever, SQLite usage is so versatile that we can actually still trigger it in many scenarios 🙂\r\nExploitation Game-plan\r\nCVE-2015-7036 is a very convenient bug to work with.\r\nIn a nutshell, the vulnerable fts3_tokenizer() function returns the tokenizer address when called with a single argument (like\r\n“simple”, “porter” or any other registered tokenizer).\r\nWhen called with 2 arguments, fts3_tokenizer overrides the tokenizer address in the first argument with the address\r\nprovided by a blob in the second argument.\r\nAfter a certain tokenizer has been overridden, any new instance of the fts table that uses this tokenizer allows us to hijack\r\nthe flow of the program.\r\nOur exploitation game-plan:\r\nLeak a tokenizer address\r\nCompute the base address\r\nForge a fake tokenizer that will execute our malicious code\r\nOverride one of the tokenizers with our malicious tokenizer\r\nInstantiate an fts3 table to trigger our malicious code\r\nNow back to our exploit development.\r\nQuery Oriented Programming ©\r\nWe are proud to present our own unique approach for exploit development using the familiar structured query language. We\r\nshare QOP with the community in the hope of encouraging researchers to pursue the endless possibilities of database\r\nengines exploitation.\r\nEach of the following primitives is accompanied by an example from the sqlite3 shell.\r\nWhile this will give you a hint of what want to achieve, keep in mind that our end goal is to plant all those primitives in the\r\nsqlite_master table and hijack the queries issued by the target software that loads and queries our malicious SQLite db file\r\nMemory Leak – Binary\r\nMitigations such as ASLR definitely raised the bar for memory corruptions exploitation. A common way to defeat it is to\r\nlearn something about the memory layout around us.\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 9 of 19\n\nThis is widely known as Memory Leak.\r\nMemory leaks are their own sub-class of vulnerabilities, and each one has a slightly different setup.\r\nIn our case, the leak is the return of a BLOB by SQLite.\r\nThese BLOBs make a fine leak target as they sometimes hold memory pointers.\r\nThe vulnerable fts3_tokenizer() is called with a single argument and returns the memory address of the requested tokenizer.\r\nhex() makes it readable by humans.\r\nWe obviously get some memory address, but it is reversed due to little-endianity.\r\nSurely we can flip it using some SQLite built-in string operations.\r\nsubstr() seems to be a perfect fit! We can read little-endian BLOBs but this raises another question: how do we store things?\r\nQOP Chain\r\nNaturally, storing data in SQL requires an INSERT statement. Due to the hardened verification of sqlite_master, we can’t use\r\nINSERT as all of the statements must start with “CREATE “. Our approach to this challenge is to simply store our queries\r\nunder a meaningful VIEW and chain them together.\r\nThe following example makes it a bit clearer:\r\nThis might not seem like a big difference, but as our chain gets more complicated, being able to use pseudo-variables will\r\nsurely make our life easier.\r\nUnpacking of 64-bit pointers\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 10 of 19\n\nIf you’ve ever done any pwning challenges, the concept of packing and unpacking of pointers should not be foreign.\r\nThis primitive should make it easy to convert our hexadecimal values (like the leak we just achieved) to integers. Doing so\r\nallows us to perform various calculations on these pointers in the next steps.\r\nThis query iterates a hexadecimal string char by char in a reversed fashion using substr().\r\nA translation of this char is done using this clever trick with the minor adjustment of instr() which is 1-based.\r\nAll that is needed now is the proper shift that is on the right of the * sign.\r\nPointer arithmetics\r\nPointer arithmetics is a fairly easy task with integers at hand. For example, extracting the image base from our leaked\r\ntokenizer pointer is as easy as:\r\nPacking of 64-bit pointers\r\nAfter reading leaked pointers and manipulating them to our will, it makes sense to pack them back to their little-endian form\r\nso we can write them somewhere.\r\nSQLite char()  should be of use here as its documentation states that it will “return a string composed of characters having\r\nthe Unicode code point values of an integer.”\r\nIt proved to work fairly well, but only on a limited range of integers\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 11 of 19\n\nLarger integers were translated to their 2-bytes code-points.\r\nAfter banging our heads against SQLite documentation, we suddenly had a strange epiphany: our exploit is actually a\r\ndatabase.\r\nWe can prepare beforehand a table that maps integers to their expected values.\r\nNow our pointer packing query is the following:\r\nCrafting complex fake objects in memory\r\nWriting a single pointer is definitely useful, but still not enough. Many memory safety issues exploitation scenarios require\r\nthe attackers to forge some object or structure in memory or even write a ROP chain.\r\nEssentially, we will string several of the building blocks we presented earlier.\r\nFor example, let’s forge our own tokenizer, as explained here.\r\nOur fake tokenizer should conform to the interface expected by SQLite defined here:\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 12 of 19\n\nUsing the methods described above and a simple JOIN query, we are able to fake the desired object quite easily.\r\nVerifying the result in a low-level debugger, we see that indeed a fake tokenizer object was created.\r\nHeap Spray\r\nNow that we crafted our fake object, it is sometimes useful to spray the heap with it.\r\nThis should ideally be some repetitive form of the latter.\r\nUnfortunately, SQLite does not implement the REPEAT() function like MySQL.\r\nHowever, this thread gave us an elegant solution.\r\nThe zeroblob(N) function returns a BLOB consisting of N bytes while we use replace() to replace those zeros with our fake\r\nobject.\r\nSearching for those 0x41s shows we also achieved a perfect consistency. Notice the repetition every 0x20 bytes.\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 13 of 19\n\nMemory Leak – Heap\r\nLooking at our exploitation game plan, it seems like we are moving in the right direction.\r\nWe already know where the binary image is located, we were able to deduce where the necessary functions are, and spray\r\nthe heap with our malicious tokenizer.\r\nNow it’s time to override a tokenizer with one of our sprayed objects. However, as the heap address is also randomized, we\r\ndon’t know where our spray is allocated.\r\nA heap leak requires us to have another vulnerability.\r\nAgain, we will target a virtual table interface.\r\nAs virtual tables use underlying shadow tables, it is quite common for them to pass raw pointers between different SQL\r\ninterfaces.\r\nNote: This exact type of issue was mitigated in SQLite 3.20. Fortunately, PHP7 is compiled with an earlier version. In case\r\nof an updated version, CVE-2019-8457 could be used here as well.\r\nTo leak the heap address, we need to generate an fts3 table beforehand and abuse its MATCH interface.\r\nJust as we saw in our first memory leak, the pointer is little-endian so it needs to be reversed. Fortunately, we already know\r\nhow to do so using SUBSTR().\r\nNow that we know our heap location, and can spray properly, we can finally override a tokenizer with our malicious\r\ntokenizer!\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 14 of 19\n\nPutting It All Together\r\nWith all the desired exploitation primitives at hand, it’s time to go back to where we started: exploiting a password stealer\r\nC2.\r\nAs explained above, we need to set up a “trap” VIEW to kickstart our exploit. Therefore, we need to examine our target and\r\nprepare the right VIEW.\r\nAs seen in the snippet above, our target expects our db to have a table called Notes with a column called BodyRich inside it.\r\nTo hijack this query, we created the following VIEW\r\nAfter Notes is queried, 3 QOP Chains execute. Let’s analyze the first one of them.\r\nheap_spray\r\nOur first QOP chain should populate the heap with a large amount of our malicious tokenizer.\r\np64_simple_create, p64_simple_destroy, and p64_system are essentially all chains achieved with our leak and packing\r\ncapabilities.\r\nFor example, p64_simple_create is constructed as:\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 15 of 19\n\nAs these chains get pretty complex, pretty fast, and are quite repetitive, we created QOP.py.\r\nQOP.py makes things a bit simpler by generating these queries in pwntools style.\r\nCreating the previous statements becomes as easy as:\r\nDemo\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 16 of 19\n\nCOMMIT;\r\nNow that we have established a framework to exploit any situation where the querier cannot be sure that the database is non-malicious, let’s explore another interesting use case for SQLite exploitation.\r\niOS Persistency\r\nPersistency is hard to achieve on iOS as all executable files must be signed as part of Apple’s Secure Boot. Luckily for us,\r\nSQLite databases are not signed.\r\nUtilizing our new capabilities, we will replace one of the commonly used databases with a malicious version. After the\r\ndevice reboots and our malicious database is queried, we gain code execution.\r\nTo demonstrate this concept, we replace the Contacts DB “AddressBook.sqlitedb”. As done in our PHP7 exploit, we create\r\ntwo extra DDL statements. One DDL statement overrides the default tokenizer “simple”, and the other DDL statement\r\ntriggers the crash by trying to instantiate the overridden tokenizer. Now, all we have to do is re-write every table of the\r\noriginal database as a view that hijacks any query performed and redirect it toward our malicious DDL.\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 17 of 19\n\nReplacing the contacts db with our malicious contacts db and rebooting results in the following iOS crashdump:\r\nAs expected, the contacts process crashed at 0x4141414141414149 where it expected to find the xCreate constructor of our\r\nfalse tokenizer.\r\nFurthermore, the contacts db is actually shared among many processes. Contacts, Facetime, Springboard, WhatsApp,\r\nTelegram and XPCProxy are just some of the processes querying it. Some of these processes are more privileged than\r\nothers. Once we proved that we can execute code in the context of the querying process, this technique also allows us to\r\nexpand and elevate our privileges.\r\nOur research and methodology have all been responsibly disclosed to Apple and were assigned the following CVEs:\r\nCVE-2019-8600\r\nCVE-2019-8598\r\nCVE-2019-8602\r\nCVE-2019-8577\r\nFuture Work\r\nGiven the fact that SQLite is practically built-in to almost any platform, we think that we’ve barely scratched the tip of the\r\niceberg when it comes to its exploitation potential. We hope that the security community will take this innovative research\r\nand the tools released and push it even further. A couple of options we think might be interesting to pursue are\r\nCreating more versatile exploits. This can be done by building exploits dynamically by choosing the relevant QOP\r\ngadgets from pre-made tables using functions such as sqlite_version() or sqlite_compileoption_used().\r\nAchieving stronger exploitation primitives such as arbitrary R/W.\r\nLook for other scenarios where the querier cannot verify the database trustworthiness.\r\nConclusion\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 18 of 19\n\nWe established that simply querying a database may not be as safe as you expect. Using our innovative techniques of Query\r\nHijacking and Query Oriented Programming, we proved that memory corruption issues in SQLite can now be reliably\r\nexploited. As our permissions hierarchies become more segmented than ever, it is clear that we must rethink the boundaries\r\nof trusted/untrusted SQL input. To demonstrate these concepts, we achieved remote code execution on a password stealer\r\nbackend running PHP7 and gained persistency with higher privileges on iOS. We believe that these are just a couple of use\r\ncases in the endless landscape of SQLite.\r\nCheck Point IPS Product Protects against this threat: “SQLite fts3_tokenizer Untrusted Pointer Remote Code Execution\r\n(CVE-2019-8602).”\r\nSource: https://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nhttps://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/\r\nPage 19 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/"
	],
	"report_names": [
		"select-code_execution-from-using-sqlite"
	],
	"threat_actors": [],
	"ts_created_at": 1777949093,
	"ts_updated_at": 1777949196,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d91ec1e5429dacc20f1ec03c351ecce3c4d6b826.pdf",
		"text": "https://archive.orkl.eu/d91ec1e5429dacc20f1ec03c351ecce3c4d6b826.txt",
		"img": "https://archive.orkl.eu/d91ec1e5429dacc20f1ec03c351ecce3c4d6b826.jpg"
	}
}