[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...
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- idna_to_unicode_8z8z() takes a stroll through the heap,
Sam Varshavchik <=