Heap overflow when parsing malformed URLs

[Dan Rosenberg]

Binary package hint: lynx-cur

Lynx is vulnerable to a heap overflow when parsing malformed URLs. When Lynx attempts to URL decode hostnames using the convert_to_idna() function in WWW/Library/Implementation/HTParse.c, it mallocs() a destination buffer based on the size of the hostname. However, if a malicious website were to provide a link containing a hostname that included a % character in the last two characters, the parsing code will increment past the null byte of the hostname and continue to copy attacker-controlled contents into the too-small heap buffer. Since this is a heap overflow with attacker-controlled contents and length, with very few character restrictions, this may lead to arbitrary code execution (and winning pwn2own if it were held in 1993).

The attached reproducer causes a crash on my 32-bit Lucid system. It's not entirely reliable due to the fact that stack layout determines whether enough characters are overflowed to trigger glibc's heap checking. I've also attached a fix for the issue, which I've tested and confirmed it resolves the vulnerability.

[Kees Cook (kees)]

It seems to be a clear problem, but I'm unable to reproduce the crash.

[Dan Rosenberg (dan-j-rosenberg)]

Maybe this one will work better.

[Dan Rosenberg (dan-j-rosenberg)]

jduck rightly noticed that my previous fix would break certain functionality (like %0a in URLs), since '0' ASCII also returns 0 from hex_decode(). This new patch is better, and is thanks to him.

[Henri Salo (henri-nerv)]

Please use CVE-2010-2810 for this issue.

[Jamie Strandboge (jdstrand)]

This was fixed in 2.8.8dev.7-1.