Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Linux :: Apps N-Z :: nap144.htm

Nap 1.4.4 (Napster for Linux) string format attacks



    Nap (Napster for linux) 1.4.4


    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()

        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);

    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


    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 )
                         <------------------- ( 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"


        "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

    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

    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

    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.


    Just take care about what you are about to download.

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH