Major security flaw in Zope 2.3.2
Hi, first I'm sorry if this is a well known problem. Anybody who can read the file Data.fs (or Data.fs.old) can also do whatever he wants on your ZODB. explanation: it seems that Zope 2.3.0 and 2.3.2 store passwords in clear text in the ZODB !!! The following is only partially tested, but should work: Say someone has a local unix account on your Zope server (don't know for NT, but I think the problem is still there), and has readonly access to the Zope/var/Data.fs file. Then he just installs Zope on his own machine, and put the stealed Data.fs file there, and use the emergency user facility to access to it. Then he just have to put an External method in the root which does: --- CUT --- for username in self.acl_users.getUserNames() : user = self.acl_users.getUser(newusername) clearpassword = user._getPassword() # do something with username/clearpassword --- CUT --- The user has now a list of username/passwords to access YOUR ZODB's root from everywhere, and can do whatever he wants. Setting rw------- permissions on Data.fs may help, but not in all cases: 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. Solutions: * make Data.fs and Data.fs.old only readable by a user every other user on the system can't run commands as. * But the best to do is: Encrypt all passwords in the ZODB. hoping this helps. bye, Jerome Alet
On Wed, Jun 06, 2001 at 02:44:10PM +0200, Jerome Alet wrote: Sorry, there was a Cut&Paste problem:
--- CUT --- for username in self.acl_users.getUserNames() : user = self.acl_users.getUser(newusername) clearpassword = user._getPassword() # do something with username/clearpassword --- CUT ---
the second line should read: user = self.acl_users.getUser(username) bye, Jerome Alet
ooops... me for one! perhaps a post-build/install script in the distributions would be useful to ensure less experienced users don't get stung by this? g On 6 Jun 2001, at 15:25, Frank Tegtmeyer wrote: From: Frank Tegtmeyer <fte@lightwerk.com> To: zope@zope.org Subject: Re: [Zope] Major security flaw in Zope 2.3.2 Date sent: Wed, 6 Jun 2001 15:25:46 +0200
On Wed, Jun 06, 2001 at 02:43:48PM +0200, Jerome Alet wrote:
* make Data.fs and Data.fs.old only readable by a user every other user on the system can't run commands as.
Anyone out there who does *not* do that?
Regards, Frank
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
+-------------------------------------------+ Garry Steedman mailto:gs@styrax.com Styrax Associates http://www.styrax.com/ "The Good Man has no shape." +-------------------------------------------+
On Wed, 6 Jun 2001, Garry Steedman wrote:
perhaps a post-build/install script in the distributions would be useful to ensure less experienced users don't get stung by this?
http://www.zope.org/Members/phd/build-zope/ Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
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
Hi Reading all these posts on default user/permissions problem. I wonder, I'm no expert, but wouldn't it be better to set the distribution scripts to create a "zope admin" user during zope's install process, a bit like PostgreSQL's postgres user? I don't know how this would work in windows... Then individual users can be assigned permissions to parts of the zope directory structure using the web interface... A pain for any sysadmin I know (when I'm wearing my sysadmin brain I hate doing anything that can't be done in vi and bash), but more potentially secure than simply requiring a generic user to use their own username. As it is now, if someone sniffed my password, and got into my account, they would be able to get into my zodb too. Isn't that how zope was cracked that time? I've also got the problem that my computer is sometimes turned off by accident, as it sits in a computer lab (there's security for you) in a university. Each time this happens I have to go in manually and turn zope on again. Is there a way to automate this? eg using a script that I can put in /etc/rc.d? Ale Joachim Werner wrote:
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
-- Alejandro Fernandez Bscp 5 Caledonian University 0790 541 8809 - ale@nin.cx
On Wed, Jun 06, 2001 at 03:34:10PM +0200, Joachim Werner wrote:
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?
Yes: you miss that after having "walked" into your own copy of a stealed Data.fs, you know all the password which will allow you to deface the original site putting there your own index_html saying "nice" things about you on the frontpage...
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 ...
Yes, you can copy it, but not modify it, see above. However this is just a matter of "the good way to do it", and "the good way to do it" regarding passwords storing is to store them in an encrypted form. bye, Jerome Alet
Yes: you miss that after having "walked" into your own copy of a stealed Data.fs, you know all the password which will allow you to deface the original site putting there your own index_html saying "nice" things about you on the frontpage...
You are right with this. However, it's funny how people think different: We are mainly building intranets, and our customers say: "It's not that much of a problem if the site is down from time to time, but absolutely nobody should get to the data if not authorized to do so." If you mainly think of public websites, the priorities are totally different: Uptime is important, and nobody should be able to modifiy the original data, i.e. deface the site or so. The data is publicly available anyway, so getting read access to it is not considered a problem ...
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 ...
Yes, you can copy it, but not modify it, see above.
see above ...
However this is just a matter of "the good way to do it", and "the good way to do it" regarding passwords storing is to store them in an encrypted form.
I am really not against encrypted passwords. DC should implement this soon. AFAIK the only reason for passwords not being encrypted yet was that the encryption modules needed were not available for all platforms or so. Joachim
"JW" == Joachim Werner <joe@iuveno-net.de> writes:
JW> I am really not against encrypted passwords. DC should JW> implement this soon. AFAIK the only reason for passwords not JW> being encrypted yet was that the encryption modules needed JW> were not available for all platforms or so. I'm coming in totally in the middle of this thread, and I only follow this list tangentially, but I thought I'd comment w.r.t. my experience in Mailman. One reason to keep passwords in the clear is to provide a mail-back service when a user forgets his or her password. If you store them in encrypted form, you can't really do this. (You could store user-supplied hints and mail those back, but that doesn't seem to work to well in my experience. I haven't seen any usability studies to say whether that's a useful approach or not.) In Mailman, we keep user passwords in the clear so we can do the monthly password reminders. However, the list admin passwords are kept as a sha1 hash - not in the clear. That means that if a list admin forgets his password, it's up to the site admin to assign them a new password. So far, this has been a workable trade-off. We have the advantage that user passwords don't protect a highly valuable resource; the worst that can happen is that they'll get unsubscribed from a list. Bad, but not catastrophic. List and site admin passwords are more valuable, so they affort a higher degree of security (and necessarily, less convenience). Side note: Mailman doesn't -- by default -- have SSL for its login pages, although I'm aware that some sites have augmented their Mailman installations to provide this. It would probably be a good idea to someday bundled this functionality. Cheers, -Barry
DC's position has always been that if you can access your boxes filesystem, you can access Zope. For a web application server this seems reasonable to me and has never concerned me, if anyone gets access to my filesystem on IIS, im screwed as well. Sending passwords over HTTP and using plain text to store them is a little more of a concern IMHO. By the way, probably the easiest way to read passwords is to install Shanes wxPython widget and browse the passwords in a GUI :) ----- Original Message ----- From: "Jerome Alet" <alet@unice.fr> To: <zope@zope.org> Sent: Wednesday, June 06, 2001 5:44 AM Subject: [Zope] Major security flaw in Zope 2.3.2
Hi,
first I'm sorry if this is a well known problem.
Anybody who can read the file Data.fs (or Data.fs.old) can also do whatever he wants on your ZODB.
explanation: it seems that Zope 2.3.0 and 2.3.2 store passwords in clear text in the ZODB !!!
The following is only partially tested, but should work:
Say someone has a local unix account on your Zope server (don't know for NT, but I think the problem is still there), and has readonly access to the Zope/var/Data.fs file.
Then he just installs Zope on his own machine, and put the stealed Data.fs file there, and use the emergency user facility to access to it.
Then he just have to put an External method in the root which does:
--- CUT --- for username in self.acl_users.getUserNames() : user = self.acl_users.getUser(newusername) clearpassword = user._getPassword() # do something with username/clearpassword --- CUT ---
The user has now a list of username/passwords to access YOUR ZODB's root from everywhere, and can do whatever he wants.
Setting rw------- permissions on Data.fs may help, but not in all cases:
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.
Solutions:
* make Data.fs and Data.fs.old only readable by a user every other user on the system can't run commands as.
* But the best to do is:
Encrypt all passwords in the ZODB.
hoping this helps.
bye,
Jerome Alet
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (8)
-
Alejandro Fernandez -
Andy -
barry＠digicool.com -
Frank Tegtmeyer -
Garry Steedman -
Jerome Alet -
Joachim Werner -
Oleg Broytmann