Join GitHub today
Out-of-bounds references due to hacks that try to figure out if a string is in the local code page or in UTF-16LE #1575
WinPcap 4.1.1 added a hack to the adapter open path to work around
The hack attempts to check whether the device name string is ASCII (local code page) or UTF-16LE by checking whether the first byte is non-zero and the second byte is zero. If that's the case, it's treated as a UTF-16LE null-terminated string.
Unfortunately, a one-character ASCII string can't be distinguished from the first byte of a UTF-16LE string, and if you mis-identify a one-character ASCII string as a UTF-16LE string, you'll go past the end of the string when processing it as a UTF-16LE string.
The comment from WinPcap 4.1.1 is
Tcpdump, however, uses
If binary compatibility with programs using
Character encodings need some cleanup in libpcap-for-Windows - there should be versions of the API that uniformly use the local code page for strings and that uniformly use UTF-8 for strings, with a define such as PCAP_UTF_8 that, if defined, causes the UTF-8 version of the API to be used, with the local code page version being used otherwise. That way, old programs will still see local code page APIs, and new programs either coming from UNIXland (and making no code page assumptions) or from Windows (and wanting to use full Unicode) can get UTF-8 support.
I'm going to look at implementing that. Is the packet32.dll API sufficiently important enough to need to be stable enough that some of its routines may need similar treatment?