Date:         Mon, 30 Oct 2000 23:43:54 GMT
From: gregory duchemin <c3rb3r@HOTMAIL.COM>
Subject:      numerous format string attacks in Nap ( Napster for linux )
To: BUGTRAQ@SECURITYFOCUS.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.