Re: New draft document on the new pointer-passing interfaces

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New draft document on the new pointer-passing interfaces

petern
Great.  But, if this is an ultimate replacement for BLOB'ed pointers, these
new pseudo-null pointers must support SQLITE_STATIC and destructor function
pointer lifetime disposition for those migrating their code.

Why can't the producer destructor disposition be preserved within a chain
of application functions by subsequent consumers passing SQLITE_STATIC
disposition as they do now?   Isn't this feature just an accident of
statement scope controlled destruction that will continue to work with
tracked lifetime pseudo-null pointers?

BTW, let's call them what they are.  These are explicit pseudo-nulls for
the purpose of keeping pointer bits out of band from hacker SQL.

Also.

What is to stop black budget funded developers from creating popular
applications in the wild which preserve penetration channels of BLOB
pointers the original way?  Total security improvement justifications for
the pseudo-null pointer API are specious if the API is merely another
alternative.

Are sqlite3_result_subtype() and sqlite3_value_subtype() being deprecated
in light of the duplicate functionality?

Supplementing/deprecating the already secure sqlite3_X_subtype() API with a
more complete and pointer leak opaque replacement sqlite3_X_pointer() API
seems a worthy goal.  But, if that's the plan, where is the rest to the
proposal?  Honestly, it appears all you've proposed so far is yet another
way to pass pointers more aligned with the whims of your present tastes for
FTS3 MATCH, FTS5 extensions, and one code sample.

To those posting low information congratulatory notes on this thread, you'd
better hold off on popping those champagne corks.  The current API already
contains irreversible additions to solve this problem that fell short.


On Mon, Jul 24, 2017 at 4:54 AM, Richard Hipp <[hidden email]> wrote:

> https://www.sqlite.org/draft/bindptr.html
>
> --
> D. Richard Hipp
> [hidden email]
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New draft document on the new pointer-passing interfaces

Richard Hipp-3
On 7/27/17, petern <[hidden email]> wrote:
>
> 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?
>

I do not understand what this sentence means.  Can you explain it
again in simpler terms?

Refresh my memory please:  What exactly (and succinctly) is your
complain with the current sqlite3_bind_pointer(),
sqlite3_result_pointer(), and sqlite3_value_pointer() design?  Are
there multiple complains?  Can you enumerate them?  Please be as
specific as possible.

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New draft document on the new pointer-passing interfaces

Jens Alfke-2
In reply to this post by petern

> On Jul 27, 2017, at 10:02 AM, petern <[hidden email]> 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
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New draft document on the new pointer-passing interfaces

petern
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 <[hidden email]> wrote:

>
> > On Jul 27, 2017, at 10:02 AM, petern <[hidden email]>
> 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
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New draft document on the new pointer-passing interfaces

petern
>...the attacker is already able to read the process’s address space. The
rest of us here are saying that, in that case, as far as we’re concerned
the attacker has already won.

I understand that.  What I'm saying is your standard is not nuanced.
Applying a security standard that amounts to best practice web server
administration is insufficient for all environments.  Extra care is
warranted where compromised apps can be installed alongside yours.  Maybe
there is no exploit to take over the app or host but there could be very
good ones for your app to assist in eavesdropping and boosting social
engineering attacks.  The goal should be "secure in the wild" rather than
merely secure on the server.

A bit of reading reveals how the most spectacular SQLite exploits so far
occurred in desktop and portable environments marketed as a platforms for
users to commingle apps of their choice and quality.  Therefore, a more
realistic security threat standard comes from imagining an environment
where unknown threats and partially effective countermeasures are presently
in a precarious stalemate equilibrium.  Introducing an app with secure in
isolation but unorthodox implementation may not have the secure in the wild
guarantee that is expected.

At this point I've got no dog in this fight.  The new pointer API is now
fairly complete and can be mechanically patched to use a more sensible key
type.  Serious implementors anticipating widespread desktop or mobile
deployment can do this easily for themselves.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Loading...