Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> As for making a 7.2.2 release for the sake of form and for those
> users who do provide access to untrusted users (universities, ISPs,
> say) this would be pointless without the changes to opaque which Tom
> has put forward and may/may not work on before 7.3 beta.

I don't think that releasing 7.2.2 without the opaque changes would be
pointless. For one thing, the opaque-related security problems are
comparatively minor: the cracker must be able to execute arbitrary SQL
commands against the database, and by that stage of the game, a DoS
attack is already trivial (e.g. disable GEQO and execute a 15 table
join query).

Also, from skimming the discussion on fixing the opaque problems,
there will be at least some degree of backwards incompatibility. That
is definitely undesirable for a stable point release -- as is an
initdb, as you point out. This amount of pain to fix a minor security
hole is *not* worth it, IMHO.

So I think that fixing the opaque problems in 7.2.x is simply
impossible. Given that, the question is whether we should make a 7.2.2
release with fixes for the other security holes (lpad(), rpad(),
reverse(), and the datetime overruns). IMHO, we should.

The datetime hole is fairly serious: it's not unreasonable for
developers to accept datetime input from the user without limiting
it's length. So it's quite likely that there are 7.2 systems in
production that have a sane security policy (e.g. hidden behind a
firewall, validate user input, etc.) that are still vulnerable.

The alternative seems unattractive: if we require that users wait for
7.3 to come out, it may be months before the 7.3.0 release. And even
then, upgrading to 7.3 is non-trivial: it requires an initdb and
reload, as well as testing to ensure that the user's applications run
smoothly on 7.3. Therefore, it may be several months before many
production sites upgrade to 7.3; leaving them in the cold for that
period isn't something I think we should do, if we can avoid it.

That said, there's only a limited amount that I can do. I think we
should make a 7.2.2 release, and to that end I've posted patches
against REL7_2_STABLE for all four of the security holes. The rest of
the work that goes into making a release needs to be done by others
(Marc, Vince, Bruce, etc.) -- if there's anything I can do to help,
let me know.

Cheers,

Neil

--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC