Hi, On Wed, Aug 28, 2024 at 08:14:20PM +0200, a1ex@dismail.de wrote:
Hi,
On Wed, 28 Aug 2024 19:12:43 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
You may be able to get some info on where it is failing by building Dillo with the address sanitizer enabled:
$ git clone https://github.com/dillo-browser/dillo $ cd dillo $ ./autogen.sh $ mkdir build $ cd build $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' $ make $ src/dillo https://narkive.com
That doesn't seem to work:
$ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' checking build system type... x86_64-unknown-openbsd7.6 [...] configure: error: C compiler cannot create executables See `config.log' for more details
Oh, I didn't knew it was not supported in OpenBSD. Well, I added a simple patch to reproduce your problem, and I got a heap use after free with asan: hop% LD_LIBRARY_PATH=/usr/lib/libressl src/dillo https://narkive.com dillo_dns_init: Here we go! (threaded) TLS library: LibreSSL 3.9.2 Enabling cookies as from cookiesrc... Nav_open_url: new url='https://narkive.com' Dns_server [0]: narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 TLS connect error: "an EOF was observed that violates the protocol" Tls_close_by_key: Avoiding SSL shutdown for: https://narkive.com fd 6 is done and failed ================================================================= ==1646866==ERROR: AddressSanitizer: heap-use-after-free on address 0x5030002c8649 at pc 0x64733a019b37 bp 0x7ffd6d8bfe00 sp 0x7ffd6d8bfdf0 WRITE of size 1 at 0x5030002c8649 thread T0 #0 0x64733a019b36 in Tls_connect IO/../../../src/IO/tls_openssl.c:1201 #1 0x64733a019d88 in a_Tls_openssl_connect IO/../../../src/IO/tls_openssl.c:1266 #2 0x64733a019e9a in a_Tls_connect IO/../../../src/IO/tls.c:133 #3 0x64733a01a10d in Http_connect_tls IO/../../../src/IO/http.c:521 #4 0x64733a01b7c4 in Http_connect_socket_cb IO/../../../src/IO/http.c:555 #5 0x769620b7c1f3 in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa51f3) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #6 0x769620b1b09a in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x4409a) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #7 0x769620b1b15d in Fl::run() (/usr/lib/libfltk.so.1.3+0x4415d) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #8 0x647339fd912c in main ../../src/dillo.cc:583 #9 0x769620039c87 (/usr/lib/libc.so.6+0x25c87) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) #10 0x769620039d4b in __libc_start_main (/usr/lib/libc.so.6+0x25d4b) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) #11 0x647339fb8894 in _start (/home/ram/dev/dillo/git/build-libressl/src/dillo+0xe1894) (BuildId: 83bcb2b57d527264c53219ed2204e01b019e3e34) 0x5030002c8649 is located 25 bytes inside of 32-byte region [0x5030002c8630,0x5030002c8650) freed by thread T0 here: #0 0x769620cfb422 in free /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:52 #1 0x64733a083ca3 in dFree ../../dlib/dlib.c:70 #2 0x64733a019782 in Tls_connect IO/../../../src/IO/tls_openssl.c:1192 #3 0x64733a019d88 in a_Tls_openssl_connect IO/../../../src/IO/tls_openssl.c:1266 #4 0x64733a019e9a in a_Tls_connect IO/../../../src/IO/tls.c:133 #5 0x64733a01a10d in Http_connect_tls IO/../../../src/IO/http.c:521 #6 0x64733a01b7c4 in Http_connect_socket_cb IO/../../../src/IO/http.c:555 #7 0x769620b7c1f3 in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa51f3) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #8 0x769620b1b09a in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x4409a) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #9 0x769620b1b15d in Fl::run() (/usr/lib/libfltk.so.1.3+0x4415d) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #10 0x647339fd912c in main ../../src/dillo.cc:583 #11 0x769620039c87 (/usr/lib/libc.so.6+0x25c87) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) #12 0x769620039d4b in __libc_start_main (/usr/lib/libc.so.6+0x25d4b) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) #13 0x647339fb8894 in _start (/home/ram/dev/dillo/git/build-libressl/src/dillo+0xe1894) (BuildId: 83bcb2b57d527264c53219ed2204e01b019e3e34) previously allocated by thread T0 here: #0 0x769620cfca31 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x64733a083c3a in dMalloc ../../dlib/dlib.c:47 SUMMARY: AddressSanitizer: heap-use-after-free IO/../../../src/IO/tls_openssl.c:1201 in Tls_connect Shadow bytes around the buggy address: 0x5030002c8380: fa fa fd fd fd fa fa fa fd fd fd fd fa fa fd fd 0x5030002c8400: fd fd fa fa 00 00 00 00 fa fa fd fd fd fd fa fa 0x5030002c8480: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd 0x5030002c8500: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 0x5030002c8580: 00 fa fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa =>0x5030002c8600: 00 00 00 fa fa fa fd fd fd[fd]fa fa fd fd fd fa 0x5030002c8680: fa fa fd fd fd fa fa fa 00 00 00 fa fa fa 00 00 0x5030002c8700: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 fa fa fa 0x5030002c8780: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd 0x5030002c8800: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd 0x5030002c8880: fd fd fa fa fd fd fd fd fa fa fd fd fd fd 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 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 ==1646866==ABORTING Hopefully is the same you are seeing. Here is the patch I'm using: diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c index 3e68e928..05d795a5 100644 --- a/src/IO/tls_openssl.c +++ b/src/IO/tls_openssl.c @@ -1108,8 +1108,11 @@ static void Tls_connect(int fd, int connkey) a_IOwatch_remove_fd(fd, -1); + ret = 0; + if (ret <= 0) { int err1_ret = SSL_get_error(conn->ssl, ret); + err1_ret = SSL_ERROR_SYSCALL; if (err1_ret == SSL_ERROR_WANT_READ || err1_ret == SSL_ERROR_WANT_WRITE) { int want = err1_ret == SSL_ERROR_WANT_READ ? DIO_READ : DIO_WRITE; This is enough for me to at least fix this case on Dillo side. However, it doesn't explain the EOF you are getting in narkive. Are you using tor or some proxy? Best, Rodrigo.