Issue Details (XML | Word | Printable)

Key: CORE-1789
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Kovalenko Dmitry
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Access to children of multiple transaction

Created: 13/Mar/08 09:17 AM   Updated: 14/Mar/08 07:15 AM
Component/s: API / Client Library
Affects Version/s: 2.5 Initial
Fix Version/s: None


 Description  « Hide
fbclient.dll allows access to internal transactions created at multiple transaction

Scenario
1. create two connection: cn1, cn2
2. start of single transaction1 (cn1)
3. start of multiple transaction (cn1 and cn2)
4. start of single transaction2 (cn1)
5. scan the handles at range (transaction1_handle, transaction2_handle). Exclude handle of multiple transaction

Obtained new handles can be used as separate transactions handles.



 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 13/Mar/08 11:54 AM
Do you want sub-transactions to have non-public handles? Or do you have problems with the range scan hack? The latter is by design, FWIW (although there's no guarantee you will be so lucky under high load).

Kovalenko Dmitry added a comment - 13/Mar/08 12:27 PM
I want obtain the error "invalid transaction handle" when the non-public transaction handles uses with public API

Alexander Peshkov added a comment - 14/Mar/08 03:45 AM
What is described here is not a vulnerability. I'm agreed that API should be able to protect from crazy errors (like NULL pointer when non-NULL expected, etc.). But what you suggest here (scan range of handles from M to N) sooner looks like attack on remote site, not use of API, when you work with your _own_ set of transactions. Why in the hell would any user try to find and use subhandles of his own, legally started transaction? If he wants to break his application inside API call, there are a lot of much simpler ways to do it - just use not NULL, but invalid pointer:)
This range scan will never let him to gain accees to the resources which he cannot reach without it. Therefore I suggest to close this request.

Kovalenko Dmitry added a comment - 14/Mar/08 04:36 AM
The test for this problem has about 100 lines

Correction of this problem (I think) will be have less than 100 lines
 - append the property 'is_public_resources' to BaseHandle
 - correct translate<> template function. Append the argument public_resource_only. Or create new translate<> template

Or [more private case]
 - append the property 'is_public_resource' to Transaction
 - create (specialization?) translate<> template for Transaction

Alexander Peshkov added a comment - 14/Mar/08 07:15 AM
Dmitry, could it be a real problem we will take measures to fix. But I see no problems here at all.