Re: invalid memory access in idna_to_ascii_8z

[Simon Josefsson]

Giuseppe Scrivano <address@hidden> writes:

> Hi Simon,
>
> Nikos Mavrogiannopoulos <address@hidden> writes:
>
>> On Sat, Mar 28, 2015 at 12:51 PM, Nikos Mavrogiannopoulos
>> <address@hidden> wrote:
>>> Hello Simon,
>>>  Robert reported some invalid memory access in gnutls, and one I traced
>>> it back to libidn. A reproducer is attached. The reproducer uses strings
>>> on the heap because valgrind doesn't seem to detect such accesses on the
>>> stack.
>>> ==623== Invalid read of size 1
>>> ==623==    at 0x4E38E7F: g_utf8_to_ucs4_fast (nfkc.c:399)
>>> ==623==    by 0x4E38E7F: stringprep_utf8_to_ucs4 (nfkc.c:1023)
>>> ==623==    by 0x4E3A7DE: idna_to_ascii_8z (idna.c:578)
>>> ==623==    by 0x4005FD: main (in /home/nmav/cvs/gnutls/lib/a.out)
>>> ==623==  Address 0x541105f is 1 bytes after a block of size 30 alloc'd
>>> ==623==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
>>> ==623==    by 0x50E99D9: strdup (strdup.c:42)
>>> ==623==    by 0x4005E0: main (in /home/nmav/cvs/gnutls/lib/a.out)
>>
>> The attached patches handle the reported issue. However, all functions
>> which use g_utf8_next_char() including g_utf8_strlen() are affected.
>
> is there anything holding this patch?

I'll add it to the next release...  it is cosmetic workaround for a
glibc/gcc/valgrind issue, there is no bug in libidn there.

> There is a security issue reported for wget, related to this issue, I
> don't think (as others on bug-wget as well) a workaround in wget is the
> correct solution as it affects any libidn user.
>
> http://lists.gnu.org/archive/html/bug-wget/2015-06/msg00000.html
>
> Could this please be addressed?

That's a completely separate issue.  You need to pass valid UTF-8 to
libidn.  Libidn could help here, and probably should since nobody
appears to get this right, but I haven't looked into how to do it.

/Simon

signature.asc
Description: PGP signature