COMMAND

    procmail

SYSTEMS AFFECTED

    Linux (at least)

PROBLEM

    Michal Zalewski found following.  Don't panic - at least for  now.
    Months ago, Michal found  a problem with LINEBUF  variable defined
    in .procmailrc  files.   By setting  arbitrary values  of it - eg.
    negative  or  extremely  large  ones  -  we're  able  to  at least
    overwrite  memory  locations  with  zero  value  (used to properly
    terminate string buffer,  unfortunately there's no  range checking
    on  signed  int  arithmetic  in  C.   Actually,  it  splits in two
    vulnerabilities:

    a) On    some     glibc     2.0     machines    (eg.      RedHat),
       malloc(negative_integer) won't result in EINVAL, but with valid
       pointer,  for  which  malloc_usable_size()  returns  size of 12
       bytes.   Heap  overflows  possible?  Hmm,  at  least  SEGVs  in
       procmail.

    b) With glibc 2.0/2.1, there's also some way to overwrite mem with
       '\0'  due  to  lack  of  range  checking  and signed<->unsigned
       integer conversion.  Nasty  memory hacking required to  exploit
       it.

SOLUTION

    On  a  pedantic  note:  it  is  not  possible  to  call a standard
    conforming  malloc()  with  a  negative  integer;  the argument to
    malloc is unsigned (size_t).  In Solaris, calls to malloc > 2^31-1
    can  result  in  memory  being  returned  of  the  requested size.
    Various older  releases of  Solaris do  have problems  at the  2GB
    barrier, even thgough > 2GB can be available for malloc.