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

On Tue, 2002-08-20 at 23:34, Neil Conway wrote:
> 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
>

Assuming that we do go ahead with a 7.2.2 release, can we get some kind
of unofficial statement on pushing back the 7.3 beta? I know Tom was
hoping to start it by sept 1 but that seems rushed to me. Furthermore,
between schema support and now more backward incompatibility in regards
to functions/opaque, should we open some discussion on 7.3 really being
8.0?

Robert Treat