New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users
Status: Fixed
Owner:
Email to this user bounced
Closed: Oct 2014



Sign in to add a comment
OS X IOKit kernel code execution due to NULL pointer dereference in IOHIKeyboardMapper::stickyKeysfree
Project Member Reported by ianbeer@google.com, Jun 30 2014 Back to list
When setting a new keyboard mapping the following code will be reached:

    IOHIKeyboardMapper * IOHIKeyboardMapper::keyboardMapper(
                                                            IOHIKeyboard * delegate,
                                                            const UInt8 *  mapping,
                                                            UInt32       mappingLength,
                                                            bool       mappingShouldBeFreed )
    {
      IOHIKeyboardMapper * me = new IOHIKeyboardMapper;
      
      if (me && !me->init(delegate, mapping, mappingLength, mappingShouldBeFreed))
      {
        me->free();

If the init method returns false, IOHIKeyboardMapper::free will be called.

    bool IOHIKeyboardMapper::init(  IOHIKeyboard *delegate,
                                  const UInt8 *map,
                                  UInt32 mappingLen,
                                  bool mappingShouldBeFreed )
    {
      if (!super::init())  return false;
      
      _delegate         = delegate;
      
      if (!parseKeyMapping(map, mappingLen, &_parsedMapping)) return false;
    ...
      _reserved = IONew(ExpansionData, 1);

If the parseKeyMapping method returns false (by supplying a malformed key mapping),
the init function will return early, and won't initialize the _reserved member.

The IOHIKeyboardMapper::free method will call stickyKeysfree() (both _parsedMapping.mapping and _parsedMapping.mappingLen
are non-zero) :

    void IOHIKeyboardMapper::free()
    {
        if (!_parsedMapping.mapping || !_parsedMapping.mappingLen)
            return;
        
        stickyKeysfree();

stickyKeysfree attempts to release all member objects which have been initialized:

    void IOHIKeyboardMapper::stickyKeysfree (void)
    {
      // release shift toggle struct
      if (_stickyKeys_ShiftToggle)
        stickyKeysFreeToggleInfo(_stickyKeys_ShiftToggle);
        
      // release option toggle struct
      if (_stickyKeys_OptionToggle)
        stickyKeysFreeToggleInfo(_stickyKeys_OptionToggle);
        
      // release on param dict
      if (_onParamDict)
        _onParamDict->release();
        
      // release off param dict
      if (_offParamDict)
        _offParamDict->release();
        
    // release off fn param dict
    if (_offFnParamDict)                 <-- (a)
    _offFnParamDict->release();          <-- (b)

However, at (a) _offFnParamDict isn't actually a member but the following macro:

    #define _offFnParamDict       _reserved->offFnParamDict


Since we returned early from IOHIKeyboardMapper::init before _reserved was allocated it's null.
By mapping the null page we can control the value of the offFnParamDict pointer and therefore
control the virtual function call at (b)
 
key_mapping_null_deref.c
4.2 KB Download
Project Member Comment 1 by ianbeer@google.com, Jun 30 2014
Labels: Reported-2014-June-30 Id-607551979
Project Member Comment 2 by ianbeer@google.com, Aug 22 2014
Labels: Deadline-90
Comment 3 by cevans@google.com, Sep 23 2014
Labels: -Reported-2014-June-30 Reported-2014-Jun-30 CVE-2014-4405 Product-iOS-Kernel
http://support.apple.com/kb/HT6441 (i.e. also affected iOS)
No mention of CVE in OS X update (http://support.apple.com/kb/HT6443) ??
Project Member Comment 4 by ianbeer@google.com, Sep 24 2014
Labels: -Restrict-View-Commit
Comment 5 by cevans@google.com, Oct 17 2014
Labels: Deadline-Exceeded Fixed-2014-Oct-16
Status: Fixed
Interesting case.
Looks like it wasn't fixed in OS X until Yosemite: 
https://support.apple.com/kb/HT6535. Therefore, it can be observed:

1) By declaring this in the earlier iOS patch, Apple dropped on bug on their own OS X software.

2) The original report was against OS X, not iOS, so this definitely went well over deadline. Marking as such.
Sign in to add a comment