(1.5.3) Closed an Endemic Security Hole Alex Peshkoff Previously, a user could log into a server on a Unix/Linux host remotely, using a Linux UID and pass- word accepted on that host. It was recognised as a security hole and fixed in Firebird 2 development. It is an endemic security bug in previous versions and InterBase. The security fix has been back-por- ted to Firebird 1.5.3: a UID received from the client side is now not trusted.
please provide fixed ebuilds, thanks
Created attachment 78207 [details] firebird 1.5.3 ebuild
(In reply to comment #2) > Created an attachment (id=78207) [edit] > firebird 1.5.3 ebuild > ebuild requires: cp files/firebird-1.5.2-build.patch files/firebird-1.5.3-build.patch
firebird-1.5.3 is now in portage
arches, please give us your blessing, thx
x86 done
Someone taking care about Firebird again? Nice, thanks
sparc stable.
ready for glsa vote, tend to a yes here.
i'm for yes
I vote NO as upstream doesn't even mention it in their 1.5.3 release blurb. Though you find this note if you dig deep enough: * Fixed unregistered security related bugs. 1) Server crashed when too long filename is provided 2) No longer trust UID received from the client side 3) isc_user_* functions worked wrongly under "superuser" account on win32 Contributor(s): Alex Peshkov <peshkoff at mail.ru>
Looking at their 2.0 roadmap
Looking at their 2.0 roadmap¹ it sounds like there are more security relevant issues with the 1.5.x code. The exact wording is " Weak security and many known vulnerabilities". [1] http://firebird.sourceforge.net/devel/engine/roadmap2006.html
I suggest we mask it until we have a fixed version then.
Security please comment.
yes, masking seems like a good idea.
(In reply to comment #15) > yes, masking seems like a good idea. > That would implicate quite some other packages to mask or remove Firebird support from the relevant ebuilds. Given that Firebird is not that widely used and if, then more likely in a restircted environment, I'd say a post install warning should do it. Especially since we do not have specific information.
Please provide an appropriate post install message.
(In reply to comment #17) > Please provide an appropriate post install message. > Sune, that was just my opinion, weighing the implications of possible malicious sql code or whatever may cause problems against some unwanted extra work. A possible message would be "The developers of Firebird attest their 1.5.x code base weak security, so please take this into account when using this database." It's of course Karol's and the security herds voices that count. :)
I'm for information. Masking it would impact many users, because firebird is widely used. It's not a good idea to mask it, really.
Ok, if masking is no good idea then I'd say make a big fat warning, something one simply *has* to see while emerging so we can get rid of this bug. We might send an informational glsa too, but no clue about our usual methods in such cases.
After some reconsideration I'm not too much in favour of post-install message. If it really has these problems it ought to be masked according to policy. Perhaps we should poke upstream about more details?
Packages affected by masking would be: dev-db/hk_classes dev-db/jxtray dev-db/libdbi-drivers dev-java/jdbc2-firebird dev-java/jdbc3-firebird dev-libs/ibpp dev-php5/pecl-pdo-firebird dev-python/kinterbasdb dev-python/orm dev-python/sqlobject dev-ruby/ruby-dbi gnome-extra/libgda x11-libs/qt x11-libs/qt-embedded
firebird and ia64 don't presently mix at all, so I've marked them all -ia64, and ia64 is no longer affected by this bug
been a little silent here... So what do we do with this one now... current stable version in the tree is 1.5.3-r1. Firebird 2.0 has officially been published last month it seems. Suggestions?
Wrong track, firebird's a database ^_^
i know ;-) Even though one could confuse the versions with thunderbird et al., firebird has similar versions (s. http://www.firebirdsql.org/)
long time no comments here It seems the only reason for this bug to be open is comment #13 right? So do we want a notice in the ebuild or do we ignore the statement in the roadmap or are there any open publically known security issues open?
I've committed 1.5.4 plus some debian patches including a fix for a remotely triggerable crash. It starts, but didn't test really. There're more bugs than this one, though and Karol is completely inactive. Need to find a new maintainer (definitely not me) or have to go the unpleasing way to remove it as dependency from other packages and finally Firebird itself, I suppose.
@carlo, thx for the response, I've mailed -dev for assistance. Arches please test and mark stable.
firebird is USE.masked on sparc, and there's also bug #177916, recommendations?
wfm...x86 stable
Let's wait and see wether the sparc sandbox issues are solved before taking GLSA decision.
Access violations have been resolved. I would like to remove all versions < 1.5.4-r2. Requesting all archs stabilize that version, firebird-1.5.4-r2. amd64 arch: Firebird was previously stable on that arch then was moved back to ~arch due to some questionable recommendations from upstream. Which are resolved in 1.5.4. Thus requesting rush stabilization even though it's not been 30 days in ~arch.
x86/amd64 stable
Eh, sorry for commiting an ebuild with access violations. :( No idea, why it didn't hit me.
firebird-1.5.4-r2 stable on sparc.
This one is ready for GLSA decision. I tend to vote NO.
I'll vote no, unless someone has a better issue than this one that got fixed.
I definitely vote no.
Let's kill this one off. Closing with NO GLSA.