Wednesday, December 13, 2006

pax-utils-0.1.15 released

Removed *macho* from release files.
Lots of minor white space and style updates.
List known pkg maintainers for other distributions that carry the pax-utils.

scanelf:
Improved return values of many functions to be ints vs voids.
Support added for displaying em_machine via %a format flag.
Make scanelf_file_bind() not output anything if quiet mode and the ELF is static or not setuid.

pspax:
Support added for -u,--user
Support added for -g,--group

-----------------------------------------------------------------------
http://hardened.gentoo.org/pax-utils.xml

http://people.gentoo.org/solar/pax/pax-utils-0.1.15.tar.bz2

53850 bytes

MD5
acf0e368cb33bc2f6a335ba3f5e4fd2b

RMD160
f0744724b286be2b6d9a37980504d3b4a7dcb695

SHA256
e20f47cd64f2749cfee5b313b7a0439d8ad5df921c66a1b8384140e5e76fc055


Wednesday, October 25, 2006

Post-Install package verification revisited

Some time ago I wrote an article on how to verify the md5 checksums of installed packages on a Gentoo system. Since that time the required package gentoolkit has changed and it no longer provides qpkg in a useful location. To update that article, since I no longer work there, I've put together something for the blog here.

Verification of installed files on a system is an important part of administration. Thankfully, we have tools like tripwire to make that task much easier. These tools allow us to determine which, if any, files have been altered on a system. These tools require that they have been setup to monitor files before the need to verify them comes up though. What can administrators do to find this information out if they were unable to setup something like Tripwire in advance ?

Enter equery. Equery is a multi-purposed application provided by app-portage/gentoolkit. It has so much functionality that many users I've spoken to find it somewhat complicated to get the hang of.


Usage: equery command
where is one of
-q, --quiet - minimal output
-C, --nocolor - turn off colours
-h, --help - this help screen
-V, --version - display version info
-N, --no-pipe - turn off pipe detection
where command(short) is one of
belongs(b) files... - list all packages owning files...
changes(c) - not implemented yet
check(k) pkgspec - check MD5sums and timestamps of pkgspec's files
depends(d) pkgspec - list all direct dependencies matching pkgspec
depgraph(g) pkgspec - display a dependency tree for pkgspec
files(f) pkgspec - list files owned by pkgspec
glsa(a) - not implemented yet
hasuse(h) useflag - list all packages with useflag
list(l) pkgspec - list all packages matching pkgspec
size(s) pkgspec - print size of files contained in package pkgspec
stats(t) - not implemented yet
uses(u) pkgspec - display USE flags for pkgspec
which(w) pkgspec - print full path to ebuild for package pkgspec


For this purpose, we'll only be making use of two equery functions: list and check.

First order of business is to determine what packages are installed on the system. Knowing this is useful in general and something you might want to monitor anyway. This step is very straight forward.


# equery -i list
[ Searching for all packages in all categories among: ]
* installed packages
[I--] [ ] app-admin/addpatches-0.2 (0)
[I--] [M ] app-admin/perl-cleaner-1.01 (0)
[I--] [ ] app-admin/php-toolkit-1.0-r2 (0)
[I--] [ ] app-admin/procinfo-18-r1 (0)
[I--] [ ] app-admin/sudo-1.6.8_p9-r2 (0)
[I--] [ ] app-admin/syslog-ng-1.6.9 (0)
--SNIP--


The first thing you'll notice is the output contains colors etc. To remove them, you'll want to use the -C flag. Another gotcha you'll encounter for this exercise will be the need to hand this output to a pipe. By default equery doesn't produce pipe-friendly output. In order to get the output to traverse a pipe, you'll also need the -N flag.


# equery -N -C -i list


Now that we're able to produce a list of installed software, we need to use equery to check these packages. There's two ways you can do this: You can manually hand equery the package name.


# equery check sqlite
[ Checking dev-db/sqlite-2.8.16-r4 ]
* 22 out of 22 files good
[ Checking dev-db/sqlite-3.3.5-r1 ]
* 22 out of 22 files good


Or, you can make use of awk and xargs to directly hand the equery list output to equery check.

For example:


# equery -N -C -i list | awk '{print $4}' | xargs -i equery check ={}
[ Checking app-admin/addpatches-0.2 ]
* 3 out of 3 files good
[ Checking app-admin/perl-cleaner-1.01 ]
* 7 out of 7 files good
[ Checking app-admin/php-toolkit-1.0-r2 ]
* 12 out of 12 files good
[ Checking app-admin/procinfo-18-r1 ]
* 15 out of 15 files good
[ Checking app-admin/sudo-1.6.8_p9-r2 ]
!!! /etc/sudoers has incorrect md5sum
* 34 out of 35 files good
--SNIP--


This command string will verify the checksums of all software installed on the system using portage. As you'll see, it's quite a bit of output. Since our application of this tool is to determine just what files have been altered, you might want to pull out just those lines starting with !!!

For example:

# equery -N -C -i list | awk '{print $4}' | xargs -i equery -N -C check ={} | grep ^\!\!\!
!!! /etc/sudoers has incorrect md5sum
!!! /etc/init.d/syslog-ng has incorrect md5sum
!!! /etc/syslog-ng/syslog-ng.conf has incorrect md5sum
--SNIP--


Now we have just the output we're interested in. From here there's a few things you might do. First, you'll probably want to keep a know "good" copy of this output as it contains some false positives for packages that checksum their default configuration files. With this you might make use of the diff command to determine what new packages no longer have good checksums.

Finally, should you identify a file with a bad checksum and are unsure as to what package provided that file you can make use of the equery function belongs. I know that I said we'd just be covering two equery functions. I lied.

So, for example we want to find out what package provided /etc/sudoers from our example above.


# equery belongs /etc/sudoers
[ Searching for file(s) /etc/sudoers in *... ]
app-admin/sudo-1.6.8_p9-r2 (/etc/sudoers)


That's it. You can now take advantage of these features to determine what things have changed on your system. This method is two things. It's Ugly, but it's also unexpected. Unexpected is advantageous to you as an admin. If someone gains access to your system, you can bet they'll check to see if you use tripwire. You can also bet that they'll most likely have no idea this method of checksumming even exists.

Friday, October 13, 2006

Mount options as a security layer

Most people think of security as the process of keeping their system software at its most recent version, keeping good passwords, and controlling access to their system. In reality there's many many things that make something "secure". When I decided to (or maybe coerced into) start this blog, my hope was to introduce people to the idea that every little bit helps. That no set "thing" was the gateway to a secure system. Instead, I wanted people to start considering the value of taking advantage of every chance for leverage.

"the general who wins a battle makes many calculations in his temple ere the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat: how much more no calculation at all! It is by attention to this point that I can foresee who is likely to w in or lose." -Sun Tzu, the Art of War

One thing often thought of but rarely as a security leverage point are partition mounting options. The mount(8) command has a number of options that can be advantageous for such purpose. The following are non-filesystem dependent options that can be used to make a system less hospitable to intrusion.
noauto
Can only be mounted explicitly (i.e., the -a option will not cause the file system to be mounted).
nodev
Do not interpret character or block special devices on the file system.
noexec
Do not allow direct execution of any binaries on the mounted file system. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.)
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.)
The idea here is to consider the role of the system and what ways you can segment the partitioning scheme to best take advantage of these options. Doing so will make the system non-standard and help to cause an intruder to spend time adjusting to the system. This time spent by the intruder is valuable time that you may have to better detect their presence. Additionally, some of these non-standard options render worms useless as they often depend on certain directories to behave in a certain way. For example, most worms in the wild assume they can read, write, and execute from /tmp. Don't let them.

Here's an example fstab for a multi-partition production system.

#
/dev/hda1 /boot ext2 noauto,noatime 1 2
/dev/hda2 none swap sw 0 0
/dev/hda3 / ext3 defaults 0 1
/dev/hda5 /tmp ext3 nodev,noexec 0 1
/dev/hda6 /var ext3 nodev,nosuid 0 1
/dev/hda7 /var/www ext3 nodev,nosuid 0 1
/dev/hda8 /home ext3 noatime,nodev,nosuid 0 1
/dev/hda9 /usr/portage ext3 nodev,nosuid 0 1

# NOTE: The next line is critical for boot!
proc /proc proc nosuid 0 0
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0


In the example, /tmp cannot be used as a point of execution. As mentioned above, this breaks most attacks. It will also throw off the neophyte miscreant. The example also keeps some filesystems from being able to leverage the special bit upon execution. This is very useful to keep bit-preserving archives from being planted on the system and leveraged.

Some things to remember. Some options will break your system if applied to some directories.

/tmp - Some software depends on special bits being able to be set. This will often occur in /tmp.

/var/tmp/portage - Portage expects and needs to be able to build your system from this directory. If you deny execution for this directory as a mount point, you WILL break your system.

/? - There's likely others and, depending on your system, you will need to test any options you attempt. Make sure you don't attempt to make drastic mount changes when you don't have physical access to your system. It is possible to render your system un-bootable or unable to boot into run-level 3+ if you make mistakes.

The goal here is simple. Every little bit helps. If you can defeat the latest XML-RPC worm that you weren't aware you were vulnerable to just by breaking its expectation to use part of your system, then the time was well spent and your tactic successful.

Monday, October 09, 2006

HTTPS Gentoo Mirrors

Some Gentoo mirrors able to accommodate SSL wrapped HTTP.

Note that some of these mirrors have expired and/or self-signed certificates. I've still included them. In my opinion, if you're maintaining your system from a tree that uses only md5sum to verify package integrity[1] on public mirrors that you don't control, you've resigned yourself to an acceptable level of risk based on the design.

With that in mind. I think it's reasonable to, if available, use a self-signed, expired, certificate with SSL instead of un-ecrypted HTTP. We've already accepted that we trust the source as a mirror, at this point the gained security is that of security-by-privacy (otherwise known as security by obscurity). By wrapping our system update in SSL we've limited the number of people in the world, with any idea as to what version and type of software installed on our system, to just us and the mirror operator. A small gain, but certainly worth the effort of putting an "s" on the URL you're using already. All of these mirrors have an HTTP tree available from the mirror list at gentoo.org.
In order to take advantage of mirrors that self-sign or may be expired, you'll likely need to add arguments to the download method you have enabled in your make.conf. You'll want to add or adjust the GENTOO_MIRRORS, FETCHCOMMAND, and RESUMECOMMAND entries.

For example:
GENTOO_MIRRORS="https://ftp.ucsb.edu/pub/mirrors/linux/gentoo/"
FETCHCOMMAND="/usr/bin/wget --no-check-certificate -t 5 -P \${DISTDIR} \${URI}"
RESUMECOMMAND="/usr/bin/wget --no-check-certificate -c -t 5 -P \${DISTDIR} \${URI}"
Random:
1. The fact that portage only uses md5 to verify distfiles is a real issue. One that we've hopefully all realized is there, and accepted the possible risks associated with that. While the probability of mirror compromise is low, its value is not 0. There are steps taken within the Gentoo infrastructure to minimize this risk, and presumably if you're using Gentoo they meet your criteria. I will say though that I sincerely look to the day where the portage tree files are signed by a master key.