Warning: Security breach in svn-1689 an possible others

FireFly Media Server Firefly Media Server Forums Firefly Media Server Nightlies Feedback Warning: Security breach in svn-1689 an possible others

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #2686
    mas
    Participant

    Please beware of the following security problem with svn-1696 and possibly also all other versions.

    I found this breach by chance when I was trying to give a DAAP-protocal streaming link to a friend and discovered, that the user password was NOT neccessary to access the file, despite the fact that I have of course a user password set.

    Affected:
    All remote accessible DAAP databases with a user password set.

    Bug:
    Even when a user password to access a music database is configured, it is possible to access the whole database without authentification.

    Cause:
    It turns out that the DAAP handler (the RSP handler does not seem to be affected) excludes certain requests from authentifications to work around bugs in the DAAP protocol. Unfortunately also the streaming requests for the actual music files are excluded, but especially these links are easy to guess. Therefore in fact the server only checks calls to browse the database. Anyone guessing a file id right can however download the file without authentification.
    If that is really neccessary because of bugs in DAAP protocol as the source code states, then all I can say is thanks Apple for such a crappy protocol.

    Confirmation:
    Just point your normal browser to

    http://yourserver:3689/databases/1/items/idnr.mp3

    with idnr = any existing id number. These are easy to guess as the server usually numbers starting from 1. Oh and you have to guess the file ending but thats rather simple as well. Most will use mp3s.

    And voila, no password request, it all downloads unauthorized.

    Workaround:

    plugins/out-daap.c:
    /**
    * check for auth. Kind of a ham-handed implementation, but
    * works.
    */
    int plugin_auth(WS_CONNINFO *pwsc, char *username, char *password) {
    char *uri = pi_ws_uri(pwsc);

    /* don’t auth for stuff we shouldn’t */
    if(strncasecmp(uri,”/server-info”,12) == 0)
    return TRUE;
    if(strncasecmp(uri,”/logout”,7) == 0)
    return TRUE;
    /**
    * Grrr, not authing the database is a huge security hole!
    * I dont care what braindead itunes DB it breaks but
    * not authing this means everyone can download
    * all songs easily by just guessing the id!

    if(strncasecmp(uri,”/databases/1/items/”,19) == 0)
    return TRUE;

    * Thats insane!
    * hence taken out
    */
    if(strncasecmp(uri,”/activity”,9) == 0)
    return TRUE;

    return pi_ws_matchesrole(pwsc,username,password,”user”);
    }



    The commented out the culprit here. Quite possible that this breaks some braindead DAAP clients.

    #17847
    EVILRipper
    Participant
    #17848
    mas
    Participant

    Hehe guess we are the only ones alive in this forum from time to time.

    Well I was not aware of this “feature” which is a security wise quite huge flaw.

    I mean if the link was

    /databases/item/1/RANDOMKEY.mp3

    then ok. But the id is very very predictable. De facto such a DAAP server is open for anyone. Inacceptable when you use it from remote also.

    #17849
    fizze
    Participant

    Stickified.

    Hey, I’m alive too 😉

Viewing 4 posts - 1 through 4 (of 4 total)
  • The forum ‘Nightlies Feedback’ is closed to new topics and replies.