On Monday, 12 August, 2019 11:09, Simon Slavin <slav...@bigfraud.org> wrote:
>Some interesting things are emerging from this year's DEF CON. This >one is related to an issue we've often discussed here. I hope you'll >indulge this slightly off-charter post. > >https://www.iheart.com/content/2019-08-12-clever-vanity-license-plate-backfires-on-man-winds-up-with-tons-of-tickets/> Perhaps more apropos is the following story from the Register, also originating at DEF CON: https://www.theregister.co.uk/2019/08/10/memory_corruption_sqlite/ Although I would point out that the root problem is that the attacker already has access to the file in order to change it, and therefore already has presence on the machine. This is really no different that saying that "if an attacker has access the filesystem to replace the login program, that the login program can be compromised". In other words, much ado about nothing. Solve the root issue (the inappropriate granting of access by some other method) and the issue is resolved. This (seems to me) falls into the class of "if you have SYSTEM (root, for the *nix crowd) authority" you can "exploit vulnerability X" to obtain SYSTEM authority. Why on earth would you bother? Sure, you can exploit the vulnerability but it gains you nothing that you do not already have. Perhaps I am just lazy but I see no point in engaging in extra work for no advantage (then again, maybe that is just the Control Systems background rearing its head). As a side note, if one ALREADY HAS access to a machine hosting a database, and ALREADY HAS access to be able to make arbitrary changes to the database file, then the same exploit can be carried out on just about ANY system running just about ANY database imaginable .. it is trivial to create a view which replaces a table and have that view "do things" that are other than what was intended by the original designer, and have the fact that the table was replaced by a view remain "hidden" from routine uses. And in any case, why bother with all the rigamarole. You can already copy the contents of the database or make changes directly, so why go to such great lengths to be able to achieve indirectly that which you can already do directly? (Not to mention that there are already capabilities to monitor for this sort of thing via the authorizer). Granted, it is not usual to "ship around" SQLServer or DB2 databases or have those host "application file formats" quite like it is with SQLite3 databases, but then, files (no matter the type) originating from untrustworthy third-parties should be, well, untrusted. The same applies to files which have been accessed (and perhaps modified) by untrustworthy parties. The root problem is the prior untrustworthy access -- fix that and the problem goes away. Conversely there is a great trend these days to "execute" data -- thankfully something which SQLite3 does not do. An application might, but that is an application problem and not a data problem. The only interesting thing is CVE-2015-7036, but I don't know if that was so much an SQLite3 issue, as it was an issue in the use of the tokenizer by Apple. In either case, Apple fixed their bugs and SQLite3 was hardened against some inappropriate (unintended by the application developer) uses of the fts3_tokenizer() function. https://www.sqlite.org/releaselog/3_28_0.html Item 10 -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
