search

RfidResearchGroup / proxmark3

Iceman Fork - Proxmark3
http://www.icedev.se
GNU General Public License v3.0
3.95k stars 1.05k forks source link

mfdes writedata with data above ~132 bytes results in buffer overflow and crash #977

Closed aveao closed 4 years ago

aveao commented 4 years ago

Describe the bug\ Writing large amounts of data (in this example, 132 bytes) using mfdes (but smaller than the documented limit of 0xFFFF bytes) causes a buffer overflow, which in turn results in stack smashing detection to terminate the client.

Parameter error: buffer overflow.
*** stack smashing detected ***: terminated

To Reproduce Steps to reproduce the behavior:

  1. Create a desfire file with a large amount of bytes (hf mfdes createfile -f 0001 -n 01 -c 0 -r EEEE -s 000085 -a 123456)
  2. Write data with that amount of bytes (hf mfdes writedata -n 01 -t 0 -a 123456 -o 000000 -d AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
  3. Observe error

Expected behavior I expected the write to file to succeed as it does for shorter input.

Screenshots

Desktop (please complete the following information):

[#] Memory
[#]   BigBuf_size.............42520
[#]   Available memory........42464
[#] Tracing
[#]   tracing ................1
[#]   traceLen ...............0
[#]   dma8 memory.............-2111648
[#]   dma16 memory............-2111648
[#]   toSend memory...........-2111648
[#] Current FPGA image
[#]   mode.................... HF image built for 2s30vq100 on 2020-07-08 at 23: 8:19
[#] Flash memory
[#]   Baudrate................24 MHz
[#]   Init....................OK
[#]   Memory size.............2 mbits / 256 kb
[#]   Unique ID...............0xD5690C23DFAEB12A
[#] Smart card module (ISO 7816)
[#]   version.................v3.11
[#] LF Sampling config
[#]   [q] divisor.............95 ( 125.00 kHz )
[#]   [b] bits per sample.....8
[#]   [d] decimation..........1
[#]   [a] averaging...........Yes
[#]   [t] trigger threshold...0
[#]   [s] samples to skip.....0
[#] LF Sampling Stack
[#]   Max stack usage.........3936 / 8480 bytes
[#] LF T55XX config
[#]            [r]               [a]   [b]   [c]   [d]   [e]   [f]   [g]
[#]            mode            |start|write|write|write| read|write|write
[#]                            | gap | gap |  0  |  1  | gap |  2  |  3
[#] ---------------------------+-----+-----+-----+-----+-----+-----+------
[#] fixed bit length (default) |  29 |  17 |  15 |  47 |  15 | N/A | N/A |
[#]     long leading reference |  29 |  17 |  18 |  50 |  15 | N/A | N/A |
[#]               leading zero |  29 |  17 |  18 |  40 |  15 | N/A | N/A |
[#]    1 of 4 coding reference |N/A | N/A | N/A | N/A | N/A | N/A | N/A |
[#]
[#] HF 14a config
[#] [a] Anticol override......0: No (follow standard)
[#] [b] BCC override..........0: No (follow standard)
[#] [2] CL2 override..........0: No (follow standard)
[#] [3] CL3 override..........0: No (follow standard)
[#] [r] RATS override.........0: No (follow standard)
[#] Transfer Speed
[#]   Sending packets to client...
[#]   Time elapsed............500ms
[#]   Bytes transferred.......279040
[#]   Transfer Speed PM3 -> Client = 558080 bytes/s
[#] Various
[#]   Max stack usage.........4080 / 8480 bytes
[#]   DBGLEVEL................1 ( ERROR )
[#]   ToSendMax...............-1
[#]   ToSend BUFFERSIZE.......2308
[#]   Slow clock..............31864 Hz
[#] Installed StandAlone Mode
[#]   HF Mifare Ultralight read/simulation by Ave Ozkal
[#] Flash memory dictionary loaded
[#]   Mifare..................961 keys
[#]   T55x7...................110 keys
[#]   iClass..................7 keys
[=] Measuring antenna characteristics, please wait...
 🕙  10
[=] ---------- LF Antenna ----------
[+] LF antenna: 70.02 V - 125.00 kHz
[+] LF antenna: 33.02 V - 134.83 kHz
[+] LF optimal: 70.02 V - 125.00 kHz
[+] LF antenna is OK
[=] ---------- HF Antenna ----------
[+] HF antenna: 47.38 V - 13.56 MHz
[+] HF antenna is OK

[+] Displaying LF tuning graph. Divisor 88 is 134.83 kHz, 95 is 125.00 kHz.

Additional context

In my specific case writes with byte counts above 47 seems to fail too, but I deployed a temporary fix where I changed the following lines to be 47, which fixed that issue for me (I am trying to figure out why it fails, and this is a mere workaround):

https://github.com/RfidResearchGroup/proxmark3/blob/42eb98cdda13f54658556fd96766939901228895/client/src/cmdhfmfdes.c#L1712-L1713

If this is not just a quirk of this particular card, it may be needed to apply a workaround/fix such as this while testing this bug.

iceman1001 commented 4 years ago

There isn't any real chance of writing 0xFFFF bytes from command line ever,

  1. command line buffer limit 1000b
  2. client - device package limit 512b
  3. device to tag limit 255b

Even if the DESfire protocol allows for sizes, the Pm3 client isn't. If the command line isn't resized and taken care for the best you can hope for is about 255bytes in one go. Which fits into the other limits. However I doubt even that will work since readline on the different platforms this repo is used with might also have an smaller limit. And I am no sure how the parameter read hex string from command line string deals with these sizes.

With that said, the client should be able to input and correctly parse 255 bytes of data without smashing stacks.

aveao commented 4 years ago

I see, that does indeed make sense.

I think simply changing the help text from saying that the limit is 0xFFFF to 132 bytes would be a good enough fix, or if you have any ideas on how to get it working with 255 bytes, doing that and updating the help text accordingly.

iceman1001 commented 4 years ago

Of course I have :)

The steps

  1. input bytearray size
  2. is in the paramget xall with your parameter converts hex string -> byte array. Verify it works for 255b.
  3. send to device usb package.

That should sort out the client side problems,

aveao commented 4 years ago

As I mentioned on discord I did pretty much that (except this uses CLIParamHexToBuf instead of param_gethex), and it seems to work fine. Thanks a lot for the pointers, will PR shortly.

iceman1001 commented 4 years ago

Excellent!