lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <75108D66D7627A41AD74EF474F4347A64B70A29B@UFEXCH-MBXN02.ad.ufl.edu>
Date: Tue, 5 Aug 2014 14:56:16 +0000
From: "Choulat, Trace" <tchoula@....edu>
To: Frank Stanek <frank@...nk-stanek.de>,
  "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: RE: ownCloud Unencrypted Private Key Exposure - version (6.0.4)
 reported not vulnerable

This came into our security group when we inquired with ownCloud:

It has been officially confirmed by ownCloud security team that the version (6.0.4) running on our servers is not vulnerable to this issue.

"Hi --:
 
I heard back from the Security team within ownCloud and this is not an issue in 6.0.4.

________________________________________

-----Original Message-----
From: Frank Stanek [mailto:frank@...nk-stanek.de] 
Sent: Monday, August 04, 2014 10:01 AM
To: bugtraq@...urityfocus.com
Subject: Re: ownCloud Unencrypted Private Key Exposure

Hi,

thank you for this announcement. I have a (very naive) question about this. As a consequence of this vulnerability an attacker with access to the ownCloud server's file system can compromise the encrypted data stored on the server. There does not seem to be a workaround for that and there will be no fix. Thus, data on an ownCloud server is always accessible to an attacker with access to the file system, regardless of whether ownCloud's encryption feature is enabled or not. Is that correct so far?

It seems to me that one of the encryption feature's main purposes is to prevent an attacker with access to the server's file system from immediate access to the user data. If my understanding above is true, then this purpose is void since the encryption is useless in that scenario. If this is somehow not part of the vendor's threat model, isn't it at least an important restriction? Or did I completely misunderstand something?

Regards
Frank


Am 04.08.2014 08:38, schrieb Senderek Web Security:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Senderek Web Security - Security Advisory
>
> ownCloud Unencrypted Private Key Exposure 
> =========================================
>
> 
> https://senderek.ie/archive/2014/owncloud_unencrypted_private_key_expo
> sure.php
>
> Revision:         1.00
> Last Updated:     3 Aug 2014
>
>
> Summary:
>
>         In consequence of an insufficient threat model, ownCloud is 
> storing all user's
>         private RSA keys in clear text in PHP session files.
>         These unencrypted private keys can be accessed by every web 
> application that
>         has the privilege of the web server user. The affected files 
> exposing cryptographic
>         keys will be stored in the PHP session directory for a number 
> of hours until they
>         are removed.
>
>         This issue was reported to ownCloud via encrypted email on 
> Tue, 11 Mar 2014.
>         I received a reply to this report from the vendor on Wed, 12 
> Mar 2014.
>
>         On Tue, 22 July 2014 the vendor confirmed, that they will not 
> address this problem,
>         because the protection of user encrypted files from remote 
> attackers that have
>         read access to the file system with web server privilege is 
> not - and will not be -
>         part of their threat model. Consequently, the vendor does not 
> consider this to be
>         a vulnerability or security issue.
>
> Severity: High
>
>
> Affected Software Versions:
>
>         All versions of ownCloud since the introduction of the 
> encryption module in
>         version 5.0.7 including version 7.0.0.
>
>
> Impact:
>
>         An attacker, who is able to read the PHP session files by 
> exploiting another web
>         application that is running on the ownCloud server, will be 
> able to gather the
>         unencrypted private key of every ownCloud user.
>         All encrypted files that are stored in a user's home directory 
> can be decrypted
>         with this RSA private key, stored in the PHP session files in 
> plain text.
>         If the user's encrypted files are synced to other devices or 
> shared with
>         other servers - for hosting or backup - an attacker will be 
> able to decrypt all
>         user data that is being intercepted, even if the attacker has 
> no longer access to
>         the server's file system.
>
>
> Fixes:
>
>         In addition to the ownCloud encryption module users are 
> advised to encrypt their
>         sensitive files separately with a standard server-side 
> encryption mechanism like
>         GnuPG using a passphrase, that is not stored on the server 
> except while being used
>         in memory.
>
>         One software solution that extends ownCloud with GnuPG-based 
> server-side encryption
>         can be downloaded here:
>
>                 
> https://senderek.ie/downloads/release/cloud/wee-owncloud.tar
>
>         A detailed installation tutorial is available at:
>
>                 https://senderek.ie/wee/cloud/wee-owncloud.php
>
>         This general web application extension addresses a more 
> comprehensive threat model,
>         that includes the possibility of read-access to web server 
> accessible files on the
>         server. However, it does not protect against malicious actions 
> of server admins,
>         as this cannot be prevented by web applications.
>
>
> Security Advice Policy:
>
>         Complete information about reporting security vulnerabilities 
> can be found here:
>
>                 https://senderek.ie/responsible.disclosure.policy.php
>
>         All information in this security advisory is copyrighted 
> because of the time and
>         effort in analysing and documenting the vulnerability 
> described here.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJT3lsOAAoJECyxzx4lRhdKI30QAKrVrr9nFO3+qdX6a0V6sJoy
> sJUaqTbW9i1EI8IId2Vd1oh5GHJVq6BI9mnO+dTX+Y32B/cct1vfe+7Xfzhl9sGM
> g0Z3vMsnm2MbEW2AjJTC3CCCHsLt3oSwpsevQaQ2BRZbUgSS1VIYCA6zACLJgzHr
> oX/ExHXqdZ8Slol4N+3h9q5+DT2VjVgoBdNXWIeq0nd6iYbAlFS9YLECDAnFPtAl
> OW05Z9m1wkMSxW1NiJPrQRmHn7YY41/SH7lgyIX0+lpi0h2D/LzAvpoVDRQL1j9A
> aTP3B3xjCW8sQShKd4y8xLKQq2023L8ucy+h6anWbJCliIbK5cnXsjBgIJaGwpQw
> 9j5a1huKDsaXXEw5bmGpyiKMEhQ48YPBX0eMnGxOmShnRyvmhWiGPNMey9CgwEdR
> hFZPN+sPC88EjSO+VMheWv4Ts3gDw9g2VmDy30B2Xd3X4yRBSjCLrD0OZbbytNQx
> HIU7CJWnFKNUFZnQY4sZdxjlQf9wrLjGK7dxSTAY+n5qWH56RJVSO/Bj79i+Y+km
> JVF3OO4IIO3BXcWwUfiPAmLvAOwedKNmbm23MdqquYsUnpWQYNiumETz/hpD1z/P
> RCJS1Uc4sjg1mtBxxZqXLjpXm/WjgfOA8uulLdtmcmkqxaGfRdxQkJOsqZPdsje0
> fJ2oNHU/Zu5KkROksoN9
> =Pg9f
> -----END PGP SIGNATURE-----

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ