4 ms·

"This bug is an array-bounds overflow. The bug is only accessible when using some of the C-language APIs provided by SQLite. The bug cannot be reached using SQL

"This bug is an array-bounds overflow. The bug is only accessible when using some of the C-language APIs provided by SQLite. The bug cannot be reached using SQL nor can it be reached by providing SQLite with a corrupt database file. The bug only comes up when very long string inputs (greater than 2 billion bytes in length) are provided as arguments to a few specific C-language interfaces, and even then only under special circumstances." Source: https://www.sqlite.org/cves.html#status_of_recent_sqlite_cves https://www.sqlite.org/cves.html#status_of_recent_sqlite_cve...

efficax 4y ago
ah looks like they had 32 bit assumptions that broke on 64 bit chips.
- remram 4y ago
  ... in one internal function. It seems that the assumptions totally hold for the library as a whole.
- zoomablemind 4y ago
  I vagely remember that there were a few more places in SQLite codebase which could benefit from proper use of size_t type. Catching increment overflows is not that straightforward, perhaps some review specifically for such cases may help SQLite get even more robust.
chmaynard 4y ago
> The bug is only accessible when using some of the C-language APIs provided by SQLite. I assume the SQLite CLI (sqlite3) uses these APIs. Could the bug be triggered indirectly by input to sqlite3? The article doesn't appear to address this question.
- torstenvl 4y ago
  [EDIT: https://sqlite.org/forum/forumpost/3607259d3c https://sqlite.org/forum/forumpost/3607259d3c appears to be only one way this bug can rear its head, not the core of the bug itself]
  - ferbivore 4y ago
    That's a different bug.
    - torstenvl 4y ago
      You're right, my mistake
- SQLite 4y ago
  The CLI does use the relevant APIs, however I don't know of a way to reach this bug using a script input to the CLI. If there is such a path that I don't know about, it seems like it would require at least a 2GB input script.
  - _the_inflator 4y ago
    This, and also there is the saying: "Never trust the frontend" So in any case a string length check in the Backend should help here. Also if you get strings from a Browser Frontend, it seems unlikely you could create a payload of 2GB due to several reasons, one being string length limitations on the Browser side: https://stackoverflow.com/questions/34957890/javascript-string-size-limit-256-mb-for-me-is-it-the-same-for-all-browsers?noredirect=1&lq=1 https://stackoverflow.com/questions/34957890/javascript-stri...
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]

efficax 4y ago

ah looks like they had 32 bit assumptions that broke on 64 bit chips.

remram 4y ago
... in one internal function. It seems that the assumptions totally hold for the library as a whole.
zoomablemind 4y ago
I vagely remember that there were a few more places in SQLite codebase which could benefit from proper use of size_t type. Catching increment overflows is not that straightforward, perhaps some review specifically for such cases may help SQLite get even more robust.

chmaynard 4y ago

> The bug is only accessible when using some of the C-language APIs provided by SQLite. I assume the SQLite CLI (sqlite3) uses these APIs. Could the bug be triggered indirectly by input to sqlite3? The article doesn't appear to address this question.

torstenvl 4y ago
[EDIT: https://sqlite.org/forum/forumpost/3607259d3c https://sqlite.org/forum/forumpost/3607259d3c appears to be only one way this bug can rear its head, not the core of the bug itself]
- ferbivore 4y ago
  That's a different bug.
  - torstenvl 4y ago
    You're right, my mistake
SQLite 4y ago
The CLI does use the relevant APIs, however I don't know of a way to reach this bug using a script input to the CLI. If there is such a path that I don't know about, it seems like it would require at least a 2GB input script.
- _the_inflator 4y ago
  This, and also there is the saying: "Never trust the frontend" So in any case a string length check in the Backend should help here. Also if you get strings from a Browser Frontend, it seems unlikely you could create a payload of 2GB due to several reasons, one being string length limitations on the Browser side: https://stackoverflow.com/questions/34957890/javascript-string-size-limit-256-mb-for-me-is-it-the-same-for-all-browsers?noredirect=1&lq=1 https://stackoverflow.com/questions/34957890/javascript-stri...
deleted 4y ago
[deleted]

deleted 4y ago

[deleted]