help-libidn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

idna_to_unicode_8z8z() takes a stroll through the heap


From: Sam Varshavchik
Subject: idna_to_unicode_8z8z() takes a stroll through the heap
Date: Wed, 20 Feb 2013 22:17:21 -0500

Greetings!

valgrind will complain at the following:

#include <idna.h>
#include <stringprep.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main()
{
        int err;
        char *utf8_ptr;
        char *p=strdup("example.com\xe3");
        err=idna_to_unicode_8z8z(p, &utf8_ptr, 0);
        free(p);
}


In g_utf8_to_ucs4_fast():

      while (*p)
        {
          p = g_utf8_next_char (p);
          ++n_chars;
        }

When g_utf8_next_char() gets 0xe3, this loop will merrily skip over
the trailing \0 in the C string, and off it goes, into merry-land.

Yes, idna_to_unicode_8z8z() is documented as taking valid UTF-8 for
input. But, is it unreasonable for me to take an address from an
E-mail header, and feed it to idna_to_unicode_8z8z(), without having
to validate it for properly UTF-8ness?

But wait, this gets better.

This is just a small bit of a bunch of code that reformats a header
for further processing/display. The high level logic is:

1) Make a first pass over the input, counting the number of characters
that the entire header gets reformatted into.

2) Allocate a buffer on the heap.

3) Make a second pass over the same input, writing it into the buffer.

But wait, since the output of idna_to_unicode_8z8z() is now
non-deterministic, on the second pass it emitted a larger string, for
the same (invalid) UTF-8 string as it did on the first pass (because
on the second pass, when it walked off the entire of the C string, it
kept walking a little bit longer, because that part of the heap has
changed).

Yay buffer overflow!

I'm not a happy camper, today...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]