This warning that “The Future” could arrive any day:

Important: In the future, individual application processes may not always share the same address space, so in general you should never attempt to access code or data in another process.

and this one is just precious:

Note: Because multitasking allows an operating system to attend to several different operations at the same time, these operations may appear to occur simultaneously on even a single-processor system, due to the speed of the processor.

You don’t say.

At the moment, it just contains a bare-bones language definition, a template for Ant tasks, and a couple of snippets. I’d like to keep improving it, and would welcome suggestions and modifications.

I’ll be setting up anonymous SVN access one of these days (yeah, right), but for the moment, you can download the bundle directly:

ScalaAWH.tmbundle.zip

Here is my .bashrc in all its glory.

And here is a typical prompt it produces:

The first little box there just displays the login information — whether I’m local or remote, and from which host. That’s handy if I’m bouncing between servers and have forgotten whether I’m connected to machine C via machine B, or directly from A, etc.

Also of interest there is an updated version of this MacOSXHints.com suggestion of mine, which lists available GNU screen sessions.

Some other little functions I use daily are pathappend, pathprepend, and try_export, which simply add a directory (if it exists) to the beginning or end of a given env variable, usually $PATH.

So, for example, I have these lines:

path_prepend $HOME/software/crossplatform/bin
try_export "/usr/local/java/java1.5" JAVA_HOME
try_export "/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/" JAVA_HOME

which I think makes for a much tidier way to conditionally set a variable depending on which platform I happen to be logged into. IMHO.

Anyway, enjoy.

The Textmate snippet system is a wonderful creation — simple, delightful, and helpful. Unfortunately, the templating system is not nearly so nice — just a Perl one-liner to substitute in some environment variables, and no snappy tab-tab autofill magic.

Then I ran across this great post by Henrik Nyh, in which he scrapes together a little Applescript to create a Textmate template as a snippet.

However, I found myself wanting both some templated boilerplate, with variable substitution, and some snippetized text below. This proved a little trickier than I first thought, since the Applescript inserts at the top of the document, and it would require a nasty keypress script to insert the snippet below.

So, I came up with a slightly modified version of Henrik’s system, which supports a template_in.txt file with the usual variable substitutions, as well as a snippet below.

The template script looks like this: if [[ ! -f "$TMNEWFILE" ]]; then TMYEAR=date +%Y \ TMDATE=date +%Y-%m-%d \ TMUSERNAME=niutil -readprop / /users/\$USER realname \ TMTEMPLATEOUTPUT=$(mktemp “/tmp/tmtemplate_XXXXXX”)

{ # Insert the template & snippet!
osascript "${TM_BUNDLE_SUPPORT}/load_snippet.scpt" "$TM_TEMPLATE_OUTPUT" "snippet.txt" 
} &>/dev/null &

fi

and the Applescript is modified to this: on run args set templateoutputfile to (item 1 of args) set snippet_file to (item 2 of args)

-- retrieve the template and snippet text
set existing_text to read (POSIX file (template_output_file)) as «class utf8»
set loaded_snippet to read (POSIX file (snippet_file)) as «class utf8»

-- insert both into the document
tell application "TextMate"
    insert existing_text
    insert loaded_snippet with as snippet
end tell

-- remove the temporary file
do shell script "rm \"" & template_output_file & "\""

end run

You can download Snipplate2 (AWH) here.

mdfind “kMDItemKind == ‘Application’” | perl -ne ‘chomp; print “\”$_\”\n” ‘ | xargs mdls -name kMDItemFSContentChangeDate -name kMDItemVersion -name kMDItemDisplayName -name kMDItemPath | perl -pe ’s/^\/.+/”-” x 20/e’

Sample output:

kMDItemDisplayName         = "MarsEdit.app"
kMDItemFSContentChangeDate = 2006-03-13 22:58:25 -0500
kMDItemPath                = "/Applications/3rdPartyApps/Write/MarsEdit.app"
kMDItemVersion             = "1.1.2"
--------------------
kMDItemDisplayName         = "OmniWeb.app"
kMDItemFSContentChangeDate = 2007-02-14 17:23:51 -0500
kMDItemPath                = "/Applications/3rdPartyApps/Connect/OmniWeb.app"
kMDItemVersion             = "5.5.4"
--------------------
kMDItemDisplayName         = "CandyBar.app"
kMDItemFSContentChangeDate = 2006-04-14 18:40:52 -0400
kMDItemPath                = "/Applications/3rdPartyApps/Tinker/prettify/CandyBar.app"
kMDItemVersion             = "2.6.1"
--------------------
kMDItemDisplayName         = "Vienna.app"
kMDItemFSContentChangeDate = 2007-01-27 13:38:17 -0500
kMDItemPath                = "/Applications/3rdPartyApps/Connect/Vienna.app"
kMDItemVersion             = "2.1.1.2109"

x="foo"
awk '{ print "'"$x"'" }'

That’s a ” followed by ‘ and then another “.

For the curious, the actual script was a one-liner for dumping out Mac OS X application version information:

for x in /Applications/*.app 
do mdls $x | awk -F \" '/kMDItemVersion/ { print "'"$(basename $x)"'", $2 }'
done

cheers.

Because the universe is propelled by an elaborate irony-generating engine, Apple released a 10.4.1 update addressing the flaw within hours of the publication of the article. (Hmmm, is that really ironic? Perhaps the engine also produces…)

It is still my aim to see Mithras himself appear in a major publication, i.e. one that has actual deadlines. I shall not resort to acts of violence or property destruction, fear not.

I’m often hunting around for machines to run jobs on, and so log into a bunch of different machines to find one well-suited to my task. So when I log into a machine, I often want to get a quick sense of its capabilities. I got tired of trying to remember that Solaris uses /usr/sbin/psrinfo, while Linux uses /proc/cpuinfo, and which lines to grep for in each. So I wrote this script.

I also find this script handy for my duties as part-time administrator; it helps me keep tabs on which machines we’ve upgraded to how much RAM, etc.

Example output — at home:

[11:14 AM mithras@powerbook: ~] machineinfo.pl cpucount=1 cpuspeedmhz=667 cputype=PowerMacintosh hostip=xxx.xx.245.99 hostmac=00:03:93:a3:95:c2 hostname=powerbook.school.edu os=Darwin osnotes=Mac OS X 10.4 (build 8A428) osversion=8.0.0 rammbytes=768

And on a work server:

08:17 PM mithras@server6: src] machineinfo.pl cpucount=4 cpuspeedmhz=3056 cputype=i686 hostip=xxx.xx.22.98 hostmac=00:0E:0C:31:59:CF hostname=server6.school.edu os=Linux osnotes=Red Hat Linux release 9 (Shrike) osversion=2.4.20-31.9.progeny.6smp ram_mbytes=2016

Here’s the script:

#!/usr/bin/perl -w
use strict;
 
#
# FILE: machine_info.pl
# AUTHOR: Mithras THe Prophet (mithras.the.prophet, which is a gmail account)
# DATE: June 2004
#
# This script runs on Linux, Solaris, and Mac OS X machines
#  to give you a quick rundown of the setup of the machine:
#  The processor type and speed, memory, disks, etc.
#  
# I find this useful when I've just logged into an unfamiliar machine
#  and want to get my bearings.
#
 
 
#
#
#---- settings
 
#-----
#
#
 
#
#----- globals
 my %info;
#--
#
 
 
#
# Step 0: Determine platform
#
my $PLATFORM;
{
 my $uname_s = `uname -s`;
 chomp $uname_s;
 my $uname_m = `uname -m`;
 chomp $uname_m;
 $uname_m =~ s/ /_/g;
 $PLATFORM=$uname_s . "-" . $uname_m;
 
# print STDERR "## machineinfo\n";
# print STDERR "##\n";
# print STDERR "## running on $PLATFORM\n";
# print STDERR "##\n";
}
 
#
# os
#
{
 my $uname_s = `uname -s`;
 chomp $uname_s;
 
 $info{'os'} = $uname_s;
}
 
 
 
#
# cpu_count
#
{
 my $cpu_num="1";
 if ( $info{'os'} eq "Darwin" )
 {
  my $command = '/usr/sbin/sysctl hw.ncpu | awk \'{print $2}\' ';
  $cpu_num = `$command`;
  chomp $cpu_num;
 }
 elsif ( $info{'os'} eq "Linux" )
 {
  my $command = 'awk \'/processor/ { max_num=$3 } END { print max_num " +1"} \' /proc/cpuinfo | bc ';
  $cpu_num = `$command`;
  chomp $cpu_num;
 }
 elsif ( $info{'os'} eq "SunOS" )
 {
  my $command = '/usr/sbin/psrinfo -v | perl -ne \' BEGIN { $count = 0 } if (/processor (\d+)/) { $count++ } END { print ($count) }\' ';
  $cpu_num = `$command`;
  chomp $cpu_num;
 }
 
 $info{'cpu_count'} = $cpu_num;
}
 
 
#
# cpu_speed_mhz
#
{
 my $cpu_speed="unknown";
 
 if ( $info{'os'} eq "Darwin" )
 {
  my $command = '/usr/sbin/sysctl hw.cpufrequency | awk \'{print $2 "/ 1000000"}\' | bc';
  $cpu_speed=`$command`;
  chomp $cpu_speed;
#  $cpu_speed .= " MHz";
 }
 elsif ( $info{'os'} eq "Linux" )
 {
  my $command = 'cat /proc/cpuinfo | perl -ne \'if (/cpu MHz\s+: (\d+)/) { print "$1\n" unless ($done); $done=1 } \' ';
  $cpu_speed=`$command`;
  chomp $cpu_speed;
#  $cpu_speed .= " MHz";
 }
 elsif ( $info{'os'} eq "SunOS" )
 {
  my $command = '/usr/sbin/psrinfo -v | perl -ne \'if (/(\d+) MHz/) { print "$1\n" unless ($done); $done=1 }\'  ';
  $cpu_speed=`$command`;
  chomp $cpu_speed;
#  $cpu_speed .= " MHz";
 }
 
 $info{'cpu_speed_mhz'} = $cpu_speed;
}
 
#
# config_cpu_type
#
{
 my $uname_m = `uname -m`;
 chomp $uname_m;
 $uname_m =~ s/ /_/g;
 
 $info{'cpu_type'} = $uname_m;
}
 
 
#
# hostname
#
{
 my $hostname=`hostname`;
 chomp $hostname;
 
 $info{'host_name'} = $hostname;
}
 
 
#
# host_ip
#
{
 my $dig_command="dig " . $info{'host_name'} . " | awk 'BEGIN { ans=0 } /;;/ { if (ans==1) { ans=0 } } /ANSWER SECTION/ { ans=1 } /" 
  . $info{'host_name'} . "/ { if (ans==1) { print \$5 } } '";
 my $ip = `$dig_command`;
 chomp $ip;
 
 $info{'host_ip'} = $ip; 
}
 
#
# host_mac
#
{
 my $mac = "unknown";
 if ( $info{'os'} eq "Darwin" )
 {
  my $command = '/sbin/ifconfig | perl -ne ' . "'" . 'if (/en0/) { $next = 1; } ; if (/ether\s+(.*)/) { if ($next==1) { print $1; $next=0; } }' . "'";
  $mac=`$command`
 }
 elsif ( $info{'os'} eq "Linux" )
 {
  my $command = '/sbin/ifconfig  | awk ' . "'" . '/eth0/ {print $5}' . "'";
  $mac=`$command`;
 }
 elsif ( $info{'os'} eq "SunOS" )
 {
  my $command = 'arp `hostname` | awk ' . "'" . '{print $4}' . "'";
  $mac=`$command`;
 }
 chomp $mac;
 $info{'host_mac'} = $mac;
}
#
# OS-version
#
{
 my $uname_r = `uname -r`;
 chomp $uname_r;
 
 $info{'os_version'} = $uname_r;
}
 
#
# OS-notes
#
{
 my $os_flavor="";
 if ($info{'os'} eq "Darwin")
 {
  if (-e '/usr/bin/sw_vers')
  {
   my $productName = `/usr/bin/sw_vers -productName`;
   chomp $productName;
   my $productVersion = `/usr/bin/sw_vers -productVersion`;
   chomp $productVersion;
   my $buildVersion = `/usr/bin/sw_vers -buildVersion`;
   chomp $buildVersion;
   $os_flavor = "$productName $productVersion (build $buildVersion)";
  }
 }
 elsif ($info{'os'} eq "Linux")
 {
  if (-f '/etc/redhat-release')
  {
   $os_flavor=`cat '/etc/redhat-release'`;
   chomp $os_flavor;
  }
  else
  {
   $os_flavor="unknown Linux distro";
  }
 }
 elsif ($info{'os'} eq "SunOS")
 {
  if (-f '/etc/release')
  {
   $os_flavor=`head -n 1 '/etc/release'`;
   chomp $os_flavor;
   $os_flavor =~ s/^\s+//;
  }
 }
 $info{'os_notes'} = $os_flavor;
}
 
#
# ram
#
{
 my $mem="unknown";
 if ($info{'os'} eq "Darwin")
 {
  my $command = 'sysctl hw.memsize | awk \'{print $2 " / (1024*1024)"}\' | bc';
  $mem = `$command`;
  chomp $mem;
#  $mem .= " MB";
 }
 elsif ( $info{'os'} eq "Linux" )
 {
  my $command = 'cat /proc/meminfo | perl -ne \'if (/Mem:\s+(\d+)/) { print int( $1 / (1024 * 1024) ) }\' ';
  $mem = `$command`;
  chomp $mem;
#  $mem .= " MB";
 }
 elsif ( $info{'os'} eq "SunOS" )
 {
  my $command = '/usr/local/bin/sysinfo -msglevel terse -show "memory"';
  $mem = `$command`;
  chomp $mem;
  if ($mem =~ m/(\d+) MB/) # chop out the ' MB' part
  {
   $mem = $1;
  }
 }
 $info{'ram_mbytes'} = $mem;
}
 
#########
# print out info
foreach my $key (sort keys %info)
{
 if ($key ne "")
 {
  my $value = $info{$key};
  print "$key=$value\n";
 }
}

When you have lots of gnu screen windows open, sometimes it’d be nice to run the same command on several of them — for example, cd several windows to the same directory, or ssh to the same server. I’ve always done this by copy-and-pasting, though there are some funky commands in screen for copying and pasting text between windows.

Now, thanks to the screen -X command and a short shell script, I can do this very easily.

I name the script screenex, and use it as follows:

[03:36 PM mithras@powerbook: ~] screenex 1 6 ls In windows 1 - 6, doing: ls

I simply pass the range of window numbers to run the command in, followed by the command itself. I can also omit the second number, to execute the command on just one other window:

[03:39 PM mithras@powerbook: ~] screenex 2 pine In windows 2 - 2, doing: pine

Neat! This becomes much more powerful, though, when you add substitution of the window number. When you include the token –INDEX– in the command, the window number is substituted for –INDEX–. I use this to launch ssh connections to six machines at once, which is handy when I’m running a bunch of jobs in parallel. At work we have a bunch of servers, named server1.school.edu, server2.school.edu, etc. So to connect to a different machine in each window, I just run:

[03:41 PM mithras@powerbook: ~] screenex 1 6 ssh server–INDEX–.school.edu In windows 1 - 6, doing: ssh server–INDEX–.school.edu

And I’m connected, ready to run my parallel jobs! You can also do cool stuff if you have environment variables that are indexed by number, for example WORKINGDIR1, WORKINGDIR2, etc. Anyway, I’ll save more for later.

The script:

(Note that the ^M character is a literal newline character, which you can enter in vi by typing ctrl-V, then enter.)

#!/bin/sh
#
# command to run the given command on multiple `GNU screen' windows
#  usage: screenex [begin-window] [end-window] command
# 
#  by Mithras The Prophet (mithras.the.prophet, which is a gmail account.)
# 
 
#
# returns 1 if arg is numeric, 0 otherwise
#
is_numeric()
{
	var="$1"
	if [ -z "$var" ]; then
		echo "0"
	else
		[ "$var" -eq 0 ] 2> /dev/null
		if [ $? -eq 0 -o $? -eq 1 ]; then 
			echo "1"
		else
			echo "0"
		fi
	fi
}
 
#
# if argument 1, or arguments 1 and 2 are numeric, then
#   we apply the command to just that range of windows;
#   otherwise, to all windows
#
mycommand=""
window_begin="1" # beginning of range of windows to send command to
window_end="6"  # and end
 
arg1="$1"
shift;
if [ -z "$arg1" ]; then
	exit;
fi
if [ $(is_numeric "$arg1") -eq 1 ]; then
	# this is beginning of range
	window_begin="$arg1"
 
	# try to grab a second numeric arg?
	arg2="$1"
	shift;
	if [ $(is_numeric "$arg2") -eq 1 ]; then
		# we have a second number!
		window_end="$arg2"
		# get start of command
		arg3="$1"
		shift;
		mycommand="$arg3"
	else
		# ahve second arg, but not a number
		# so it must be start of command
		window_end="$window_begin" # just do the one window
		mycommand="$arg2"
	fi
else
	# arg1 -not- numeric, 
	# so it must be start of command
	mycommand="$arg1"
fi
 
while [ ! -z "$1" ]
do
	mycommand="$mycommand \"$1\"" # rest of line
	shift
done
echo "In windows $window_begin - $window_end, doing: $mycommand"
 
#
# now execute!
#
newline=<<EOQ
 
EOQ
let "window_end = $window_end + 1" # so we can do strict -lt test
index="$window_begin"
while [ $index -lt $window_end ]
do
	thiscommand=${mycommand//--INDEX--/$index}
	screen -X at ${index}# stuff "${thiscommand}
"
	let "index = $index + 1"
done

Safari / Dashboard vulnerability in OS X 10.4

This page discusses a security flaw resulting from a series of bad design choices in Safari and Dashboard in OS X 10.4, and links to a demonstration exploit.

You can make your machine safe by unchecking the “automatically open `safe’ files” option in Safari:

*Update: Mac OS X 10.4.1 fixes this vulnerability, by changing Safari to present a dialog when downloading all widgets. Kudos to Apple for their speedy response to the issue. * Updated May 10 with a new, simpler, more deadly exploit.

1. Widget Auto-Install

Safari 2.0 in Mac OS X 10.4 Tiger has a dangerous new “feature”. By default, when asked to download a .zipped Dashboard widget, Safari not only unzips the widget, but also copies the widget into ~/Library/Widgets, and adds it to your Dashboard Bar. As first pointed out by Stephan.com, Safari does this not only for widgets you explicitly click on, but also for widgets that are silently, automatically downloaded by a web page’s META refresh tag. So a malicious website can auto-install potentially malicious widgets without you even realizing the installation happened.

This is the rough equivalent of automatically installing auto-downloaded applications into the /Applications/ folder, and putting them on the Dock.

2. The Evil Twin

Apple’s second major mistake in Dashboard is in how widgets are loaded.

First, it is important to emphasize that the auto-installed widgets do not execute automatically. It remains a `social engineering’ task for a malicious attacker to get you to launch with widget by dragging it from your Dashboard Bar.

However, this is aided by Apple’s second incredibly bad design decision. Widgets are identified by a `bundle identifier’, such as com.apple.widget.stickies. When Dashboard encounters two or more widgets with the same bundle identifier, it only displays the last one loaded. And — you guessed it — widgets in ~/Library/Widgets are loaded after the system-supplied widgets in /Library/Widgets.

This means that our malicious widget can completely replace an Apple-supplied widget. Your ordinary Stickies widget simply will not appear in the Dashboard Bar — but in its place, silently installed by Safari, is a malicious widget.

For example, here is the Dashboard Bar before visiting a malicious web page:

And here it is afterwards:

Can you tell the difference? If you can’t, and try to create a new Sticky note…

…you have just launched a malicious program.

Note: It appears that an additional, unrelated bug in Dashboard may actually be a saving grace here. After ~/Library/Widgets has been updated, Dashboard sometimes garbles the contents of the Dashboard Bar, so when you try to drag a widget from the Bar, you get no widget, or an entirely different widget. Scrolling between pages of the bar resolves the issue. Nonetheless, your original safe Stickies is now gone, with a malicious one in its place.

3. The Sandbox That Isn’t

And now we come to Apple’s third major mistake. Apple went to great lengths to develop a security model for Dashboard widgets. By default, Widgets do not have access to local files, your network connection, or the ability to run native code, other than opening applicications and web pages.

Widgets can request additional privileges, including the ability to run arbitrary shell commands with the widget.system() call. The first time you double-click to run a widget that requests extra privileges, in most cases Dashboard presents an `are you sure?’ prompt before allowing it to run.

Ought to appear, but does not.

However — incredibly, amazingly, stupidly — Dashboard does not present a prompt before running a privileged widget that is one of the Library/Widgets folders, including our auto-installed widgets. So now your auto-installed replacement look-alike widget has complete access to your system, and could do nasty things like delete your home folder.

If a widget contains a native Mach-O executable, Safari will present a warning before downloading the widget. However, because widgets in ~/Library/Widgets can run shell commands with the widget.system() call, this protection is easily defeated. The demonstration exploit below includes a native Mach-O application with its bits reversed, so Safari does not realize it’s an application. A call to a Perl script unreverses the bits and makes the file executable, allowing full native code to be run.

Or, in a self-propagating attack, the widget could start a user-level Apache (on a user-accessible port like 8080), and email everyone in your addressbook with the URL to visit. They need only click on the URL to install the widget on their own Macs running Tiger, etc. etc.

4. Privilege Escalation

Our malicious widget has all of the capabilities of an ordinary application launched by your user. This is bad enough, but it could also take advantage of privilege escalation vulnerabilities to run as root, where the damage could be more widespread. If the widget acquired root it could, for example, start Apache for you and proceed as described above in the self-propagation.

One such privilege escalation that is known to work on Tiger is this sudo-piggyback method, in which the widget waits silently in the background for an admin user to run sudo, then piggy-backs onto the sudo grace period and acquires root. I’m sure there are a few other buffer-overflow vulnerabilities lying around.

Demonstration Exploit

I have received feedback that due to an unrelated Dashboard bug, you might have to scroll the Dashboard Bar once or twice before you can drag new widgets from it.

None of these widgets does anything actually malicious. (My school would kill me if I were distributing malware from their servers

To get rid of the evil Stickies' widget, simply go to ~/Library/Widgets, and delete the widget namedStickies.wdgt’. It will be gone — and the normal Apple widget back again — the next time you invoke the Dashboard.

If and only if you understand those removal instructions, you may now try the example exploit:

exploit.html

I’d appreciate feedback on how these widgets behaved on your system. Did the Stickies widget require confirmation to run? Did the widget displace the Apple one from your Dashboard Bar?

Please write with comments to mithras.the.prophet@gmail.com. Thanks.