[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Jul 2021 15:01:51 +0300
From: "Alexandr Savca (chinarulezzz)" <alexandr.savca89@...il.com>
To: Jeffrey Walton <noloader@...il.com>
Cc: oss-security@...ts.openwall.com, jchelmert3@...teo.net
Subject: Re: Polipo: denial-of-service using range
Hi Jeff,
There is Heap Buffer Overflow:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
==2450==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x602000000277 at pc 0x7fe440a56332 bp 0x7ffd71e73b10 sp 0x7ffd71e732c8
WRITE of size 10 at 0x602000000277 thread T0
#0 0x7fe440a56331 (/usr/lib/libasan.so.6+0x42331)
#1 0x5582d71d4b05 (/usr/bin/polipo+0x150b05)
#2 0x5582d71d0de7 (/usr/bin/polipo+0x14cde7)
#3 0x5582d71c34d2 (/usr/bin/polipo+0x13f4d2)
#4 0x7fe43ff05e09 in __libc_start_main (/lib/libc.so.6+0x23e09)
#5 0x5582d71c3c99 (/usr/bin/polipo+0x13fc99)
0x602000000277 is located 0 bytes to the right of 7-byte region [0x602000000270,0x602000000277)
allocated by thread T0 here:
#0 0x7fe440ac61a7 in __interceptor_malloc (/usr/lib/libasan.so.6+0xb21a7)
#1 0x5582d72a876c (/usr/bin/polipo+0x22476c)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/libasan.so.6+0x42331)
Shadow bytes around the buggy address:
0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff8000: fa fa 00 00 fa fa fd fd fa fa 00 00 fa fa 00 00
0x0c047fff8010: fa fa 00 00 fa fa fd fd fa fa 00 00 fa fa 00 00
0x0c047fff8020: fa fa 00 00 fa fa fd fa fa fa fd fa fa fa fd fa
0x0c047fff8030: fa fa fd fd fa fa fd fd fa fa fd fd fa fa 00 fa
=>0x0c047fff8040: fa fa 01 fa fa fa 00 02 fa fa fd fa fa fa[07]fa
0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8090: 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
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
==2450==ABORTING
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Built with CFLAGS: -O2 -march=x86-64 -pipe -fdiagnostics-color=always -fsanitize=address
-fsanitize=leak -fsanitize=undefined -fsanitize-recover=address -DNDEBUG
Kind Regards,
Alex.
On Mon, 19 Jul 2021 14:18:05 -0400
Jeffrey Walton <noloader@...il.com> wrote:
> > I found a vulnerability in the Polipo [1],
> > lightweight, caching web proxy.
> > ...
> >
> > Polipo doesn't ignore/reject the malformed header. Instead, it has
> > an assertion:
> >
> > server.c:1473: assert(from >= 0 && (to < 0 || to > from));
> >
> > So, a malformed Range header ("Range: bytes=3-2" for example) will
> > cause an assertion failed. This error handling allows an attacker
> > to cause a denial of service.
>
> I would be interested to know what happens when NDEBUG is defined so
> the assert goes away. Does the server crash, does it lead to memory
> corruption, an information leakage (like a private key), or something
> else?
>
> Jeff
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
