Re: [exim-dev] Remote root vulnerability in Exim

Ted Cooper <eximX0902w <at> linuxwan.net> writes:
> On 11/12/10 06:31, Stefan Fritsch wrote:
> > I was worried about constructs like this
> >
> > old_pool = store_pool;
> > store_pool = SEARCH_POOL;
> > reset_point = store_get(0);
> > ...
> > internal_search_find(...);
> > ...
> > store_reset(reset_point);
> > store_pool = old_pool;
> >
> > In this case, the store_reset would reset MAIN_POOL, which is not what
> > the caller of internal_search_find wanted to do. But after reading the
> > store code some more, I think that store_reset() would cause exim to
> > exit in this case, so it could only cause a DoS.

This should have read internal_*l*search_find, of course.

> >
> > But you may want to fix internal_lsearch_find() anyway, in order to
> > prevent future bugs and to make it clearer in the code that there
> > really is no problem.
>
> Is this what the pool_reset_issue patch in debian is about or is this an
> even more significant change?

No, that patch is for this issue. At the time I did the release, I was not yet
convinced that this bug could not be triggered.

> From what I can see it looks like a
> sensible thing to do. It doesn't have a detrimental effect and puts the
> global state back to the way it found it.
>
> Also, has the FD leak been addressed in an exim bug report at all? It
> seems like a very sane thing to do also. There's no need for those to be
> open to a running program.

Maybe all relevant FDs should be marked with FD_CLOEXEC?

Cheers,
Stefan

PS: Please CC me, I am not subscribed to this list.