Rants by Chort
What's wrong with everything

Ready for a shocker? A lot of the things your IT/Security department makes you do are stupid. According to Microsoft researcher Cormac Herley quoted in The Boston Globe, many "common sense" security practices are economically unwise. In plain English: You lose more money following a lot of security recommendations than you would by just letting the bad thing happen and dealing with the aftermath.

To continue, flip over the keyboard and read the sticky note...

Read the rest of this story...

As many people know, Apple introduced Parental Controls in Tiger. The current version in Snow Leopard allows administrators to block potentially inappropriate content, specific sites, and access to unapproved applications.

The first two work more or less how you would expect (although the error message when a site is blocked for content has been bewildering in my experience), but the application ACLs are a disaster. They prevent the application from being run if it's not approved for that user (in fact, with Simple Finder enabled you can't even see it), but it's when you try to allow a restricted user to access an application that the fun starts.

I haven't examined it in depth, but it appears that OS X adds some kind of wrapper or extended attribute to an application when you enabled a restricted user to run it. The problem is that this extra layer is extremely invasive, and most of the apps I've tried to use it with simply crash. Not only do the crash for the restricted user, but they also crash for unrestricted users. It's demonstrably the Parental Controls that cause this problem, because if you Trash the app and reinstall it, leaving Parental Controls alone, the app will run fine for unrestricted users.

Parental Controls have been around since Tiger, and this problem existed for sure in Leopard (possibly Tiger, I forget when I started using the feature) and definitely still exists in Snow Leopard. So I have a simple question for Apple: Did you bother to QA this feature at all? I know I've submitted the automated reports at least a few times after OS X detected an app crash and it does include audit trail information showing that Parental Control attributes were changed for the app prior to it crashing.

Today is has yielded a bumper-crop of FAIL from various organizations out there. Here is a sampling of the head-scratching stupidity.

Read the rest of this story...

Apple's operating system has long been considered a refuge for those sick of viruses and malware that plague Windows systems, but this reputation for safety has been widely misinterpreted to mean the design is safe. In fact, as has been widely recognized in the security community, it's the relative rarity of Apple machines on networks that simply makes them an economically uninteresting target.

Apple for their part have enthusiastically encouraged this misconception, and while they've benefited from the positive PR, they haven't actually taken the concept of safety to heart. Much like the corporation in Redmond that they delight so much in mocking, they seem determined to ignore security issues until they affect public perception.

Read on for the ownage ->

Read the rest of this story...

It took nearly 7 hours, that's right SEVEN HOURS to build the GIMP.app port (on a 2.33GHz C2D w/4GB RAM), which inexplicably included a full build of gcc4.3. Is that reeeeeeeeeeally necessary when 4.2.1 is included with Xcode? Did those 5 hours of my life have to be wasted? WHY WAS IT YOU COULDN'T JUST UPGRADE PERL???

That's not even the best part. The best part is it got all the way to the gimp-app port itself (after going through a quarter of a day worth of dependencies), and it failed. Yes, apparently there were incompatible functions, which were found three months ago! Diffs were uploaded 3 weeks ago, and 9 days ago instructions were posted for manually applying them, yet today the port was still broken when I tried to install it. Outstanding. Really nice work guys, seriously. Three months?

In case my warning didn't come in time and you actually tried to build this abomination, you need to go here for the solution. If you're even thinking about trying to install gimp-aDON't! There, it's like I just bought you enough time to say goodbye to half a dozen more relatives on your deathbed.

I've been a long-time user of MacPorts, from back when it was Darwin Ports and I was still using a PowerBook, in fact.

The "upgrade" for Snow Leopard is making me seriously think about looking for alternatives. Originally their site said it might be possible to use the usual selfupdate method, or to be safe do a total uninstall/reinstall. As I've been using it for years and have piles of software installed through MacPorts I didn't exactly want to blow that all away and start over, so I tried the selfupdate method.

It "mostly" worked, with several broken packages that I forced a rebuild on. Today I found one I couldn't work around: PERL. I found bug reports for it on the MacPorts site and their solution was great: rm -rf and start over. Well, that's fun! Couldn't be bothered to roll a PERL rebuild into the update script, huh?

I dutifully generated a list of all my installed packages, backed up all the existing files to an external drive, and did the rm -rf plunge...

Read the rest of this story...

A while back I noticed Cyveillance, Inc were aggressively spidering my site. I found quite a few other references on the web to their anti-social behavior, including links to the recording industry's heavy-handed and borderline illegal tactics. In order to block them from my network, I compiled a list of their IPs.

It's been some time since I've actively monitored my firewall and over time the list had grown stale. I'd also previously been stymied on doing more research by my inability to figure out the nuances of some RWHOIS systems. Happily I made a breakthrough this week and I've been able to update my list, which I'll share for the good of humanity. The link above has the same list.

# Cyveillance @ Cogent
38.99.209.176/30
38.100.3.128/28
38.100.19.8/29
38.100.21.0/24
38.100.41.64/26
38.104.29.36/30
38.104.29.156/30
38.105.71.0/25
38.105.83.0/27
38.105.109.168/29
38.105.109.192/29
38.112.21.140/30
38.118.25.56/29
38.118.42.32/29

# Cyveillance @ Verizon (incomplete?)
65.213.208.128/27
65.222.176.96/27
65.222.185.72/29

# Previous(?) Cyveillance IPs
#63.146.13.64/27
#63.148.99.224/27
#63.213.208.128/27
#65.118.41.192/27

I'll try to update the text file over time to match current reality as best I can, but this blog post will go stale. I'm only putting the IPs here for spiders to find. If you want to use the list on your firewall, download the linked version. The list is admittedly incomplete since I haven't been able to reliably query Verizon for IPs (let alone other possible providers).

Updated 2010-03-28 to add 65.213.208.128/27, which came to me via a comment. Thanks for the tip!

While doing some research last night I finally figured out how to query a WHOIS server for all netblocks owned by a particular organization. For example, to find all netblocks owned by OrgID: NOC, do the following:

$ whois -a '> o !NOC'

In this case I'm using BSD whois, so the '-a' means "search ARIN". The other options are for the server. ARIN's WHOIS server interprets '>' as "show subordinate entries", the 'o' as "query for organizations", and the '!' as "search for handle or ID".

You should get output that starts like:

Resources Used By Organization:
Network Operations Center Inc. (AS21788) NOC 21788
[additional lines removed]

Linux users will need to adjust the flags passed to whois.

You can often get help from a specific WHOIS server by querying for '?'. This needs to be protected from your shell, so either backslash escape it, or wrap it in single-quotes. To get help from ARIN's WHOIS server do this:

$ whois -a \?

Final note: BSD whois doesn't appear to have a flag to force the RWHOIS protocol and different OSs have widely different ideas of what WHOIS ports are "well-known". For instance, OpenBSD has WHOIS and nothing else, while OS X has WHOIS++ and RWHOIS, but not WHOIS. FYI these are the ports:

whois           43/tcp          nicname
whois++          63/udp     # whois++
whois++          63/tcp     # whois++
rwhois          4321/udp    # Remote Who Is
rwhois          4321/tcp    # Remote Who Is

You can specify the port with the '-p' flag on BSD whois.

I've been noticing that since I put up this blog I've been getting scans for common PHP files/site layouts. This is interesting because my main site hasn't been scanned for them at all during the same time period.

I also noticed that the majority of the spider traffic to my blog is from Baidu, in contrast with the rest of my site.

I had forgotten how fun it is to scan my webserver logs for patterns.

One of my current projects at work is to create a pre-packaged virtual appliance that potential customers can install in their VMware virtualization environment to benchmark host performance and report it back to us. The data is used to make sizing and resource allocation recommendations for virtual deployments of our product. The issue I'm stuck on is reporting the data.

Obviously the preferred method would be a phone-home capability that simply ships the data directly from the VM to one of our servers, without the end-user having to do anything. The problem is that a lot of network operators (wisely) block outgoing connections by default. This is compounded by the fact that the appliance automatically gives itself an IP address via DHCP (to make installation easier), which means firewall exceptions are a non-starter.

Since phoning home via SMTP or HTTP probably won't even hit 70% success rate, I decided to not bother wasting time on those. The next idea was to write to a virtual floppy device, which is saved in the datastore as a .FLP file and could easily be downloaded by the end-user and e-mailed to us. A far-fetched idea (thought of by myself and another engineer on my team completely independently) is to use specially formatted DNS queries--á la Dan Kaminsky--to feed base64 encoded data to our server (since DNS queries are much more likely to be allowed though the firewall than say, SMTP connections).

It turns out that VMware Studio apparently cannot create virtual appliances with virtual floppy drives, even if you use the command-line tools (if that's wrong, please e-mail me--the documentation doesn't seem to indicate how to do it).

My next idea was to create an additional, very small, hard disk drive and write the output to that. This actually works in practice, but it's very cumbersome to retrieve data from. We need to import the returned .vmdk to one of our VMs, which then needs to be power-cycled so it can mount the disk and retrieve the data. I went looking for easier solutions for mounting .vmdk files and found references to a VMware Disk Mount Utility, but unfortunately the most recent version was shipped with Workstation 5.5 and appears to not read virtual hardware rev 4 .vmdk files created with ESX(i).

I then found signs pointing to the VMDKmounter utility on Mac OS X, which excited me quite a lot since I use a Mac and this would make the data retrieval trivially easy. Unfortunately this utility relies on MacFUSE, which has not yet been updated to handle 64-bit kernels. I'm running OS 10.6.2 with a 64-bit kernel. Damn.

This basically means my best option for grabbing a plain text file off a .vmdk is to import it to a VM and reboot. WTF? There has to be an easier way to do this.

• Comments (0)
• Tags:   vmware   there should be an app