Re:Stranger Strings: An exploitable flaw in SQLite
by chasil on Tuesday October 25, 2022 @10:20AM
(#33330795)
It sounds from the article that "-fstack-protector-all" might remove everything except the denial of service.
"...arbitrary code execution is confirmed when the library is compiled without stack canaries, but unconfirmed when stack canaries are present, and denial-of-service is confirmed in all cases."
Everything should be compiled with all available compiler defenses:
https://manpages.debian.org/testing/devscripts/hardening-che...
Re:Stranger Strings: An exploitable flaw in SQLite
by chasil on Tuesday October 25, 2022 @02:41PM
(#33334556)
It does appear safe with the OS package on CentOS 7.
$ hardening-check /usr/lib64/libsqlite3.so.0.8.6
/usr/lib64/libsqlite3.so.0.8.6:
Position Independent Executable: no, regular shared library (ignored)
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: no, not found!
SQLite has some fairly extensive fuzzing. https://www.sqlite.org/testing.html#fuzz_testing
One of the sections on Fuzz testing:
> 4.3 Boundary Value Tests
> SQLite defines certain limits on its operation, such as the maximum number of columns in a table, the maximum length of an SQL statement, or the maximum value of an integer. The TCL and TH3 test suites both contains numerous tests that push SQLite right to the edge of its defined limits and verify that it performs correctly for all allowed values. Additional tests go beyond the defined limits and verify that SQLite correctly returns errors. The source code contains testcase macros to verify that both sides of each boundary have been tested.