Latest Tweets

Chkrootkit 0.48 and 0.49 suspicious PHP files aid strange behaviour

Preamble

Chkrootkit 0.48 and newer versions have an aid so as to scan some temporary directories inside the file-system in searching of “suspicious” PHP files. This functionality shows two different messages on the screen: one of them is just the list of “suspicious” PHP files which have been found. The second one is just the header (merely the first line) of each one. In theory. As a matter of fact, chkrootkit looks for PHP files where there should be no one. This way, any found file will be categorized as a “suspicious one” immediately.

The matter

We’ve been reported about some weird problem concerning a scanning of PHP files inside a GNU/Linux box file-system using Chkrootkit 0.48 and 0.49 versions. To be exact: as soon as the chkrootkit script started analysing suspicious PHP files, that’s what came out:

Searching for suspect PHP files... /tmp/plugtmp-27/plugin-mm_as3.php
H<)Y:=-j>NK!^'D[H`bdepf"L]CZB'rd^*PPD-Adobe:
"4.3"8]GsO?'ap=#K4j;!#_EMP+3bpb?P%Gn+5_

The effect was really weird: because of the fact it was executed on a TTY console, all those ASCII characters appeared all of a sudden, provoking the terminal to behave strangely, due to some of those ASCII characters were processed by the terminal as escape commands – this was a terminal, after all, don’t forget that!- . This way, as far as the user was concerned, this sort of things happened:  text lines had started to be deleted, the cursor has been moved to the left or to the right screen area, etcetera.

Analysing the issue

First and foremost, I took a quick look at the PHP file reported by chkrootkit scan, that is, the /tmp/plugtmp-27/plugin-mm_as3.php. Unluckily, there was nothing off-topic in there. Thus, I decided to have a deeper look at the very chkrootkit script code:

   if [ "${QUIET}" != "t" ]; then
      printn "Searching for suspect PHP files... "; fi
      files="`${find} ${ROOTDIR}tmp ${ROOTDIR}var/tmp ${findargs} -name'*.php' 2&gt; /dev/null`"
      fileshead="`${find} ${ROOTDIR}tmp ${ROOTDIR}var/tmp ${findargs} -type f -exec head -1 {} \; | grep php 2&gt; /dev/null`"
   fi
   if [ "${files}" = "" -a "${fileshead}" = "" ]; then
      if [ "${QUIET}" != "t" ]; then echo "nothing found"; fi
   else
     echo "${files}"
     echo "${fileshead}"
   fi

Clearly, the line showing up “the file-names” was echo ${files}. Then, I came to my first decision: just to try commenting  the echo “${fileshead}” line. Then, I re-ran  the chkrootkit script Those weird ASCII char codes were nowhere to be seen this time.

Obviously, the issue was directly related to the “php” file-headers, so I redirected those hypothetical headers to a file in order to be capable of studying them. Then I re-ran the script one more time so as to capture those headers.

After a while, I had a file containing, in theory, plugin-mm_as3.php‘s headers. So, I asked what it was using the file command:

 file /tmp/php_headers
/tmp/php_headers: PDF document, version 1.2

Well, it was not a PHP file header at all. I could even open this PDF file using xdpf, and it revealed to be a valid PDF one, no doubt.

The culprit

Looking back at the chkrootkit script sources, the line in charge of gathering all PHP file-headers has nothing to do with that one in charge of scanning for “suspicious” PHP files through the entire file-system, as it is clearly shown right here:

fileshead="`${find} ${ROOTDIR}tmp ${ROOTDIR}var/tmp ${findargs} -type f -exec head -1 {} \; | grep php 2&gt; /dev/null`"

This line just looks for any file, no matter if it is really a PHP one or not, asking for the “php” string on its very header. But, unluckily, when it comes to binary ones, like PDF files, the head -1 command reports, in fact, the entire file data, not merely its first line as when it affects ASCII files. Why’s that? Well, there’s only one line, because there are no new lines or return carriages at all!

Running the string command, it is obvious that inside this PDF file there is the php string, really:

host:/tmp # strings /tmp/php_headers |grep php
4<>J#dp23p&7R!OPMNUWXr?a,(Y7'[-f^l]PT4K96Cphp?aRQ0%6MBR3PS5`=WI:,_Cm[&_%LmK*7F<R
F;mj!8P>ldm34TgSsUo?5)<`sASSsb-X$aUqJqs&fudC4C)&MG9>FRg;;hRc4^)V8"G,phpE=W[k+i;Y
<:[QcP/(Zd^(j>B.]2jL8Nq&SBCDhphpU5$[ju]B+89WkTnkdCQBiJ\LdF6m:Ia(LcN+A8ZqWAa]E/GF
1Z)%o+hNJQFA;D"_0jT\P&+I#>R*,B'tp\Bm=p'b'Rm?])Du\S1]EC1)F-o#lJLe:NSphp'u[Yon$U`L
8]_O=1FYqnHmOKZgqWZ%Ah6u$6]3XN'!+\\G%B&BboF!1r+nT">_?Z+(]phpi!sZDnZ#sAXZ;?R$$pB-

To sum up, it was not a “suspicious” php file, as wrongly chkrootkit informed us. It was merely a valid PDF document, a temporary one which probably should  not be there, right, but not something the user has to be aware of, after all.

Conclusions

It seems not one hundred per cent feasible at all to determine when a file is a PHP one or not just by checking its header out. In fact, it seems totally pointless. In this particular case, for example, the real user seems to be mockered by this script, showing a “false positive” and alarming him or her. This erroneous behaviour has been reported to the chkrootkit developer’s team.