Exploitable pine heap overflow (Re: Remote pine Denial of Service)

[3APA3A <3APA3A () SECURITY NNOV RU>]

Dear Linus Sjöberg,

There  is  a classic and probably exploitable heap overflow in bldaddr.c
addr_list_string().


    else{
        char *charset = NULL;

        list = (char *)fs_get((size_t)est_size(adrlist));
        list[0] = '\0';
        rfc822_write_address_decode(list, adrlist,
                                    verbose ? NULL : &charset, do_quote);
        if(charset)
          fs_give((void **)&charset);
    }


est_size should calculate size of target string :

est_size(a)
    ADDRESS *a;
{
    int cnt = 0;

    for(; a; a = a->next){

        /* two times personal for possible quoting */
        cnt   += 2 * (a->personal  ? strlen(a->personal)  : 0);
        cnt   += (a->mailbox  ? strlen(a->mailbox)  : 0);
        cnt   += (a->adl      ? strlen(a->adl)      : 0);
        cnt   += (a->host     ? strlen(a->host)     : 0);

        /*
         * add room for:
         *   possible single space between fullname and addr
         *   left and right brackets
         *   @ sign
         *   possible : for route addr
         *   , <space>
         *
         * So I really think that adding 7 is enough.  Instead, I'll add 10.
         */
        cnt   += 10;
    }

    return(max(cnt, 50));  /* just making sure */
}

As  you  can  see  there is no memory resseravation for characters to be
commented in mailbox.

rfc822_write_address_decode  finally  calls  to rfc822_cat which decodes
mailbox to address quoting special characters. Special characters are:

()<>@,;:\\\"[]\1\2\3\4\5\6\7\10\11\12\13\14\15\16\17\20\21\22\23\24\25\26\27\30\31\32\33\34\35\36\37\177

and, of cause, it's impossible to use \0 in shellcode.



--Thursday, November 7, 2002, 4:16:13 PM, you wrote to bugtraq () securityfocus com:

LS>                            Security Advisory

LS>                            23rd October 2002

LS>            Remote pine version 4.44 denial of service

LS> Name:             Pine version 4.44
LS> Arch:             Redhat 7.2 i386
LS> Severity:         Medium
LS> Vendor URL:       http://www.washington.edu/pine/
LS> Author:           Linus Sjöberg (lsjoberg () aland net)
LS> Vendor notified:  14:th October 2002
LS> Vendor response:  14:th October 2002
LS> Vendor fix:       ??????

LS> Impact:   An attacker can send a fully legal email message with a crafted
LS>           From-header and thus forcing pine to core dump on startup.
LS>           The only way to launch pine is manually removing the bad message
LS>           either directly from the spool, or from another MUA. Until the
LS>           message has been removed or edited there is no way of accessing
LS>           the INBOX using pine.


LS> Description
LS> ***********

LS> When pine detects an email with a From-header looking like
LS> From: 
LS> "\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\""@host.fubar
LS> it will die with a segmentation fault. Note that the address is fully
LS> legal, even if quite unusable.

LS> When i reproduced the problem with a pine running within gdb I got the
LS> following backtrack:
LS> #0  0x401ea490 in chunk_free (ar_ptr=0x4029e300, p=0x83b65d8) at 
LS> malloc.c:3231
LS> #1  0x401ea3f4 in __libc_free (mem=0x83b65e0) at malloc.c:3154
LS> #2  0x081ef8e2 in fs_give (block=0xbfffb9b8) at fs_unix.c:60
LS> #3  0x080feb4f in set_index_addr 
LS>     (idata=0xbfffc8c0, field=0x83012d8 "From", 
LS>     addr=0x83b6160, prefix=0x0, width=18, 
LS>     s=0xbfffbd11 
LS>     "\"\\\"\\\"\\\"\\\"\\\"\\\"\\\"\\\"\\\b`´:\bX½^?¿ïø\036\b")
LS>     at mailindx.c:4508
LS> #4  0x080fb397 in format_index_line (idata=0xbfffc8c0) at mailindx.c:3376
LS> #5  0x080f9ec4 in build_header_line (state=0x839f260, stream=0x83aba88, 
LS>     msgmap=0x83a17b0, msgno=40) at mailindx.c:2761
LS> #6  0x080f71e3 in update_index (state=0x839f260, screen=0xbfffcb90)
LS>     at mailindx.c:1264
LS> #7  0x080f576c in index_lister (state=0x839f260, cntxt=0x83a8d28, 
LS>     folder=0x839f325 "INBOX", stream=0x83aba88, msgmap=0x83a17b0)
LS>     at mailindx.c:603
LS> #8  0x080f5347 in mail_index_screen (state=0x839f260) at mailindx.c:452
LS> #9  0x081588e6 in main (argc=1, argv=0xbfffddc4) at pine.c:1122
LS> #10 0x40185657 in __libc_start_main (main=0x8156974 <main>, argc=1, 
LS>     ubp_av=0xbfffddc4, init=0x804ab28 <_init>, fini=0x8225c70 <_fini>, 
LS>     rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbfffddbc)
LS>     at ../sysdeps/generic/libc-start.c:129

LS> Since pine dumped core it might be possible to execute code on the victims
LS> machine, but since I am not into those kind of games I leave that part for
LS> others to find out.

LS> The possibility of locking somebody out from his email is important enough
LS> for an advisory+update IMHO.

LS> Fix Information
LS> ***************

LS> Washington University replied to my posting within a few hours and
LS> reported that the issue was to be fixed in version 4.50. They have not yet
LS> made such a version publicly available after 1½ month, so I have chosen to
LS> go public with this advisory even if there is no patch yet available.



-- 
~/ZARAZA
Êëÿíóñü ëûñèíîé ïðîðîêà Ìîèñåÿ - ÿ òåáÿ ñåé÷àñ ñúåì. (Òâåí)