Mambo Exploit Blocked by SELinux

A real-world case where SELinux proved its worth.

Richard Bullington-McGuire is the Managing Partner of PKR Internet, LLC, a software and systems consulting firm in Arlington, Virginia, specializing in Linux, open source and Java. He also founded The Obscure Organization, a nonprofit organization that promotes creativity and community through technology. He has been a Linux sysadmin since 1994. You can reach him at rbulling@pkrinternet.com.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Titanic movie rendered with Linux

bosch servisi's picture

bosch servisi, bosch servis

..

turkce's picture

Thanks..

radyo

radyo's picture

thank you very good

An alternate defense against this attack

Richard Bullington-McGuire's picture

Kyle Wilson recently wrote me regarding this article, and gave me permission to share his remarks with Linux Journal readers:
________________________________________________________

Richard,

Hi. I just finished reading your article about SELinux in this month's Linux Journal. I enjoyed it very much. I thought I'd share a tip with you which I use to protect my internet facing servers. I always edit my fstab file to include the nosuid and noexec mount options for my tmp file system. In the case of the Mambo exploit which you wrote about, having the noexec mount option on /tmp would have also prevented the exploit by preventing the execution of the cback binary which was placed in your /tmp file system. Here's the description of the options from the mount man page:

noexec - Do not allow execution of any binaries on the mounted file system. This option might be useful for a server that has file systems containing binaries for architectures other than its own.

nosuid - Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe if you have suidperl(1) installed.)

Kyle
________________________________________________________

Kyle has some good points about protecting filesystems using mount options. That is a solid and time-honored way of helping to secure a system, to be sure. I've seen some systems that have many filesystem mount points that are locked down with noexec and nosuid options.

Many systems today (including the one I wrote about) only have two file systems by default, that is a boot and / filesystems. This system was one of those. Locking down /tmp like that would also have protected from this specific attack, had SELinux not been activated:


# for /etc/fstab:
none /tmp tmpfs nosuid,noexec,rw,size=512m 0 0

However, other points of vulnerability also exist, such as /dev/shm, /var/tmp, and really, any writable file on your system. To be thorough about using nosuid and noexec options, you would need to ensure that these directories are also protected with these options. That is easy enough for /dev/shm, but not so easy for /var/tmp unless you dedicate a disk partition to it, or do funny tricks such as mounting a file on /var with the loop device and mounting that on /var/tmp. Even doing that is not proof against a determined attacker, as this shell code snippet illustrates:


# Try this out on your system to see how wide-open you could still be
echo "World-writable directories:"
find / -type d -perm +0002
echo "World-witable files:"
find / -type f -perm +0002

One of the nice things about the Red Hat / Fedora SELinux targeted policies is that it stops attacks on pretty much all of these locations with a default-deny rule.

Correction: sentence below Listing 4

Richard Bullington-McGuire's picture

The sentence below Listing 4 should read:

Lines showing further attacks similar to the trace on targetbox versus Mambo, xmlrpc.php, drupal and phpgroupware also appeared in this grep.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix