Differences

This shows you the differences between two versions of the page.

--- exploit [2011/08/14 19:34] – add another variant hessophanes
+++ exploit [2011/08/19 13:38] (current) – [The Keys] nitram
@@ Line 61: / Line 61: @@
 </code>
-c is the glyph index and ought to be in the range [firstChar,lastChar], but it is at least type 'int', so it is theoretically possible to make the outcome negative. And indeed, the responsible function _getIndex() is vulnerable to fonts like this:
+c is the glyph index and ought to be in the range [0,u8LastChar-u8FirstChar+numExtras], but it is at least type 'int', so it is theoretically possible to make the outcome negative. And indeed, the responsible function _getIndex() is vulnerable to fonts like this:
 <code>
@@ Line 68: / Line 68: @@
 Input characters in the range '0xf0-0xff' are then mapped through the "extras" feature because they are greater than u8LastChar, and their index value is calculated as (u8LastChar+1+matched_extras_entry-u8FirstChar), which happens to be (-0xef) for input 0xf0. This trick enables us to read far enough to discover the keys, encrypt&sign a proper firmware-dump l0dable and retrieve the rest... although we must admit that reading all those pixels from the display and converting them back to data was painful.
+===== Other attack vectors ====
+We (from [[http://events.ccc.de/camp/2011/wiki/Chaostreff_Heilbronn|Chaostreff Heilbronn village]])
+also discovered some attack vectors. Even if we didn't extracted the 128bit holy grail,
+these vectors should be closed to prevent others from p0wning your device ;-)
+Finally we want to say **Thank You** too all the people who inspired us (CCCP, deadbyte, red becon, TkkrLab, and others).
+====== charBuf overflow ======
+Basically by using the charBuf overflow already mentioned above,
+you're able to overwrite some special data structure, containing up-codes.
+These up-codes are executed in IAP (In Application Programming) context.
+This means, you can place custom ones there.
+PoC may follow.
+Additionally, this overflow is able to write into the section, where the l0dables
+are located. This means you can do some kind of heap spraying by using special prepared custom fonts.
+We've discovered, that ''0x00 0x00'' is a possible equivalent to NOP.
+**Countermeasure**: fix charBuf buffer overflow
+====== Receive VCard, remote exploits ======
+The method ''filetransfer_receive()'' within ''recvcard.c'' doesn't validate
+the incoming file name but using the file name directly from the received meta data.
+Thus it's possible to send l0dables (*.c0d).
+This could be an option for remote exploits, when combining with other vectors.
+**Countermeasure:** Extra check the incoming meta data and create only valid VCARD files.
+====== Two-staged l0dable exploit (unfinished) ======
+We didn't were scared about the [[http://en.wikipedia.org/wiki/XXTEA|XXTEA]] crypto algorithm which
+protected the l0dables, but also tried to circumvent the checks.
+In the end we came up with a two staged approach, which may work, if some one fixes the "firmware bug" ;-)
+**Stage 1:**\\
+Prepare some l0dable with your shell code by
+   a) do not encrypt it
+   b) add 16 bytes of padding in front of your code (using NOPs and/or hex editor)
+   c) make sure the file size is not a multiple by 16 (simply add some 0x00s)
+Put this l0dable on your original protected device and execute it.
+This should result in error code ''size!''. But our shell code is now loaded right in place.
+**Stage 2:**\\
+Now we want to execute our code. Therefore we spotted out two possible options,
+where no special checks/validations are existing.
+   a) Zero-size l0dable: Create a file with size=0 and execute it right after stage 1.
+      This will keep our stage 1 code in place and bypass the size check.
+      Unluckily this will end up in a integer overflow within the ''xxtea_cbcmac()'' see ''len-4''.
+   b) 16-byte l0dable: Create a file with size=16, containing 0x00 and execute it right after stage 1.
+      This will also keep our stage 1 code in place, bypass the size check
+      and bypass the MAC check.
+      Unluckily this will end up in a division by zero exception within ''xxtea_decode_words()''.
+      At this point, only a programming bug prevents us from successfully running our code!
+      Because every static code analyzer will spot this as a devision by 0 programming error,
+      there is some hope, that someday this could be fixed and exploited.
+      Remember the OpenSSL issue CVE-2008-0166? ;-)
+**Countermeasure:** (1) Clean the memory before loading new l0dables. (2) Do more checks before executing loaded code.