Glibc Buffer Overflow in Iconv

Original Article ↗ Hacker News Discussion ↗

A newly disclosed buffer overflow in glibc’s iconv implementation, particularly affecting the rare ISO-2022-CN-EXT charset, has prompted admins to rush updates or disable that encoding as a mitigation, with special concern for PHP applications that call iconv(). Commenters debate whether the vulnerability handling followed responsible disclosure norms, noting that patches and a CVE are already in place. The incident also reignites broader arguments over character encodings, from calls to standardize on UTF‑8 to the complexity and security pitfalls of handling text across different languages, filesystems, and programming languages.

Workarounds and Affected Configurations

  • Several comments focus on a practical mitigation: disable the vulnerable ISO-2022-CN-EXT charset in glibc by commenting its entries in gconv-modules / gconv-modules-extra.conf and running iconvconfig to rebuild the cache.
  • Users confirm this removes the charset from iconv -l output and is useful on systems where upgrading glibc is hard (e.g., old VPSes).
  • It’s stressed that this matters not just for PHP; any software using iconv() may be exposed.

Disclosure, CVE, and Process

  • Some wonder if the bug was “burned” for a conference talk.
  • Others respond that there is already a CVE (CVE-2024-2961) and fixed glibc releases in major distros, which suggests maintainers were informed privately first.
  • Consensus: nothing in the thread strongly indicates irresponsible disclosure; talk is likely about exploitation details and finding methodology.

PHP and Exploitability

  • People ask why PHP is being singled out.
  • Replies suggest the key risk is application-specific: PHP code that calls iconv() in particular ways could become an easy path to RCE, but any iconv-using stack could be affected.
  • Automatic charset negotiation via HTTP headers is discussed; on-the-fly conversion by web servers is described as rare.

iconv, Encodings, and POSIX

  • Some wish everything were UTF-8 so iconv wouldn’t be needed, but note it’s mandated by POSIX.
  • Others note a conforming implementation can still refuse specific charset pairs (e.g., by returning EINVAL), so problematic encodings could be disabled.

Unicode, UTF-8, and Security Debate

  • One camp argues Unicode/UTF‑8 everywhere has increased complexity and security bugs (e.g., IDN, email, source code confusables) and should be limited to documents and UI.
  • Opponents push back that this perspective is biased toward English; non-Latin scripts require proper Unicode support to participate fully.
  • Efficiency vs. simplicity is debated: some claim CJK encodings are more space-efficient than UTF‑8; others say in 2024 efficiency is less important than interoperability.

Filenames, Locales, and OS Behavior

  • Discussion touches on UNIX filenames as raw bytes vs. text.
  • Some argue kernels should enforce UTF‑8 filenames; others note backward-compat concerns.
  • There’s debate over how well glibc and locales actually support non‑UTF‑8 encodings in practice, especially for Asian locales.