Monday, January 16, 2012

Really basic wireless survey with built-in linux tools

What channel should I use for my access point? It seems like I'm always asking this question as people start new access points in my neighbourhood. Some wireless access points can pick a channel automatically, but my experience with this has been pretty poor. I suspect the algorithm is too simplistic to be of any use. A naive implementation might pick the first channel that has no other APs on it, which could be a terrible choice if the strongest interference signal is on the adjacent channel.

Ideally you want to pick the channel that gives you the best signal-to-noise ratio, but where there are heaps of APs at varying strengths in different parts of the house the choice is non-obvious. Sadly there doesn't seem to be a FOSS wireless survey tool like Fluke AirMagnet, and while you can use kismet to collect signal strength data you will have to do some analysis of the data yourself (my wireless card also didn't play well with kismet).

I decided to optimise for one location - where I use the laptop the most. So I set my AP to channel 1 and:
sudo iwlist wlan0 scanning > ch1.txt
Rinse and repeat for all the other channels (setting the channel on my AP is quick, but this might be impractical if yours is slow, requires re-auth etc.). Then compare the signal strengths:
grep --before-context=4 "myessid" ch*.txt
Pick the channel with the highest quality number (best signal strength).

Root a TMobile MyTouch 4G (HTC Glacier) to install Cyanogen

This was my first time rooting an android phone. There are most probably better ways to do this, but here are my notes for better or worse. I followed these instructions, which were pretty good and I won't reproduce them, so consider this a diff. First install the jdk from the 'default-jdk' apt package.

Install the Android SDK, including the platform-tools component to get adb. If you try to use it without root you'll get a permissions error like this:
$ android-sdk-linux/platform-tools/adb devices
List of devices attached 
???????????? no permissions
Add this UDEV rule to /etc/udev/rules.d/51-android.rules. Note this gives all users write permissions:
SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"
Plug it back in:
$ android-sdk-linux/platform-tools/adb devices
List of devices attached 
Change the mode on the phone to 'charge-only', and unmount the SD card if it is mounted. This allows adb and subsequent rooting tools to access /sdcard. If you have it in disk drive mode you'll get errors like these from adb:
failed to copy 'Superuser.apk' to '/sdcard//Superuser.apk': Read-only file system
To do the cyangogen install you can use the 'ROM Manager' app by ClockworkMod, available in the android market.

Tuesday, January 10, 2012

Ubuntu system monitor in the taskbar post-unity (Natty and Oneiric)

With the unity changes from Natty onward, the traditional Ubuntu gnome taskbar disappeared to be replaced by a set of application panel indicators. I was used to seeing my machine vitals (cpu, network, load etc.) displayed using system monitor in the taskbar. I was pleased to see that this can still be achieved by installing the 'indicator-multiload' package.

Depending on the version you have, the autostart might not work. If it doesn't, just:
mkdir ~/.config/autostart
and toggle the 'autostart' checkbox under preferences.

Monday, January 9, 2012

Broken BCM4313 "ping: sendmsg: No buffer space available"

My Broadcom wireless card was broken on Ubuntu 11.10 Oneiric Ocelot. The card connected to my AP fine, but after a short time would barf. A ping to the AP would return a few successful replies followed by:
ping: sendmsg: No buffer space available

This is a known issue, and seems to affect quite a few people.

First I tried installing the proprietary broadcom driver from the 'broadcom-sta-common' package, but that was worse - it wouldn't even recognise the interface. I tried a whole bunch of later kernels and finally found one that worked: 3.1.8.

The ubuntu mainline kernel repo makes trying new kernels easy. Just download and install these debs:

Update: spoke too soon. This is still broken on 3.1.8 it just takes longer to manifest. I'm now also seeing a bunch of these messages:
kernel: [25244.951243] ieee80211 phy0: START: tid 1 is not agg'able

Update 2012-01-30: Now I'm also seeing lots of this:
ieee80211 phy0: brcms_c_prec_enq_head: No where to go, prec == 4
I'm going to up net.core.rmem and net.core.wmem as suggested in a comment, but that's really only treating the symptoms.

Update 2012-02-10: I realised that at some point I'd put my AP into 'high bandwidth' mode, presumably 802.11n, which worked really badly. I'm guessing that was because of the crowded 2.4GHz spectrum in my area and/or poor linux driver support. When I put it back to regular 802.11g it has been rock solid ever since.

Friday, January 6, 2012

Firewire and DMA attacks on OS X

I recently spent some time testing Firewire memory access on OS X to determine the current state of vulnerability to DMA attacks. There is a lot of prior art (Uwe Hermann has a good summary), and I was particularly interested in the claims of deficiencies in the DMA defences provided by Lion (Update: it looks like this was CVE-2011-3215 fixed in 10.7.2, which agrees with my findings).

To check for firewire and thunderbolt ports programmatically you can parse the output of system_profiler:
$ system_profiler SPFireWireDataType SPThunderboltDataType

    FireWire Bus:

      Maximum Speed: Up to 800 Mb/sec


    MacBook Pro:

      Vendor Name: Apple, Inc.
      Device Name: MacBook Pro
      UID: 0x0001000A19999900

I used two MacBookPros, one running 10.6.8 and one running 10.7.2 fully patched as at 2011-12-29. Hardware specs:
$ system_profiler SPHardwareDataType

Model Name: MacBook Pro
Model Identifier: MacBookPro8,2
Processor Name: Intel Core i7
Processor Speed: 2 GHz

I used the pyfw-20041111 module to do the DMA using dumpmem which reads 256MB from 0x10000000:

hexdump -C cfffffffffffffff-10000000-20000000.memdump

and I also tested using and the libforensic1394 libraries, with the same results.
python ./ 1024 f
SBP-2 not used, forcing 2048 byte pages.
[<forensic1394.device.Device object at 0xfffffffff>]
Attempting to access device 0: Apple Computer, Inc. Macintosh
Wrote file ramdump.bin.

Target 10.7.2, attacked from 10.6.8.

When targeting the 10.7.2 machine I could only access memory when the screen was unlocked, in all other scenarios I just received zeros. Note I tested with and without FileVault2 enabled, and the results were the same.

StatusDMA Capture Result
Logged in, not lockedCaptured
Logged in, locked0s
Login, log out, at login screen0s
System booted, not logged in0s
Switch user from fast user switching menu0s

The cleartext password for the logged in user can be trivially retrieved with:
strings memdump | grep --after-context=4 longname | grep --after-context=1 password

Target 10.6.8, attacked from 10.7.2.

10.6.8 is the complete opposite, capture is possible in all cases (note that there is a NVRAM setting that can be used to defend against this attack without requiring a firmware password).

StatusDMA Capture Result
Logged in, not lockedCaptured
Logged in, lockedCaptured
Login, log out, at login screenCaptured
System booted, not logged inCaptured
Switch user from fast user switching menuCaptured

Get cleartext password with:
strings memdump | grep --after-context=3 managedUser | grep --after-context=1 password

Inception and libforensic1394

Update 2013-01-29: I get regular questions about this tool, so I'm going to update this post to record my answers.

Carsten's tool inception, is talked about a lot. He has wrapped the libforensic1394 libraries with some convenience functions to make sure the firewire modules are loaded, and detect when a new firewire device is connected. He's made it a little easier to run this attack, although I'm surprised he went to the trouble of wrapping the library but didn't write the couple of extra lines to do the grep for the password string.

Despite the title of this video and its ominous soundtrack, inception does not attack via the thunderbolt interface directly (that would be interesting). You need a thunderbolt to firewire converter to use the tool since it's just using libforensic1394, which uses the IOKit firewire library, to read from a firewire device. And as stated above, assuming you have filevault2 enabled, it only works with the one fairly lame remaining attack scenario (user logged in, screen unlocked, attacker with physical access to the machine). To his credit Carsten has described a plausible attack, but if you're talking about physical access attacks I'd be more worried about Snare's bootkit.

OS X Open Firmware settings: use nvram security-mode to disable firewire DMA without a firmware password

First some background. OS X uses Open Firmware, which is similar to a PC's BIOS. The nvram utility can be used to manipulate Open Firmware settings stored in NVRAM. Print NVRAM settings with:
nvram -p

For firewire DMA the important setting is security-mode. Here is an explanation of the different nvram security modes:

The "none" mode effectively disables security. The "command" mode just restricts the commands that may be executed to "go" and "boot". Additionally, under the "command" mode, the "boot" command may not have any arguments--that is, it will only boot the device specified in the boot device variable; no other command may be entered or any settings changed unless the password is supplied. Moreover, this password protection feature also applies to booting up with the option key held down (which allows you to choose from available bootable volumes through a built-in graphical user interface). Finally, in "full" mode, the machine is completely prohibited from booting until the password is entered.

To set a firmware password (puppet recipe):
nvram security-password=mypass
nvram security-mode=command
Note that anyone with root can read the hex encoded password with nvram security-password. To remove the password ('none' is the default security mode):
nvram -d security-password
nvram security-mode=none
When a firmware password is set, Firewire DMA is disabled. This can be abused to disable firewire DMA without setting a password - just by setting security-mode to something other than 'none'. This works for example (and will take effect after a reboot):
nvram security-mode=NONE
This causes the firewire controller to put itself into secure mode:
OSString * securityModeProperty = OSDynamicCast( OSString, options->getProperty("security-mode") );
if( securityModeProperty != NULL && strncmp( "none", securityModeProperty->getCStringNoCopy(), 5 ) != 0 ) {
  // set security mode to secure/permanent
  mode = kIOFWSecurityModeSecurePermanent;

Gather OS X hardware and software information with system_profiler

system_profiler is a good way to gather lots of recon information about OS X hardware and software. Some examples
     system_profiler -detailLevel full
       Gives you absolutely everything

     system_profiler -listDataTypes
       Shows a list of the available data types.

     system_profiler SPSoftwareDataType SPNetworkDataType
       Generates a text report containing only software and network data.

     system_profiler SPThunderboltDataType SPFireWireDataType
       Just firewire and thunderbolt interfaces