Description
Security issue - How to obtain another identity
This is a security issue, where anybody with access to the data directory can obtain any users identity by using, the lost password feature of MoinMoin. You just have to combine the user identity into the default link.
Example
By following the link below you can obtain access as me (PeterGylling). This link can be constructed by anybody who can read the data/user directory.
Details
From the latest source : MoinMoin ver. 1.2.3 I have extracted this line from the tar-ball.
drwxr-xr-x twaldmann/twaldmann 0 2004-07-21 22:04:33 moin-1.2.3/wiki/data/user/ -rw-r--r-- twaldmann/twaldmann 239 2004-07-21 22:02:17 moin-1.2.3/wiki/data/user/README
- It should be changed to this:
drwxr-x--- twaldmann/twaldmann 0 2004-07-21 22:04:33 moin-1.2.3/wiki/data/user/ -rw-r--r-- twaldmann/twaldmann 239 2004-07-21 22:02:17 moin-1.2.3/wiki/data/user/README
- From our settings:
peg@bw03> ls -ld /var/www/moin-1.2.3/share/moin/LinuxSetupProject/user drwxrwx--- 2 apache apache 4096 Jul 1 12:57 /var/www/moin-1.2.3/share/moin/LinuxSetupProject/user
Discussion
This security issue is relevant to all serving MoinMoin in a multi user environment, where any user usually have read access to practically any partitions on the server. And you don't need more than read access to gain un-authorized access to a wiki which is ACL protected.
We use the MoinMoin product to document how to setup our Linux environment, and this is vital information to us, though we are running with ACL enabled to make sure, that the persons who can obtain write access is knowing what he/she is doing.
Replacing these lines in userform.UserSettingsHandler.handleData:
with:
should disable the uid only login. Or you could remove the lines in user.User that don't check the password if the uid is given. -- OliverGraf 2004-07-27 08:56:51
This problem is obviously not solvable. Even if you disable UID login you can easily read the encrypted password and change it with this information. In my opinion it is task of the wiki administrator to keep the data dir secret - if he doesn't all security will fail... -- FlorianFesti 2004-07-27 15:02:06
You are right: If the attacker is already on the server and can read the UIDs, he can also read the password hashes and crack them. But there are other ways to obtain the UID (I've seen them on pages, in logentries, etc...) and so disabling is a bit more security in my eyes. The same is true for the MOIN_ID cookie. Its not about total security its about making it harder to mask as someone else. -- OliverGraf 2004-07-27 17:49:42
This is not a "bug". This is how moin worked since the beginning. You have to keep the data directory secret, so no unauthorized person can access it (no matter if it is the subdirectory data, backup or user - in any of them you could find data that is not for everybody's eyes). The install docs have a big red hint to NOT put data under documentroot (as some people did that accidently, making it even available via the web server).
Of course the usage of that "uid" like it is now is not the best method one can think of. But as many people used that for "login bookmarks" we could not switch that off completely yet. Same if you lose your password and did not enter a valid email address - then that uid method is a simple way to get access again (with the help of a wiki admin).
Using that UID stuff for login purposes is deprecated though and you must enter name, password and email now, so we can switch off that uid login method - as soon as a better method is implemented.
I will look into changing the mode of the data directory, though. Thanks for that hint.
-- ThomasWaldmann 2004-07-28 14:44:41
But we can add a config option that switches to a different authentication and session handling scheme. So Wiki admins who feel insecure can choose the old method if the want to stay compatible or use a different, probably more secure scheme (security depends, as always, on many factors). This is the plan for OliverGraf/HttpAuthentication.
-- OliverGraf 2004-07-29 06:35:32
Plan
- Priority:
- Assigned to:
- Will be fixed in release:
OliverGraf/HttpAuthentication will also 'fix' this, if I can find the time to finish it -- OliverGraf 2004-07-27 08:51:33