5668656 2000-10-30 23:43 +0000 /214 rader/ gregory duchemin <c3rb3r@HOTMAIL.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2000-11-02 03:21 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: c3rb3r@HOTMAIL.COM
Mottagare: Bugtraq (import) <13535>
Ärende: numerous format string attacks in Nap ( Napster for linux )
------------------------------------------------------------
From: gregory duchemin <c3rb3r@HOTMAIL.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <F161B9DjCSDAmwtyL810000359d@hotmail.com>
hi to everyone here,
nap (ver 1.4.4 ) is a little ( and good ) term based napster client
for linux ( tested on my linux 2.2.17 ) and others *nix like. to
simplify the pb just consider two parts, one for outgoing tasks, the
other for incomings ones. there are plenty of possible string format
attacks and even some buffer overflow in the source but curiously
just on the outcoming side, just like if the author didn't take care
about a local possible compromise. This proggy don't need any
suid/guid to run so we would tend to believe us safe but wrong. For
example, when nap has finished to build its mp3 database (at the prog
start or during a rebuild), it then call the sendpack() function to
send a list to the remote napster server. take a look now at
sendpack()
nap.c
int sendpack(int s, unsigned short op, char *fmt, ...)
{
char *pack, *data;
phead_t *hdr;
va_list args;
int r;
......
va_start(args, fmt);
vsprintf(data, fmt, args);
va_end(args);
}
when sendpack is called in the mp3 database context there is no args,
everything is already inside the fmt char*. that is to say filename
too. So i can make a title with % chars to be interpreted by
vsprintf and should be visible with a simple database browsing far
away from here.
nap is given with a file nap.conf
nap.conf
========
user=Ilove
pass=Napster
upload=/mymusics/
download=/mymusics/
dataport=6699
connection=3
email=c3rb3r@hotmail.com
ok but what ? there are no setuid ?! just make your logical bomb
inside the last laming boyz band title ( go to your nearest cd store
to get the precious information. thanx to MINX for this great idea )
don't forget that if you r on nap, U R VULNERALE too ! modify source
to be immuned and double every % char in your bomb because the remote
client will compute a first time your title before definitly ask for
it.
(u can immune yourself too just by using 8 % for 1, no more
discretion )
X (cracker) -----------------> Victim
( bomb %%.mp3 ) ( bomb %%.mp3 => bomb %.mp3 )
|
|
Victim
<------------------- ( bomb %.mp3 )
X (cracker)
( bomb %.mp3) ------------------> *** BINGO ***
U have always to create 2 files for each bomb u make. in a % and in a
%% way. in this example bomb %.mp3 and bomb %%.mp3 just because
victim will call vsprintf a first time prior to the final GET
request. printf("%%n") -> %n printf("%n")-> Seg fault (in most of
cases ;) )
1- the little boy, just a little BOUM ( remote dos )
===================================
make your title "LAMING BOYZ BAND - Do%n't Leave me.mp3"
and "LAMING BOYZ BAND - Do%%n't Leave me.mp3"
in /mymusics/ directory.
note the %n in do%n't leave me, it will force remote nap client to write 22
at a certain address
read in stack causing in segmentation violation. This address should be
outside the process address space.
Note that the bomb will be effective when the remote victim will finally
decide to rebuild his database or restart
his client and in this manner will read the title.
If he really like this kind of noise, chances he use nap on linux are slim
;)
2- the bomb that wanna be a worm. ( remote password recovery )
==============================
this one will print the username and password in plain text at the
end of the title when someone will browse the victim files, he will
see something like
...
Bugz Can Dance -And even steal you [[ILove - Napster]].mp3
...
Oh ! thanx for your pasword.
.0 precision in %s is really cool, no need for a NULL, nothing
printed out even if 4 bytes eaten. this bomb ( trojan ?) will read
in the stack from sendpack function() up to login() function to get
back auth information in the process memory ( login and password ).
nice isn't it ?
Bugz Can Dance -And even steal you %.0s%.0s%.0s%.0s%.0s%.0s%.0s%.0s
%.0s%.0s%.0s%.0s%.0s%.0s%.0s%.0s%.0s%.0s [[%s - %s]].mp3
Bugz Can Dance -And even steal you %%.0s%%.0s%%.0s%%.0s%%.0s%%.0s%%.0s%%.0s
%%.0s%%.0s%%.0s%%.0s%%.0s%%.0s%%.0s%%.0s%%.0s%%.0s [[%%s - %%s]].mp3
No buffer overflow here, only format string attack in the pure way of
the thing. we can read and so write almost everything in the process
memory that is to say things like its napster server IP address,
database file (shared.dat), conf file (nap.conf). Obviously there
are thing worse to do than just a little password robbery.
For example, if i modify the directory to (up/dow) mp3 files and i
put, hmm, well /etc/ instead of. After the next database rebuild, i
should be able to browse remotely almost everything on my victim
/etc, considering he is root on his own machine ;)
3- The code bomb (sorry for that ;)
=======================
Now things are getting very bad for our victim since we can write an
arbitrary value in saved eip when sendpack() is called, we r able to
force return address to point in our title. Because this title can
contain native code for the remote victim cpu, we are potentialy
enough skilled to force his computer to do plenty of compromising
things like spawning a shell, etc.. just like things are in a buffer
overflow scenario.
Who would be enough stupid or innocent to download such silly titles
?! however, still enough for kiddies to have fun.
Because anybody can ask for the victim titles (after the bomb has
worked) and can see his secret informations, publicly exposed. We can
easily imagine a scenario in wich, kiddies will use specialy crafted
titles to perform more efficient searches few day latter and then get
their payload back.
i don't want to publicly disclose such a beautiful bomb, it's not the
purpose of this paper.
Solution: just take care about what u r about to download ;)
Greetings: for MINX and A big THANX for u jaheira, my favorite cobaye ;) !
Have a nice day,
Gregory Duchemin
Security Consultant
& Ethical hacking
NEUROCOM CANADA
1001 bd Maisonneuve Ouest suite 200
Montreal (Quebec) H3A 3C8 CANADA
Tel 514 908 6800
Email: gdn@neurocom.com
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
(5668656) --------------------------------(Ombruten)