Radio Crankypants #17 : On streaming and security
To my knowledge, the centralized Radio UserLand web-hosting servers don't have an XML-RPC interface. Nor would they since the Radio framework doesn't appear to support "downstreaming", or the sync-ing of data between their servers and your machine. There is therefore no reason to be sending UserLand, proper, a request to update a website. But, as I write this, I'm thinking it is subject matter better suited for this website. I can't post it there because I am not writing this from the computer running that particular copy of Radio. Since Radio doubles as an XML-RPC server, it is true that the Blogger API XML-RPC interface could be enabled allowing me to post to my blog from a variety of clients. That's pretty cool. But it assumes a few things : that the machine running Radio is always on; that the machine running Radio has a fixed IP; that the machine running Radio is not being NAT-ed or, if it is, that the appropriate IP forwarding rules have been set up; that you're comfortable sending passwords in cleartext to an application running not on some one else's computer, but your own. This last point raises an interesting problem for Radio. There are no authentication or authorization checks on running the application itself. Radio benefits from the fact that the two platform vendors it is written for are developing increasingly secure multi-user logins and widgets for limiting who can do what. But the application itself just runs. Let's imagine that someone neglects to limit which users can run Radio or that it is installed on a machine with a universal login. Both of these things are very bad practice but we all know this kind of stuff happens all the time. Think high-school. There isn't a whole lot to prevent someone from sitting down at the machine and setting up handlers to turn Radio into a warez server. Or from monitoring a set of files on your desktop and sending them to anyone who requests them over the wire. Or deleting them. And if a bad person can sniff your password -- one presumes that if they can just sit down at your workstation they can look it up in Radio, but anyway -- then all of these actions happen as though "you" initiated them. If your copy of Radio runs on OS X, you've added a whole other layer of nightmarish-ness because shell commands can be issued from inside the errant XML-RPC handler. Which brings us back to "streaming". If you look at the actual files that get written to disk by Radio, you'll see they contain a bunch of control statements and then a macro :<%radio.macros.viewWeblog ()%>. These are what generate the HTML sent to a remote www server. What I am about to say next may be premature. I haven't had a chance to really dig through the code to see what's going on here. If Radio is doing some kind of checking/untainting on the string value of the macro directive then everything I am about to say should be moot. If, however, Radio is simply eval -ing the macro it raises an enormous red flag. It means that all a bad person needs to do is fire up a copy of NotePad and change one of the files in the www directory to contain a new <% do.something.bad () %> macro which would be run the next time you sync your blog with a remote server. Just in case you ever thought that your sysadmin was being grumpy and cranky or just generally contrary simply out of spite.