php posts

xz backdoor

in

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.

Apache PHP FPM and “Primary Script Unknown”

in

A while back, I wrote about dealing with the Apache / FastCGI error ‘Primary script unknown’ when trying to access non-existent PHP files. Bots often do this trying to test for vulnerabilities, and it can fill up error logs and be annoying to look through. In that post, I fixed the problem through mod_rewrite and a RewriteCond. For PHP 2.4+, there is a more broad and likely more efficient solution using the <If> directive. It will work for all virtual hosts on a server.

Continue reading post "Apache PHP FPM and “Primary Script Unknown”"

Homebrew `composer` 2.6.x failing

in

For some reason, the Homebrew version of composer hasn’t been working recently, either 2.6.1 or 2.6.2. So I’ve manually grabbed the phar from getcomposer.org and replaced the file it was getting. I’m running the latest MacOS and up to date Homebrew, PHP, and Composer on an Intel Macbook Air. When I would run composer, I would get an exception

Continue reading post "Homebrew `composer` 2.6.x failing"

Playing with GitHub Pages

in

This past weekend, I started playing with GitHub Pages for the first time. It took a while to figure out, but was somewhat fun. I’ve been interested in it for a while, but was unsure of how to do what I wanted, such as building with PHP, Sass, and Rollup. Turns out it was fairly easy with GitHub Actions to do most any sort of build steps I want. It is very interesting for free static site web-hosting.

Continue reading post "Playing with GitHub Pages"

Swap file for composer out of memory problems

in

PHP’s defacto package manager, composer, has long required large amounts of memory to do updates for larger projects, often more than servers or virtual machines have. The script will die with an out of memory error, or more recently, the simple message “Killed”, and do no work in these situations. The normal procedure is to develop locally, deploy local lock file (composer.lock) to the server, and run composer install instead of update. But I’ve recently moved to doing most of my development in VMs, so I have had to work around this problem to get things installed or updated. A swap file is the solution for Linux machines provided in the official docs and expanded in a StackOverflow answer.

Continue reading post "Swap file for composer out of memory problems"

Sorting with `FIELD()` function in Doctrine

in

I recently needed to sort query results to match the order of IDs passed to it for use in a WHERE … IN() clause. In MySQL, this can be done using the FIELD() function in the ORDERY BY clause. For Doctrine, which doesn’t have the FIELD() function and doesn’t allow functions in the ORDER BY clause, there’s a little more work needed to make use of it.

Continue reading post "Sorting with `FIELD()` function in Doctrine"

PHP-FPM / Apache caching symlinks

in

At Cogneato, we use symlinks to point the web server to different versions of our software for websites. Sometimes, especially on our Ubuntu server, which uses PHP-FPM to serve PHP files through Apache, I was noticing problems caused by scripts being loaded from the previous symlink destination when I changed to the new one. There seems to be some sort of caching going on. The solution was to restart PHP-FPM and Apache after switching the symlinks. On Ubuntu, this looks like:

ln -s /path/to/new-version /path/to/software-link \
&& sudo service php7.2-fpm restart \
&& sudo service apache2 graceful

where the 7.2 is the version of PHP being used. Haven’t noticed the problem since.