[pkg-firebird-general] Bug#432753: [Firebird-devel] Old 1.5 security issues question

[Alex Peshkov]

On Wednesday 15 August 2007 11:05, Damyan Ivanov wrote:
> >>     http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7214
> >>     CVE-2006-7214
> >>     Multiple unspecified vulnerabilities in Firebird 1.5 allow remote
> >>     attackers to (1) cause a denial of service (application crash) by
> >>     sending many remote protocol versions; and (2) cause a denial of
> >>     service (connection drop) via certain network traffic, as
> >>     demonstrated by Nessus vulnerability scanning.
> >
> > This one in theory can be fixed - backporting from HEAD is possible.
>
> OK. I don't require that you make the porting. I just need some clues
> about what exactly the problems are (instructions how to reproduce them
> would be nice) and where to look at for fixes. Is this feasible?
> I really would not want to take too much time from you.

No 1 is specially dangerous cause easy to reproduce (with 2.0 I failed to kill 
server with Nessus - may be did not run it long enough).
There is fixed size CNCT_VERSIONS plain-C array p_cnct_versions (see 
op_connect in protocol.cpp, bool_t xdr_protocol(XDR* xdrs, PACKET* p)). I 
think that comparing one from 1.5 and HEAD will give you clear idea what 
happens. To reliably reproduce an issue I was building a special client that 
was sending >10 kinds of suggested protocol to server. I did not keep it 
after fixing a bug.

> >>     http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-7212
> >>     CVE-2006-7212
> >>     Multiple buffer overflows in Firebird 1.5, one of which affects
> >>     WNET, have unknown impact and attack vectors. NOTE: this issue might
> >>     overlap CVE-2006-1240.
> >
> > They are so multiple that it's close to impossible to backport them.
> > Moreover, fixes for some of them are based on new collection of classes,
> > introduced in 2.0. I.e. firebird after fixing all BOFs will not be 1.5
> > any more :)
>
> I see. Unfortunately we can't just drop 2.0 as a replacement for 1.5 in
> Debian/stable, because "stable" is meant to not offer *any* surprises
> and migration from 1.5 to 2.0 is far from trivial.
>
> Can you estimate to what extentt 1.5.4 suffers from this, compared to
> 1.5.3?

Some are fixed, most not.