3 ms·
It seems crazy to me that vulnerabilities like this still exist today. I understand that not everything will be written in Rust, but this could have been caught
by pbrowne011 2y ago
It seems crazy to me that vulnerabilities like this still exist today. I understand that not everything will be written in Rust, but this could have been caught by basic testing and/or fuzzing, as Nick (the person who found the vulnerability) points out: https://www.openwall.com/lists/musl/2025/02/14/1 https://www.openwall.com/lists/musl/2025/02/14/1. So far, this earned an 8.1 from MITRE: https://nvd.nist.gov/vuln/detail/CVE-2025-26519 https://nvd.nist.gov/vuln/detail/CVE-2025-26519, although I'm not sure if that's just a function of it being a bug in a library that so many applications use.
This also goes to show how every line matters. The one line change was from
if (c >= 93 || c>=0xc6-0x81 && d>0x52)
to
if (c > 0xc6-0x81 || c==0xc6-0x81 && d>0x52)
Link to relevant source code: https://git.musl-libc.org/cgit/musl/tree/src/locale/iconv.c https://git.musl-libc.org/cgit/musl/tree/src/locale/iconv.c (bug fix is line 505).
To explain the bug, EUC_KR is Extended Unicode - Korean. After ASCII characters (0-127), each character is multiple bytes. The logic adjusts to look up from a base-0 index, then checks that both bytes (variables c and d) are in the normalized range. If not, the code adjusts the characters and checks the bounds again. This second check is what contained the bug.
0xc6 - 0x81 is the upper bound of this check (69), not 93. The irony is that the second part of the check gets this correct. I wonder what a `git blame` would reveal about this particular line.