LukasReschke

Earlier discussion from yesterday: https://news.ycombinator.com/item?id=25869798

> Most rewrites fails because the team rewriting is not the team that did the initial development.

Looking at https://github.com/owncloud/core/graphs/contributors, most of the initial core contributors contribute now to Nextcloud instead.

I am interested in seeing how the rewrite affects end-users. Currently, it seems to be mainly focused on File Sync and I don't see things such as calendar or contacts management. (they totally could appear in the future though)

I'd assume that limiting the scope of components, makes a rewrite also easier. Nextcloud for example has a ton of hooks that allow you to write apps to customize the behaviour (want users to sign the ToS before downloading a share? Should be doable etc.). When you leave these out, implementing new things just got a whole lot easier :) (so I guess I am envious on the fact that they got rid of a ton of backwards compatible APIs to maintain :-) )

Disclaimer: Contributed to ownCloud for a few years, then to Nextcloud.

> Plus as far as I know neither ownCloud nor nextCloud went through a security audit

This is inaccurate. Nextcloud does receive security audits and is in fact also used by quite some security-conscious organizations (to name a few: German Government, Siemens, ...)

There's also a bug bounty program that pays pretty decently considering the company size: https://hackerone.com/nextcloud. (Remote Code Execution = 10k, Auth Bypass = 4k - compare that to rewards that the FAANG pays and you'll see it's not that bad)

> and they are big piles of PHP with a lot more complexity than Seafile

I did a small audit of Seafile years ago and I don't think that argument flies.

For example, they copied https://github.com/django/django/blob/23c612199a8aaef52c3c7e... to https://github.com/haiwen/seahub/blob/b6f8935c0f355cc70145f9... and removed some security-critical checks. They removed the check for the password hasht here. (https://github.com/django/django/blob/23c612199a8aaef52c3c7e...)

Furthermore, the Django secret key was generated as shown at https://github.com/haiwen/seahub/blob/b6f8935c0f355cc70145f9....

``` def random_string(): """ Generate a random string (currently a random number as a string) """ return str(random.randint(0,100000)) ```

That's not really secure and copy-pasting Django core code and then removing security checks ... is shady at best.

Disclaimer: I wrote a significant part of the ownCloud code (https://github.com/owncloud/core/graphs/contributors), then forked it into Nextcloud. After some years I moved to Facebook to do application security there :-)

I've been working on an open-source Identity Access Management solution in the past few months: https://gatekeeper.page/en/

Gatekeeper aims to enable small and medium-sized enterprises to have their own on-premise IAM solution that supports all relevant protocols and standards and is secure by default (by offering automated updates and using memory-safe languages etc.).

Features include, for example, LDAP, OpenID Connect, SCIM, and Gatekeeper as an identity-aware reverse proxy. (with fully managed ACME certificate management)

The tech stack is ASP.NET Core + Postgres on the backend. The frontend is written in C# and uses Blazor to run using Web Assembly. If someone is interested in taking a look, we are working on a hopefully helpful Developer Documentation (https://docs.gatekeeper.page/developer/)

The code on GitHub: https://github.com/GetGatekeeper/Server

> So what do you think is going on in this piece (5 years old), where Alex Stamos characterizes the issue as "trivial and of little value"?

I sadly wasn't there at the time, and Stamos post doesn't refer to it at all. So I can't comment on this.

I guess the truth on this is just known to the researcher, their boss, and Stamos.

> But what I'm describing above are ways for the company to screw the researcher without really being motivated by stinginess. Fairness is not a concern.

That's a fair point, and I can see how representation can cause a significantly different payout decision, especially if there is no technical payout panel with a security background.

Phrasing something as "Reflected XSS" vs. "Account Take-Over via XSS" sounds undoubtedly different. But it is impact-wise probably the same.

The problem is mitigated at Facebook by having engineers in the payout panel that understand the tech stack and security implications. But I think many companies don't have that luxury, and you undoubtedly may end up with inconsistencies.

Thanks for sharing your perspective. Much appreciated!

I'd advise anyone against trying that for a system not owned by them. (e.g., someone's else website)

As soon as you do that, you venture into dangerous territory. Companies are required to investigate claims of breaches seriously. And as soon as something like this is escalated, it may be out of the Information Security team's hands to decide the next steps.

I was part of "big corp" for the past three years and was involved in many bug bounty reports. A reasonable claim like "I think this should be higher because XYZ" gets investigated and, if justified, higher bounties issued.

This blog post seems a bit one-sided and doesn't correlate to the facts that I have heard. I wasn't there at the time being so I don't know the truth. But that blog post seems not quite 100% to be it.

What I have seen, however, in the past years, is that some people omit facts or misrepresent things to get some press. So I am quite a cynic on blog posts like this :-)

How else would you phrase someone telling you "I have this bug and will exploit it if you don't pay me X amount" vs. "I think the impact is bigger because of Y"? For me, the first sounds quite clearly like extortion.

The first case would get you likely in trouble. The second case would routinely cause a further review in any decent program, and if there's any merit to it, you get a higher bounty.

Nobody is forced to participate in any bug bounty program. If people feel the reward is too low, they should not partake.

Disclaimer: I was a Security Engineer on the FB Security Team until last month and was also involved in the Bug Bounty Program :-)

That's not how Facebook treats Bug Bounty Participants. By far, it's one of the better programs in terms of payouts, fairness, and triage time on critical issues.

Just a recent example: a bug bounty hunter reported unexpired CDN links. After internal research, FB figured out to chain this into a Remote Code Execution and paid out 80k USD to the researcher. (https://www.facebook.com/BugBounty/posts/approaching-the-10t...)

That said, I wasn't there in 2015, so I only know the story from some stories. (which portray the story a tad different) - Even if it were true, I haven't seen such treatment in the last three years at FB.

> Companies always say they will investigate the full impact of a vulnerability when you follow the protocol they urge of "as soon as you find something, report it and don't try to escalate". But this is nearly impossible to do even if you're trying in good faith.

Disclaimer: I was a Security Engineer on the FB Security Team until last month and regularly attended the payout meetings :-)

I've seen plenty of bug bounty programs making such claims, but the Facebook program keeps up to this promise the most. Every bug is root caused to the line that caused the issue and assessed on maximal potential impact.

Sometimes that leads to cases where low impact vulnerabilities got paid out tens of thousands of dollars. The big bounty often came as a big surprise to the reporter :-)

Just a recent example: a bug bounty hunter reported unexpired CDN links. After internal research, FB figured out to chain this into a Remote Code Execution and paid out 80k USD (https://www.facebook.com/BugBounty/posts/approaching-the-10t...)

Facebook has big pockets. As a bug bounty hunter, I'd not worry about being screwed by them. It's by far one of the best paying bounty programs.

There are many reasons to criticize Facebook or Instagram. But the handling of its application security should not be in the top 10 :-)

Just as a remark, we run a bug bounty program at https://hackerone.com/nextcloud offering up to $5,000 for Remote Code Executions.

If someone here feels challenged: We look forward to your reports. :)

Fair enough, there is some kind of marketing-ishy statement in that. I give you that :-)

But considering the security features that we include such as Same-Site Cookies, CSP using Nonces, etc. I don't think the statement is totally wrong – many products are sadly missing these. We also have a bug bounty program where we offer up to $5000 for qualifying vulnerabilities: https://hackerone.com/nextcloud

We don't offer any PPA for the server repository ourselves. Mainly because we didn't had many good experience in the past with repositories.

So what we're focusing on is providing an easy and reliable updater (just like Wordpress does) instead of distribution packages.

Migrating is described at https://nextcloud.com/migration/ and we also have a help topic in our forums: https://help.nextcloud.com/t/migrating-from-owncloud-to-next...

Probably the easiest way in your case is to backup the config folder and your data folder, then uninstall the ownCloud packages and install PHP/Apache yourself. Then simply put our newest release into the web root and copy your old config there as well. If you need more help on that I'm sure we have many people in our forums willing to help :)

> Is it the locations services workaround thing?

That's correct.

I highly doubt that the planned features are related. Seems just to be a try to make the press release look less worse...

Disclaimer: I quit ownCloud to work now at Nextcloud.

Happy to answer this. First of all: Makes using a specific programming language a software much less secure? Probably not. You can do mistakes in every programming language. But since a lot of software is written in PHP and there are also many unexperienced PHP developers this reflects kinda bad on the language.

There is often the perceiption that ownCloud would be insecure because we have so many advisories. But these are just there because we proactively look for security vulnerabilities and patch them. (see also https://statuscode.ch/2015/09/ownCloud-security-development-...)

Oh! And we also run a bug bounty program for ownCloud and Nextcloud will have one with probably even higher rewards soon! - HackerOne did even do a case study with us so it can't be too bad ;) (https://hackerone.com/resources)

Good questions! Note, that I'm affilated with Nextcloud so obviously a bit biased.

Only because a project is very transparent about security vulnerabilities does not necessarily mean it's inherently insecure. In fact, at ownCloud we found all critical vulnerabilities ourself and also run a successful bug bounty program. (for Nextcloud we are also considering one)

Check https://news.ycombinator.com/item?id=11821854 for more insights.

Not in the way that you require it. But you can always file an issue or enhancement request :-)

That said, we'll likely have Webcal support (https://github.com/owncloud/calendar/pull/443), that way you can at least in ownCloud view your Google calendars. (it's not synced though)

Actually, I should add that to my CV "poached developer" ;-)

- Lukas (Nextcloud'er - see also http://www.zdnet.com/article/owncloud-founder-forks-popular-...)

The impact is a different one though. In that scenario pointed by Hanno somebody needs to have access to the storage which already requires some kind of previous gained access. What could be done by an attacker then is to infect EXE files or so.

In the case of Seafile one could simply change passwords of any user etc.

But yes, crypto is hard and I agree that the way we did it at ownCloud is far away from the best way. :-)

I'd like to point you to https://statuscode.ch/2015/09/ownCloud-security-development-... and make you aware of https://seacloud.cc/group/3/wiki/security-records.md and you should probably consider who reported the last critical vulnerability.

Only because a project is serious about actually publishing vulnerability data does not make it necessarily more insecure (or secure).

Fantastic idea! We have started a public discussion about this at https://help.nextcloud.com/t/should-we-adopt-c4/113/1. You're more than welcome to join it as well :-)

We can't talk about this in detail yet but http://blog.jospoortvliet.com/2016/06/nextcloud-is-replacing... has some more information on what's upcoming. If you can understand German a very good in-depth research article is at http://www.golem.de/news/community-fork-und-neues-unternehme...

Disclaimer: I am one of those folks that left ownCloud for Nextcloud.

The archive.org links were used at the creation of the blog post. (which was not necessarily the release date ;-) - needed to find some time to write it)

So Wordpress is an interesting example. Because the CVE assignment date has nothing to do with the release date of the patches. Wordpress doesn't request the CVE on their own.

So we're still at a 4-5 day delay (https://wordpress.org/news/2016/02/wordpress-4-4-2-security-...) for security fixes for a web-facing software. This is still far worse than just enabling automatic updates in Wordpress. I have not much problems if that would be a locally exploitable vuln, but web software usually is exploitable via web.

When it comes to web software I believe it's unacceptable to add any additional delay. (sure those bugs were not that severe, but as other examples in the blog show the problem with delayed or never updated packages is inherent)

> The one column at the link with that has "medium" and "low" values is "complexity" which means CVSS's "access complexity". So it means there are many vulnerabilities that are easy to exploit.

I'm aware of that, I have a ton of CVE entries filed myself. I was referring to the score (https://nvd.nist.gov/cvss.cfm), anything below 7.0 is not deemed "high".

> Also CVE-2015-2213 is marked as NOT requiring authentication (along with about 7 other straight remote code execution CVEs).

CVE entries are often terribly done wrong if they are not provided by the vendor (which is what ownCloud does).

See https://core.trac.wordpress.org/changeset/33555 for the patch for CVE-2015-2213. As you can see this is within the function "wp_untrash_post_comments" which is called by "wp_untrash_post" which only accepts user-input from the Wordpress admin panel.

So, if we ignore all lower and medium severity ones we're basically only left with CVE-2015-2213 which requires authentication. Also XSS is barely something one can blame PHP for. That's pretty low number.

For the record: ownCloud protects you against XSS using Content-Security-Policy.

> that doesn't really scale

There are deployments out there with a ton of users. For example Sciebo: https://owncloud.com/customer/sciebo/ / http://sciebo.de/projekt/index.html

We also have some nice graphs about the speed of PHP 7: https://owncloud.org/blog/php-7-is-here-and-owncloud-is-read...

> logging changes

"Please look at this commit so you know how you can hack us", sounds certainly like a much better idea ;-)

> Security history at Wordpress

When was there a single very grave vulnerability within the core of Wordpress? Mostly plugins are the root of all evil there. (besides the nasty XSS one in Jetpack, which was caused by a static HTML file)

> - From what I've heard, security fixes are provided to enterprise customers first, so if you're lucky your adversary is one of them and knows about vulnerabilities way ahead of you.

This is wrong. Until now there has not been a single moment where customers did receive patches in advance. The only difference being is that they see the advisories earlier, but at this moment patches are already available for all.

> maximum bug bounty is $500

For the record we receiced until now 340 reports by over 150 individuals and until now only 1 vulnerability within the server has been pointed out. (Full Path Disclosure of the ownCloud root folder such as "/var/www")

> If you need project management stuff and care about privacy, maybe look at https://protonet.info/ or something along those lines

What makes you thinl they are more secure? Note that most of the vulnerabilities within ownCloud are found internally: https://statuscode.ch/2015/09/ownCloud-security-development-...

We could easily never have published any information as do a lot of other projects and companies.

That was actually the part where they partially mitigated the vulnerability with. So before it was more insecure. The green one is the "fix" :)

The constant time comparison is pretty irrelevant here. Check https://github.com/haiwen/seahub/commit/7cdb70368aa7acbf0546..., basically a valid password reset token in default Django requires an attacker to know:

- Primary Key of the user (User ID)

- Hashed version of the user password

- Timestamp of the last login (1 second accuracy)

- Number of days since 2001-1-1 converted to base 36

- The configured SECRET_KEY

Basically except the configured SECRET_KEY and the hashed version of the password everything is known to an attacker. And even if an attacker knows the SECRET_KEY they would not be able to generate a valid token as the old password hash is required.

However, Seafile has removed the hashed password out of their version of "tokens.py". This means that if somebody knows the SECRET_KEY they could create valid password reset tokens. That the initial SECRET_KEY was basically generated by `str(random.randint(0,100000))` did make this all much more worse… (https://github.com/haiwen/seahub/blob/b6f8935c0f355cc70145f9...)

Bad thing about this is that this basically makes a lot of old Seafile instances insecure unless they get a new SECRET_KEY. They did somewhat tell users to regenerate it within a forum post and some wiki page (https://seacloud.cc/group/3/wiki/whats-new-in-the-next-versi...) but that's not really a good way to spread awareness…