Cooking With Technology

mod_python Project Configuration Files

In my last post I brought up how to get around mod_python’s default inability to handle relative paths for imported modules. The next night after writing that, I faced a very similar issue with configuration files.

It is a sin to duplicate data in a project (except when caching), so most sane desktop applications will have a central store that contains the configuration parameters for the application (usually packaged as a resource with the application, or in the registry for Windows users). Mod_python can’t do this because, as was discussed in my last post, it views the current working directory of whatever script it is executing as the root directory of the filesystem (”/”). So where do you put the configuration file for your mod_python based project if you can’t refer to it relatively, don’t want to hardcode an absolute path, and want to distribute the configuration with the project?

The solution hit me like a bucket of cold water. Give up on the property or ini format file, and make your configuration a python dict object that you can directly import:

# config.py
#
# This is the project's configuration. Import it when a class needs to access
# project configuration variables.
#

_config = {
    # The name of my app so pathHack knows what string to look for
    'rootname': 'sampleWebApp',
    # Database options
    'db_host': 'localhost',
    'db_dbname': 'sampleWebApp',
    'db_user': 'sampleWebAppUser',
    'db_password': 's0m3p455w0rd',
    # Debug logfile path
    'debug_logfile': '/tmp/lostafollower.log'
    };

This file needs to live in your project’s root directory as far as mod_python is concerned. For more information, read my last post. If you’ve already read it, then you’ll understand when I say that config.py lives in the same folder as pathHack.py.

Once you can import it from your main source files, use it like this:

<%
# sample usage of config
from config import _config as _c
req.write(_c['rootname'])
%>

Tada! Extraordinarily simple configuration file that is easily accessible and can be distributed with your mod_python application. I’m pretty happy about it :)

Relative Import Paths Using Mod_Python

A long while back (a year already? Jeeze!) David Brenner and I wrote a web application without using any frameworks, only mod_python and python server pages (PSP). We ran into a few problems along the way, one of which being that the import path mod_python used had to be composed of absolute paths. It isn’t a huge problem to just hard code a path to your project’s lib directory, but it is hardly portable and adds to the fragility of the system.

I’m now doing another project (more on that later), again using mod_python and psp. This time around however, I have a hack that gets around the absolute path problem. The solution looks like this:

# This file has only one function: to add directories to the path
# so we can import other python files/modules.

import sys

# Default directories to add to the path
_dirs = ["/src", "/lib"]
_applicationRoot = "sampleWebApp"

# Will go through the list and add the directories given relative to the
# lostafollower base path. Allows us to do paths relative to our installation
# instead of hard-coding absolute paths.
def addLibs( dirs ):

  # If [] was provided, just use the default.
  if not dirs:
    dirs = _dirs

  base = ""
  for entry in sys.path:
   if entry.find(_applicationRoot) != -1:
     base = entry
     break

  for dir in dirs:
    try:
      # Test if the path contains the path we want
      sys.path.index(base+dir)
    except:
      # The path doesn't already contain our path
      sys.path = sys.path+[base+dir]

The reason we normally can’t use relative paths when doing imports is because the mod_python handler considers the root (”/”) of the filesystem to be the current working directory of the application, regardless of where the application is actually running from. However, Apache will put whatever alias it has for your application’s directory [1] in the PYTHONPATH for mod_python, which is what allows us to do this hack. By finding the path that Apache has in the PYTHONPATH, we can add whatever paths we want relative to that. No .htaccess PythonPath directives, no hard coding of paths to your project’s module locations. Just:

1. Put the above code in a file (I call it pathHack.py) in your application’s root directory (root as far as Apache is concerned) [1]
2. import pathHack (or whatever you called it) in whichever file needs your other modules
3. Call pathHack.addLibs([]) to add the defaults (/path/to/sampleWebApp/lib, etc), or pathHack.addLibs(”/lib/3rdParty”) to add /path/to/sampleWebApp/lib/3rdParty to your path
4. import any python module in those newly added directories!

That is really it. Hard coded paths begone!

[1]

When I say “the alias it [Apache] has for your application’s directory,” what I mean is that even though, for example, my application runs out of /home/robertp/src/sampleApp/src, mod_python sees the root as being /home/robertp/src/sampleApp because of some unknown magic. It doesn’t really matter what the path is, in all honesty – when specifying a value for _applicationRoot in the solution code above, you are just looking for a string unique to the path to your application (just be sure to make all supplied paths relative from that base). Try just your project’s deployment folder for starters. If you are still having trouble finding it, create a quick psp file in the same folder as your other psp files, and do:

import sys
from mod_python import apache
req.write(str(sys.path))

That will just print out all the path elements to your browser window when visited. Pick out your application’s name or path from there, and set _applicationRoot to that. It isn’t completely ideal, but it is better than hard-coding ;)

Hacking: Lecture Two Follow-up

Yesterday I gave the second lecture in my “hacking” series. We’ve progressed beyond general descriptions and terminology and moved into the technical aspects of the stack, vulnerable code, and crafting exploits. The lecture ran about 45 minutes, and was accompanied by a live demonstration of exploiting vulnerable code.

For those that came late or missed it, the slides are available here (pdf format), although once again the real content was in the accompanying talk.

The demonstration used three source files. The shellcode was written by BreeZe of binbash.org, while the other two are my own. They are:

• The vulnerable sample program
• The shellcode
• The exploit code

Running the Exploit

First, I only tested the exploit running on Debian Linux, running a 2.6.23 kernel on a 32bit x86 machine. It probably won’t work on Windows or a Mac, and it definitely won’t run on your SPARC.

Second, I used version 3.3 of gcc’s compiler. Newer versions contain checks to make stack smashing harder, but 3.3 is free of any of these security features. You’ll have to use it when compiling these, which can be done by issuing gcc-3.3 -o <name> <name.c>, like:
gcc-3.3 -o exploit exploit.c

Third, Linux kernels after 2.6.12 do virtual address space randomization, which will prevent the exploit from running successfully after being compiled. To disable this, issue (as root):
sysctl -w kernel.randomize_va_space = 0

Fourth and finally, if you want to trigger a core dump in the vuln program, you have to lift any restrictions on dumping core files. Something like the following should work:
ulimit -c 100000

Note that the shellcode file is superfluous, I only included it as an example and guide.

Next Time

At this point, I’m not sure what I’ll be covering next week. There is a lot I could do – writing shellcode, showcase more advanced shellcode, demonstrate gaining a remote shell (remote exploitation is a whole other beast), secure coding, polymorphic and self-modifying shellcode… there are a lot of topics, and only one lecture left before the end of the series.

Regardless, it will be fun, and we’ll all learn a hell of a lot.

I’ll be at Barcamp Rochester 3 this Saturday in GCCIS, and more likely than not I’ll be talking about anything and everything computer security. If you have any questions anything or find something I’ve said interesting, hit me up! I’m friendly, and always up for talking about computer security :)

Reset BIOS Passwords – An Explanation and Tool

I’ve been seeing a lot of sites throwing around a “how to reset BIOS passwords” tip that revolve around using the DOS/Windows DEBUG tool. In case you haven’t seen it, it goes a little like this:

1. Create a boot floppy/disc with the debug tool on it
2. Type -o 70 2e
3. Type -o 71 FF
4. Type quit
5. Reboot

Curious as to why this works? So was I, but none of the sites I saw included an explanation. So after some googling, I uncovered the nitty-gritty details.

The CMOS memory is actually accessible to the user for reading and writing. I’m not aware of a recent operating system that doesn’t restrict write access to the administrator/super user, but it is there nontheless. It contains a lot of information, such as the system time (direct access to the real-time clock), BIOS information, and CMOS data. With this knowledge, I would suggest taking a look at this link, which is a reference to how the CMOS memory is laid out. It is what I used to determine what the hex values being output were doing.

The -o option of debug just outputs a value to an io port. The CMOS memory is accessed through ports 70 and 71, which explains the first parameter of the steps above. The second part can be seen from the CMOS reference I linked to above – by latching the address 0×2e for writing, and then setting its value to 0xff, we are manually telling the CMOS that it has an invalid checksum. The behavior when this occurs is to revert to the default BIOS, a feature which is supported independent of operating system or processor architecture – ie, any AT/ATX motherboard will do this.

None of the sites list instructions for if you are a Linux user, and assume you’ll have access to the debug program. So, now understanding how this specific utilization of debug worked, I wrote my own version in C. It can be compiled using gcc, and is compatible with all *nix distributions – so add it to your rescue LiveCD toolkit, you never know when you’ll need it :)

Here is the source:

resetBIOS.c

#include <stdio.h >
#include <stdlib.h>
#include <unistd.h>
#include <sys/io.h>

/* Written by Robert Peaslee - www.robertpeaslee.com */
/* compile: gcc -o resetBIOS resetBIOS.c */
/* Run as superuser. */

int main() {

  /* Allow writing to ports 70 and 71  */
  if( ioperm(0x70, 1, 1) || ioperm(0x71, 1, 1) ) {
    perror("Error setting write permissions");
    printf("\n");
    exit(1);
  }

  /* output 0x2e to port 70, which is the address where the
   * CMOS checksum is stored */
  outb(0x2e, 0x70);
  /* Small sleep to allow the changes to take effect. */
  usleep(100000);
  /* Tell the CMOS that the checksum is bad, forcing it to
   * load the default BIOS on reboot. */
  outb(0xff, 0x71);

  /* Reset the port permissions to not be writeable */
  if( ioperm(0x70, 3, 0)) {
    perror("Error restoring permissions");
    printf("\n");
    exit(2);
  }

  exit(0);

}

And if you only want the assembly specific portions without relying on external libraries:

out 70, 0x2e
out 71, 0xff

…but note you’ll have to add your own data/text sections and a main: entry point if you want to actually assemble it. Additionally, you’ll have to convert this to at&t syntax if you want to inline it in C code using the gcc compiler.

So there you have it – a full explanation of why it works, an example in C, and a complete reference of the layout of CMOS memory. If you still have questions, leave them in the comments!

AspectJ and Erasure Limitation

As previously mentioned in this blog, I’m taking a programming skills course focusing on Aspect Oriented Programming (AOP) using AspectJ. I am using eclipse with the AspectJ plugin to develop, and recently came across a situation where I wanted to define a pointcut based on an object that uses generics. In attempting to do so, I got the following error in eclipse:

parameterized types not supported for this and target pointcuts (erasure limitation)

While the error puzzled me momentarily, a quick hop over to the AspectJ developer notebook sorted things out. The full description of the solution is there if you want to read, but the quick fix is easy: remove the generic identifier of whatever you are trying to match against.

For example, this is incorrect:

pointcut badPointcut(): target( List<String> );

While this is the fixed version:

pointcut goodPointcut(): target( List );


Now get back to work :)

Converting a Relative Path to an Absolute Path in Bash

This really shouldn’t have taken me as long as it did to figure this out, but it was a big enough of an annoyance that I decided to share it.

How to convert a relative path to an absolute path in linux/unix/bash script:

#!/bin/bash

# Assume parameter passed in is a relative path to a directory.

# For brevity, we won't do argument type or length checking.

echo "Absolute path: `cd $1; pwd`"

For those unaware, you don’t have to ‘cd -’ because the backticks perform command substitution and don’t modify the working directory of the script.

EDIT: Anonymous poster ‘foo’ left a comment mentioning that this only works if the path destination already exists, which is indeed the case. This isn’t at all elegant, but it is the ‘two minute hack’ version I could immediately come up with. The result only works if you have permission to write where the path should go, meaning *yes,* there will be a version three of this script when I have more time:

#!/bin/bash
# Alright, this time we'll do parameter checking.

if [ $# -eq 0 ]; then
	echo "Usage: $0 "
	exit 1
fi

if [ -d $1 ]; then
	# Paramater is an existing directory. Print it using the method in the script above.
	echo "Absolute path: `cd $1; pwd`"

elif [[ -e $1 && ! -d $1 ]]; then
	# File already exists and isn't a directory. Be more safe with the conversion.
	mkdir $1$$ 2> /dev/null
	if[ $? -ne 0 ]; then
		echo "We cannot conver this path without write permissions to the path's destination."
		exit 1
	fi
	# I don't want to escape the quotes. This is already ugly, anyway.
	dirName=`cd $1$$; pwd | awk -F"$$" {'print $1'}`
	echo "Absolute path: $dirName"
	rm -r $1$$
else
	# File doesn't exist, begin unelegant conversion
	mkdir $1 2> /dev/null
	if [ $? -ne 0 ]; then
		echo "We cannot convert this path without write permissions to the path's destination."
		exit 1
	fi
	echo "Absolute path: `cd $1; pwd`"
	rm -r $1
fi

Secondary notes: I really wrote this on the spot in a couple minutes, directly into this blog post. It is untested, and very ugly. I promise to post something better soon!

HowTo: Use Multiple Addresses in Gmail Filters

Gmail has incredible filtering, and I forward most of my older addresses to it to take advantage of its spam filtering capabilities before pulling the messages down to my box. Another cool feature is having the ability to tag messages based on some criteria, such as based on who sent a message. The only thing lacking is the user interface for creating these filters, because it doesn’t make readily obvious how to incorporate multiple addresses into one filter.

I’ve incorporated the knowledge gleamed from a google search on the topic into a Ruby script that takes multiple addresses in and returns a filter string that will work with gmail filters. I hope someone else finds it useful! (download)

#!/usr/bin/ruby -w
#
# Gmail supports filters, but the interface provided doesn't make it appear
# to support filtering multiple addresses at the same time. It does,
# and given multiple addresses, this script will return a filter string
# that matches multiple sources.
#
# Author: Robert Peaslee
#

if $*.length < 3
        p "Usage: filters.rb   ..."
        exit( 1 )
end

case $*[0]
        when "from"
                # Get rid of first element
                $*.shift

                string = "from:("
                $*.each { |addr|
                        string << "#{addr}) OR from:("
                }
                string.slice!( -8, string.length )
                p "Copy this into the filter:"
                p "#{string}"
                exit( 0 )
        when "to"
                # Get rid of first element
                $*.shift

                string = "to:("
                $*.each { |addr|
                        string << "#{addr}) OR to:("
                }
                string.slice!( -8, string.length )

                p "Copy this into the filter:"
                p "#{string}"
                exit( 0 )
        else
                p "Please supply either from or to as the first argument."
                exit( 1 )
end

Finding iButton Adapters Quickly

The attendance database project I’ve recently written about requires the use of iButtons for verifying the physical presence of members at meetings. Having never worked with either the hardware other than as a user of it nor the software SDK in any capacity, it was a learning experience. One thing I quickly ran across when developing the software to locate a plugged-in adapter and read the iButton’s ID was the incredible amount of time it took to enumerate through the available ports just to find a connected adapter. The SDK provided examples on how to go about locating connected adapters, but to improve the speed at which it runs we can take advantage of what we know about the system and exploiting the code’s error conditions.

During installation of the 1-Wire drivers needed to communicate with iButton adapters, you have the option of selecting a default port to which the adapter will be connected. This information is stored as a property the SDK knows how to locate. The first step to increasing the speed of locating an adapter is to use this information – simply check the default port before searching all other ports on the machine. Odds are higher that the adapter is located on that port than any other port on the system, and by placing it as the first check before serially searching all other ports you increase your chances of getting on the first attempt.

The second enhancement requires a bit of background information. The example provided in the SDK shows you how to search all possible adapter types, then all possible ports for that adapter, and print them out. To be useful we would want instead of printing out the adapter and port names to attempt retrieving the device connected there. This would logically be done using the static getAdapter(String adapterName, String portName) method of the DSPortAdapter class. However, the time this method takes to return whether the adapter exists could be measured in seconds. To make this faster using our understanding of the system, we could skip over adapters we know we won’t be using (network adapters, parallel adapters, serial adapters, etc) and avoid scanning for them over all ports entirely. Reducing the size of the problem reduces the time it takes to come to a solution.

That is not all we can do, however. For some reason, if you try to retrieve an adapter using the getAdapter method and attempt to tell if it is successful by comparing the return object against null, it takes a long time. In comparison, the method throws an exception if it cannot locate the adapter much more quickly. Using this last bit of information, by putting a continue statement in your exception catching code you can just skip the attempt to open the obviously unavailable reader and enjoy a nice speed boost.

Here is some example code illustrating what I’ve talked about, excluding rolling over adapters we don’t care about. The speed of this is much faster than my first attempt, from taking around five minutes to locate an adapter to around 30 seconds. Base of code taken from the examples provided in the 1-Wire Java API. Sorry about the indenting, I gave up trying to figure out how to adjust the tabstop!

/**
 * Locate a reader to communicate with.
 *
 * @return boolean - true if adapter was found, false otherwise.
 */
public boolean locateAdapter( ) {
	boolean found = false;
	while( !found ) {
		try {
			DSPortAdapter adapter = OneWireAccessProvider.getDefaultAdapter();
			System.out.println(”Adapter ” + adapter.getAdapterName() +
						” found on port ” + adapter.getPortName());
			this.adapter = adapter;
			this.port = adapter.getPortName();
			found = true;
		} catch(Exception e) {
			System.out.println(”Adapter not found on default port, trying all ” +
					“available to the system…”);
		}
		if( !found ) {
			DSPortAdapter adapter;
			String port;
			// get the adapters
			for (Enumeration adapter_enum = (Enumeration) OneWireAccessProvider.enumerateAllAdapters();
				adapter_enum.hasMoreElements(); )
			{
				adapter = ( DSPortAdapter ) adapter_enum.nextElement();
				System.out.println(”Trying adapter ” + adapter.getAdapterName() );
				// get the ports
				for (Enumeration port_enum = adapter.getPortNames();
					port_enum.hasMoreElements(); )
				{
					port = ( String ) port_enum.nextElement();
					System.out.println(”trying port ” + port );
					try {
						OneWireAccessProvider.getAdapter(adapter.getAdapterName(), port);
						this.adapter = adapter;
						this.port = port;
						found = true;
					} catch( OneWireException owe ) {
						// Just continue…
						continue;
					}
				}
				if( found ) {
					break;
				}
			}
		}

		if( found ) {
			System.out.println(”Adapter found! Using ” + this.adapter.getAdapterName() +
					” on port ” + this.port );
		} else {
			// Wait 5 seconds before trying again
			try {
				Thread.sleep( 5000 );
			} catch (InterruptedException ie ) {}
		}
	}

	return found;
}

My Time With Facebook

Being one of the millions of Facebook users, I was pretty happy to hear that they opened up a restricted API for those interested in developing applications that interact with it. I found myself with a few hours one weekend, and came up with a simple application using the API to check if you have any Facebook messages. Normally I wouldn’t post a task like this because it was rather trivial, but I decided to anyway because I did it in what I think is a cool way.

First, the actual code to check the messages is written in PHP and hosted on my web server. It will refresh every five seconds and check if you have new messages, displaying an icon to open a new browser window to check the messages. It can be seen here. Notice that I’m much better at writing code than designing interfaces ;) If you are interested, I’m using the official Facebook PHP5 client as a base for the web portion of the application. Full source is here.

The second part of the final application is a program written in C#. It is a small window that fits the dimensions of the used part of that page, using the maximize button to switch between the messages pane and the login pane when required. Internet Explorer is embedded in the application to do the rendering, but is stripped down in terms of navigation and context menu usage. It is still possible to navigate outside of the intended area, but this is a limitation on how Facebook designed it’s login page. The source of the application can be obtained here (zip format) and the executable itself can be obtained here (zip format). The source was built using Visual Studio 2005 – you should be able to build it without complication.

But enough of the program specifics.

Web applications are nice for developers. They develop the application in one place, and the changes are immediate to all users of the software. Feature and security updates are completely transparent, and best of all, the users don’t have to worry about them. Developer liability goes down because users aren’t running around with out of date and possibly insecure versions of their application, and users are happy because they always have the latest version of the software – a win-win situation. Even better, developers don’t have to concern themselves with deciding which operating systems or platforms to develop their primary application for because it is all online. This opens the application to a huge market of people. On the down side, web applications aren’t as accessible to as many people. Most people understand how to click an icon and use a program, it takes a higher level of acceptance to understand, for example, that their web browser could be used to replace Excel. The obvious solution to this problem is what is exemplified in the small application I’ve written to do an overall meaningless task. Embedding a browser in an application allows developers to have a binary executable that the masses are comfortable with that navigates solely to a web application that the developers prefer to maintain. With proper design, the web application can be made to always look good within the client executable, and following some rules of development will prevent people escaping to other sites from within the application. Everyone is happy.

I might expand on the idea later. There are other ways this would be useful, and some other ideas I’d like to tack to the list of supporting reasons for this concept. We’ll see :) It should also be noted that these thoughts originally came out of talking with the very intelligent Mike Manzano in my time working as his intern at Topia Technologies. See Mike, I *was* listening!

Non-blocking Networking in Ruby

First, let me say that figuring out how to do Non-blocking IO in Ruby is a sparsely documented *pain in the ass.* Apparently non-blocking IO is only built into Ruby from version 1.8.4, and even then only through importing fcntl and fighting through making your socket object a non-blocking descriptor. New in 1.8.5 are non-blocking methods for common actions that will handle the descriptor handling for you, making things much nicer.

This all came about because I was writing a port knocking utility in Ruby because I got tired of studying for finals. If you want to see an example of a non-blocking socket connect, follow the code below. I’ll comment on it in a bit.

require 'socket'
include Socket::Constants

if $*.length   [port 2] ... [port N] \n"
    exit
end

for i in 1...$*.length
    s = Socket.new( AF_INET, SOCK_STREAM, 0 )
    sa = Socket.pack_sockaddr_in( $*[i], $*[0] )
    begin
    s.connect_nonblock( sa )
    rescue Errno::EINPROGRESS
    end
end

The first part of the code should be self-explanatory for anyone familiar with ruby. We just import the socket library, and include the constants from within so we don’t have to prepend Socket:: to all of our constants later. Following this immediately is an argument check – we want at least a hostname and one port to knock, but we can accept as many ports as the user can provide.

The second loop is the more interesting part. It starts off by creating a stream socket that expects a hostname or IP address as an endpoint. Then we create a socket address object containing the port ($*[i] = args[i]) and the hostname (contained in $*[0]). After the socket address has been created, we throw in the ‘begin’ statement so we can catch errors later on. Then comes the non-blocking connect call: the program execution will not wait for the socket to establish a connection before moving on, which is what we want when portknocking because no connection will be established when knocking. The rescue statement is so that we don’t get an error the next time the socket tries a connection. If we didn’t have it, ruby would complain that we already have a socket operation in progress and exit for us.

The script is simple, but this took a long time to figure out. I love ruby, but sometimes the documentation on niche areas of coding are a little weak. For other non-blocking IO procedures, look in the Ruby 1.8.5 core API: http://www.ruby-doc.org/stdlib