Wow, TFTP servers really do suck.

I went to a talk by Dave Aitel yesterday at Harvard (notes here, if you're interested). Hopefully more to say on it later, but it definitely helped my burnout by reminding me what I'm really doing in security. (Hint: poring through IDS alerts is not what I signed up for.)

One thing Dave mentioned is that TFTP servers are notoriously buggy, so I thought a nice exercise would be to take a look at one and see if I could find something. I'd been playing around in IDA Pro for a while and I was about sick of it, so I was ready to knock that off and read some actual source code. I went to SourceForge and downloaded the first TFTP server I saw. Sure enough, I had a remote DoS within probably 10 minutes. It can most likely even run code, though I'm not hugely interested in proving it right now. That might make a good rainy day project.

So, rather than go through a bunch of hassle, I just posted it on the bug tracker for the project. Was that bad? I kind of thought it was a tiny bit of code that nobody's probably using, but I just checked and it's had 60,000+ downloads.

If you're interested, the bug report is here. It's pretty simple, you need to successfully TFTP GET a file with a long enough filename to overflow the log message buffer. You can do that by requesting "./" a bunch of times before the filename you want. So, basically something like:

tftp X.X.X.X PUT `perl -e'print "A"x128'`
tftp X.X.X.X GET `perl -e'print "./"x100'`/`perl -e'print "A"x128'`

will cause the server to segfault.

UPDATE 4/3: Haha, oh I suck. Exploit code was posted for this bug a couple days after I made the initial bug report (http://www.offensive-security.com/0day/sourceforge-tftpd.py.txt) and
it's much simpler than I thought.

UPDATE AGAIN: Actually it looks like the code and advisories came out the week BEFORE I made the bug report. Now THAT is a weird coincidence, given that the vulnerable release of the server code has been sitting out there since June 2007. What are the odds? Anyway, original update continues...

Turns out the overflow happens well before I thought it did, and the logging function has nothing to do with it. I'm not sure what I failed to check that made me miss this. Actually, I think what I was doing was looking for a way specifically to overflow the log buffer, rather than the struct that holds the filename in the first place. I likely failed to check the simpler option of just sending a GET long filename at all because that wouldn't have gotten me to where I thought I needed to be in the code. I feel incredibly silly now. I guess in the future I will think harder about what I'm doing and pay more attention to detail.

Specifically, the processRequest function starts by defining two variables:

char logbuff[512];
request req;

The request struct looks like:

struct request
{
timeval tv;
fd_set readfds;
pthread_t threadId;
int m_socket;
BYTE sockInd;
BYTE attempt;
char path[256];
FILE *file;
char *filename;
char *mode;
char *alias;
...

And part of the processRequest function includes an unsafe:

strcpy(req.path, cfig.homes[0].target);
strcat(req.path, req.alias);

So, yeah. Next time just grep for strcpy and strcat.

Lost Code

I kinda want to post code for a Metasploit module I wrote a while back against ZDI-06-043
(Novell Netware Client Print Provider Buffer Overflow Vulnerability), but I totally can't find a copy of the finished version.

There's an in-progress version archived from the Metasploit mailing list here. I think it's a working version, if I recall, but I was in the process of learning the MSF DCERPC stuff and a lot of it is pretty ugly.

VM Visibility

Well, the world is catching up. Last summer, I didn't have a simple solution for gaining visibility into traffic between guests on a single virtual host. Recently, I spoke a bit to Montego Networks about their HyperSwitch product, and I have to say I was impressed. The product was officially announced today. As far as I understand it, this product provides all the capabilities I need and more. Assuming it works as advertised, this thing is going to catch on like wildfire. The price is pretty nice, too.

Here's the full press release. The CTO of Montego also maintains a virtualization security blog, which is worth a read.

Things That Aren't Working

Some weeks, nothing is quite as simple as it ought to be. Such as:

• SSH via Perl from a Windows box. Should be just a matter of choosing between Net::SSH2 and Net::SSH::Perl, right? Neither seems to work for me. I can execute commands, but I can't read the output. There's even a module (Net::SSH::W32Perl) which apparently attempts to resolve compatibility issues, but all it really does is flip blocking on and off for the inet socket at certain points in the connection.
  
• Scripting interactions with sudo over SSH. Who knew THIS would be so irritating? The basic problem, I think, is that sudo doesn't read the password from stdin by default. It does have an option to force it to do so, so I just did that. I'm still not able to read the password prompt, though (it's not on stdout or stderr), so I have to kind of fudge it. Did I mention this is all happening in a PHP script that talks to a Bash script which calls SSH to talk to another machine? Yeah. It's kind of a Rube Goldberg contraption.
• Performing forensics on a Windows Mobile device. You'd think this would be widely supported, but in fact, it seems it's very POORLY supported. I have a trial version of Device Seizure from Paraben Software, which at least claims to do what I'm trying to do. It keeps wanting to crash during acquisition, though, so we'll see how far we get.
• Also had some problems getting the TOC::Oscar module to work right in Perl, but I'll chalk that up to my own laziness in RTFM.
  

Hmm, that's all kind of embarrassing to post in public.

An incredibly insightful essay by Bruce Schneier.

Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail.