2 ms·

Despite being an 'easy problem' it has led to code execution on android/ios: https://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/ http

by jamii 6y ago

Despite being an 'easy problem' it has led to code execution on android/ios: https://research.checkpoint.com/2019/select-code_execution-from-using-sqlite/ https://research.checkpoint.com/2019/select-code_execution-f... > We established that simply querying a database may not be as safe as you expect. Using our innovative techniques of Query Hijacking and Query Oriented Programming, we proved that memory corruption issues in SQLite can now be reliably exploited. As our permissions hierarchies become more segmented than ever, it is clear that we must rethink the boundaries of trusted/untrusted SQL input. To demonstrate these concepts, we achieved remote code execution on a password stealer backend running PHP7 and gained persistency with higher privileges on iOS. We believe that these are just a couple of use cases in the endless landscape of SQLite.

dnautics 6y ago
technically that's exactly the 'hard' problem, since QOP and QH are 'dealing with database problems' and not low-level problems like memory safety.
- masklinn 6y ago
  QOP/QH are not the point, they're ways to reach the existing memory corruption. Without the memory safety issue you can reach QOP/QH are not useful.
  - dnautics 6y ago
    IIRC, QOP/QH though requires the somewhat unfortunate way that tables are laid out and initialized in SQLite, so it was my impression that QOP/QH are the highest order problem that needs to be patched; after all there are other types of vulns that aren't memory safety problems that are reachable with QOP/QH.