They mention that Windows will still execute the DOS stub when it can't find a PE header. Is this still true in 64-bit Windows? I would think that the DOS stub would be 16-bit code, which is not supported anymore in 64-bit Windows.
Pwncloud – Bad crypto in the Owncloud encryption module
31–40 of 46 posts
Re: Pwncloud – Bad crypto in the Owncloud encryption module
#32Earlier quoted context omitted.
If you want to go along with owncloud (and I don't know a proper alternative) there's not much you can do then upgrading to Owncloud 9 and hope that the fix was done right. In the meantime you could encourage your users to use their own client-side encryption while giving up the idea of an easy setup.
Im already running the newest version. I hope they approve on it in future versions. Client side crypto would be cool.
Someone is working on that. It's called ownCrypt: https://github.com/owncloud/client/issues/4327 and
https://conference.owncloud.org/conference/oCC2015/proposal/...
Re: Pwncloud – Bad crypto in the Owncloud encryption module
#33Earlier quoted context omitted.
There is seafile ( https://www.seafile.com/en/home/ ) which provides client side encryption. Easy to install and to upgrade (except a small glitch in the last upgrade). For the community version, the source code is here : https://github.com/haiwen/seafile (see others haiwen projects). The Android client could be improved, but it does the job.
This issue in Seafile was lovely: https://github.com/haiwen/ccnet/issues/35 /* truly random sequece read from /dev/urandom. */ static unsigned char salt[8] = { 0xdb, 0x91, 0x45, 0xc3, 0x06, 0xc7, 0xcc, 0x26 }; https://github.com/haiwen/seafile/issues/587 Enough to understand if people writing this software know how to apply cryptography. This was 2 years ago, so I hope they improved.
What seems truly scary is how little the developer seemed to care about those security bugs (following related issues, you also find an exploit, SQL injection and so on) and being dismissive of the guy who found them.
Re: Pwncloud – Bad crypto in the Owncloud encryption module
#34Earlier quoted context omitted.
This issue in Seafile was lovely: https://github.com/haiwen/ccnet/issues/35 /* truly random sequece read from /dev/urandom. */ static unsigned char salt[8] = { 0xdb, 0x91, 0x45, 0xc3, 0x06, 0xc7, 0xcc, 0x26 }; https://github.com/haiwen/seafile/issues/587 Enough to understand if people writing this software know how to apply cryptography. This was 2 years ago, so I hope they improved.
https://xkcd.com/221/
Thanks for saving me from having to look that one up.
Incredible that people will actually do this in production code. I don't understand a lot about cryptography, and even I know this not a good idea.
Re: Pwncloud – Bad crypto in the Owncloud encryption module
#35So what is the implication of this? The major reason to use the crypto module is that my users can add their google drives to owncloud and its encrypted on there. Whats the recommended course of action?
As always it is not black and white. It depends on your threat model. If you just want to make sure that Google can't read your content (which was the original intention of ownClouds server-side encryption) then everything is fine. Also with older versions. But if you fear that Google might not only read your data but manipulate it then I would suggest to upgrade to ownCloud >= 9.0. But keep in mind that the files only get encrypted the new way the first time you touch them. ownCloud will not migrate all your existing files to the new encryption which includes the signature.
Re: Pwncloud – Bad crypto in the Owncloud encryption module
#36Earlier quoted context omitted.
If you want to go along with owncloud (and I don't know a proper alternative) there's not much you can do then upgrading to Owncloud 9 and hope that the fix was done right. In the meantime you could encourage your users to use their own client-side encryption while giving up the idea of an easy setup.
Im already running the newest version. I hope they approve on it in future versions. Client side crypto would be cool.
There are some community activities to implement client-side encryption. But as far as I know there doesn't exists any running code at the moment. So don't expect to much in the next few months.
In general I want to note that client side encryption is great. I also like and use it in many areas. But you also have to keep in mind that it will make most of the web interface and it features useless. Personally I run my ownCloud in my basement. The connection to the server is secured by https and the hard disc is encrypted with LUKS. In this case it doesn't make sense to me to add additionally server-side or client-side encryption.
The first step is always to check your threat model, your setup and your requirements to see if you really need server-/client-side encryption.
Re: Pwncloud – Bad crypto in the Owncloud encryption module
#37Earlier quoted context omitted.
This issue in Seafile was lovely: https://github.com/haiwen/ccnet/issues/35 /* truly random sequece read from /dev/urandom. */ static unsigned char salt[8] = { 0xdb, 0x91, 0x45, 0xc3, 0x06, 0xc7, 0xcc, 0x26 }; https://github.com/haiwen/seafile/issues/587 Enough to understand if people writing this software know how to apply cryptography. This was 2 years ago, so I hope they improved.
What seems truly scary is how little the developer seemed to care about those security bugs (following related issues, you also find an exploit, SQL injection and so on) and being dismissive of the guy who found them.
https://github.com/haiwen/seafile/issues/587#issuecomment-40...
> We don't roll our own crypto.
> There are two parts of the code base in which "we roll our own crypto": the transfer protocl and encrypted library.
That's just ridiculous.
Re: Pwncloud – Bad crypto in the Owncloud encryption module
#38Earlier quoted context omitted.
There is seafile ( https://www.seafile.com/en/home/ ) which provides client side encryption. Easy to install and to upgrade (except a small glitch in the last upgrade). For the community version, the source code is here : https://github.com/haiwen/seafile (see others haiwen projects). The Android client could be improved, but it does the job.
This issue in Seafile was lovely: https://github.com/haiwen/ccnet/issues/35 /* truly random sequece read from /dev/urandom. */ static unsigned char salt[8] = { 0xdb, 0x91, 0x45, 0xc3, 0x06, 0xc7, 0xcc, 0x26 }; https://github.com/haiwen/seafile/issues/587 Enough to understand if people writing this software know how to apply cryptography. This was 2 years ago, so I hope they improved.
I would strongly recommend against using Seafile.
Seafile stores a lot of metadata in clear text (including filenames): https://github.com/haiwen/seafile/issues/350
The developers know about it, the issue is 3 years old, this huge limitation is still not reflected on their documentation.
An attacker who obtains a copy of the encrypted library without the key can:
- read the complete list of directory and file names.
- know the size of every file
- know which files share some of the same information
- see the history of who changed each file, when, and what byte ranges were alteredRe: Pwncloud – Bad crypto in the Owncloud encryption module
#39Earlier quoted context omitted.
This issue in Seafile was lovely: https://github.com/haiwen/ccnet/issues/35 /* truly random sequece read from /dev/urandom. */ static unsigned char salt[8] = { 0xdb, 0x91, 0x45, 0xc3, 0x06, 0xc7, 0xcc, 0x26 }; https://github.com/haiwen/seafile/issues/587 Enough to understand if people writing this software know how to apply cryptography. This was 2 years ago, so I hope they improved.
https://xkcd.com/221/
Also, though less exactly relevant: http://dilbert.com/strip/2001-10-25
Re: Pwncloud – Bad crypto in the Owncloud encryption module
#40> "First it is important to understand what this encryption module is actually supposed to do and understand the threat scenario. The encryption provides no security against a malicious server operator, because the encryption happens on the server. The only scenario where this encryption helps is if one has a trusted server that is using an untrusted storage space." While it's a good finding that even in this specifi…
Well, you can use client side encryption with Owncloud as well. What makes dropbox special?
> "or any other cloud storage provider"
I just wanted to point out that as long as you're not in full control of the server hosting Owncloud (and not connect your Owncloud to third party cloud spaces) you've to care about your own client-side crypto like on any other cloud provider (self hosted or not). So there's nothing special about Dropbox - but also not so much special in security terms about Owncloud.
Anyway I would still recommend using Owncloud over any other cloud storage provider if you're able to host it or know someone hosting it. But you should consider the security implications if you care.