Dropbear

Year: 2018

  • WordPress 5.0.1

    While I missed the WordPress 5.0 release, it was only a few more days before there was a security release out.

    So WordPress 5.0.1 will be available in Debian soon. This is both a security update from 5.0.1 and a huge feature update from the 4.9.x versions to the 5.0 versions.

    The WordPress website, in their 5.0 announcement describe all the changes better, but one of the main things is the new editor (which I’m using as I write this).  It’s certainly cleaner, or perhaps more sparse. I’m not sure if I like it yet.

    The security fixes (there are 7) are the usual things you expect from a WordPress security update. The usual XSS and permission problems type stuff.

    I have also in the 5.0.1 Debian package removed the build dependency to libphp-phpmailer. The issue with that package is there won’t be any more security updates for the version in Debian. WordPress has an embedded version of it which *I hope* they maintain. There is an issue about the phpmailer in WordPress, so hopefully it gets fixed soon.

  • Another ActivityPub quirk

    I’m wondering now if the problem with the activitypub is because the user object was already in the remote site and somehow the two were not being linked up properly.

    Removing the user information off the mastodn instance may help, or not.

  • wordpress 4.9.7

    No sooner than I had patched WordPress 4.9.5 to fix the arbitrary unlink bug than I realised there is a WordPress 4.9.7 out there. This release (just out for Debian, if my Internet behaves) fixes the unlink bug found by RIPS Technologies.  However, the WordPress developers used a different method to fix it.

    There will be Debian backports for WordPress that use one of these methods. It will come down to do those older versions use hooks and how different the code is in post.php

    You should update, and if you don’t like WordPress deleting or editing its own files, perhaps consider using AppArmor.

  • Odd dependency on Google Chrome

    For weeks I have had problems with Google Chrome. It would work very few times and then for reasons I didn’t understand, would stop working. On the command line you would get several screens of text, but never would the Chrome window appear.

    So I tried the Beta, and it worked… once.

    Deleted all the cache and configuration and it worked… once.

    Every time the process would be in an infinite loop listening to a Unix socket (fd 7) but no window for the second and subsequent starts of Chrome.

    By sheer luck in the screenfulls of spam I noticed this:

    Gkr-Message: 21:07:10.883: secret service operation failed: The name org.freedesktop.secrets was not provided by any .service files

    Hmm, so I noticed every time I started a fresh new Chrome, I logged into my Google account. So, once again clearing things I started Chrome, didn’t login and closed and reopened.  I had Chrome running the second time! Alas, not with all the stuff synchronised.

    An issue for Mailspring put me onto the right path. installing gnome-keyring (or the dependencies p11-kit and gnome-keyring-pkcs11) fixed Chrome.

    So if Chrome starts but you get no window, especially if you use cinnamon, try that trick.

     

     

  • Securing WordPress with AppArmor

    WordPress is a very popular CMS. According to one report, 30% of websites use WordPress, which is an impressive feat.

    Despite this popularity, WordPress is built upon PHP which is often lacking in the security department. Add to this that the user that runs the webserver often has a fair bit of access and there is no distinguishing between the webserver code and the WordPress code and you set yourself up for troubles.

    So, let’s introduce something that not only can tell the difference between Apache running and WordPress running under it, but also limit what WordPress can access.

    As the AppArmor wiki says “AppArmor is Mandatory Access Control (MAC) like security system for Linux. AppArmor confines individual programs to a set of files, capabilities, network access and rlimits…”.  AppArmor also has this concept of hats, so your webserver code (e.g. apache) can be one hat with one policy but the WordPress PHP code has another hat and therefore another policy. For some reason, AppArmor calls a policy a profile, so wherever you see profile translate that to policy.

    The idea here is to limit what WordPress can access down to the files and directories it needs, and nothing more. What follows is how I have setup my system but you may need to tweak it, especially for some plugins.

    (more…)