Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buffer overrun when querying for database info on very long path through isc_database_info() API call. [CORE1447] #1865

Closed
firebird-automations opened this issue Sep 11, 2007 · 11 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Claudio Valderrama C. (robocop)

Assigned to: Claudio Valderrama C. (robocop)

It's possible to cause a buffer overrun by just creating a db on a long path.
When asking information about it through isc_database_info(), an internal buffer is saturated without checking bounds.

Commits: 8edad4b 5fcb8df b18b0ee

@firebird-automations
Copy link
Collaborator Author

Commented by: Claudio Valderrama C. (robocop)

I modified isql's show.epp in the following way:
- Added the item isc_info_db_id to the array "db_items" near the top of the file.
- Changed SHOW_dbb_parameters() so it uses a temporary buffer of length 400 bytes to be able to receive the result.
- In the same function, to the switch() that decodes the information, I added the following:

	case isc\_info\_db\_id:
		// Will print with garbage for now\.
		//It's sprintf\(info, "DB/Host = %\.\*s", length, d\);
		printf\("DB/Host = %\.\*s", length, d\);
		break;
		
	case isc\_info\_truncated:
		return info \> info\_buf; // If we got some items, we are \(partially\) successful\.

- Preprocessed, compiled isql and did the command SHOW DATABASE. Nothing strange.
- Created the following path
F:\temp\long_directory_name\long_directory_name\long_directory_name\long_directory_name\long_directory_name\extremely_long_directory_name_for_testing_fb\extremely_long_directory_name_for_testing_fb\extremely_long_directory_name_for_testing_fb\long
and put inside it the db named z234567.fdb
This was the maximum length I could achieve in W2k by normal means. Using escape sequences (using the NT namespaces) it's possible to go further.

- Connected with isql and did SHOW DATABASE again. This time the engine crashes. No surprise, since it's writing more than 300 bytes into a 256 bytes array.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Modified by: Claudio Valderrama C. (robocop)

assignee: Alexander Peshkov [ alexpeshkoff ] => Claudio Valderrama C. [ robocop ]

@firebird-automations
Copy link
Collaborator Author

Modified by: Claudio Valderrama C. (robocop)

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.1 Beta 2 [ 10190 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @pcisar

Shouldn't we back port this to 2.0 ?

@firebird-automations
Copy link
Collaborator Author

Modified by: Claudio Valderrama C. (robocop)

status: Resolved [ 5 ] => Reopened [ 4 ]

resolution: Fixed [ 1 ] =>

@firebird-automations
Copy link
Collaborator Author

Commented by: Claudio Valderrama C. (robocop)

Backported to v2.0.X as well.
It was backported to v1.5.5 in addition to the RISE-related bugs.

@firebird-automations
Copy link
Collaborator Author

Modified by: Claudio Valderrama C. (robocop)

status: Reopened [ 4 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 1.5.5 [ 10220 ]

Fix Version: 2.0.4 [ 10211 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 13020 ] => Firebird [ 13920 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment