Automatic Script Updater

[Mark Kretschmann]

On Thu, Oct 8, 2009 at 2:51 AM, Jakob Kummerow
<jakob.kummerow at googlemail.com> wrote:
> it's time for me to publish my work on an automatic updater for
> Amarok's scripts, and to invite all of you to comment on it and
> discuss it thoroughly so that it can be included in 2.2.1. I'll try to
> make this as short as possible without omitting important aspects, and
> I'll use titles for the sections so that you can read this email
> selectively if you want to.
>
> What is this all about?
>
> In the past months, we have seen that sometimes it would be very
> useful if we could deploy an update for a script as quickly as
> possible, especially without releasing a whole new Amarok version. The
> lyricwiki script is the prevalent example for this; but the same
> situation could occur for any script that makes use of external web
> sites, since the web generally is a moving target.
> The idea is therefore to implement an updating system for the scripts
> (which is possible because they don't need to be compiled but can
> simply be replaced). But since scripts are allowed to do almost
> anything permission-wise, it must be made sure that the updating
> mechanism cannot be abused to put malicious scripts onto users'
> computers - not even if the Bad Guy who's attempting to do this has
> gained access to the update server. In consequence, all updates have
> to be protected by a digital signature.
>
> Built-in vs. 3rd-party scripts.
>
> The updater doesn't care where a script originally came from. It scans
> all installed scripts and checks for each of them whether an update is
> available. This check is implemented to be as lightweight as possible.
> Updates are always installed to the user's directory
> (~/.kde4/share/apps/amarok/scripts), because that's where Amarok can
> write to without requiring root access.
> The consensus on IRC so far seems to be that we initially only use the
> system for updates for Amarok's built-in scripts, but it is always
> possible to deploy updates for 3rd-party scripts as well, should that
> be desired. As I said, the updater doesn't care.
>
> Security.
>
> An update is only applied if it has a valid digital signature. To
> create such a signature, one needs to have the private key. The
> private key is additionally protected by a password. The signature
> algorithm used is RSA with a key length of 2048 bit.
> This system is what is considered secure by the current state of
> technology and science and is used widely wherever the integrity of
> documents/files/whatever needs to be protected. You can ask security
> experts for confirmation if you like; but as a CompSci student I'm
> very confident that this statement is correct.
> There are two cases that digital signing can't and won't protect against:
> (1) If a cracker has already gained control over the update server and
> placed a malicious update there, and then kidnaps and tortures one of
> the developers who have the private key and know its password, then
> depending on whether that poor dev manages to ingest his suicide pill
> quickly enough, the cracker might be able to generate a valid
> signature for his manipulated update.
> (2) If an Amarok client is manipulated so that it no longer checks for
> valid signatures, it will install any update it finds on the server.
> But if a cracker already has that level of control over a user's
> computer (the Amarok binaries are read-only for ordinary users after
> all), be it because he knows the root password or by means of a virus
> that manipulates running apps in memory, he could most probably just
> install any malicious script he wants to all by himself, without ever
> messing with our automatic updating system.
>
> Necessary changes to Amarok.
>
> Due to the signing stuff, QCA2 becomes a build time and run time dependency.
> Scripts aren't loaded immediately any more; instead, for each script a
> new thread is spawned that checks for updates and installs them if
> applicable; finally the (possibly updated) scripts are loaded.
> In utilities/updatesigner/, there's a nice little command-line utility
> that can create signatures (if it can find the private key in the
> current directory, and if the correct password is entered), verify
> existing signatures, and create new key pairs if that's ever
> necessary.
>
> Workflow for releasing an update.
>
> Whoever creates the update sends it to a developer who has access to
> the private key. The developer (ideally) reviews the update, then
> packs it into an archive called "main.tar.bz2", creates a signature
> (in a file called "signature"), and a file called "version" that
> contains the version of the updated script. These three files are then
> put to <base-url>/<scriptname>/ (for instance
> "amarok.kde.org/update/lyrics_lyricwiki/"). Done. Now, whenever an
> Amarok client starts up, it will see the update and apply it.
>
> "Wait, I don't want this. I hate automatic updates!"
>
> Well, good for you, then, that there's a checkbox in the Script
> Manager dialog that allows you to turn automatic updates off. But
> don't complain about bugs in the lyrics script then!
>
> Having a look at the code.
>
> You can find my code either at
> http://gitorious.org/~jmrk/amarok/jmrk-clone/commits/scriptupdater or
> in the patch that is attached to this mail.
> I am also attaching the private key that matches the public key that
> is currently integrated into Amarok (i.e. in the patch). Note that I
> would never do this with the private key that is supposed to be used
> in the real world; this is just for you to play around with keys and
> signatures. The password for this private key is "amarok" (without the
> quotes). Very secure :-)
> To fetch updates, for now I defined the URL of my personal webspace at
> my university. Again, this is just for your testing pleasure. I
> provide a dummy update for the lyrics script there that should get
> installed (you can check it in the Script Manager, the dummy update
> has version 0.3; or take a look at the file main.js, which contains a
> big fat notice in the comment right at the beginning). I also provide
> an update for the librivox service script that will not get installed
> because its signature is invalid.
> Feel free to play around with everything. The public key as well as
> the update URL are defined in src/dialogs/ScriptUpdater.h (the key
> *must have* those line breaks \n !). If you compile and install Amarok
> with my patch, you'll have a binary called amarok-update-signer in
> your PATH. Start it without parameters to get info about its usage.
>
> Some more details about the implementation.
>
> The versions of the currently installed scripts are read from their
> respective script.spec files. Version strings are allowed to contain
> dots and numbers, nothing else (i.e. "1", "1.1", "1.1.1.1.1.1.1.0" are
> ok; "1.0b1", "1.0-1" are not). What's between two dots is interpreted
> as an integer, i.e. "1.2" == "1.02" < "1.20" < "1.20.1" < "1.21".
> Sections of the version string that aren't parsable like this are
> interpreted as "0".
> There are quite a few status messages that are printed to debug(), so
> if you want to see what the updater does, be sure to start Amarok in
> --debug mode and watch the output.
>
> What remains to be done.
>
> - Definitely: Define another URL for the updates. I propose
> "http://amarok.kde.org/updates/" or something similar.
> - Definitely: Create a new key pair, put the public key into
> ScriptUpdater.h and store the private key carefully. Me, I don't need
> to possess that key (or know its password), but if you want me to do
> the job of signing updates, I can do it. Of course I'm not quite as
> trustworthy as the long-time devs...
> - Maybe: Change something else, depending on your feedback :-)
>
> Apart from these changes, the code could be merged into master right
> now, as far as I'm concerned. But I'm also prepared to change/improve
> some details before that, just tell me where you think that
> improvements are necessary.
>
> That's it for now, I hope that I haven't forgotten anything (and that
> I haven't bored you). Have fun with the updater, and I look forward to
> hearing your thoughts.

For your information, I have been discussing this feature for a long
time with Jakob, so I was able to form an opinion and also bounced
some ideas to him, etc. We've also discussed the security aspect at
length, which I find is absolutely crucial for this kind of feature.

I've become convinced that this feature would be very good to have, as
the current situation with our bundled scripts has turned into a
catastrophe. Amarok 2.2.0 currently wants to sell you Ringtones for
your Mobile Phone in the lyrics applet. What if someone hacked
LyricWiki and Amarok started showing kiddie porn or Nazi spam?

So I'm very much advocating Jakob's approach. But I'm also very
concerned with security. I believe the system is safe, but I would
additionally love to hear the opinion of a security expert on this
too.

-- 
Mark Kretschmann
Amarok Developer
www.kde.org - amarok.kde.org