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

If you’re in a position to perform an attack that address space randomization can defend against, then you have already successfully performed a code execution attack. And so far as I can tell... *any* constant strings in the executable, including things like elements of the SQL language

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

>...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

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

> On Jul 28, 2017, at 2:46 PM, petern wrote: > > 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,

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

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

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

On Thursday, 27 July, 2017 11:03, petern wrote: >Richard. Were you aware of this paper? >http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf >Are you able to put two facts together? >What prevents stack busting or other code injection attacks on an

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

> On Jul 27, 2017, at 10:02 AM, petern 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()

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

On 7/27/17, petern 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

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

Richard. Were you aware of this paper? http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf 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

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

On 7/24/17, petern wrote: > 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. Nobody is forcing you

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

My tone isn't about the technical development discussion. Its about my subscribing to this forum and seeing my 11 year olds mentality shine through with his "I'm not getting the attention I want, so I'm going to yell and scream and pout until I get what I want". Perhaps it is a language barrier,

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

> On Jul 25, 2017, at 9:39 AM, Stephen Chrzanowski wrote: > > Your attitude towards a public forum and bully attempts isn't required > here. I'd ask YOU to leave based on the fact that your behavior is > anything but professional, as I'm not interested in your self

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

On Tue, Jul 25, 2017 at 12:25 PM, petern wrote: > You're trying to change the topic to the security model. This thread is > supposed to be about a lengthy beyond the pale proposal that named all > manner of hypothetical boogie men before concluding the only way is a

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

On 7/25/17, 11:25 AM, "sqlite-users on behalf of petern" wrote: > You're trying to change the topic to the security model. All I was doing was pointing out that hiding the type information from attackers is

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

SQLite Database >Subject: [sqlite] New draft document on the new pointer-passing >interfaces > >https://www.sqlite.org/draft/bindptr.html > >-- >D. Richard Hipp >d...@sqlite.org >___ >sqlite-users mailing list >sqlite-users@maili

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

You're trying to change the topic to the security model. This thread is supposed to be about a lengthy beyond the pale proposal that named all manner of hypothetical boogie men before concluding the only way is a "nuclear solution" as in: "Let's just nuke it, that's only way to be safe". I'll

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

Justifications presented in the proposal claim hardwired constants for mandatory lock and key style pointer value receiving are a great idea because SQL can't generate constant space strings. And, this is true provided the executable is secret and remote. I know there are a lot of web server

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

On 7/24/17, 3:50 PM, "sqlite-users on behalf of petern" wrote: > BTW, if the hypothetical attacker has a copy of the application, aren't the > constant space pointer access keys' string addresses all there

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

Your proposal does not walk through the alternative of sticking with subtypes to add non-persistent sqlite3_bind_subtype() and corresponding sqlite3_column_subtype() methods. With a few extra lines and some imagination can't this more straightforward alternative be combined with the existing BLOB

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

Gwendal. Yes. You've missed something. My application is working code not a hypothetical feature request. BLOB application object pointer lifetime presently works precisely as I've described and without memory leak. My point (and Dominique's point) was that this proposal as it stands isn't a

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

> Le 24 juil. 2017 à 19:02, petern a écrit : > > 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.

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

> Le 24 juil. 2017 à 19:02, petern a écrit : > > 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

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

On 7/24/17, petern wrote: > > Are sqlite3_result_subtype() and sqlite3_value_subtype() being deprecated > in light of the duplicate functionality? > No. The subtype() interfaces were originally created for completely unrelated purposes (specifically to identify

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

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

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

;To: General Discussion of SQLite Database >Subject: [sqlite] New draft document on the new pointer-passing >interfaces > >https://www.sqlite.org/draft/bindptr.html > >-- >D. Richard Hipp >d...@sqlite.org >___ >sqlite

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

On Mon, Jul 24, 2017 at 1:54 PM, Richard Hipp wrote: > https://www.sqlite.org/draft/bindptr.html Thanks. Very helpful. Still unsure whether not having a destructor D for pointer P is a good thing though. The text explicitly says the pointer is "destroyed" when not flowing

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

un...@mailinglists.sqlite.org] Im Auftrag von Peter Da Silva Gesendet: Montag, 24. Juli 2017 15:37 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Betreff: Re: [sqlite] New draft document on the new pointer-passing interfaces What about imposing

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

linglists.sqlite.org> Betreff: Re: [sqlite] New draft document on the new pointer-passing interfaces What about imposing some structure on the pointer type strings that uses a guaranteed unique substring, for example “org.sqlite.fts3.snippet”, to ensure there wouldn’t be accidental conflicts?

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

What about imposing some structure on the pointer type strings that uses a guaranteed unique substring, for example “org.sqlite.fts3.snippet”, to ensure there wouldn’t be accidental conflicts? On 7/24/17, 6:54 AM, "sqlite-users on behalf of Richard Hipp"

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

>https://www.sqlite.org/draft/bindptr.html Thank you very much for this, detailed, informative write-up, Dr Hipp. It's very helpful to see the sensible rationale behind the new interfaces. Thanks for continuing to enhance the API! ___ sqlite-users

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

> Le 24 juil. 2017 à 13:54, Richard Hipp a écrit : > > https://www.sqlite.org/draft/bindptr.html Thank you very much for this detailed rationale! Gwendal Roué ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

[sqlite] New draft document on the new pointer-passing interfaces

https://www.sqlite.org/draft/bindptr.html -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users