[Zope] Major security flaw in Zope 2.3.2

[Joachim Werner]

Hi!

> if Data.fs is owned by nobody.nogroup, Apache is installed on the same
> machine, and the user can run his own cgi-scripts (most ISPs I suppose),
then
> by default the user's CGI scripts will run as nobody too, allowing him
> to read Data.fs during his own CGI execution, and copy it wherever he
wants
> during this time.

This is indeed the only really frightening scenario. Finally a reason to not
use "nobody" but a dedicated Zope user to run a Zope instance ;-)

> Solutions:
>
> * make Data.fs and Data.fs.old only readable by a user every
>           other user on the system can't run commands as.

yep

> * But the best to do is:
>
> Encrypt all passwords in the ZODB.

And then I copy the Data.fs to a new Zope, create a superuser and walk in
... Or did I miss something?

First of all, I don't think the password issue really IS an issue. I mean,
as soon as I have read access to an Apache's data directory, I also can copy
it. You just should not be able to come that far ...

AFAIK there already exist patches for encrypted passwords, and alternative
user folder implementations do it, too.

Second, IF you want to make ZODB really secure, you would have to encrypt
all of it, e.g. using a plugin similar to the compressed storage plugin,
only doing encryption instead of compression, or doing the same thing on the
OS layer with a loopback encrypted filesystem. However, in most cases this
seems to be a bit too paranoid ...


Joachim