LMD 1.3.9r1: Hexdepth Bug

I have put up a revision to the 1.3.9 release of LMD that fixes a hexdepth bug in which malware greater than 65Kbytes would cause an error in the internal hexstring.pl script and be considered clean on the stage2 hex scanning of malware. This would mean that unless malware had a MD5 signature for it to be caught on stage1 scan, it would not be picked up by a corresponding HEX rule in stage2 scan if its file size was greater than 65Kbyte, due to the bug.

In addition, I have made the decision in this revision to enable release update checks in the default cron.daily entry installed by LMD, this can be found at /etc/cron.daily/maldet line 9 (after update) if you wish to comment it out. I would however encourage users to leave this option enabled as it will greatly improve receiving timely updates for future bugs fixes and release updates. In the past, the decision was made to not enable automatic release updates for many reasons but mostly in the interest of the software still maturing and being in early development, thereby not wanting to rock any boats with large and sweeping release updates to a version they may have got working the way they prefer. Now though, LMD has come a long way, the installer imports most options and ignore files and there are no drastically sweeping changes planned that will cause a great deal of headaches — so it seemed fitting time to enable automatic updates.

You can update your installation using the ‘maldet -d|–update-ver’ flags or download the current build for new installations.

This release update also coincides with passing 7k signatures….. We now sit at 7,106 signatures or +146 signatures added today. This is no small feat, I remember when we had just a couple hundred signatures not so long ago and I thought that was a big deal! The LMD submissions repository stays very active, it is now the source of almost 60% of the weekly signature additions and has contributed greatly to creating a vastly more accurate signature set that is representative of the threats you, the users, face day-to-day.

That said, month ending March stats recorded +1,464 installations of LMD bringing the install count to 7,157 — which puts LMD now ahead of APF in month-to-month new installation growth. Although, APF still beat LMD on raw downloads last month (3,091 vs 2,583), it is reasonable to predict that LMD will soon take the number one spot for downloads as well. It however still has a long way to go for total active installations, which APF sits at a comfortable 24,791 currently.

Till next time, happy malware hunting 🙂

Linux Malware Detect v1.3.6: Loose Ends

In LMD 1.3.3 there was allot of changes, 29 to be exact, that made LMD much more robust and especially the monitoring component, much more usable. If that release was about making good things better, then this release is about bringing loose ends together. I spent a couple of days running LMD through its paces along with having many people help me test it and during that process, we brought allot of little things to the surface that needed fixing or revising.

In total, there has been 31 changes, fixes or new additions to LMD since that 1.3.3 release on the 15th, most of these changes were completed days ago but I wanted to take the time to make sure they were working as intended and that no more bugs/issues came to the surface. At the moment, since releasing LMD on the 11th, there has been a total of 1349 downloads, so to say that there is plenty of opportunity for bug reports would be understated. I am comfortable in saying that the changes from 1.3.3 to 1.3.6 are stable, reliable and working as intended.

The version changes aside for the moment, there has also been a mountain of user submitted files with the –checkout feature, I processed many of those yesterday and earlier last week for a total of 71 new signatures for the week. Those signatures will have automatically been updated to your install through the cron.daily run of –update, or you can run it yourself if you do not use the default cronjob.

So, what of significance has changed since 1.3.3? The biggest changes are that there is now a -d|–update-ver feature that performs a version update check and if a new version of LMD is available, it will install it. This feature does both a version number check and hashes the main LMD files checking for differences with the server side files, when one of the two checks fails, an update is forced. The version update is not automatically run for a number of reasons that I am to lazy to explain, just think about it a bit. All session and quarantine data is migrated on update.

Most of the other changes are fixes and improvements on existing features, especially the monitoring component which of the 31 changes since 1.3.3, 17 of them are all within the monitoring component. There has also been a few changes to the README file to reflect some minor usage changes, to clarify better some usage of the monitoring service and to explain some new ignore options.

That is all from me, changelog is below, enjoy.

Project Page: http://www.rfxn.com/projects/linux-malware-detect/

Change Log v1.3.3 => v1.3.6:
[Fix] session data gets recreated if it disappears during scan
[Fix] tlog now handles data that logged between 0bytes and first wake cycle
[Fix] monitor_check now properly handles CREATE,ISDIR events
[Change] –alert-daily|weekly alerts have been changed similar to manual alerts
[Fix] cleaner was not properly running on monitor_check calls to scan files
[Fix] quar_suspend was not properly running on monitor_check calls to quar()
[Change] monitor tracker files now pass through trim_log to avoid oversizing
[Fix] monitor_check now properly handles path names with spaces
[Fix] monitor_check was throwing nx file/directory error for monitor.pid
[Fix] older bash versions were having trouble with the [[ =~ ]] regexp search
[Change] set all script files from shebang/bin/sh to shebang/bin/bash
[Change] –alert-daily|weekly will now only send alerts if hits were found
[New] -d|–update-ver now compares file hashes to determine update status
[Fix] suspend events were not properly being added to monitor alerts
[Change] all alerts have had spacing changes to make them more readable
[Fix] signature names now properly list for daily|weekly alerts hit list
[Fix] monitor_check will now recursive monitor newly created directories
[New] monitor daily|weekly alerts now save as a pseudo scan report with SCANID
[Fix] monitor reports now generate properly when quar_hits=0
[Fix] cleaner function was not properly executing under certain conditions
[Change] additional error checking/output added to the cleaner function
[Change] default status output of scans changed for better performance
[New] added ignore_intofiy for ignoring paths from the monitor service
[Change] updated ignore section of README
[Fix] backreference errors kicking from scan_stage1 function
[New] -d|–update-ver option added to update installed version from rfxn.com
[Change] updated short and long usage output for update-ver usage
[Fix] -k|–kill-monitor now properly kills only the inotifywait/monitor pid’s
[Fix] monitor_cycle function now correctly stores its pid in the pidfile
[Fix] files with multiple events in the same waking cycle are only scanned once
[Change] install.sh now symlinks maldet executable to /usr/local/sbin/lmd

BFD 1.4: Important Security Fix

Today I have put up a new release of BFD, version 1.4, that addresses an unsanitized variable issue that is used on the command line. This is a serious issue and should be treated as such, if you currently have BFD installed I would encourage you to update it immediately, the install.sh script in the BFD package will retain all your options and tracking data so the update process is painless.

Current Release:
http://www.rfxn.com/downloads/bfd-current.tar.gz

Change Log:
[Fix] properly sanitized vars passed to the command line
[Fix] ignore.hosts is now updated with system addresses on each bfd run
[Note] thanks to [email protected] for invaluable input and pointers

wget http://www.rfxn.com/downloads/bfd-current.tar.gz
tar xvfz bfd-current.tar.gz
cd bfd-1.4/
./install.sh

Although this issue has many mitigating factors that lessen the severity of the potential impact it is nevertheless very serious and best to opt on the side of caution. I need to extend a special thanks to Jeff Petersen of webhostsecurity.com for identifying this issue in a very professional fashion and offering technical input.

The Way Forward

It is hard to believe the year is almost done and gone already, it has been busy for me with some life drama earlier in the year then a couple of larger projects keeping me on my toes since then.

During the last few weeks I have taken the time to draft a solid road map for the projects and where I would like them to be by this time next year. The road map evolved in very organic fashion with me jotting down a few points here and there every day, now it is pretty long but very constructive. It is not really something formal enough for me to release in its retarded disorganized point-form fashion but I will touch on a few items.

The biggest community oriented change will be bringing the projects source to a svn/git management system with the usual web interfaces to go with them and allow public bug/contrib additions/tracking. This to some might seem like a really long overdue task but you need to understand that the projects to this point have been developed to cater to my administrative needs day-to-day with work and secondary to the community. Although I will still put priority on features I require, it will become easier for others to submit contributions and assist with bug tracking, hopefully allowing for a more robust set of projects in the end.

The next big ticket item on the road map is the integration of projects into a suite utility which is a long standing desire of mine and others but it requires allot of work. I have decided that it is best to just completely rewrite many of the projects instead of trying to hack them into some half-ass suite utility. The age of APF and BFD is beginning to show, they no longer really compete with some other tools and in certain cases even find themselves dragging behind in performance, features and usability. I intend to modernize the projects by rewriting them in cleaner (read: documented) code with clear project targets that are better outlined from the start along with features that will blow other Linux firewall wrappers and security suites out of the water. I do not want to get into the actual gritty details of specific plans yet but things are definitely going to change in a good way.

On smaller items there is about 40 odd specific items I have put down to paper, that range from feature additions, enhancements, rewrites, bug fixes and contrib additions that need to be worked on either in conjunction with the suite project or before it can even get off the ground. Though these are tedious tasks they are all things that must be done and will get done, I will detail further on these actual items in a future post but for now it is only important to keep in mind that the suite will not beat around the deficiencies of the smaller projects, everything will get some TLC.

I know this post is not that forthcoming in specifics but stay tuned, I will get the road map cleaned up and posted soon. One of the new projects that will become part of the suite will be a malware detection utility primarily for web servers which you can read more about here.