Synology PhotoStation password vulnerability

On Synology NAS, synophoto_dsm_user executable, part of PhotoStation package, was leaking NAS user password on the command line.

Using a simple shell loop to run "ps ax | grep synophoto_dsm_user", it was possible to get user and password credentials for user on the NAS who had PhotoStation enabled with their DSM credentials.

Fortunately, by default, shell access on the NAS is not available (by ssh or telnet), it has to be enabled by the admin.

Still, it is a bad practise to pass credentials to process using command line, which can be intercepted.

PhotoStation version 6.7.1-3419 or earlier is vulnerable. I've contacted Synology and they should release a security fix really shortly, as well as a CVE for it.

Update (June 13, 2017): Synology has released a CVE and the vulnerability is fixed in PhotoStation 6.7.2-3429 or later. Remember to update this package on your NAS !

Hackweek projet: Let's Encrypt DNS-01 validation for acme.sh with Gandi LiveDNS

Last week was SUSE Hackweek and one of my projects was to get Let's Encrypt configured and working on my NAS.

Let's Encrypt is a project aimed at providing SSL certificates for free, in an automated way.

I wanted to get a SSL certificate for my Synology NAS. Synology now supports natively Let's Encrypt but only if the NAS accepts incoming HTTP / HTTPS connections (which is not always what you want).

Fortunately, the protocol used by Let's Encrypt to validate a hostname (and generate a certificate), Automatic Certificate Management Environment (ACME) has a alternative validation path, DNS-01, based on DNS.

DNS-01 requires access to your DNS server, so you can add a validation token used by Let's Encrypt server, to ensure you own the domain name you are requesting a certificate for.

There is a lot of ACME implementations, but very few supports DNS-01 validation with my DNS provider (gandi.net).

I ended-up using acme.sh, fully written in shell script and tried to plug Gandi DNS support in it.

After some tests, I discovered Gandi current DNS service is not allowing fast changing DNS zone informations (which is somehow a requirement for DNS-01 validation). Fortunately, Gandi is now providing a new LiveDNS server, available in beta, with a RESTful HTTP API.

I was able to get it working quite rapidly with curl, and once the prototype was working, I've cleaned everything and created a pull request for integrating the support in acme.sh.

Now, my NAS has its own Let's Encrypt certificate and will update it every 90 days automatically. Getting and installing a certificate for another server (running openSUSE Leap) only took me 5 minutes.

This was a pretty productive hackweek !

We are hiring !

Did you knew SUSE is hiring ?

I've just looked at our counter today (October 7, 2015) and we have 68 opened positions.

Moreover, we have two positions which might interest people who are reading this blog through Planet GNOME(-FR):

• Xorg is your thing :  Linux Graphics Developer 
• you are more a GNOME desktop guy : SUSE Linux Desktop Engineer

Interested ? Apply !

Hackweek 12: improving GNOME password management, day 1

This week is Hackweek 12 at SUSE

My hackweek project is improving GNOME password management, by investigating password manager integration in GNOME.

Currently, I'm using LastPass which is a cloud-based password management system.

It has a lot of very nice features, such as:

• 2 factor authentication
• Firefox and Chrome integration
• Linux support
• JS web client with no install required, when logging from a unknown system (I never needed it myself)
• Android integration (including automatic password selection for applications)
• cli open-source client (lastpass-cli), allowing to extract account specific information
• encrypted data (nothing is stored unencrypted server side)
• strong-password generator
• support encrypted notes (not only password)
• server based (clients sync) with offline operations supported
   

However, it also has several drawbacks:

• closed-source
• subscription based (required for Android support)
• can't be hosted on my own server
• doesn't integrate at all with GNOME desktop

I don't want to reinvent the wheel (unless it is really needed), which is why I spend my first day at searching the various password managers available on Linux and compare their features (and test them a bit).

So far, I found the following programs:

• KeePass (GPL):
• version 1.x written in Java, still supported, not actively developed
• version 2.x written in C# (Windows oriented), works with Mono under Linux
• UI feels really Windows-like
• DB format change between v1 and v2
• supports encrypted notes
• password generator
• supports plugins ( a lot are available)
• support OTP (keeotp plugin, provide 2factor auth through TOTP, HTOP built-in)
• shared db editing
• support yubikey (static or hotp)
• 2 Firefox extension available(keefox, passifox)
• 3 android applications available (one application KeePass2Android supports alternative keyboard, KeepShare supports alternative keyboard + a11y framework to fill android application forms, like LastPass)
• Chrome extension available
• JS application available
• CLI available
• big ecosystem of plugins and other applications able to process file format


• KeePassX (GPL)
• Qt4 "port" of KeePass (feels more a Linux application than KeePass)
• alpha version for DB v2 support
• missing support for OTP
• missing support for keypasshttp (required by firefox extensions to discuss with main application), support is being done in a separate branch by a contributor, not merged
• release are very scarse (latest release is April 2014, despite commits on git, very few people are contributing, according to git)
• libsecret dbus support is being started by a contributor


• Mitro:
• company developped it was bought by Twitter last year, project released under GPL, no development since January.


• Password Safe (Artistic license):
• initially written by Bruce Schneier 
• beta version available on Linux
• written in wxWidgets 3.0 / C++
• yubikey supported
• android application available, no keyboard nor a11y framework usage, only use copy/paste (but allows sync of db with owncloud and other cloud platforms)
• CLI available
• 3 different DB formats (pre-2.0, 2.0, 3.0)
• password history
• no firefox extension and the "auto-type" built-in function is all but intuitive
• support merge of various db


• Encrypt:
• same 0 knowledge framework as SpiderOak
• node-js based


• Pass:
• simple script on top of text files / gnupg and optionnally git (used for history and can also be used to manage hosting the file)
• not easy learning curve (CLI mostly), need gnupg to be setup before usage
• one file per password entry, should make 
• very basic Qt GUI available
• basic FF extension available
• basic android application available

Unfortunately, none of those applications properly integrates (yet) in GNOME (master password prompt, locking keyring when desktop is locked, etc..).

I've also looked at gnome-keyring integration with the various browsers:

• Several extensions already exist, one is fully written in Javascript and is working nicely (port to libsecret is being investigated)
• Chrome has already gnome-keyring and libsecret integration
• Epiphany already works nicely with gnome-keyring
• No password generator is available in Firefox / Chrome / Epiphany (nor GTK+ on a more generic basis)

Unfortunately, each browser is storing metadata in gnome-keyring for password entries in a slightly different format (fields name), causing password entries duplication and not allowing sharing keyring data across browsers.

Conclusions for this first day of hackweek:

• Keepass file format seems to be the format of choice for password manager (a lot of applications written around it)
• Password manager which would fit my requirement is KeePass but is written in Mono (I don't want Mono stack to come back on my desktops) and too Windows oriented, so not an option.
• KeePassX seems to be the way to go (even if it is Qt based) but it lacks a lot of features and I'm not sure if it worth spending effort in adding those missing features there.
• Pass is extremely simple (which would make hacking around it pretty straightforward) but requires a lot of work around it (android, GUI) to make it nicely integrated in GNOME.

I haven't yet made up my mind which solution is the best, but I'll probably spend the following days hacking around KeePassX (or a new program to wrap KP db into libsecret) and Firefox gnome-keyring integration.

Comments welcome, of course.

Coffee: my personal history

As always, long time no blog. These days, I don't have enough energy (nor content, IMO) to write blog posts, mostly on Free Software, which would relevant for other people.

Why, would you ask ? Mostly because with my not-so-new-anymore position at SUSE (Enterprise Desktop Release Manager), I'm mostly working behind the scene (discovery the joy of OBS to create ISO images and lot of crazy similar stuff) which might not be that sexy to describe but still need to be done ;)

So, instead of closing this blog for new posts, I'm trying something new to me: writing about things which aren't Free Software but might still interest people:

My new thing these days (asks my wife ;) is coffee.

I've always been fond of coffee (and tea, they aren't mutually exclusive, fortunately), probably because when I was a child, my parents loved good coffee and I was happy to be the one taking care of both electric grinder and Expresso machine we had. And I remember how difficult it was to find good coffee, even more when you were living in a very rural area of France and when the only online services were accessible with a Minitel and were definitively not selling coffee ;)

Fast forward ten years, when I started to work in Paris, I was still into coffee and I discovered something which wasn't known at all at that time (it was in 2002 and George was still working in ER ;): Nespresso. This was a great thing (even if I was a bit worried by the closed system around it) because I was able to get a expresso at home which was always good (IMO at that time) and which also allowed me to switch between various coffees without any hassle (try that with several ground opened coffee bags when you are single and only drink one expresso per day ;)

And then started my love story with Nespresso, which has not ended (yet), with its ups (being part of a customer panel once, including UI designers, very interesting) and downs. I often skipped coffee in cafés and restaurants because I knew it wouldn't be good!

Fast forward again 10 years. We are in 2014. Caps war is on for few years in France, since some of Nespresso patents are in public domain and competitors are trying to get a share of this huge market (France is apparently one of the biggest markets for Nespresso). I've tried various alternative caps and most of them are just cheaper and not as good as the original caps, except one or two caps done by some "small" roasters (Terre de Café for instance). I ended up sticky with the original, until something better "happens".

And it has happened these days, somehow unexpectedly: for a few years, I was reading about strange devices (Aeropress being cited often) and tasty filter coffee (which, for me, as always been synonym of bad coffee) and I also heared some radio shows on coffee which make me think: let's try.
I ordered an Aeropress and tried it (with some fair trade coffee from my supermarket since I don't have any grinded coffee at home and opening caps wasn't really a good idea). Result: not bad, compared to the consistency of Nespresso but not that great. I knew I wasn't using great coffee.

So, I decided to expand a bit more and searched for good coffee roasters in Paris. And one of those which was often mentionned is Coutume Café (their main website is not great ATM, better to look at their FB account), who also have a coffee shop. I went there, tried one of their coffee and I was astonished. This was the best ever coffee I ever tasted, with flavor like red fruits and chocolate. This was incredible and it wasn't even an expresso (which has been my reference for coffee) but filter coffee which looks like dishwater ;)

So, I'm now with this exact same coffee at home, waiting for delivery of a freshly ordered manual grinder to try to duplicate this coffee experience, because I try other coffee and other Paris roasters.

Let's see if I succeed :)

Secure Boot on openSUSE talk at FOSDEM cancelled

Hi folks,

for those of you who are attending FOSDEM this year and were planning to attend my talk about Secure Boot on openSUSE on Sunday, I'm sorry to announce I had to cancel my travel to Brussels (and my talk) for family reasons.

Since my slides were already written, I thought I could still share them with you Feel free to ask questions / comments on this blog post.

Secure Boot on openSUSE, a battleplan

At openSUSE Conference in Prague last month, we had a BoF about Secure Boot, where I describe the various tasks which are needed to ensure openSUSE can support Secure Boot. They are listed on my slides, but I thought it would be more useful to describe them here.

Before we begin, if you need some refresh about Secure Boot, I suggest the blog posts from Olaf Kirch and Vojtěch Pavlík on SUSE Blog (overview, details and approach to it) and of course, all the war stories of Matthew Garrett on this topic ;)

To have openSUSE installable (and runnable) on a Secure Boot enabled system, without any additional user intervention (like adding your own key in UEFI firmware or disabling Secure Boot), we need to do the following to the distribution :

• to the kernel (many of those features are in 3.7 or in upcoming 3.8):

• convert the kernel as a EFI executable (it will be used to store kernel signature)
• UEFI variable access
• UEFI clock support (nice to have)
• UEFI getvideomode (if we want flicker-free boot)
• UEFI reboot (we already have 4 other way to reboot a system, why not add yet another one ;)
• KMS drivers (for old chipsets like Matrox, AST).
• sign main kernel
• sign all in-tree kernel modules
• generate a private/public key pair to be used out of tree modules
• add Secure Boot support in KExec / KDump and Xen (optional)
• disable hibernation in Secure Boot mode (or have a secure way to save / restore suspended system)
• add signature check in kernel
• to bootloader:
• package shim loader
• modify grub2 so it uses shim loader to check kernel signature at boot
• to Build Service:
• to be able to build external kernel modules (think KMP) using the private/public key generated at kernel build
• but do not allow this key to be used for any random KMP build (otherwise, you defeat the purpose of signing the module)
• to userspace tools:
• package xf86-video-modesettings, for graphics chipset with non-accelerated KMS drivers
• add support for signature check in modutils / kmod
• package tools to sign kernel / modules
• package tools to manage UEFI variables and keys
• to the installer / DVD image
• maybe display some warnings about installing a system in Secure Boot mode (not 100% sure we should do this)
• maybe signing the initial installer (and make sure it can't load non-signed modules)
• ensure the DVD image has shim + grub2 as bootloader when booting on UEFI system
• and we also need to do the signing part:
• if we want Secure Boot to be transparent to users, we need our shim loader to be signed by the authority handling UEFI key, ie Microsoft
• this requires some legal paperwork (getting MS developer account, getting a Authenticode certificate, etc..), some obligation (making sure you can't circumvent Secure Boot once Linux is booted) and once it is done, sending shim loader to be signed by MS and package the result.

As you can see, this is a lot of work but I think we will be able to have everything in order for next openSUSE release !