The difference, in Apple's case _very_ specifically, is that they sign the majority (all the rest? Unsure) of their files so that this style of exploit fails. Basically SQLite is being used to bypass an existing Apple-specific security control. Outside of the iOS world the applicability is a lot lower (if any) as you detail.
Regards, Donald Shepherd. On Tue, 13 Aug 2019 at 06:14, Keith Medcalf <kmedc...@dessus.com> wrote: > > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
