Current status of Kismet security vulns
dr

<b>The vuln?</b>

I've only heard of 2 vulnerabilities that came out of a talk at Defcon.

One claimed that embedding a \001 in the SSID would render the network invisible to Kismet.  I'm not sure how this would be since the code explcitly caught and mangled anything not printable (below ascii 32, ' ').  None of my test cases could reproduce hiding the network or corrupting the kismet server/client protocol.  In the interest of being more complete and accurate I've rewritten the ssid-to-printable munger to throw in the octal triplets for unprintable characters (ie, "\001") and increased the internal tracked SSID length to 255 characters to hand that.  SSID literals are still limited to 32 characters in a packet.

Since I have still not been given any information about the supposed buffer overflow, everyone should assume that it is still a risk.

<b>Why I think this was handled irresponsibly</b>

People want to make waves and get some press at Defcon by releasing 0day announcements.  OK, thats rather annoying, but whatever.  What annoys the <b>hell</b> out of me is that the claim "if you run kismet this weekend you will be owned" implies that the exploit code was <b>in use</b>.  Capturing the exploit frames and reverse engineering the exploit is very possible (of course, I have no examples and I wasn't there).

By not following up and getting information on the exploit to me, all users are left exposed.  Handling it this way does NOTHING to help security.

<b>Don't agree?</b>

My complaining here is unfortunately one-way.  Don't agree?  Email me.  Want to disagree with me in public?  Hit up IRC or the Kismet forums.  I'm trying to be fair about this but it's really really annoying to have people asking me about info and having none to give.  Communication breaks down, but something should have been communicated so that I could fix the vulnerability.