Everything that comes out of Dossy, from the strange to the banal.
In order to get afacli working on Ubuntu Hardy, I did these things:
1. Get afa-apps-snmp.2807420-A04.tar.gz from Dell.
2. Get libstdc++2.10-glibc2.2 from Debian afacli depends on libstdc++-libc6.2-2.so.3.
Since I’m running Ubuntu x86_64, I put libstdc++-libc6.2-2.so.3 in /usr/lib32. Installing the rpm package under Ubuntu provides rpm2cpio which I used to extract afaapps-4.1-0.i386.rpm like this:
$ rpm2cpio afaapps-4.1-0.i386.rpm | (cd / && cpio -iudvm)
That’s it. You now have /usr/sbin/afacli.
Last week, I decided to take a stab at implementing a basic OAuth consumer in order to integrate Twitter Karma with Twitter using OAuth. I’d read through the OAuth 1.0 specification before, but never closely enough to realize that there was a serious attack vector in it. So, I mentioned this on the twitter-development-talk mailing list, hoping to get some answers on April 16th:
Also, the redirect to the callback URL has no signature. What stops an attacker from brute-force attacking an OAuth consumer, iterating through posisble tokens? Simply the large search space of valid OAuth tokens? Even if it’s only “possible in theory” … some teenager with nothing better to do is going to eventually turn that theory into practice.
My concern was met with confusion so I brought the concern to the OAuth mailing list (also) on April 17th:
Currently, the OAuth callback URL is susceptible to replay attack and token shooting. Signing it would eliminate this in a very low-effort way.
…
[…] it’s very desirable to be able to tell if the callback was legitimate or either a replay attack or a brute-force token shooting attack.
Even client-side browser cookies may not win here if a simple session fixation attack is coupled with the token shooting attack.
I wasn’t sure if I was being understood, either, but then a few days later on April 20th, Twitter yanked their OAuth support offline.
Eventually, an OAuth security advisory 2009-1 was published on April 23rd that clearly states “A modified specification to address this issue is forthcoming” as I pointed out was necessary, and Eran Hammer-Lahav writes a thorough explanation of the problem in his blog. The money quote:
If we put it all together, even if an application:
- Makes sure to use the account of the user coming back from the callback and not that of the one who started
- Checks that the user who starts the process is the same as the one who finishes it
- Uses an immutable callback set at registration
It is still exposed to a timing attack trying to slide in between the victim authorizing access and his browser making the redirection call. There is simply no way to know that the person who authorizes is the same person coming back. None whatsoever.
This is exactly why the callback URL that the OAuth provider uses to redirect the user back to the OAuth consumer needs to be signed.
So, why am I making a big deal out of all of this? Well, I’m irked. Coincidentally, their “discovery” of this issue conveniently coincided with my raising of the issue publically on the mailing lists, yet nowhere is my name mentioned in any of this. In my opinion, that’s really poor form in an “open community” where often the only compensation for effort is recognition. It’s this kind of back-handed treatment that encourages people to demonstrate these security concerns through actual working exploits, which benefits no one but guarantees the creator their recognition.
In the end, I’m glad that this issue is going to be addressed and hopefully in a timely fashion because all of us developing applications in the public software ecosystem will benefit, but I still feel slighted. I’ll get over it, while I wait for the OAuth 1.1 specification.
Are you a student that meets Google’s eligibility criteria, who is interested in contributing to an Open Source project this summer? Google’s Summer of Code 2009 is on, and once again, the Tcl community has been accepted as a mentoring organization, which includes AOLserver.
Students can apply until the deadline of 19:00 UTC on April 3rd. If you have any questions about GSoC or AOLserver’s involvement in it, please ask me! I’ll try to help answer whatever questions you might have.
Good luck to all the students and mentoring organizations this summer!
Tags: Google Summer of Code 2009, Tcl, AOLserver, open source
I make extensive use of Google throughout the day and I’ve always got “g” set up as the keyword for a Quick Search in Firefox. However, I also spend a lot of time at shell prompts, and sometimes I don’t want to bounce to a browser just to Google for something.
So, tonight, I wrote a small Tcl script that lets me “google for” at the prompt. Just save the previous link and rename it to “google” and move it somewhere in your PATH like /usr/local/bin, then make it executable with chmod 755.
The script requires Tcl with tDOM installed, as well as Tidy–both of these things are installed out-of-the-box on MacOS X 10.5 Leopard.
Once you get the script installed, you can do something like this:
If you notice, for Google search queries that have a special result like the one above, the script displays it separately before the results. The script also emits the search query URL so you can just Control-click on it in Terminal and then select “Open URL” and have it pop up in your browser, which also works for any of the search result URLs.
I don’t know if anyone else would find this script useful, but it’s already saved me a ton of time–especially when I’m on a slow 64 kb/s GPRS connection like I am this evening. Either way, I’m releasing this script into the public domain.
Tags: Google, Tcl, open source
Apparently, South African Airways runs some kind of Linux for their in-flight entertainment system.
Of course, on the leg of the trip from New York to Senegal, the flight staff kept rebooting the system trying to get it to work, with very little luck. Most of the time we just stared at the Linux boot process hanging, trying to talk to the NFS server. Fortunately, they got it working for the Senegal to South Africa leg of the trip.
Tags: South African Airways, Linux, fail
So, I have a TiVo Series 2 stand-alone DVR with a Product Lifetime subscription. For years, I’ve had it connected to the home network using a Linksys WUSB11 wireless network adapter, but it finally died. I went and grabbed a Linksys WUSB54G as a replacement, but found out that the TiVo doesn’t support it. No problem, I know the TiVo runs Linux and there’s plenty of documentation on how to “hack” the TiVo so I can load my own kernel modules on it, etc.
It turns out that the Linksys WUSB54G v4 uses the Ralink 2570 chipset. Fortunately, there’s been effort on native Linux drivers for the Ralink family of wireless chipsets. The hurdle, of course, is that the TiVo’s MIPS R5432 is big-endian, so it presents a bit of a challenge porting the driver to the TiVo.
Working off the latest code for the legacy rt2570 driver from CVS, I’ve gotten it to compile using TiVo’s Linux 2.4.20 kernel. Loading the module, however, results in this:
rt2570: init usb.c: registered new driver rt2570 rt2570: idVendor = 0x13b1, idProduct = 0xd rt2570: idVendor = 0x13b1, idProduct = 0xd rt2570: using permanent MAC addr rt2570: Active MAC addr: 00:12:17:89:f5:02. rt2570: driver version 1.0.0 Unaligned Access to 0x80230b2b in kernel mode at 0xc0217be4 Unaligned Access to 0x80230b2d in kernel mode at 0xc0217c04 Unaligned Access to 0x80357076 in kernel mode at 0xc021b3dc Unaligned Access to 0x80357076 in kernel mode at 0xc021b408 Unaligned Access to 0x80357076 in kernel mode at 0xc021dc2c Unaligned Access to 0x80357076 in kernel mode at 0xc021dc08 Unaligned Access to 0x80357076 in kernel mode at 0xc021cd8c Unaligned Access to 0x80230f47 in kernel mode at 0xc0217be4 Unaligned Access to 0x80230f49 in kernel mode at 0xc0217c04 Unaligned Access to 0x80231155 in kernel mode at 0xc0217be4 Unaligned Access to 0x80231157 in kernel mode at 0xc0217c04
So, now I get to go fishing through /proc/ksyms and try to fix up all these unaligned access errors. Hopefully, I’ll be able to get through all of this and get the driver working.
Anyone out there have experience porting Linux device drivers like this? Got any tips or techniques that might help me? I’d really love any help I can get …
Update: I’m posting my debugging progress in a rt2x00 forum thread. Given enough eyeballs, all bugs are shallow, right?
Update: I’ve gotten it working! I’ve addressed the majority of the unaligned access traps and I can now use my WUSB54G as a wireless NIC on my TiVo! Here’s a patch against rt2570-cvs-2008102616 of the driver and the corresponding kernel module binary:
If you have a SA2 TiVo and want to use a Linksys WUSB54G as your wireless NIC, this driver is what you want. It works for me, anyway!
Tags: Linux, TiVo, open source, hacking, Linksys WUSB54G, Ralink 2570
So, the AOLserver.com site, which has been hosted at SourceForge for years, is effectively “down” right now as requests to it are returning a “Error establishing a database connection” error. I’ve been a paying subscriber for SourceForge since 2004 because they claim to provide “priority support”–whatever that means.
Well, I went and opened “priority” support tickets to try and get the AOLserver.com site back online. To put it gently, the response I received was less than useful. I mean, three hours before I get a response–a canned response–which doesn’t even resolve my problem?
I recognize there’s not much I can do at this point, but what I can do is “vote with my wallet” … I’ve cancelled my SourceForge subscription today:
The clock is now ticking: they have just under a year to show that they can seriously run a valuable service correctly, or I won’t be renewing my subscription next year.
Update: Jacob Moorman, Director of Operations at SourceForge.net, emailed me to point out that the IP addresses for SourceForge’s VHOST had changed. Sadly, the DNS for aolserver.{com,net,org} had been set up as A records instead of as CNAME records. :-( So, I’ve sent a request to have the DNS updated.
Tags: SourceForge, subscription, cancelled
In replacing my aging Dell C840 laptop with a new MacBook Pro, I need to switch from using Pidgin to using Adium for IM. Since they’re both based on libpurple underneath, I figured there ought to be a way to migrate my settings from one to the other. As it turns out, it might be possible.
Your libpurple settings are stored in %USERPROFILE%\Application Data\.purple on Windows. Similarly, they’re stored in ~/Library/Application Support/Adium 2.0/Users/Default/libpurple on OSX. If you simply replace the blist.xml and accounts.xml that Adium creates with the ones from Pidgin, that should work, right?
Wrong!
Adium’s preferences are stored in plist format which, can now be easily edited since 10.5 (Leopard), even through AppleScript. Luckily, there’s even a simple utility called plutil that can convert from XML to binary plist format.
It would be pretty straight-forward to write a simple script that parses the libpurple XML and wrote out the appropriate plist XML then use the plutil tool to convert to plist binary format – but, I’m feeling lazy and only have about 10 accounts to migrate, so I’ll just do it by hand. Of course, there’s more to migrate than just accounts (old chat logs, etc.) but it’s not enough to overcome the inertia of my lack of caring to do it right now.
… or, “Everything old is new again!“
Yesterday, Google announced Protocol Buffers, their data interchange format and API libraries. Before I say anything else, I want to say I’m glad they did it: it uses neither XML nor ASN.1, which means someone at Google has a clue.
What bothers me is that yet again, what was old is new again–their on-the-wire encoding of the data is simply TLV and AOL has been using SNAC/TLV for at least 15 years now. However, AOL’s SNAC/TLV covers a lot more use cases than what Protocol Buffers does. Then, there’s AOL’s FLAP transport for SNAC which Google hasn’t even approached. There’s still a lot more “work” that Google has to do–or, just use what AOL’s already proven works.
Of course, Google gets the community pat-on-the-back because they released this publically whereas AOL still has it hidden behind some proprietary lock and key. AOL, this is another technology opportunity missed: you could have continued to keep your internal, proprietary technology relevant if you’d simply opened this stuff up, first. Now, you’ll have to continue to replace it–at a huge sunk cost–with “standards-based implementations.” Oops.
In the end, I’m glad to finally see someone not blindly drinking the XML Kool-Aid. Maybe there’s hope, yet.
As part of the Gnash buildbot farm, I run several virtual machines as build slaves. I started with VirtualBox because it is free software and I prefer to support free software, but it’s still a bit too fragile and it still lacks x86_64 guest support.
When I discovered that VMware Server is now available for free–well, free as in beer, anyway–I happily installed it and set up some new VMs on it. Best of all, it supports x86_64 guests! Of course, now I have the problem of migrating those VirtualBox guest VMs over to VMware.
VMware uses its own VMDK format for storing virtual disk images, while VirtualBox uses its own VDI format. The first step is getting a copy of vditool, VirtualBox’s command line program for manipulating VDI files.
The host OS I used to run VirtualBox is Ubuntu‘s 8.04 Hardy Heron on AMD64. The VirtualBox 1.6.0 .deb package didn’t include vditool, for some reason. Fortunately, the VirtualBox package in Debian’s “lenny” release includes it, so lets just grab it from there.
$ wget http://http.us.debian.org/debian/pool/main/v/virtualbox-ose/virtualbox-ose_1.5.6-dfsg-6_amd64.deb $ dpkg -x virtualbox-ose_1.5.6-dfsg-6_amd64.deb vbox-1.5.6 $ sudo cp vbox-1.5.6/usr/lib/virtualbox/vditool /usr/lib/virtualbox/vditool $ sudo ln -sf /usr/lib/virtualbox/vditool /usr/bin/vditool
There, now we have vditool installed. Next, we use it to export our old VirtualBox VDI back to raw disk data. However, if you used VirtualBox’s “Snapshots” with differencing VDI’s, you need to discard all snapshots before the one you want to write out as the raw disk: only the “base” data gets written out, not the “Current State”.
$ cd ~/.VirtualBox/VDI $ vditool copydd win2000-i386-32gb.vdi win2000-i386-32gb.dd vditool Copyright (c) 2004-2008 innotek GmbH. Copying VDI image file="win2000-i386-32gb.vdi" to DD file="win2000-i386-32gb.dd"... The operation completed successfully!
Be careful, this could consume a lot of disk space, if you were using compacted VDI’s instead of fixed size as the raw image will be the full size of the disk image, which in my case was 32 GB even though the VDI only took ~6.5 GB on disk.
Once we have the raw data, we can create the VMDK metadata for our DD image. We compute the size of the raw data in sectors by dividing its size in bytes by 512:
$ stat --printf="%s 512/p" win2000-i386-32gb.dd | dc 67108864
We also need to compute the CHS geometry of the virtual disk. I used the assumption of 255 heads and 63 sectors:
$ stat --printf="%s 512/255/63/p" win2000-i386-32gb.dd | dc 4177
Once we have that information, we go ahead and create the VMDK metadata. Change the elements highlighted in blue as appropriate for your system:
$ cat >win2000-i386-32gb-flat.vmdk <<-__EOF__ # Disk DescriptorFile version=1 CID=4dd210c6 parentCID=ffffffff createType="monolithicFlat" # Extent description RW 67108864 FLAT "win2000-i386-32gb.dd" 0 # The Disk Data Base #DDB ddb.virtualHWVersion = "4" ddb.geometry.cylinders = "4177" ddb.geometry.heads = "255" ddb.geometry.sectors = "63" ddb.adapterType = "buslogic" __EOF__
There, we now have a VMDK suitable for use in VMware! But, it takes up all 32 GB of space on the disk while only ~6.5 GB is actually in use. Lets use vmware-vdiskmanager to create another VMDK that is growable, instead:
$ vmware-vdiskmanager -r win2000-i386-32gb-flat.vmdk -t 0 win2000-i386-32gb.vmdk Using log file /tmp/vmware-dossy/vdiskmanager.log Creating a monolithic growable disk 'win2000-i386-32gb.vmdk' Convert: 100% done. Virtual disk conversion successful.
And there you have it: a growable converted VMDK from VDI:
$ ls -lh win2000-i386-32gb* -rw------- 1 dossy dossy 32G 2008-05-23 11:26 win2000-i386-32gb.dd -rw------- 1 dossy dossy 327 2008-05-23 13:40 win2000-i386-32gb-flat.vmdk -rw------- 1 dossy dossy 6.5G 2008-05-23 14:25 win2000-i386-32gb.vdi -rw------- 1 dossy dossy 6.3G 2008-05-23 14:20 win2000-i386-32gb.vmdk
From here, I created a new virtual machine under VMware Server, specifying “Custom” and using an existing virtual disk–the one I just created.
Of course, I couldn’t just boot this VM up because the virtualized hardware from VirtualBox differs from the virtualized hardware in VMware, and the particular VM in question is a Microsoft Windows 2000 guest. To fix the Windows install, I performed a “repair installation” of Windows 2000. I guess this is necessary when you change all the hardware out from underneath a Windows machine. After completing the repair installation, the VM booted up! I went ahead and installed VMware Tools, rebooted, and now everything works as expected.
I don’t know how many folks out there want to migrate away from VirtualBox to VMware, but I couldn’t find very much useful information on doing it so hopefully this will help people out who want to do it.
Tags: HOWTO, VirtualBox, VMware
Copyright © 2024 · Log in
Latest comments