Tcpdump, dhclient bugs, those recent libext2fs vulns, and the IDefense Clamav vuln

In recent weeks my sister was wed, and I attended the event in Thailand.  I’m back in Australia again..

 I’ve been holding onto some bugs (none allowing for code execution) in Tcpdump for a while now, with the hope that IDefense would buy them.  It seems they aren’t interested, so I thought I’d write something touching the topic here.

I’ve been auditing Tcpdump for a while now.. Its fairly easy code to read, and its nice practice before attempting more complicated software.  I found a few bugs, some I haven’t tested, which include a remote denial of service.  And memory leaks in almost every module.

Most of the pretty printing functions, eg ipaddr_string, return a heap allocated buffer.  But in the printer code its used like this

 printf(“%s\n”, ipaddr_string(…));

 This type of practice is common to almost every module in tcpdump.  The result is memory leaks everywhere.  A couple of questions exist.

 1) Are the maintainers aware of these fundamental problems?  Do they care (I’m not trying to be rude)?  I mean, is it something they are aware of, but consider not important to fix?  Or has it slipped into the source without anyone being aware of.

2) Does the code exist, simply because bad practice has spread from some reference modules that everyone is using to base their code from?

 I’m planning on submitting patches to www.tcpdump.org to correct theses issues, and other bugs I’ve found.

I’m wondering what is the right approach.  Decoupling all the functions from use within the printf argument list, and freeing each call explicitly.. or have new printing functions that keep track of all the allocations and have modules call a final cleanup function.

Dhclient for FreeBSD is a daemon that renews DHCP leases.. it has some vulnerabilities in it that allow for denial of service.

I was looking hard for code execution bugs in both dhclient and the isc dhcp server.  No bugs..  There was one bug in the dhcp server which I haven’t verified but it wont allow for code execution (its a denial of service, but requires trickery to trigger), if it turns out to be a legitimate bug.  A long time ago, found on google, are some advisories for dhclient

 Also, on bugtraq were some libext2fs bugs posted.. I looked at the patch, and new malloc/array allocation wrappers are now being used that touchs a significant amount of code that previously could allow for integer overflows.  There is still at least one other potential bug that I haven’t verified yet that is still current.  Don’t know if it will allow for code execution – I think probably not.

 Apologies for talking alot about ‘unverified potential vulnerabilities’.  It’s just that I get into the habbit of quickly reading through code finding potential bugs, and then later going back to check if they are really bugs or not.  Alot of the time, I get it wrong, and there is no bug, but I also get it right alot of the time too.  Part of the problem is that I want to get more involved in the development side than purely auditing.  So my intention is to send patches to fix the stuff I find..

 There was a recent advisory on clamav on the MEW handler in the Windows PE binary handler.  I actually came across the the code in question that was identified on vulnerable.. It was on my TODO list of bugs to verify..  There are still infact integer overflows present with the exact code in question, but its no longer exploitable.  On a positive note, clamav seems to be under active development – which is always a positive thing.  The code is still pretty messy though.