Linux Broadcom 5820 Cryptonet Driver Integer Overflow
-----------------------------------------------------

Overview:

    There exists an integer overflow in the cryptonet driver.  A user supplied
value is used to size a dynamic buffer, and this buffer is subsequently filled
with user supplied data.  

Impact:
    
    Local DOS, and possible code execution depending on the location of the
    buffer in slab.  The Cryptonet driver is not distributed by default in all
    distributions.  I found it in the RedHat 8 2.4.20 sources, but not in
    Slackware 9.  If it is installed, you can find it in 
    /usr/src/linux/drivers/crypto/bcm/
	    

Details:

    The ubsec_ioctl() function is used to setup various operating parameters
    for the device driver.  One of the commands is used to setup the key being
    used for encryption.  This occurs in the following code:

/drivers/crypto/bcm/dispatch.c, 196:

case UBSEC_KEY_SETUP_FUNC:
    status = ubsec_keysetup(DeviceInfoList[SelectedDevice].Context, (void *)arg);
    break;

which calls this function found in /drivers/crypto/bcm/pkey.c, 91:

int ubsec_keysetup(ubsec_DeviceContext_t pContext, ubsec_key_io_t *pKeyIOInfo)
{
    ...snip....

1]
  copy_from_user( &KeyIOInfoForDSA,pKeyIOInfo, sizeof(KeyIOInfoForDSA));

  if((KeyIOInfoForDSA.command == UBSEC_DSA_SIGN) || (KeyIOInfoForDSA.command == UBSEC_DSA_VERIFY)) {
    message_alignment = DSA_MESSAGE_ALIGNMENT;
2]
    add_dsa_buf_bytes = KeyIOInfoForDSA.key.DSAParams.InputFragments->FragmentLength + DSA_MESSAGE_ALIGNMENT;
  }
   
   .......

3]
  pkey_buf = (unsigned char *) kmalloc((4096+add_dsa_buf_bytes),GFP_KERNEL|GFP_ATOMIC);
  pCommandContext = (CommandContext_pt)pkey_buf;
  kcmd = (ubsec_KeyCommandInfo_pt) &pCommandContext[1];
  KeyIOInfo = (ubsec_key_io_pt)&kcmd[1];
  KeyLoc = ((unsigned char *)&KeyIOInfo[1]) + message_alignment;
  
4]
  copy_from_user( KeyIOInfo, pKeyIOInfo, sizeof(*KeyIOInfo));

   ...snip...
}

    The last argument passed to ubsec_keysetup() is the device specific user
    supplied argument to ioctl().  It is copied into the KeyIOInfoForDSA
    variable at 1], and then used to size the buffer at 2].  Now one of the
    things that doesn't make sense to me, is that at 2] when accessing the
    just copied in user structure, they are accessing a pointer embedded in
    the structure.  This pointer would point somewhere into userland, and from
    what I have learned so far about kernel programming, that would NOT be a
    valid pointer to just dereference?  I don't have this hardware, so I
    couldn't test this myself, but I was under the impression that code would
    fault, or perhaps access some random area of memory?  However, proceeding
    on regardless, that signed integer value is then added to 4096 at 3] when
    used to allocate the buffer.  Part of this buffer is then used at 4] when
    the same user structure from 1] is copied into an address further into the
    allocated buffer.  If a properly calculated negative value is used for the
    add_dsa_buf_bytes variable, an integer overflow will occur when allocating
    the buffer at 3].  The smallest sized buffer that can be allocated via
    kmalloc() is 32 on some platforms, and 64 on others.  Regardless of this,
    it is still possible to overflow the buffer at 4] because of the size of
    the structure being copied combined with the fact that we start copying
    from buffer base + 24(or greater on certain platforms) bytes into the
    allocated buffer.  Depending on the location of the allocated buffer in
    the cache slab, it may be possible to overwrite slab control structures
    and execute arbitrary code.  However, it is likely that we will be
    overwriting a piece of memory that belongs to someone else, and this may
    lead to system instability when that memory is accessed by whomever it
    belongs to.

Vendor Status:
   The vendor was not contacted.

Thanks:
   This bug and several others were found with the advanced, open source 
   auditing tool grep.

-- 
-sean