Issue Details (XML | Word | Printable)

Key: CORE-4058
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Alexander Peshkov
Reporter: Spencer McIntyre
Votes: 0
Watchers: 3

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

Remote Stack Buffer Overflow in Firebird SQL Server

Created: 05/Mar/13 08:16 PM   Updated: 21/Aug/16 07:02 AM
Component/s: None
Affects Version/s: 2.5.2
Fix Version/s: 2.1.5 Update 1, 2.5.2 Update 1, 2.1.6, 2.5.3

File Attachments: 1. File (2 kB)

Environment: Tested on Windows XP, 7, Server 2003 and Server 2008 with Firebird versions 2.1.3-2.1.5 and 2.5.1-2.5.2

QA Status: Done successfully
Test Details:
Bug was fixed on
On, and following lines appear in firebird.log after execution of this test:
       *** DUMP ***
       Tag=-1 Offset=18 Length=34 Eof=0
       Clump 5 at offset 0: AAAABBBBCCCCDDDD
       Fatal exception during clumplet dump: Invalid clumplet buffer structure: buffer end before end of clumplet - clumplet too long
       Plain dump starting with offset 18: <05><15>localhost.loca

 Description  « Hide
The FirebirdSQL server is vulnerable to a stack buffer overflow that can be
triggered when an unauthenticated user sends a specially crafted packet. The
result can lead to remote code execution as the user which runs the FirebirdSQL

Proof of Concept and technical details:

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 06/Mar/13 07:30 AM
Attachned python script to reproduce

Alexander Peshkov added a comment - 06/Mar/13 11:38 AM
A reason is a bug when extracting a group number from the CNCT info, sent by client. Size of received data was not checked. Bug exists from the first most days of firebird.

The main irony here is that this group info was never used later in the code, and therefore was cleaned up in the trunk. I.e. trunk does not require fixing.

Spencer McIntyre added a comment - 06/Mar/13 02:00 PM
I just tested against the latest build for 2.5.3 Windows 32-bit. Specifically I tested the classic, super and superclassic versions from this and they were still vulnerable except for the classic version.

Could you please provide me a revision number for when this issue was fixed?

Spencer McIntyre added a comment - 06/Mar/13 05:49 PM
I just heard back from MITRE who has reserved CVE-2013-2492 to identify this vulnerability.

Dmitry Yemanov added a comment - 07/Mar/13 05:43 AM
The fixed snapshot builds will be available today, build numbers are 26623 for v2.5 and 18514 for v2.1.