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 itself
>...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 pr
> 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, see
> the paper, isn't needed fo
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 pap
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
>otherwise valid pseudo-null pointer
> 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() loads a register to one of th
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 conveniently published for ha
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 whe
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 to migrate your legacy code to
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,
> 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 proclaimed
> expertise.
Step
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
> "nuclear solution" as in: "L
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 not a requirement, so the fact that it’s visible if you examine
the binary or source is
on 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-users mailing list
>sqlite-users@
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 ask
On 7/24/17, 7:20 PM, "sqlite-users on behalf of petern"
wrote:
> 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.
This has nothing to do with the s
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 jock
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 in clear text
But that’s not part of the security model, so what’s the problem?
__
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
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
d
> 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.
You're right that the new API
> 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 fell short.
Congrats can also go
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 validated JSON text in
the JSON1 e
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 applicat
2017 05:54
>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
>___
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
directly from producer
ntag, 24. Juli 2017 15:37
An: SQLite mailing list
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
t; pointer from statement A to a function in
statement B does not pose a risk.
-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im
Auftrag von Peter Da Silva
Gesendet: Montag, 24. Juli 2017 15:37
An: SQLite mailing list
Betreff: Re: [sql
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"
wrote:
https://www.sqlite.org/dr
>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 mailin
> 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
http://mailinglists.sqli
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
32 matches
Mail list logo
