Re: serious security bug in wu-ftpd v2.4 -- PATCH

[bjorn () sparta lu se (Bjorn Wesen)]

> /* These two functions are a kludge to try to stop a possible
> security problem with stray signals and seteuid(0) calls. I am
> taking the idea from Wietse Venema, I don't see how it can harm
> anything and ought to stop this particular hole (until a new/better
> method is found).
> */

The lesson to be learned here is to avoid doing stuff in signal handlers in
secure programs, and actually, try to avoid it in "normal" programs also.
Proper behaviour would be to have the sighandlers set volatile variables
and checking these in appropriate places in the normal flow of control, or
some similar mechanism.

The source to the problem in wu-ftpd isn't as much the lack of protection
of critical regions but the lethal design of signals longjmp'ing around
etc. I mean, I don't know the whole program but it sure looks as if it can
probably bug out in MANY ways even if you protect the setuid(0) regions due
to the SIGURG behaviour.

What should be done is to revamp these parts of wu-ftpd totally and look
if/how it's possible to avoid that longjmp for example. That way you can
avoid the critical region patches and their associated problems with
signal() behaving differently in all OS'es.

Well what _really_ should be done it seems is to give up wu-ftpd and write
a more maintainable program :) the source looks absolutely horrible... But
there are of course existing alternatives.. don't know if they are less
kludgy though.

Sorry if the last paragraph was a bit off topic.

Bjorn

ps has anyone actually tested if it's possible to exploit this race
condition in a way that yields success in a sane amount of tries?