Hashemian Blog
Web, Finance, Technology, Running

Building New PHP 7.3 on Old Fedora 14 Linux

by @ 5:36 pm
Filed under: Uncategorized — Tags: , ,

I have mentioned before this server runs on old hardware and Fedora Core 14. That’s a 9-year-old OS which in terms of software, it’s like 3 times its life expectancy at this point. Fedora is almost on version 31 now. Keeping old OS around can be real hassle, but then again so is updating and upgrading to newer versions and making sure everything still works as before.

Nowadays updating the OS is a relatively simple task. The kernel gets updated with the new version almost as easily as updating a component and a reboot finishes the job. But at this point the Fedora 14 running on this server is so old that there no upgrade paths. The only way is to make a fresh install and then migrate the files, testing everything along the way. And so, I have decided to leave the OS alone and that’s how this server is nearing a decade on the same OS.

I have previously covered the fact that I have patched and upgraded components of the OS over time, from the Apache Web Server to PHP and Python to TLS to adding IPv6 stack to this server. As the OS has been out of support for many years, in just about all cases, the update job has been done by building and installing from the source. With bits of pieces of built components all over the place, the server is now a patchwork hell, but it has been a surprisingly stable one so far.

The latest effort has been to update PHP to version 7.3. This is actually the second time I was making a PHP update attempt on this server. Last year I upgraded PHP to version 5.6 to head off some security bugs that had been discovered in prior versions, and to make use of some new language features. This time WordPress provided the impetus to make the update. The latest WordPress versions have started to display this alert on the dashboard when running on older PHP versions:

Updating to the latest versions of PHP is pretty straight forward on a newer OS. It’s just the matter of making sure the correct repository is configured and then making the install. For example, in the RedHat/CentOS/Fedora world that entails adding the “Remi” repository followed by “yum install”.

In my case however, the standard “yum” option (now “dnf”) is out of the question. I needed to download the PHP 7.3 source and build it myself. Right from the start “./configure” unleashed a torrent of errors. Some were complaints about older version of products/libraries in my Fedora 14 OS while others were about missing libraries. Fixing those errors is like falling into a rabbit hole of iterative updates. One library relies on another which relies on another library with a newer version. That meant I had to download the sources and build the downstream libraries before I could come a level back up. In other cases, I had not placed the previously built libraries in standard locations, so I had to actually edit the “configure” file and provide a bit of location guidance in a few areas. I also decided to forego a few unused extensions such as “Mapi” that I could do without.

When “./configure” finally ran successfully emitting the “Makefile” file I had miraculously passed the first hurdle. The “make” command was up next. This command, following the “Makefile” instructions, builds the executables and libraries of PHP. I was sure there would be errors and I wasn’t surprised when I saw them. As I was hunting and correcting the errors one persistent error kept emanating from a few lines in “php_zip.c”. After some consideration, I decided that I could comment out those lines without harming the overall product as it is used on this server* and the second hurdle was finally overcome. I had my “php” and “php-cgi” holy grail executables.

The right next step after “make” is “make test”. On this step a number of tests and checks are run against the newly built PHP to make sure it is functioning properly. I knew there was no passing all those tests, given the old Fedora 14 OS. Instead I wanted to test the new PHP against the existing web pages on the server. This is of course not a proper test as even if it passes, that’s no guarantee future pages or scripts will function as expected. But this is my server and my pleasure so I headed straight to executing the cli “php -v”. It was encouraging to see the new version but a few errors also printed on the screen. At least I finally had PHP 7.3 running on the server.

Turns out those errors were due to missing extensions that PHP couldn’t load. A few of those extensions such “mysql” and “mcrypt” have been deprecated and are no longer part of the PHP 7.3 core. Other errors, such as “zip” load error were caused by old library versions, requiring me to build newer versions of those libraries, such as “libssl”, and install them.

The final piece was the “mcrypt” extension which has been deprecated and its use discouraged. Instead the “Sodium” or “OpenSSL” extensions are suggested as a safer alternatives. My site does make use of “mcrypt” and I need time to update those references so leaving that extension out was out of the question.

Getting the “mcrypt” extension involved downloading its source from PECL, placing the source files under the “/ext/” directory, then “cd” into “/ext/mcrypt/”, run “phpize” then “./configure” followed by “make”. Of course, even in this case I ended up with errors at the “./configure” step. Turns out I had an older version of “Autoconf” and, surprise, I had to download the new “Autoconf”, build and install it before I could build the “mcrypt” library.

There’s no doubt that I need to migrate this server to a newer OS version like yesterday. Even though I’m happy that this site is now running on the latest version of PHP and WordPress has stopped complaining, I realize that this patchwork hell can be pushed only so far before it comes apart. It’s amazing that it has gone as far as it has and I’m under no illusion that these newly built components may not necessarily be fully stable nor secure when deployed in this fashion. Guess what I’m trying to say here is, don’t try this at home.

Note: No sooner I had deployed PHP 7.3 on this server than the word of several PHP code execution flaws hit the street. While for most people the fix was to simply install the latest released version of PHP, for me it was back to the source download, code alterations, build and deploy. At least I had a recent roadmap this time to get there faster.

* Altering source code before building the executable could have adverse consequences in terms of security and stability. It is risky.

PHP - echo'ing String Fragments Using Periods Vs. Commas

by @ 10:18 pm
Filed under: computers — Tags:

One of the mysteries of PHP's echo function is the supposed equal treatment of multiple strings separated by periods (.) vs. those separated by commas (,). Actually echo is a language construct, but I digress. In both cases echo appears to concatenate the string fragments and output the resulting string.

In actuality, the period is the real concatenation operator in PHP. The comma on the other hand signifies echo's ability to accept variable-length arguments. Judging by Google search, most people just accept the fact that they can use either periods or commas with the echo function to get the job done.

But there's a subtle difference that's mostly overlooked because it rarely mucks up the results. Take a look at the two code lines below. You might expect to see 12 for both cases, but that is not so.

php echo

The reason is that with periods, some or all expressions are evaluated first and the results are concatenated. Then echo outputs the result after all fragments are concatenated. With commas echo walks the argument list, evaluating expressions and spitting out the results as it goes along.

Wordpress Base64 Hack or PHP-CGI Hack? part III

by @ 5:37 pm
Filed under: hacking,web — Tags: , , ,

After being hit by the Wordpress base64 hack twice within a couple of weeks, it finally dawned me that the PHP CGI flaw was the culprit. The attack robots (a la Metasploit) use the knowledge of PGP CGI flaw together with the well-known scripts of popular products (Wordpress, Joomla, Drupal, etc.) to penetrate sites and that's how this site was breached as well.

Most sites run PHP as a module, so those were spared the headache. I used to run PHP as a module many moons ago, but chose to move to CGI for several reasons. Here's a an explanation of the difference between the two modes. What's disconcerting is that the CGI vulnerability had been around or some 8 years and no one seemed to have noticed during all that time and it was my PHP version 5.3.5 that did me in. It was time to move to version 5.3.14. But where to find that php-cgi version for my Fedora install.

I went hunting for php-cgi 5.3.14 all over the net, from user websites, to rpm repositories, but no dice for my Fedora version. Now sometimes you can use an off version, but then you run the risk of crashes, library mismatch and other problems. So why not download the source from php.net and build it myself? Simple, I'm too lazy and hate building/rebuilding programs. There's the big download, long waits, missing libraries, warnings and errors. I had just come off a build hell of Varnish cache, and I wasn't about to plunge myself into another. But, in the end I had no choice.

The Linux build world is a 3-word expression: configure, make, 'make install'. I'll add another word, loop. You download the source code, run configure to adjust the config and make files for your particular platform. Then you run make to build the program(s). finally you run 'make install' to install the program(s) on your system. Sounds easy enough until you realize that a million things can and will go wrong and that's where 'loop' comes in as you configure and make repeatedly to get things right.

Building PHP 5.3.14 didn't disappoint. I ended up running configure and make tens of times until I finally got the binary I wanted with all the necessary libraries included. Building php using make renders a number of binaries including the main command line program (interpreter) as well as php-cgi and it was the latter I was interest in.

I copied the newly-made php-cgi over the old version, tested the site and called it a day. Now I know this sort of installation is a cardinal sin to many techies, no argument there. Think about it, I am running a php-cgi version that is out of sync with the main php interpreter on the same machine and then the rpm (package manager) has no clue about which version of php is really installed on the system. At the first rpm update, the whole system could come crashing down. I just have to be cognizant of the fact that I have a fragmented php installation. Eventually when I migrate the site to a new Fedora version all will be back to good. For now, it's good enough to have been hack-free for a couple of months.

Part I, Part II

Wordpress Base64 Hack or PHP-CGI Hack? part II

by @ 7:15 pm
Filed under: hacking,web — Tags: ,

To be factual about it, my site was hacked twice in exactly the same way over a period of couple of weeks. The first time around I noticed it when the feeds coming via Feedburner kept crashing the RSS readers because of a javascript malware block inserted right at the top of the feed. Turns out that the php files in my wordpress installation were altered to emit the offending javascript block.

Surely the hacker must have exploited some wordpress vulnerability, I thought. A quick search on the web for wordpress base64 hack, brings up plenty of pages covering such hacking cases.

I started out by examining the MySQL tables by doing a global search for terms such as base64 or eval. The wp_options table had plenty of such entries. At first it seemed like I had found the hacker's stash. wp_options is where wordpress and the plugins save their parameter data. There were also lots of entries with the "transient" keyword. In the end they turned out to be innocuous. Transients could become real nuisances, but that's a different topic.

With the database search behind me, I put the focus on the files. Deep searching for base64_decode and eval, produced a number of them. Here's a simple command to achieve this search:

$ grep -rl base64_decode *

Some of the hits were legitimate, but eventually I ran into two types of files that were obvious hacks. The first type were mostly legitimate index.php files that had been altered with a giant code block right at the top. The blocks were of the base64_decode(eval(long-hex-string)); variety. Removing the block appeared to restore the files back to their original form. The other type were small-sized php files with varied names containing one or two lines of code like eval(stripslashes($_REQUEST['a']));. This code would basically execute raw code passed in as a parameter to the page, very simple, very effective, and very dangerous.

Armed with that knowledge I went snooping around the site looking for small-sized files and any files that had been altered recently.

$ find -size -1k -name *php
$ find -mtime -7 -name *php

The first command returns php files that are 1kb or less in size. The second returns php files that are modified in the last 7 days. I dug through the long list of files, fixed the altered files by removing the malicious code blocks and then deleted the small dropped-in files.

Finally I upgraded the wordpress installation to the latest version and everything was back to good, or so I thought. Within about two weeks I was hacked again in almost the same way as the first time. How did I recover from it and plugged the hole? Hint: PHP was the actual culprit. Stay tuned …

Wordpress Base64 Hack or PHP-CGI Hack?

by @ 10:57 pm
Filed under: hacking,web — Tags: , , ,

A couple of months ago I started noticing that this blog's RSS feed, which is via Feedburner, wasn't coming through on some RSS readers. After some tests I discovered that the feed actually contained a malicious javascript block at the top. That was breaking the XML format, causing the RSS readers to fail. Turns out that It was my own site that was hacked, replicating over to Feedburner.

After a bit of investigating I found a number of files, specially those named index.php, that had been modified by a code block at the top that started with something like "eval(base64_decode(…" followed by a long string of hex numbers. I decoded the hex string and I ended up with a php code block that looked pretty devious with references to Chinese sites.

This is what was happening. A blog page is accessed by a user. Since most Wordpress activity is funneled through the index.php file the malware at the top is executed and after a couple of iterations a javascript block is produced and sent to the browser. No idea what the javascript code was doing, but safe to assume its goal was to infect the users with malware, steal data and eventually turn them into zombies in some botnet.

Do a search for Wordpress base64 hack and you'll find thousands of sites around addressing this issue. Wordpress doesn't exactly have a good security reputation but its latest versions were thought to be more secure. But in this case Wordpress wasn't at fault. Turns out the real culprit was php-cgi 5.3.5 and a nasty security hole stretching back for 8 years. The bug would allow the attacker to view the source code of a page, run arbitrary code, and generally be a pain in the a$$.

I suspect in some cases where Wordpress (or Joomla or Drupal or phpMyAdmin) has been hacked, the true culprit has been php-cgi. The reason these popular programs are targets is that their structures and operations are well-known to all including the hackers. All it takes to exploit vulnerable sites is to write simple scripts targeting known pages and letting it loose on the internet. The robot crawls around infecting sites as it find them and then those infected sites infect their users by extension. An old concept, but pretty neat in a distorted sort of a way.

There are some of questions to be answered here. Why was such a gaping hole allowed to remain in php for 8 years? Why was it publicized before it could be plugged? Why do some sites still use CGI? After all, this vulnerability didn't affect php ran as a module. Those are good questions and there are plenty of discussions about them online, so no need to rehash here.

What might be useful is explaining what I did to plug this hole on my site. Stay tuned …

Powered by


Read Financial Markets  |   Home  |   Blog  |   Web Tools  |   News  |   Articles  |   FAQ  |   About  |   Privacy  |   Contact
Donate Bitcoin: 1K9TzBvQ2oaEb4tX9t2vKDtZouMcpfV6QF
paypal.me/rhashemian
© 2001-2019 Robert Hashemian   Powered by Hashemian.com