[3DS][SSL] Use of uninitialized class member leads to RCE in eShop movie player

Summary

#Affected Systems

• Platform : (New) Nintendo 3DS
• Region: ALL
• System version: 11.13 (latest at the time of writing)

#Description The eShop video player does not initialize pointers to some decoder objects when creating a video player object. With a specific audio codec this induces the use of uninitialized data that an attacker can potentially control through heap massaging, allowing to get remote code execution.

#Vulnerability The eShop movie player does not clear pointers to audio decoder objects when initializing a new video player object. This is not an issue when using codecs like fastaudio or imadpcm because a new decoder is allocated and the pointer is overwritten. However when using the raw pcm16 codec, even though there is no need for a decoder, it still tries to initialize a decoder object using the uninitialized decoder field:

void create_audio_decoder(u8 codec, ..., audio_decoder** out_decoder) {
    if(codec == fastaudio) {
      decoder = create_fastaudio_decoder(...);
      *out_decoder = decoder;
    }
    else if(codec == imadpcm)
      [...]
    else if(codec == pcm16)
      decoder = *out_decoder; // *out_decoder is not initialized!

   if(decoder)
      decoder->init(); //if decoder is controlled this gives an arbitrary jump!
}

This function is the first function called in the first virtual method of what seems to be the Player class?

It is possible to massage the heap such that the value of *out_decoder is controlled because just before the movie player is loaded, the application frees some JPEG images (the screenshot images displayed on the title information page). Thus one can send some carefully crafted binary files instead of valid screenshots to write controlled values in memory and hopefully writes them where the player object is then allocated.

If the data actually get written at the right location, we get an arbitrary jump through the virtual function call decoder->init(), which is enough to get remote code execution.

Impact

Because of #894922, anyone can exploit this vulnerability and get remote code execution in usermode under the eShop application. Moreover, this could potentially(?) be exploited without any SSL flaw by someone able to submit games to the eShop catalog, however since I don't know the validation process and checks performed, I cannot ensure this is possible. Note that one can exploit this vulnerability without any noticeable change to the eShop application behavior, except that the screenshots on the title details page are just not displayed. This means the user has no way to know something bad is happening before launching the video playback.