Here I'm replying to Richard and subsequent comments on Richard's question.
The attack vector is described well enough. A penetration search harness would work directly from predictable accesses to the published key constants as mapped into process address space. [Full ASLR decoding, see the paper, isn't needed for this.] These well advertised accesses "light up" otherwise randomized program and stack layouts very well since there is no access for any other purpose. CPU security might prevent directly forging pseudo-null pointers but they are as observable as subtype pointers and leak more address space layout information. I suppose what you're really after is to see a demonstrable exploit to know whether or not is a SQLite component or side channel. For that, you'll have to wait. I don't have one at my fingertips but can imagine possibilities and incentives. About that 2017 paper. It details a practical universal decoder against the randomized memory space countermeasures on every major CPU architecture. It's not really that technical. In fact, pointer leaks to randomized memory were cited in Richard's essay where, in a jarring leap, he went from the goal of preserving randomization to a new API with new countermeasures. This reader was left wondering how he got there rather than to a plan that finished up the deliberately incomplete but proven subtype pointer API. By introducing the paper, I was hoping for an appreciation of irony. For it is ironic how the new pseudo-null API leans even more heavily on a waning shield of address space randomization than the subtype API did. On Thu, Jul 27, 2017 at 11:41 AM, Jens Alfke <j...@mooseyard.com> wrote: > > > On Jul 27, 2017, at 10:02 AM, petern <peter.nichvolo...@gmail.com> > wrote: > > > > Are you able to put two facts together? > > > > What prevents stack busting or other code injection attacks on an > otherwise > > valid pseudo-null pointer by simply decoding the address space and > > observing where strcmp() loads a register to one of the pointer "keys" > > you've insisted be conveniently published for hackers in the data > segment? > > Peter, you’re > (a) assuming a lot of specialized domain knowledge, by using jargon and > referring to highly technical papers; > (b) referring vaguely to threats instead of describing a clear problem or > attack vector; > (c) speaking very condescendingly to the people you’re trying to convince. > > None of these help your case at all. I’m interested in the security > implications of this API, and I’ve got some security knowledge, but not > apparently enough to follow along. Richard is right: please describe > clearly a situation where this API results in an attack vector. > > —Jens > _______________________________________________ > 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
