Difference between revisions of "Notes vulnerability"

From freemyipod.org
Jump to: navigation, search
(Basics)
Line 6: Line 6:
  
 
Basic rules are :  
 
Basic rules are :  
*64kB files are loaded just after the boot of the nano
+
*64kB files are loaded just after the boot of the nano (needs to be validated, there were some issues --[[User:TheSeven|TheSeven]] 12:11, 12 July 2009 (UTC))
 
*each file is limited to 4kB
 
*each file is limited to 4kB
 
*the links point to other files, or to other notes, or to media files.
 
*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 ;)
 
*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 containing many files, but after UTF16 processing
+
There seem to be 2 buffers : one which is a perfect copy of the disc file, including BOM, etc..., and one containing many files, but after UTF16 processing (the latter needs to be validated, there were some issues --[[User:TheSeven|TheSeven]] 12:11, 12 July 2009 (UTC))
  
 
=== File loading ===
 
=== File loading ===
Line 38: Line 38:
  
  
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.
+
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. (should not be an issue if they are in fact first transcoded to utf8 and then unescaped --[[User:TheSeven|TheSeven]] 12:11, 12 July 2009 (UTC))
  
 
== Exploiting, getting execution ==
 
== Exploiting, getting execution ==

Revision as of 14:11, 12 July 2009

Notes vulnerability

Basics

The notes functionnality is basically a htm 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 (needs to be validated, there were some issues --TheSeven 12:11, 12 July 2009 (UTC))
  • 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 containing many files, but after UTF16 processing (the latter needs to be validated, there were some issues --TheSeven 12:11, 12 July 2009 (UTC))

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 copiues 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. (should not be an issue if they are in fact first transcoded to utf8 and then unescaped --TheSeven 12:11, 12 July 2009 (UTC))

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 finlly 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 hte 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 :

Nanofighter.jpg
  • 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