security posts

xz backdoor

Reading this weekend about a backdoor introduced to the open source xz project. It doesn’t appear to affect my Ubuntu servers, so I had assumed it wasn’t relevant to me. However, the homebrew version on my Mac was “vulnerable”. It sounds like the exploit would only work on some versions of Linux, but if it does work on Macs, that could be bad. I do a lot of stuff on this computer, including banking, email, coding, etc. They know about it backdooring ssh, but if there’s something they don’t yet know about, it might be a problem.

I have a Fedora install as well. I haven’t checked it yet, but Fedora is usually on the bleeding edge, so if it’s on there, I’ll probably wipe and reinstall. I’ve been considering anyway. Luckily, I don’t do anything important on there.

Even if it didn’t actually do anything bad on the Mac, it may have done something. I had noticed some weeks or months ago (I can’t remember when) that running PHP on the command line was going slow. Running anything would take a minimum of about five seconds, including something simple like php -r 'echo "hello\n";'. I know when I had been making scripts in the past they hadn’t been taking long at all. I did some searches on the web for anybody mentioning something like that and couldn’t find anything. So I kinda just figured maybe it had something to do with the new opcode / whatever cacheing newer versions do or something, like it takes some initial setup that the server can reuse but not the command line. I assumed I was stuck with it and even started moving some scripts to bash partly because of it. When I downgraded xz via homebrew though, I decided to test it. time says the simple php -r line took 0.092 seconds. Nice and snappy. So maybe xz was doing some checks to see if the device was exploitable. It was in the dependency graph of PHP through curl and gd. Can’t say for sure that it just sped up though and if the xz change was what caused it.

I’m glad my scripts finally run quickly again, but hope that nothing was exploited here. I’ll keep an eye on the web to see if anything comes up about Macs being exploitable, and if so I’ll probably reinstall the OS to be safe.

Note: If you have used homewbrew to install PHP, curl, or anything else that might depend on xz, run brew update; brew upgrade to be safe. The dangers of being on the bleeding edge I guess.


Easily typed passwords

I came across an interesting Stackexchange question about easy to type passwords. It seems a useful consideration for passwords we have to type frequently. Reading through the answers got me to thinking about a solution that fits the criteria of easy / fast to type along with the general password criteria of easy to remember and some reasonable level of secure.

My solution considers typing style for determining ease and uses words and rules for making them memorable. It keeps to the rules from the question of at least one upper case letter, one number, and one symbol.

Continue reading post "Easily typed passwords"

Algorithmically derived passwords

I’ve been considering a new password storage method for a while now. Currently, I have a system where I compose passwords of pieces of several different values that I have memorized. Each value has a key that I have associated in my head to the value, and I have a file with the keys for each site. Lately, I’ve also been doing part of the password as something derived from the name of the site. This has helped somewhat with making the passwords memorable, but I still frequently have to look at my password file. If someone got a hold of this file, it would take some dedication and knowledge of me, or at least access to the plain texts of some of the passwords, to crack the system. Nevertheless, I’ve been looking for something easier to use and preferably more secure at the same time.

I’ve been looking at options like YubiKeys and 1password, but they have their issues. Today, I came across a cool option wherein passwords are algorithmically derived from a single password and the site name. This is sort of like what I’m doing in my head for some of my newer passwords, but much more advanced, able to produce hash passwords of a desired length and even with character constraints. I read about the idea from a post by Tab Atkins, who has his own solution freely available to use. The comments on his post also led me to SuperGenPass, a similar idea.

Both are of these options built purely using web technologies, making them easy to use anywhere. Both are open source, so I can check their code, verify they are doing what I want, and modify them so they can be slightly different. Neither need to store anything (unless you change the config for SuperGenPass) or require accounts. They have an option to work as a single-page file that can work even offline, wherein you type your master password and the name of the site, and they will give you the password in plain-text to copy elsewhere. SuperGenPass also has a bookmarklet option that can be run from the page you are entering the password on (obviously web only) by using an iframe (requires a third-party server) that can put the password directly into the password field, bypassing the need to copy the password at all.

So these are definitely interesting options to make working with passwords much easier, and the passwords I have for each site can be more complicated and theoretically secure than what I use currently. The biggest danger would be, if someone figures out my master password and what settings I’ve used for the generators, they will have access to any passwords I’ve created. I would probably do multiple master passwords, at least a normal one and an extra-secure one, just to limit the number of accounts they could access. I could even throw in a simple modification to the master password derived from the site name to make it even less of a problem.


Security HTTP Headers

I’ve been working on the HTTP headers my site sends recently. I had been working on performance / cache related headers, but after seeing mention of a security header scanner built by Scott Helme, I decided to spend a little time implementing security related headers on my site. I don’t really know these headers that well, so I added the headers it suggested and mostly went with the recommended values. I did read up a bit on what they mean though and modified the Content-Security-Policy as I saw fit.

I added most of the headers using a Symfony reponse event listener. This handles all of my HTML responses without sending the headers for other responses, where they aren’t necessary. The exception is the X-Content-Type-Options, which should be set for all responses. I set that in Apache configuration.

Continue reading post "Security HTTP Headers"

Additive overwriting of Symfony security configuration

Symfony provides a security component and bundle for managing authentication and authorization in an application. It is versatile and powerful, if not a bit complicated. You can toss as many mixes of authentication and authorization configuration as you want. The important parts of the configuration cannot be overridden or added to by multiple config files, though. This makes sense for one-off applications, where you can be sure that no bundles are messing with your security configuration. However, if you’re building something like a CMS that will be used for multiple sites, where you want the CMS’s bundle to manage security, setting the configuration within the bundle will block the application itself from adding its own configuration.

One way I’ve found to work around this is to have the security configuration set on your bundles configuration extension instead of the ‘security’ extension directly, and have your bundle merge all such configurations and set them on the ‘security’ extension in PHP. If you allow this configuration node to be overridden, any number of bundles can add to it and avoid the “cannot be overwritten” error.

Continue reading post "Additive overwriting of Symfony security configuration"