COMMAND
Nap
SYSTEMS AFFECTED
Nap (Napster for linux) 1.4.4
PROBLEM
Gregory Duchemin found following. nap (ver 1.4.4 ) is a little
(and good) term based napster client for linux (tested on 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 we 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 boys 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 are on nap, YOU ARE 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.
X (cracker) -----------------> Victim
( bomb %%.mp3 ) ( bomb %%.mp3 => bomb %.mp3 )
|
|
Victim
<------------------- ( bomb %.mp3 )
X (cracker)
( bomb %.mp3) ------------------> *** BINGO ***
You have to always 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 we modify the directory to (up/dow) mp3 files and
we put, hmm, well /etc/ instead of. After the next database
rebuild, we should be able to browse remotely almost everything
on our 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 are
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.
SOLUTION
Just take care about what you are about to download.