[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bzip2 1.0.7 released

On Thu, Jun 27, 2019 at 4:58 PM Mark Wielaard <mark@klomp.org> wrote:
> On Thu, Jun 27, 2019 at 08:54:08PM +0200, Mark Wielaard wrote:
> > * Make sure nSelectors is not out of range (CVE-2019-12900)
> Well, that was quick... There is already a regression report about
> this fix. See https://bugs.launchpad.net/ubuntu/+source/bzip2/+bug/1834494
> ...
> -#define BZ_MAX_SELECTORS (2 + (900000 / BZ_G_SIZE))
> +#define BZ_MAX_SELECTORS (7 + (900000 / BZ_G_SIZE))
> But of course I cannot tell why increasing the max with 5 is correct.
> It might well be that the file is invalid. Before the fix bunzip2
> would overwrite some memory after the selectorMtf array. So it might
> be the file decompressed by accident in the past.
> I'll look a but deeper, but if people have a clue what exactly is
> going on that would be appreciated.

Hi Mark.

At this point, I think you should perform the root cause analysis.

I think you are having trouble identifying the the problem(s) because
the code is not instrumented, and it does not debug itself. It
requires manual intervention and time under the debugger. Time under a
debugger is mostly a waste of time in my opinion. You have better
things to do with your time.

If this were my module, then I would fill the program with ASSERT's so
the module debugs itself in non-release builds. Then, run all the
malformed test data you can find.

The good thing about instrumenting with asserts is, it is monkey work.
You can task an intern with it, and not waste a senior dev's time with
it. Even better, the intern can then identify the problems so you
don't waste your time with it.

I know assert's are not preferred in the Unix world. Many Unix dev's
prefer to cling to the old K&R way of writing code from the 1970's.
But there are a lot better ways to develop nowadays, and self
debugging code is one of them.

(This is really a policies and procedures problem. The development
process has gaps. The fix is to require completely instrumented code.
But to do that, you have to deal with the political problem of people
clinging to ancient K&R patterns).