tidy ASAN build global-buffer-overflow bug

[marcograss]

Hi,

I'm hitting this bug in the latest version 5.2.0 of tidy and also the master

./tidy

==13070==ERROR: AddressSanitizer: global-buffer-overflow on address 0x082b12e6 at pc 0xf7177cf6 bp 0xffc16078 sp 0xffc15c48
READ of size 7 at 0x082b12e6 thread T0
#0 0xf7177cf5 (/usr/lib/i386-linux-gnu/libasan.so.3+0x32cf5)
#1 0x80adab9 in tidySetLanguage /home/bob/VulnResearch/misc/xml/tidy-html5-5.2.0/src/language.c:705
#2 0x805339b in main /home/bob/VulnResearch/misc/xml/tidy-html5-5.2.0/console/tidy.c:1539
#3 0xf6fa7636 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18636)
#4 0x8058553 (/home/bob/VulnResearch/misc/xml/tidy-html5-5.2.0/build/cmake/tidy+0x8058553)

0x082b12e6 is located 58 bytes to the left of global variable 'tidyLanguages' defined in '/home/bob/VulnResearch/misc/xml/tidy-html5-5.2.0/src/language.c:38:26' (0x82b1320) of size 36
0x082b12e6 is located 0 bytes to the right of global variable 'result' defined in '/home/bob/VulnResearch/misc/xml/tidy-html5-5.2.0/src/language.c:603:17' (0x82b12e0) of size 6
SUMMARY: AddressSanitizer: global-buffer-overflow (/usr/lib/i386-linux-gnu/libasan.so.3+0x32cf5)
Shadow bytes around the buggy address:
0x21056200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x21056210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x21056220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x21056230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x21056240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x21056250: 00 00 00 00 00 00 00 00 00 00 00 00[06]f9 f9 f9
0x21056260: f9 f9 f9 f9 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
0x21056270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x21056280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x21056290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x210562a0: 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
==13070==ABORTING

unfortunately I'm not familiar with the project, so I didn't do any analysis, my env is ubuntu 16.04 fully updated

Marco

[geoffmcl]

@marcograss, thanks for the issue...

In the process of setting up a sanitizer build, to try to repeat the problem...

You say this also happens in master v. 5.3.8, or plus... appreciate any more information... thanks...

Will get back soonest...

[AdamMajer]

@marcograss Can you provide input file that triggers this bug?

[marcograss]

no input at all is required to trigger it, just execute tidy with address sanitizer.

[geoffmcl]

@marcograss it seem PR #445 fixes this...

Appreciate it if you get a chance to apply the patch and test... thanks...

[marcograss]

thanks, I will test as soon as I return back to work,

mitre thinks it can be reachable from apps using libtidy, what's your tought about it? they assigned CVE-2016-6583

but I don't have my linux box so I cannot actually check this analysis

[geoffmcl]

@marcograss got a chance to test, and see the bug, and #445 seems to fix, so now merged...

can be reachable from apps using libtidy

Yes, some locale services were added to libtidy, circa Nov. 2015. These are used by our console app, tidy.c, but would be very unlikely to be used by any other app using libtidy, at this stage... For example, they are not yet published in the public API.

They are still under test, as part of Tidy's international language support, but hopefully will be included in the next release... such an app would need access to the source, to even be able to use these API extension... they are presently only in language.h, which is not installed by distributions...

Anyway, tests of version 5.3.9 (2016.08.04) show this has been fixed... Hope you get the chance to pull, build and re-test, maybe closing this, and the CVE-2016-6583... thanks...

[geoffmcl]

@marcograss, @AdamMajer, have you had a chance to test, re-test this?

I just had a chance to built and run a sanitize Tidy version, in my RPI2/Raspbian/arm7 machine, using cmake ../.. -DCMAKE_C_FLAGS=-fsanitize=address [options], and the problem seems fixed in the current master 5.3.9...

Can we close this? ... thanks...

[geoffmcl]

@marcograss just tried this -DCMAKE_C_FLAGS=-fsanitize=address in a 3rd system, and it seems fully fixed, and since no further comments for 3/4 months, closing this...

Please feel free to re-open, or open another issue.... thanks...