Notes vulnerability

Notes vulnerability

Basics

The notes functionality is basically a html browser included in the ipod. Some doc can be found here.

Basic rules are :

• 64kB files are loaded just after the boot of the nano, however they are not kept in RAM
• each file is limited to 4kB
• the links point to other files, or to other notes, or to media files.
• the link is limited to 256 chars. apple documents this limit, but they don't say it can cause a buffer overflow ;)

There seem to be 2 buffers : one which is a perfect copy of the disc file, including BOM, etc..., and one after UTF16 processing

File loading

The htm file is converted to UTF-16 first. This limits the possible char sequences. The best thing to to have most charset possibilities is encode the exploit directly to UTF16.

forbidden values are :

• FE FF : UTF16 BOM
• D8 00 up to DF FF : not checked what happens if inserting them
• 00 00 : would stop string processing

The opcodes to execute will be placed in the body of the htm file.

Link overflow

After loading the file, the links are then checked against the file system. Many modified copies of this string are present on the stack. We could identify the most important steps of this process, until the string overflow in the stack (order could be a little different):

• Fist, the link is extracted from the file, and copied to some heap or fixed buffers
• The link is converted to UTF8. Every char >7F is encoded in many bytes
• Then it is passed through an uppercase function
• The URL encoding is decoded : %xx values are converted to their equivalent (limited to valid UTF8 or the like)
• Finally, this link is copied in a limited buffer which is located on the stack. By putting a return adress repetitively in the link, the processor will jump to this adress.

For conveninece, the return adress is always encoded using %xx URL encodings. This avoids problems with some special chars and with lowercase chars. Possible values are 00 < xx <= 7F. (the unescaped chars seem to be transcoded from ISO-8859-1 to UTF8 again)

Exploiting, getting execution

To exploit, we used JTAG to determine the correct paddings and return adresses of the buffers.

In my case, i had to put a second file to influence the buffer's location, in order to have a return adress which fits an UTF8 (no byte of the return adress >7F).

An example of a working overflow file set here. the file "Brokenlink.htm" contains first an UTF16 BOM, then "AA" as padding, then the overflowing link (return addr is 08640D60), then a NOP (opcode E1A01001) landing zone, and finally a "while(1);"

This while(1) does not freeze or reset the ipod, but instead just crashes the background task. You can still scroll the menus, but the ipod will freeze as soon as you press "play" or if you enter the notes menu, etc...

The processor arrives to the notes in supervisor state, with interrupts activated (menu scrolling), etc. Caches are activated, recommendation is to disable them if making complex IO & DMA stuff, else they can interfere.

Dumping memories

For dumping, first the cache was used (JTAG dumps), but very soon it turned out that the UART is more flexible. All these dumps can not be published here, due to copyright issues.

UART

The UART is exactly the same than described in the datasheet.

See here how to build an UART cable.

my complete setup is a little bit more complex :

• left board : DLC5 jtag interface, modified for reset and USB switching
• right board : some programmer board, only the ST232 is used
• upper board : this was the jtag scanner, now only the power supply and 5V regulator are used
• middle board : all the switching stuff

To automatically enter DFU mode, i wired transistors to the USB 5V line, and to the "play" and "enter" buttons of the clickwheel.

USB

Because UART needs HW, USB will be used to debug in the future

Analysis of the dumps

To be documented.