Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

(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 an attachment (id=78207) [details]
firebird 1.5.3 ebuild

(In reply to comment #2)
> Created an attachment (id=78207) [edit] [details]
> 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.