mount.json publishes passwords #2718

Closed
pseeger opened this Issue Apr 4, 2013 · 17 comments

8 participants

@pseeger

Expected behaviour

  • Passwords have to be stored encrypted
  • Files containing passwords have to be restricted to the owner (aka Webserver-Group)

As mount.json contains passwords for remote services the points mentioned above should apply

Actual behaviour

mount.json contains all information in plaintext, including passwords
mount.json has rw-r--r-- permissions on linux and is therefore world readable

Steps to reproduce

  1. activate App "External Storage Support"
  2. create any kind of Dropbox, WebDAV, FTP mount
  3. view OWNCLOUD/data/mount.json

Server configuration

Operating system: debian 6.0.7 Linux 64Bit

Web server: apache 2.2.16

Database: mysql 5.0

PHP version: 5.3.3

ownCloud version: 5.0.3

@LukasReschke
ownCloud member
@pseeger

Passwords are still stored in plain text!

@LukasReschke
ownCloud member

Passwords are still stored in plain text!

How should they be encrypted? - This would add nearly no additional security:

  • Using the user password as key: Not possible without keeping the password in RAM => not good
  • Using the config.php salt as key: Not really more additional security
  • ...?
@pseeger

When encrypting them with either the config.php salt or a user specifiy salt the passwords they would not be readable at first sight any longer.
This would not protect from real "hacking" attacs, but on "normal" shared hosting environments many people are in the same group with the webserver or share even the same user, so that they easily can open the file in any editor. Many of those people altough lack the knowledge of unencrypting the data or even don't want to read it.

Perhaps the configuration screen should be extended to show a clear warning.

@joegyoung

When I ROOT access, I see ALL PASSWORDS! MAHAHAHAW

@cdmiller0

Proper web handling would be to put the passwords encrypted in a browser cookie, storing the decryption key generated for the owncloud session in the server side json file. Really really do not store plain text passwords on the server. Above talked about Root access, how about web server privilege level access...

@PerlStalker

Another option is to store the user supplied 'master password' in a cookie which is used to encrypt the passwords in mount.json. This is similar to what services like LastPass do.

@nunnione

Hi.

I'm on OC 5.0.7, php 5.3.10, apache 2.2.22, mysql 5.5.29, linux ubuntu 12.04

I can confirm that the passwords are still stored in clear text and mount.json is still readable to the world (mode 644).. I agree that tech people could decrypt the passwords when the salt is known, but lots of people still don't have an idea on how to to that.. even a simple md5 would be better than clear text!
I still can't believe this issue has been closed as resolved!

Best regards,
Robi

@LukasReschke
ownCloud member

Another option is to store the user supplied 'master password' in a cookie which is used to encrypt the passwords in mount.json. This is similar to what services like LastPass do.

An admin can still easily decrypt the stored passwords and if an attacker can access arbitrary files on the server you've already lost the game ;-)

I don't see the benefit in making the process more complex here considering this drawbacks, but yeah: If you want to fix it any pull request is welcome.

I can confirm that the passwords are still stored in clear text

Because it's an absolute minor issue, if you use ownCloud in a shared hosting environment you are also most likely violating your providers ToS ;-)

even a simple md5 would be better than clear text!

We can't hash the password in this case, we need it in plaintext to connect to the external storage server.

@cdmiller0

It's pretty simple really.
1) User gets login form, enters uid and password
2) Hash on the password and random or timestamp etc. to generate a session key
3) Use the session key to encrypt the users credentials
4) Store the encrypted credentials in a browser cookie, the session key in the json file.
5) Time out the session key or regenerate it (new cookie and key created) on a regular basis.

See the old MIT cookie eaters writeup for details:
http://cookies.lcs.mit.edu/pubs/webauth.html

@LukasReschke
ownCloud member

It's pretty simple really.

Again: How does this prevent an admin from reading the password?

@karlitschek
ownCloud member

@LukasReschke is right. @cdmiller0 Another problem with your proposal is that users can share files and folders with others. So the FTP, WebDAV, CIFS shares need to be accessible even if the user itself is currently not logged in.

@cdmiller0

Only the session key is stored on the server. Obviously if the server is owned one can subvert the code of the login forms and gather data that way. However a web server access level exploit only gets a bunch of session key hashes rather than a list of user passwords. They would need to get to users browser cookies to use the hashes and gain user passwords.

The sharing of files with others from various sources is another problem.

@LukasReschke
ownCloud member

They would need to get to users browser cookies to use the hashes and gain user passwords.

Persons that reuse passwords that way are probably very good candidates for the next Darwin Award.

They would need to get to users browser cookies to use the hashes and gain user passwords.

If an attacker gain access to any arbitrary file on the system you've most seriously bigger problems than "oh fuck, he got my FTP login" (at least I'd be really angry that someone got access to my private files which is a much bigger bugger than a not reused password)

An attacker who gained access to any file on the system can in most cases (especially on shared hosts) easily gain administrative privileges of the ownCloud instance which mostly leads to arbitrary code executions. => He can also easily get the browser cookie.

Again: We won't implement this on our own in the near future, we have a lot of more important issues than this one and therefore this is not a top priority in the near future. But as I said, any pull request is welcome.

@aclater

Jumping on for this bug. In any federal context, storing unencrypted passwords is a big no-no. DOD, Civilian and IC customers are going to have an issue there. At a minimum it means someone looks for an exploit in httpd or owncloud and starts snarking associated account credentials.

@nunnione

Hello.
Unfortunately these days I have no time to work on this, but I want to say I very much appreciate your hard work on OC. Thank you.
Also I understand the problem that make you store passwords in a file in clear text.. CUPS does the same when authentication has to be done via samba. The difference is that in CUPS that file has mode 640 while mount.json is still 644.. of course when I was testing OC I set myself the mode to 640 to the mount.json files.. As I understand it, the point is that you (OC developers) believe you have corrected the file mode to 640 (as I read up on this thread), but that is not true.. (at least not at the time I was testing OC) each time OC creates (or updates?) a new mount.json file, it has mode 644.. That is the thing that should be fixed immediately as it should take only a few minutes and it already adds some security, vs the zero security it has now.
In any case, if not already fixed, when the project that brought me working on OC will be restarted, I will try a pull, fix and push.
Best regards.

@aclater

Agreed - At a minimum you are still writing the file 644

drwxr-xr-x. 5 apache apache 88 Jul 20 17:25 .
drwxrwx---. 6 apache apache 4096 Jul 20 17:05 ..
drwxr-xr-x. 2 apache apache 6 Jul 20 16:55 cache
drwxr-xr-x. 2 apache apache 16384 Jul 20 17:16 files
drwxr-xr-x. 3 apache apache 28 Jul 20 17:17 files_external
-rw-r--r--. 1 apache apache 423 Jul 20 17:24 mount.json

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment