3 ms·
> Fuzzing would be a more appropriate measure to have found this issue SQLite has some fairly extensive fuzzing. https://www.sqlite.org/testing.html#fuzz_test
by shagie 4y ago
> Fuzzing would be a more appropriate measure to have found this issue
SQLite has some fairly extensive fuzzing. https://www.sqlite.org/testing.html#fuzz_testing 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.
- chasil 4y agoIt 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-check.1.en.html https://manpages.debian.org/testing/devscripts/hardening-che...
- chasil 4y agoIt 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!