[firebird-support] Overflow problem

[Lester Caine [e-mail] [firebird-support]]

Nothing to do with Firebird but can anybody explain why the numbers in
'SELECT FIRST 102121121121212 SKIP 3574239239242420' would be a problem
in MySQL or is it some other vulnerability the original sQL injection
was trying to hit. I know I need to add limit checks in the code which
reprocessed the SQL but it quite happily 'white screens' the vast
majority of MySQL injection attempts so I'm just need to make sure there
is nothing that WOULD affect Firebird adversely.

[Mark Rotteveel [e-mail] [firebird-support]]

Post by Lester Caine ***@lsces.co.uk [firebird-support]
Nothing to do with Firebird but can anybody explain why the numbers in
'SELECT FIRST 102121121121212 SKIP 3574239239242420' would be a problem
in MySQL or is it some other vulnerability the original sQL injection
was trying to hit. I know I need to add limit checks in the code which
reprocessed the SQL but it quite happily 'white screens' the vast
majority of MySQL injection attempts so I'm just need to make sure there
is nothing that WOULD affect Firebird adversely.

That number is too big to fit in an int, could explain the problem

BTW: You might want to look for other solutions if you need to skip and
fetch that many records, it is not really efficient ;)

[[e-mail] [firebird-support]]

Are you trying to store details of the American public debt? or the world's
public debt? Just kiding.... Not

How about assigning another integer field to each record with a value
representing the "segment" for the value you are trying to store, and then
use an index on that value, I'll explain with an example:

Say your table contains values from 0 to 1,000,000,0000,000,000

Add another field called "segment" and convert your values as follows:

where the original record value was 1:
Value = 1
Segment = 0

Where the original record was 65534
Value = 65534
Segment = 0


Where the original record was 65537
Value = 1
Segment = 1 (Segment 1 = 2 bytes segment, representing 256*256 = 65536)
So Value 1 plus segment 1 = 1+65536 = 65537

Where the original record was 131073
Value = 1
Segment = 2 (Segment 2 = 2 bytes segment, representing 256*256 * 2 = 131072)
So Value 1 plus segment 2 = 1+131072 = 131073

If you use 4 bytes for the segment then the segment 1 = 256*256*256*256 =
4228250625 = 4GB


Now the important part, when running the select say I want to get all values
between 2GB and 3GB, then :

Select value from my_table where segment between 2GB / 65536 and 3GB /
65536 (if you choose to use 2 bytes for the segment)

This will fly compared to any other solution asuming you have an index on
segment.

Are you storing prime number in your DB? is that what you are trying to
resolve? If yes, I believe using the solution I am mentioning will work
fine, perhaps you may need 2 or more segment fields to get the best
performance,

Cheers,
Fabian

[Lester Caine [e-mail] [firebird-support]]

Post by ***@itbizolutions.com.au [firebird-support]
Are you trying to store details of the American public debt? or the world's
public debt? Just kiding.... Not

See other post ;)
It is vulnerability to overflow edge cases that are the potential
problem - especially in MySQL and I believe much less so in Firebird
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk


------------------------------------

------------------------------------

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu. Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-***@yahoogroups.com
firebird-support-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Lester Caine [e-mail] [firebird-support]]

Post by Mark Rotteveel ***@lawinegevaar.nl [firebird-support]

Post by Lester Caine ***@lsces.co.uk [firebird-support]
Nothing to do with Firebird but can anybody explain why the numbers in
'SELECT FIRST 102121121121212 SKIP 3574239239242420' would be a problem
in MySQL or is it some other vulnerability the original sQL injection
was trying to hit. I know I need to add limit checks in the code which
reprocessed the SQL but it quite happily 'white screens' the vast
majority of MySQL injection attempts so I'm just need to make sure there
is nothing that WOULD affect Firebird adversely.

That number is too big to fit in an int, could explain the problem
BTW: You might want to look for other solutions if you need to skip and
fetch that many records, it is not really efficient ;)

You are missing the point Mark ... This SQL has come about from a PHP
SQL injection attack. I don't need it to 'work'. I was trying to get a
handle on the vulnerability they were trying to exploit on MySQL incase
the results may be a problem. The ACTUAL SQL is only spanning a few
hundred pages and is handled via parameters. This SQL was the result of
manually added SQL in the raw fields.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk


------------------------------------

------------------------------------

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu. Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-***@yahoogroups.com
firebird-support-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Mark Rotteveel [e-mail] [firebird-support]]

Post by Lester Caine ***@lsces.co.uk [firebird-support]

[firebird-support]

Post by Lester Caine ***@lsces.co.uk [firebird-support]
Nothing to do with Firebird but can anybody explain why the numbers in
'SELECT FIRST 102121121121212 SKIP 3574239239242420' would be a problem
in MySQL or is it some other vulnerability the original sQL injection
was trying to hit. I know I need to add limit checks in the code which
reprocessed the SQL but it quite happily 'white screens' the vast
majority of MySQL injection attempts so I'm just need to make sure there
is nothing that WOULD affect Firebird adversely.

That number is too big to fit in an int, could explain the problem
BTW: You might want to look for other solutions if you need to skip and
fetch that many records, it is not really efficient ;)

You are missing the point Mark ... This SQL has come about from a PHP
SQL injection attack. I don't need it to 'work'. I was trying to get a
handle on the vulnerability they were trying to exploit on MySQL incase
the results may be a problem. The ACTUAL SQL is only spanning a few
hundred pages and is handled via parameters. This SQL was the result of
manually added SQL in the raw fields.

Ah, ok, that wasn't really clear to me.

It might just be an attempt to a denial of service (eg because skipping
the first 3574239239242420 is/could be expensive if the table actually
contains that many row), or it is used to get an idea of the size of
your table (see previous one), or maybe it can be used for
fingerprinting because it triggers an error on specific MySQL versions,
or it used to gain access to data from queries appended (eg using a
union).

There might be more scenarios, but without specifics of the exploit that
is probably impossible to tell or guess; nor would it be possible to
assess if that would be something that could affect Firebird.

Mark