From ${URL} : Description A vulnerability has been discovered in Firebird, which can be exploited by malicious people to compromise a vulnerable system. The vulnerability is caused due to an error when processing requests and can be exploited to cause a buffer overflow via a specially crafted request sent to TCP port 3050. Successful exploitation allows execution of arbitrary code. The vulnerability is confirmed in version 2.5.2.26539. Other versions may also be affected. Solution No official solution is currently available. Provided and/or discovered by Spencer McIntyre Original Advisory http://dev.metasploit.com/redmine/projects/framework/repository/entry/modules/exploits/windows/misc/fb_cnct_group.rb
http://web.nvd.nist.gov/view/vuln/detail;jsessionid=00730F5B2679C273A8CE8C9B41BBD142?vulnId=CVE-2013-2492 : Stack-based buffer overflow in Firebird 2.1.3 through 2.1.5 before 18514, and 2.5.1 through 2.5.3 before 26623, on Windows allows remote attackers to execute arbitrary code via a crafted packet to TCP port 3050, related to a missing size check during extraction of a group number from CNCT information.
@maintainers: version bump, please.
# Andreas K. Huettel <dilfridge@gentoo.org> (29 Jun 2014) # Severe security issue (bug 460780), unhandled for over a year. # Masked for removal in 30 days. dev-db/firebird dev-db/flamerobin dev-libs/ibpp dev-python/kinterbasdb # Mask use-flag firebird and package dev-db/firebird for bug 460780 firebird
This was addressed in 2.5.2.26540-0 which is in tree. If you see the release notes. That was released after the exploit was reported. That version should be stabilized and others removed. Instead of mask or removal from tree. Clearly no one did any research here.... http://www.firebirdsql.org/file/documentation/release_notes/html/rlsnotes252.html#notes-252_su1
(In reply to William L. Thomson Jr. from comment #4) > Clearly no one did any research here.... Guess whose job that would be...
I am NOT a developer it is NOT my job. You are seeking to erronously remove something from tree. Not even looking at the latest version in tree and/or if it satisifies this security bug. You are the one working this bug. Someone else already did the work of bumping the ebuild. Devrel/recruiting have made it such on several occasions preventing me from returning. Clearly the current developer pool is lacking, I am pretty sure its procedure to do research on packages you are seeking to mask and remove from tree.... But nice try to put the blame on another. I cannot stabilize or do anything as a outsider.... I have no commit access, I am NOT a dev. This is not my responsibilty. I am simply pointing out that you are about to make a mistake removing a package thinking its insecure, when it was addressed over a year ago. Next time do research before masking a package and/or working a security bug which this is.... It can be closed as resolved, and 2.5.2.26540 should be stabilized ASAP and all other versions removed. FYI I never liked keeping older versions around. When I maintained firebird I tried to remove all but current. Its not slotted from upstream, thus not slotted in tree. But for some reason people wanted to keep ancient versions around. All should be removed by the one version, and that be stablized, and issue resolved. Nothing needs to be masked, removed, etc. This is all normal stuff, but clearly Gentoo is no longer following decades + procedures anymore.... Very sad!!!!
Since the package is currently not vulnerable, I would suggest the following: - remove wltjr from metadata.xml as he told me he didn't know he was put there and doesn't want to be responsible for the package without having himself commit access - remove patrick as well as he was a proxy maintainer for wltjr and apparently didn't do the job properly - assign to maintainer-needed (or wanted? I always confuse the two), maybe swift would be interested as he did the last bump? Maybe with some other proxy maintainership? - if nobody takes over, mask as soon as new vulnerability or major bug comes
This was a Windows vulnerability, not other platforms. There is no mention of any platform in the CVE. Nor is there any record of anyone conducting such an exploit on Linux or any *nix version of Firebird. I can only assume this effected Linux, but there is no proof. Nor did anyone on security or otherwise seek out such proof, conduct any exploit test or experiments or anything.... "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" tracker.firebirdsql.org/browse/CORE-4058 "The exploit has been successfully tested on multiple 32-bit installations of Firebird SQL on both 32 and 64 bit versions of Windows including Server 2008, Windows 7, and Server 2003." blog.securestate.com/firebird-sql-stack-buffer-overflow-cve-2013-2492/ Can anyone find any proof of this ever being vulnerable on Linux? I guess any package that is found vulnerable on Windows should be vulnerable on Linux and other platforms as well, makes sense....
(In reply to Andreas K. Hüttel from comment #3) > > # Mask use-flag firebird and package dev-db/firebird for bug 460780 > firebird Now the use-flag firebird is masked and disappeared from PHP. Whenever I would recompile (or emerge --update) PHP now, the ibase_ functions would disappear, and all my scripts on all my webservers would malfunction. Why do you mask the *client* library while (a certain old version of) the *server* is vulnerable? Do I have to put dev-lang/php into package.mask now and stuck to the current version? This cannot be true :-( In addition, I have installed a current 2.5 firebird server myself and put it into package.provided. But without PHP ibase_ functions, it's become absolutely worthless. Since I guess I'm not the only one whose web server applications would break completely without ibase_ functions, there *should* be a quick solution for this...
(In reply to Matthias Hanft from comment #9) > > Since I guess I'm not the only one whose web server applications would break > completely without ibase_ functions, there *should* be a quick solution for > this... Ok, after desperately googling, I have found echo "-firebird" >> /etc/portage/profile/use.mask hence it's not that urgent any more. Sorry for being paniced, but wouldn't you get paniced as well if all your web server apps wouldn't work any more? :-) Nevertheless, I second the latest firebird version getting stabilized...
From http://www.firebirdsql.org/file/documentation/release_notes/html/rlsnotes252.html#notes-252_su1 """"""" Firebird 2.5.2 Security Update 1 A remote stack buffer overflow was discovered in the Firebird Server during March, 2013 that allows an unauthenticated user to crash the server and opens a gate for remote code execution. The vulnerability was patched by Alex Peshkov. All Firebird binaries released with build numbers 23539 or lower and all snapshot builds before 2013.03.08 have this vulnerability. """"""" (Maybe mistake in release notes... 23539 -> 26539 ?? ) I think it would be good to leave version 2.5.2.26540.0
Link from Comment #1 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2492 """""""""""""""""" External Source: CONFIRM Name: http://tracker.firebirdsql.org/browse/CORE-4058 Type: Advisory; Exploit Hyperlink: http://tracker.firebirdsql.org/browse/CORE-4058 """""""""""""""""" http://tracker.firebirdsql.org/browse/CORE-4058 """""""""""""""""" Fix Version/s: 2.1.5 Update 1, 2.5.2 Update 1, 2.1.6, 2.5.3 """""""""""""""""" Latest Releases on site http://www.firebirdsql.org Firebird 2.5 - Firebird 2.5.2 Security Update 1 File - Firebird-2.5.2.26540-0.tar.bz2 Firebird 2.1 - Firebird 2.1.6 File - Firebird-2.1.6.18547-0.tar.bz2 Discontinued : Firebird 2.0, Firebird 1.5, Firebird 1.0 I ask to leave in portage dev-db/firebird-2.5.2.26540.0 and remove other versions.
This package is currently masked as there are no maintainers for it, if anyone wants to proxy maintain the package please contact: proxy-maint@gentoo.org Please see: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers We will leave this bug around for 30 days to see if someone wants to volunteer.
I have requested to be a proxy maintainer for this package Also i agree that only 2.5.2.26540.0 should be left in the tree Also Firebird is ported on all Gentoo architectures http://buildd.debian-ports.org/status/package.php?p=firebird2.5&suite=unstable
@Wadlax it's a mistake in the release notes i have send a request to doc team to fixit 23539 -> 26539 I have tested the package in a lxc container and package seems to be usable at first look https://plus.google.com/u/0/+AdrianMariusPopa/posts/cyzHqqQtDPY So only versions < 2.5.2.26540.0 should be masked 26540+ is what we have in ubuntu/debian (wheezie, jessie , sied)/fedora and is marked as secure
(In reply to Adrian Marius Popa from comment #14) > I have requested to be a proxy maintainer for this package > > Also i agree that only 2.5.2.26540.0 should be left in the tree > > > Also Firebird is ported on all Gentoo architectures > > http://buildd.debian-ports.org/status/package.php?p=firebird2. > 5&suite=unstable I'm confused here, you said "firebird is ported on all gentoo arches" but linked with a debian URL? Tests passed on debian does not always guarantee it also pass in Gentoo.
Has anyone ever confirmed this vulnerability even existed on Linux or Gentoo? Since we are saying Debian fixes might not have fixed it in Gentoo... Getting REALLY stupid now... This was an exploit that was SOLELY tested on Windows. There have NEVER been tests for this exploit against any distro of Linux. Everyone in Linux assumed a Windows vulnerabiltiy also effected Firebird on Linux. Though upstream NEVER reported such, its not on the CVE, nor anywhere... That said, this was fixed by UPSTREAM, not Debian or others. The Firebird project addressed this legacy exploit that effected and was only tested and confirmed on Windows. I have no idea why anyone would assume this is not addressed. If you are going to make that assumption, you need to PROVE this exploit actually effected version of Firebird on Gentoo Linux. Then you can run the same tests against the last version on Gentoo Linux, and see the exploit no longer exists.... Given the amount of packages, the lack of developers, everyone's time is best spent else where, not on such futility.... Is the Security Team doing anything here to actually help this or just standing in the way of closing this bug? Has the security team ever tested this package and/or confirmed this vulnerabilty existed on Gentoo? If the security team has not confirmed this issue existed, then they should not be standing in the way of resolving this bug. Confirm it existed, confirm its been fixed, or get out of the way and remove the mask, old versions, and stabilize the lastest version and we can all go work on something beneficial.
dev-db/firebird-2.5.2.26540 version bump solved the security issue https://bugs.gentoo.org/show_bug.cgi?id=467942 the only thing that remains is the maintainer issue
(In reply to Yixun Lan from comment #16) > (In reply to Adrian Marius Popa from comment #14) > > I have requested to be a proxy maintainer for this package > > > > Also i agree that only 2.5.2.26540.0 should be left in the tree > > > > > > Also Firebird is ported on all Gentoo architectures > > > > http://buildd.debian-ports.org/status/package.php?p=firebird2. > > 5&suite=unstable > > I'm confused here, you said "firebird is ported on all gentoo arches" but > linked with a debian URL? Tests passed on debian does not always guarantee > it also pass in Gentoo. Firebird cpu port usually is a new configure option also some defines in headers you can check the work/patch that was needed for arm64 https://sourceforge.net/p/firebird/mailman/message/31692503/ All these defines are done for the cpus supported for gentoo (arches) in the firebird source so when firebird builds on one of these cpus it builds also it's own self test databases (security,examples...) So firebird is ready to compile on all these cpus (that is how the deb package is build )
(In reply to Andreas K. Hüttel from comment #3) > # Andreas K. Huettel <dilfridge@gentoo.org> (29 Jun 2014) > # Severe security issue (bug 460780), unhandled for over a year. > # Masked for removal in 30 days. > dev-db/firebird > dev-db/flamerobin > dev-libs/ibpp > dev-python/kinterbasdb Kinterbasdb is no longer an active project. For me, it could be removed from portage. Replacement for kinterbasdb is fdb (https://bugs.gentoo.org/show_bug.cgi?id=462484). Developers should focus more on fdb than Kinterbasdb.
(In reply to Vincent Hardy from comment #20) > (In reply to Andreas K. Hüttel from comment #3) > > # Andreas K. Huettel <dilfridge@gentoo.org> (29 Jun 2014) > > # Severe security issue (bug 460780), unhandled for over a year. > > # Masked for removal in 30 days. > > dev-db/firebird > > dev-db/flamerobin > > dev-libs/ibpp > > dev-python/kinterbasdb > > Kinterbasdb is no longer an active project. For me, it could be removed from > portage. > Replacement for kinterbasdb is fdb > (https://bugs.gentoo.org/show_bug.cgi?id=462484). Developers should focus > more on fdb than Kinterbasdb. also dev-libs/ibpp can be removed it's development is stalled and license imposes some restrictions acording to fedora legal https://lists.fedoraproject.org/pipermail/legal/2012-August/001959.html
Why is this package still masked? Also since when does a package having a stale upstream justify its removal, speaking of ibpp? Fedorda is not not saying there is a problem with the license, invalid, etc at best non-free, so that should not be reason to remove from tree.
+ 07 Sep 2014; Pacho Ramos <pacho@gentoo.org> + -files/firebird-2.0.3.12981.0-CVE-2008-0387.patch, + -files/firebird-2.0.3.12981.0-CVE-2008-0467.patch, + -files/firebird-2.0.3.12981.0-external-libs.patch, + -files/firebird-2.0.3.12981.0-flags.patch, + -files/firebird-2.0.3.12981.0-make-deps.patch, + -files/firebird-2.1.2.18118.0-deps-flags-libs.patch, + -files/firebird-2.1.2.18118.0-gcc-icu-declare.patch, + -files/firebird-2.5.0.26074.0-build.patch, + -files/firebird-2.5.0.26074.0-client.patch, + -files/firebird-2.5.0.26074.0-deps-flags-libs.patch, + -files/firebird-2.5.0.26074.0-deps-flags.patch, + -files/firebird-2.5.0.26074.0-superclassic.patch, + -firebird-2.0.3.12981.0-r6.ebuild, -firebird-2.1.3.18185.0-r1.ebuild, + -firebird-2.5.2.26539.0.ebuild, metadata.xml: + Remove vulnerable versions, move to maintainer-needed (#460780) +
Pacho Ramos, thank you for restoring package and "firebird" use-flag. For Your Info: Some connected packages (qtsql and php) still have masked firebird use flag. In /usr/portage/profiles/ ( grep -r firebird * ) firebird use-flag IS masked in file base/use.mask And was masked there before "removal" firebird use-flag WAS UNmasked for packages qtsql and php in file profiles/arch/amd64/package.use.mask """""""""""""""" # Markos Chandras <hwoarang@gentoo.org> (10 Jun 2011) # Unmask firebird on qtsql per bug #337451 dev-qt/qtsql -firebird # Markos Chandras <hwoarang@gentoo.org> (03 May 2011) # Unmask firebird only for php dev-lang/php -firebird """""""""""""""" . If you want these packages with firebird use-flag , you can create file and add unmask text to it /etc/portage/profile/package.use.mask/firebird """""""""""""""" # Markos Chandras <hwoarang@gentoo.org> (10 Jun 2011) # Unmask firebird on qtsql per bug #337451 dev-qt/qtsql -firebird # Markos Chandras <hwoarang@gentoo.org> (03 May 2011) # Unmask firebird only for php dev-lang/php -firebird """""""""""""""" . The firebird use flag is restored. The version 2.5.2.26540.0 is not vulnerable. Btw , if that unmask text is restored in portage tree... The bug can be closed ?
Recently deleted dev-db/firebird-2.0.3.12981.0-r6 was stable on amd64 and x86. As mentioned in comment #4, dev-db/firebird-2.5.2.26540.0 should be stabilized.
I think would be much better to downgrade all to testing only as they were at first hardmasked, later the bug ignored for months and, later, the package finally moved to maintainer-needed. Maybe if finally someone takes care of it and is able to maintain it properly...
The package as well as others has no maintainer because of the former devrel entity and recruiting. They never filled the vacancy they created. Also the alleged security issue was NEVER tested or proven to even exist on Linux. Thus I question the legitimacy of the package mask in the first place. That was someone who was over zealous not following long time policies. Plus unmaintained packages should fall to the devs maintaining the herd. But I guess dev-db herd is lacking developers to help maintain that herd. There are many packages neglected in gentoo or with maintainer neededm some 1492 according to euscan on gentoo experimental. No reason to punt just because there is no maintainer.
Did you have any problem trying to become a dev or similar? Maybe that could be solved (or did that problems occur years ago before I joined? :/) Regarding this concrete issue, the problem was caused by security team relying on maintainers to take care of this... as this package was really orphan (even having people listed in metadata.xml), the request was ignored for a long long time until Andreas saw it and decided to take the "safest" approach (until he masked the package, nobody said anything). After that, we saw the information in metadata.xml was outdated and all the argument rised :|
(In reply to Pacho Ramos from comment #28) > Did you have any problem trying to become a dev or similar? Maybe that could > be solved (or did that problems occur years ago before I joined? :/) Long story spanning many years, not sure if you were around. See bug 135927 for the drama. In short I was doing controversial things like getting the foundation reinstanted legally, a bank account, etc. I got harrassed, resginged from board of trustees, then banned from nfp mailing list over bs. Days later devrel took action they needed not to escalating the matter instead of descalation. Which caused me to resign as a dev after stepping down from the board due to harrassment. Devrel did nothing but make things worse instead of better, useless entity. I tried to return several times. People just got in my way, made bs excuses about conflict of interest. Wasted major time like 2hrs on quiz review to not even make it half way through the 1st of 3 quizzes as a returning developer. Despite it taking less time when I was a new developer the first time. People in devrel/recruiting did everything they could to keep me from returning. But even worse never filled vaccancies and several packages I maintained have gone without maintainer since I left over 4 years ago now, I think close to 6 years. This has had a larger negative effect on Gentoo. Those in devrel recruiting, should be removed and not part of the project what so ever. They are doing more harm than good. Gentoo Java is a total joke these days, as other parts of the tree. I blame the gate keepers!!!! Gentoo needs developers badly!!! > Regarding this concrete issue, the problem was caused by security team > relying on maintainers to take care of this... as this package was really > orphan (even having people listed in metadata.xml), the request was ignored > for a long long time until Andreas saw it and decided to take the "safest" > approach (until he masked the package, nobody said anything). After that, we > saw the information in metadata.xml was outdated and all the argument rised > :| The stuff in metadata wasn't outdated. I just did not like being a proxy maintainer. It is a waste of time. Patrick was being proactive and put me down as a maintainer to encourage me to continue contributing. Despite others putting me off and motivating me to not contribute. I spoke up as soon as I saw the mask. Granted should have done something to address, but given it was a confirmed vulnerabilty on Windows and had never been confirmed nor tested or proven on Linux. It wasn't a major concern to me. Nor was it a large enough security issue to warrant package removal. Back when I was a dev I recall the process to mask a remove a package to be much more involved and serious business. It did not seem like it was being handled presently as it would have in previous years. But that could be said about many things with regard to gentoo.
(In reply to William L. Thomson Jr. from comment #29) > (In reply to Pacho Ramos from comment #28) > > Did you have any problem trying to become a dev or similar? Maybe that could > > be solved (or did that problems occur years ago before I joined? :/) > > […] Could you (pretty) please discuss this in private. We have too many people watching the alias, making this bug absolutely not an appropriate forum for your concerns regarding recruitment, or any other aspects of today's Gentoo. Back to the topic: AFAICS, the problem here was caused by bug 467942 not being handled correctly. It should have been a dupe of this bug and bumping and stabilization handled here. SwifT: Please be sure to assign bugs that request security-related bumps to security to help with correctly dispatching issues. On stabilizing or not: As security is fine with either: QA, can we please get a second opinion on Pacho's request (comment #26)?
(In reply to Alex Legler from comment #30) > (In reply to William L. Thomson Jr. from comment #29) > > (In reply to Pacho Ramos from comment #28) > > > Did you have any problem trying to become a dev or similar? Maybe that could > > > be solved (or did that problems occur years ago before I joined? :/) > > > > […] > > Could you (pretty) please discuss this in private. We have too many people > watching the alias, making this bug absolutely not an appropriate forum for > your concerns regarding recruitment, or any other aspects of today's Gentoo. > Sorry to respond OT here. I agree this bug is not the appropriate place, but please do NOT just discuss this in private. What I've read here should go on a public ML, like gentoo-project.
Ping. Firebird was unmasked, and as it was stable - we should either procede with stabilization and properly unmask firebird USE-flag on apropriate arches. Or just stable mask it.
There is no stable version since the package was "rescued" after its last ritting , and I think it should be kept in testing (taking care it's orphan and won't likely get much attention)
(In reply to Pacho Ramos from comment #33) > There is no stable version since the package was "rescued" after its last > ritting , and I think it should be kept in testing (taking care it's orphan > and won't likely get much attention) Fine by me. UnCCing qa@ - our business is completed here Added to the new GLSA request
How many more years before this is closed?
This issue was resolved and addressed in GLSA 201512-11 at https://security.gentoo.org/glsa/201512-11 by GLSA coordinator Yury German (BlueKnight).
