On 13-4-2011 9:39, Alex Peshkoff wrote: > On 04/13/11 10:31, Jim wrote: > > I will comment this mainly from security POV. Ok, thanks. > >> Why: developers/end users can more easily choose and connect to a >> database on a Firebird server, even point and click. > > Point and click should be implemented by client, not by server. Agreed. I meant that a point & click interface on the client side can be implemented more easily this way. Otherwise you'd have to write a serverside daemon that scans for all fdb files or something, bringing other risks. > >> - Security issue: leakage of information on databases present on system. > > This is very serious issue. Knowing what particular databases are > present makes it easier to attack them. Yes, that is true. That's why I suggested turning the feature off by default and documenting this. As I envision the feature, though, you would have to have valid credentials to the server first....
(On the other hand, brute forcing an 8 character password and a mostly unchanged SYSDBA username isn't too hard; you could add some common database names (e.g. employee, data, application name/default name for certain applications) and try to brute force that too. But that discussion is another one. I don't intend to start a flame war about how my feature is insecure but it's already insecure, so... ;) In other words, yes it is a risk. > >> - Security issue: denial of service attacks with valid credentials by >> bruteforcing database aliases has increased impact (due to more code >> executing). Remediation: turn of DatabaseAutoRegistration in fb.conf; >> needs to be documented in manual/release notes >> > > With valid credentials one can have much more efficient attacks on server. See above. > >> ======================================================================== >> >> Assumptions/requirements: >> - Firebird process has write access to firebird.conf. Should be >> documented in manual/release notes. See below for troubleshooting. > > Write access from daemon to it's configuration files is very bad from > security POV. Oooops, big mistake on my part. I meant aliases.conf of course. Still, I see your point that this is not as secure as not allowing access. I suppose the extra risks for aliases would be: - If you gain unauthorized access to the server process in some way: -- Denial of service because you can delete aliases. -- Impersonation attacks because you could change aliases. Would require access to the filesystem on the server. -- Exploiting race conditions or other weaknesses that corrupt aliases.conf resulting in denial of service. Of course it's a tradeoff. If you want to be more conservative, you could mandate that aliases.conf should not be touched. In this way, you lose dynamic registration, and have the administrator manage the list of databases shown in RDB$DATABASES. This actually is a simpler solution that might be practical in an enterpise environment. Thanks for the valuable feedback, -- Regards, jb ------------------------------------------------------------------------------ Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
