OOB write bug found via Strshrink at Str.c.

Question

OOB write bug found via Strshrink at Str.c.

TimChan2001 opened this issue 8 months ago · 9 comments

TimChan2001 commented 8 months ago

Hi, we found two OOB write bugs via Strshrink at Str.c.

Reproduction

Build w3m with ASAN, then run

./w3m -dump $POC

We ran it on a 64-bit Ubuntu 20.04, and it also worked on Ubuntu 18.04.

ASAN Report

The POC can be found here. POC1

AddressSanitizer:DEADLYSIGNAL
=================================================================
==23442==ERROR: AddressSanitizer: SEGV on unknown address 0x55d626bb28de (pc 0x55d613dec7f1 bp 0x7ffc359fa1d0 sp 0x7ffc359fa1c0 T0)
==23442==The signal is caused by a WRITE memory access.
    #0 0x55d613dec7f0 in Strshrink /home/cyy/w3m/Str.c:418
    #1 0x55d613d249d1 in checkType /home/cyy/w3m/etc.c:390
    #2 0x55d613d04061 in loadBuffer /home/cyy/w3m/file.c:7727
    #3 0x55d613cb9174 in loadSomething /home/cyy/w3m/file.c:232
    #4 0x55d613cc9005 in loadGeneralFile /home/cyy/w3m/file.c:2288
    #5 0x55d613c8c56b in main /home/cyy/w3m/main.c:1061
    #6 0x7fcc43d85082 in __libc_start_main ../csu/libc-start.c:308
    #7 0x55d613c8778d in _start (/home/cyy/w3m/w3m+0xae78d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/cyy/w3m/Str.c:418 in Strshrink
==23442==ABORTING

The POC can be found here. POC2

AddressSanitizer:DEADLYSIGNAL
=================================================================
==23477==ERROR: AddressSanitizer: SEGV on unknown address 0x558a7545efff (pc 0x558a615d37f1 bp 0x7fff0d353e50 sp 0x7fff0d353e40 T0)
==23477==The signal is caused by a WRITE memory access.
    #0 0x558a615d37f0 in Strshrink /home/cyy/w3m/Str.c:418
    #1 0x558a6150bce9 in checkType /home/cyy/w3m/etc.c:419
    #2 0x558a614eb061 in loadBuffer /home/cyy/w3m/file.c:7727
    #3 0x558a614a0174 in loadSomething /home/cyy/w3m/file.c:232
    #4 0x558a614b0005 in loadGeneralFile /home/cyy/w3m/file.c:2288
    #5 0x558a6147356b in main /home/cyy/w3m/main.c:1061
    #6 0x7ff3c39c6082 in __libc_start_main ../csu/libc-start.c:308
    #7 0x558a6146e78d in _start (/home/cyy/w3m/w3m+0xae78d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/cyy/w3m/Str.c:418 in Strshrink
==23477==ABORTING

Answer 1 · 2023-11-17T09:53:57.000Z

On Fri, Nov 17, 2023 at 12:47:46AM -0800, TimChan2001 wrote: Hi, we found two OOB write bugs via Strshrink at Str.c. ### Reproduction Build w3m with ASAN, then run ``` ./w3m -dump $POC ``` We ran it on a 64-bit Ubuntu 20.04, and it also worked on Ubuntu 18.04. ### ASAN Report 1) The POC can be found here. [POC1](https://github.com/TimChan2001/pocs/raw/main/poc-w3m-w-0)

Can not reproduce on current master.

Answer 2 · 2023-11-17T11:15:21.000Z

It is very weird. I built a new Ubuntu 20.04 Docker to reproduce it. I couldn't reproduce it at first, the output is as follows.

However, after I attach a vscode window of the docker, it outputs as follows.

Will this information help you?

Answer 3 · 2023-11-17T11:25:59.000Z

On Fri, Nov 17, 2023 at 03:15:31AM -0800, TimChan2001 wrote: It is very weird. I built a new Ubuntu 20.04 Docker to reproduce it. I couldn't reproduce it at first, the output is as follows.

[...]

However, after I attach a vscode window of the docker, it outputs as follows.

[...]

Will this information help you?

Please don't post screenshots of text. Just insert the text into the message. Which version did you build?

Answer 4 · 2023-11-17T11:30:15.000Z

The latest version on the current master.
The above two screenshots are as follows:

root@f3299419a4a3:/w3m# ./w3m -dump ./pocs/poc0

??????????????????555555555555555555555555555555
55555555555555555?_A____

root@f3299419a4a3:/w3m# ./w3m -dump ./pocs/poc0
AddressSanitizer:DEADLYSIGNAL
=================================================================
==26715==ERROR: AddressSanitizer: SEGV on unknown address 0x55921dad09fe (pc 0x55920a75c7ee bp 0x7ffd8e53f410 sp 0x7ffd8e53f400 T0)
==26715==The signal is caused by a WRITE memory access.
    #0 0x55920a75c7ed in Strshrink /w3m/Str.c:418
    #1 0x55920a6949d1 in checkType /w3m/etc.c:390
    #2 0x55920a674061 in loadBuffer /w3m/file.c:7727
    #3 0x55920a629174 in loadSomething /w3m/file.c:232
    #4 0x55920a639005 in loadGeneralFile /w3m/file.c:2288
    #5 0x55920a5fc56b in main /w3m/main.c:1061
    #6 0x7fdc424fa082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082)
    #7 0x55920a5f778d in _start (/w3m/w3m+0xae78d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /w3m/Str.c:418 in Strshrink
==26715==ABORTING

Answer 5 · 2023-11-17T11:59:01.000Z

Still cannot reproduce. But we had this problem before. The problem is most likely in checkType. The input data contains a lot of backspaces.

Answer 6 · 2023-11-17T12:13:58.000Z

I may work on easier ways to reproduce it.

Answer 7 · 2023-11-17T13:06:02.000Z

Try this.

docker pull debian:11 && docker run -it debian:11 bash
## now step into the container
apt update && apt install wget git unzip gcc g++ make libgc-dev libtinfo-dev -y
git clone https://github.com/tats/w3m && pushd w3m
export CC="gcc -fsanitize=address -g" && ./configure && make -j
wget https://github.com/TimChan2001/pocs/raw/main/crashes2/47
./w3m -dump ./47

The asan report is

AddressSanitizer:DEADLYSIGNAL
=================================================================
==6467==ERROR: AddressSanitizer: SEGV on unknown address 0x7f456e1acffc (pc 0x56266b734ad5 bp 0x7f456e1acffc sp 0x7ffc5b07e390 T0)
==6467==The signal is caused by a WRITE memory access.
    #0 0x56266b734ad5 in checkType /w3m/etc.c:484
    #1 0x56266b6f8c11 in loadBuffer /w3m/file.c:7727
    #2 0x56266b71e380 in loadSomething /w3m/file.c:232
    #3 0x56266b71e380 in loadGeneralFile /w3m/file.c:2288
    #4 0x56266b6bac7c in main /w3m/main.c:1061
    #5 0x7f4571423d09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09)
    #6 0x56266b6be979 in _start (/w3m/w3m+0xb3979)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /w3m/etc.c:484 in checkType
==6467==ABORTING

I tried many times on different machines and was able to reproduce it consistently.

Answer 8 · 2023-11-17T15:54:04.000Z

On Fri, Nov 17, 2023 at 05:06:12AM -0800, TimChan2001 wrote: Try this.

Thanks, this worked for me. Could you try the patch below, please.

…

-- >8 -- From a3a1db7 Mon Sep 17 00:00:00 2001 From: Rene Kita ***@***.***> Date: Fri, 17 Nov 2023 16:42:48 +0100 Subject: [PATCH] Check for buffer underruns in checkType This fixes Issue #282. --- etc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/etc.c b/etc.c index b5661513..137c7d10 100644 --- a/etc.c +++ b/etc.c @@ -389,6 +389,7 @@ checkType(Str s, Lineprop **oprop, Linecolor **ocolor) else { Strshrink(s, plen); prop -= plen; + prop = prop < prop_buffer ? prop_buffer : prop; #ifdef USE_ANSI_COLOR if (color) color -= plen; @@ -418,6 +419,7 @@ checkType(Str s, Lineprop **oprop, Linecolor **ocolor) else { Strshrink(s, plen); prop -= plen; + prop = prop < prop_buffer ? prop_buffer : prop; #ifdef USE_ANSI_COLOR if (color) color -= plen; @@ -435,7 +437,7 @@ checkType(Str s, Lineprop **oprop, Linecolor **ocolor) } else { Strshrink(s, 1); - prop--; + prop = prop == prop_buffer ? prop_buffer : prop - 1; #ifdef USE_ANSI_COLOR if (color) color--; -- 2.43.0.rc0

Answer 9 · 2023-11-18T03:57:06.000Z

Is this an incomplete fix for CVE-2022-38223 or something? Need I modify the title?