[Bug libc/28524] New: Conversion from ISO-2022-JP-3 with iconv may emit spurious NUL character on state reset

["npv1310 at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28524

            Bug ID: 28524
           Summary: Conversion from ISO-2022-JP-3 with iconv may emit
                    spurious NUL character on state reset
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: npv1310 at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 13751
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13751&action=edit
Proof of concept

Hello, while investigating CVE-2021-3326 patch [here:
https://sourceware.org/git/?p=glibc.git;a=commit;h=7d88c6142c6efc160c0ee5e4f85cde382c072888]
I've found that it is possible to force iconv() to emit spurious NUL character
by converting from ISO-2022-JP-3 encoding and resetting internal state (inbuf =
NULL). This is possible because code sequence in iconvdata/iso-2022-jp-3.c
which is responsible for resetting internal state doesn't ensure that any
character has actually been saved. The main condition [data->__statep->__count
!= ASCII_set] also picks a cases where current set is different from ASCII_set.
I've written small proof-of-concept which is attached.
In a research environment, proof-of-concept program was compiled with following
command sequence:
$ gcc iconv-issue.c -c -Wall -o /tmp/iconv-issue.o
$ gcc -o /tmp/iconv-issue -nostdlib -nostartfiles /root/glibc-build/csu/Scrt1.o
/root/glibc-build/csu/crti.o `gcc  --print-file-name=crtbeginS.o`
/tmp/iconv-issue.o
-Wl,-rpath-link=/root/glibc-build:/root/glibc-build/math:/root/glibc-build/elf:/root/glibc-build/dlfcn:/root/glibc-build/nss:/root/glibc-build/nis:/root/glibc-build/rt:/root/glibc-build/resolv:/root/glibc-build/mathvec:/root/glibc-build/support:/root/glibc-build/crypt:/root/glibc-build/nptl
/root/glibc-build/libc.so.6 `gcc  --print-file-name=crtendS.o`
/root/glibc-build/csu/crtn.o
$ env GCONV_PATH=/root/glibc-build/iconvdata
LOCPATH=/root/glibc-build/localedata LC_ALL=C
/root/glibc-build/elf/ld-linux-x86-64.so.2 --library-path
/root/glibc-build:/root/glibc-build/math:/root/glibc-build/elf:/root/glibc-build/dlfcn:/root/glibc-build/nss:/root/glibc-build/nis:/root/glibc-build/rt:/root/glibc-build/resolv:/root/glibc-build/mathvec:/root/glibc-build/support:/root/glibc-build/crypt:/root/glibc-build/nptl
/tmp/iconv-issue
Here /root/glibc-build is a build root for up-to-date version of glibc.

The last command results in a following output:
Step#1
 Input characters consumed = 3
Output characters produced = 0
Step#2
Output characters produced = 1

With glibc lacking CVE-2021-3326 fix output is normal:
Step#1
 Input characters consumed = 3
Output characters produced = 0
Step#2
Output characters produced = 0

I assess that this behavior may affect data integrity in certain use patterns
of iconv where extra data ('\0') is added.
Such NUL character may confuse programs expecting NUL as the data terminator.

-- 
You are receiving this mail because:
You are on the CC list for the bug.