#12 stack-buffer-overflow

[p1ay8y3ar]

hi, i find a stack over-flow when to calculate md5 value.
crashed datas can find in https://github.com/p1ay8y3ar/crashdatas/tree/master/padcrack/29022020
here is ASAN says

freedom@ubuntu:~/Downloads/pdfcrack-0.18$ ./pdfcrack -l /home/freedom/Desktop/pdfcrack/pdfcrack-0.17/o/crashes/id\:000000\,sig\:06\,src\:000072\,op\:ext_AO\,pos\:28
=================================================================
==5441==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe99b24673 at pc 0x55929a48d42c bp 0x7ffe99b24430 sp 0x7ffe99b24420
READ of size 1 at 0x7ffe99b24673 thread T0
    #0 0x55929a48d42b in md5 /home/freedom/Downloads/pdfcrack-0.18/md5.c:79
    #1 0x55929a48da1c in md5_50s /home/freedom/Downloads/pdfcrack-0.18/md5.c:202
    #2 0x55929a48e445 in isUserPasswordRev3 /home/freedom/Downloads/pdfcrack-0.18/pdfcrack.c:261
    #3 0x55929a494d3a in initPDFCrack /home/freedom/Downloads/pdfcrack-0.18/pdfcrack.c:678
    #4 0x55929a477b4d in main /home/freedom/Downloads/pdfcrack-0.18/main.c:304
    #5 0x7f5726b4d1e2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x271e2)
    #6 0x55929a47909d in _start (/home/freedom/Downloads/pdfcrack-0.18/pdfcrack+0x809d)

Address 0x7ffe99b24673 is located in stack of thread T0 at offset 83 in frame
    #0 0x55929a48e26f in isUserPasswordRev3 /home/freedom/Downloads/pdfcrack-0.18/pdfcrack.c:253

  This frame has 3 object(s):
    [32, 48) 'test' (line 254)
    [64, 80) 'enckey' (line 254) <== Memory access at offset 83 overflows this variable
    [96, 112) 'tmpkey' (line 254)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /home/freedom/Downloads/pdfcrack-0.18/md5.c:79 in md5
Shadow bytes around the buggy address:
  0x10005335c870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005335c880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005335c890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10005335c8a0: f1 f1 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00
  0x10005335c8b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10005335c8c0: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 00 00[f2]f2
  0x10005335c8d0: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005335c8e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10005335c8f0: f1 f1 00 00 f2 f2 00 00 f3 f3 00 00 00 00 00 00
  0x10005335c900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005335c910: 00 00 00 00 00 00 f1 f1 f1 f1 01 f2 f8 f2 00 f2
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==5441==ABORTING

[Henning Noren]

Hi p1ay8y3ar!

Thanks for the bug-report!
On the one hand it is in a completely useless part of the code (save-files with wordlists, which does not really work so noone is likely to use it, and for lengths that should not be possible to use in a pdf) but it did send me in a hunt that made me find a problem with my md5-calculation (although, for sizes that is not possible in pdfs - so bug cannot really happen in reality) and since the pdf-specification is not clear how to handle pdfs with encryption dictionary lengths above 128 in revision 3 I just removed that "support" in pdfcrack.
For the interested, the problem is this:
"8. (Revision 3 or greater) Do the following 50 times: Take the output from the previous MD5 hash and pass the first n bytes of the output as input into a new MD5 hash, where n is the number of bytes of the encryption key as defined by the value of the encryption dictionary’s Length entry."
The output key of the previous hash is 16 bytes, so we are therefor in undefined territory when trying to handle anything longer than 16 bytes (128 bits). A Length above that would mean a very undefined pdf, and I have never seen any like that. Some older specs also seems to set the max Length to 128 (not sure if they did back when I originally coded it though).

Both issues should be fixed in the next version (0.19), but there is no hurry to release as this is not something that would come up in a valid pdf. If you are eager to continue fuzzing it, the diff to fix this is the below. Otherwise the next version should pop up when I get in the mood.

Sincerely,
Henning Norén

$ diff -ru pdfcrack-0.18 pdfcrack-0.19
diff -ru pdfcrack-0.18/md5.c pdfcrack-0.19/md5.c
--- pdfcrack-0.18/md5.c 2015-09-23 20:27:19.268561323 +0200
+++ pdfcrack-0.19/md5.c 2020-03-01 18:48:12.564347289 +0100
@@ -75,7 +75,7 @@
for (i = 0; i < n64; ++i) {

 /** grab a 64-byte block */

• for (j = 0; j < 16 && k < msgLen - 3; ++j, k += 4)
• for (j = 0; j < 16 && (signed)k < (signed)msgLen - 3; ++j, k += 4)
  x[j] = ((((((unsigned)msg[k+3] << 8) + (unsigned)msg[k+2]) << 8) + (unsigned)msg[k+1]) << 8) + msg[k];
  if (i == n64 - 1) {
  if (k == msgLen - 3)
  diff -ru pdfcrack-0.18/rc4.c pdfcrack-0.19/rc4.c
  --- pdfcrack-0.18/rc4.c 2017-05-11 05:04:56.499675072 +0200
  +++ pdfcrack-0.19/rc4.c 2020-03-01 18:44:58.104438244 +0100
  @@ -228,7 +228,7 @@
  /* sets which function the wrapper should call /
  bool
  setrc4DecryptMethod(const unsigned int length) {
• if(length > 255 || length < 40 || length % 8 != 0)
• if(length > 128 || length < 40 || length % 8 != 0)
  return false;

if(length == 128) {

[Henning Noren]

Fixed in pdfcrack.0.19