8 ms·

Glibc Buffer Overflow in Iconv

185 points by theamk 3y ago

keikobadthebad 3y ago
Sounds like you had better upgrade to the fixed glibc version if you're running php...
- smsm42 3y ago
  Or if you're not running PHP, since surprisingly enough PHP is not the only software using iconv() function.
- thenickdude 3y ago
  Or else edit /usr/lib/x86_64-linux-gnu/gconv/gconv-modules and comment out this section: # from to module cost alias ISO2022CNEXT// ISO-2022-CN-EXT// module ISO-2022-CN-EXT// INTERNAL ISO-2022-CN-EXT 1 module INTERNAL ISO-2022-CN-EXT// ISO-2022-CN-EXT 1 Then run "iconvconfig" to rebuild the iconv cache. This disables that charset completely.
  - LXicon 3y ago
    As a test on various distros, I ran iconv -l |grep 2022 |grep -i cn and it listed ISO-2022-CN-EXT// and ISO2022CNEXT// before I made any changes. After editing the modules and running iconvconfig the command no longer showed those charsets. This was handy since the alma8 has a /usr/lib64/gconv/gconv-modules file but the file to edit was /usr/lib64/gconv/gconv-modules.d/gconv-modules-extra.conf
    - voyagerfan5761 3y ago
      Thanks a bunch to you and thenickdude for the test command and config to change. I have an old VPS that isn't worth trying to update to a newer OS image, because I'm already (slowly) migrating things off of it before the current paid-up term expires, but it definitely won't get the newer glibc. Disabling the vulnerable character encoding works for me, since no legitimate user of the server will need these conversion pairs.
saagarjha 3y ago
> I hope Charles will share further detail with oss-security in due time, but meanwhile his upcoming OffensiveCon talk abstract reveals a bit Wonder what the story is here. Burned 0 day? Not worth exploiting? lolz?
- bawolff 3y ago
  Why do you think there is a story here? Witholding the nitty gritty details until your conference talk is not that unusual.
  - saagarjha 3y ago
    Well for one usually library maintainers don't learn about bugs in their software from the abstracts of security talks
    - kzrdude 3y ago
      There's a CVE for it - CVE-2024-2961 - and fixed glibc versions have already been released (and reached Ubuntu LTS for one thing) so I think it's fine.
    - bawolff 3y ago
      Responsible disclosure generally means you tell the maintainers first before doing your splashy talk. Which appears to be what happened here since there is a cve, and we know mostly what was fixed. The talk would probably just go into nitty gritty details about how it was found and how its exploitable, stuff a skilled researcher would already be able to figure out based on what has already been publicly released.
      - saagarjha 3y ago
        idk I read that as "I found out about this from the abstract". Not sure if it was shared in advance
        3y ago
blueflow 3y ago
Man, i wish everything was UTF-8 so we iconv would not be needed anymore. Too bad its defined in POSIX.
- rwmj 3y ago
  A corollary to this is that if we had a simpler function for converting between UTF-8 and UTF-16LE, then I could remove all uses of iconv from my code, since I only use it to convert to/from MS Windows formats. (iconv's API is ugly and difficult to use correctly.)
  - blueflow 3y ago
    Ugh i forgot about Windows. Windows used UCS-2 some decades ago, from there, UCS-2 got standardized into MEFI FAT and that document got incorporated into the EFI spec which is now the mechanism how x86 boots.
    - mananaysiempre 3y ago
      There’s more fun stuff like that: because Microsoft wrote the spec for the Language Server Protocol, the offsets in it are in UTF-16 code units even though the transport format is UTF-8. (This is less awful than it sounds, because a code point takes two UTF-16 code units iff it takes the maximum allowed four UTF-8 ones, i.e. if its UTF-8 starts with ≥ 0xF0. But it’s still pretty awful.) And of course UCS-2 had also been baked into Java and Java/ECMAScript at about the same time (circa 1990) and only afterwards was it half-brokenly extended to UTF-16. In defense of all those usages (except the LSP one, which is indefensible), the original pitches for Unicode[1] literally said that it was intended to be fixed-width, an international ASCII of sorts; that was to be achieved by restricting it to “commercially-relevant” text (and Han unification). Then it turned out there are plenty of very rare Han characters people really, really want to see encoded (for place and personal names, etc.). Of course, in hindsight an encoding with nontrivial string equivalences (e.g. combining diacritics) was never going to be as simple to handle as ASCII. [1] https://unicode.org/history/unicode88.pdf https://unicode.org/history/unicode88.pdf
  - 3y ago
CodesInChaos 3y ago
I wonder what the PHP specific part is. Does it automatically convert the encoding based on a request header?
- smsm42 3y ago
  I seriously doubt you can make PHP convert anything to that exotic charset automatically even with creative configuration, and pretty much sure it wouldn't do any of the sort in common configuration. What I suspect is going on is that the author is interested in exploiting PHP engine and is assuming PHP code using iconv() and wants to talk about how to get from there to full scale RCE. It is indeed a fascinating and non-trivial topic, though the relationship between a particular CVE and the PHP angle is rather coincidental - any buffer overflow would do, it's just the author happened to have one in a reasonably common function.
- fweimer 3y ago
  That's the other direction (legacy charset conversion to UCS-4 or UTF-8). This other direction is often reachable using the charset parameter in the Content-Type header and similar MIME contexts. HTTP theoretically supports Accept-Charset, but it's deprecated: https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-charset https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-char... But I think on-the-fly charset conversion in the web server is quite rare. Apache httpd does not seem to implement it: https://httpd.apache.org/docs/2.4/content-negotiation.html#methods https://httpd.apache.org/docs/2.4/content-negotiation.html#m... The charset in question does not have a locale associated with it (it's not even ASCII-transparent), so I don't think it's usable in a local context together with SUID/SGID/AT_SECURE programs.
- lyu07282 3y ago
  My guess is, it's application specific, php applications that use the iconv function in some specific way, in some specific context, will be vulnerable. https://www.php.net/manual/en/function.iconv.php https://www.php.net/manual/en/function.iconv.php
- pengaru 3y ago
  Your comment knocked loose a long dormant memory https://en.wikipedia.org/wiki/Magic_quotes https://en.wikipedia.org/wiki/Magic_quotes

185 points by theamk 3y ago

keikobadthebad 3y ago

Sounds like you had better upgrade to the fixed glibc version if you're running php...

smsm42 3y ago
Or if you're not running PHP, since surprisingly enough PHP is not the only software using iconv() function.
thenickdude 3y ago
Or else edit /usr/lib/x86_64-linux-gnu/gconv/gconv-modules and comment out this section: # from to module cost alias ISO2022CNEXT// ISO-2022-CN-EXT// module ISO-2022-CN-EXT// INTERNAL ISO-2022-CN-EXT 1 module INTERNAL ISO-2022-CN-EXT// ISO-2022-CN-EXT 1 Then run "iconvconfig" to rebuild the iconv cache. This disables that charset completely.
- LXicon 3y ago
  As a test on various distros, I ran iconv -l |grep 2022 |grep -i cn and it listed ISO-2022-CN-EXT// and ISO2022CNEXT// before I made any changes. After editing the modules and running iconvconfig the command no longer showed those charsets. This was handy since the alma8 has a /usr/lib64/gconv/gconv-modules file but the file to edit was /usr/lib64/gconv/gconv-modules.d/gconv-modules-extra.conf
  - voyagerfan5761 3y ago
    Thanks a bunch to you and thenickdude for the test command and config to change. I have an old VPS that isn't worth trying to update to a newer OS image, because I'm already (slowly) migrating things off of it before the current paid-up term expires, but it definitely won't get the newer glibc. Disabling the vulnerable character encoding works for me, since no legitimate user of the server will need these conversion pairs.

saagarjha 3y ago

> I hope Charles will share further detail with oss-security in due time, but meanwhile his upcoming OffensiveCon talk abstract reveals a bit Wonder what the story is here. Burned 0 day? Not worth exploiting? lolz?

bawolff 3y ago
Why do you think there is a story here? Witholding the nitty gritty details until your conference talk is not that unusual.
- saagarjha 3y ago
  Well for one usually library maintainers don't learn about bugs in their software from the abstracts of security talks
  - kzrdude 3y ago
    There's a CVE for it - CVE-2024-2961 - and fixed glibc versions have already been released (and reached Ubuntu LTS for one thing) so I think it's fine.
  - bawolff 3y ago
    Responsible disclosure generally means you tell the maintainers first before doing your splashy talk. Which appears to be what happened here since there is a cve, and we know mostly what was fixed. The talk would probably just go into nitty gritty details about how it was found and how its exploitable, stuff a skilled researcher would already be able to figure out based on what has already been publicly released.
    - saagarjha 3y ago
      idk I read that as "I found out about this from the abstract". Not sure if it was shared in advance
      - 3y ago

blueflow 3y ago

Man, i wish everything was UTF-8 so we iconv would not be needed anymore. Too bad its defined in POSIX.

rwmj 3y ago
A corollary to this is that if we had a simpler function for converting between UTF-8 and UTF-16LE, then I could remove all uses of iconv from my code, since I only use it to convert to/from MS Windows formats. (iconv's API is ugly and difficult to use correctly.)
- blueflow 3y ago
  Ugh i forgot about Windows. Windows used UCS-2 some decades ago, from there, UCS-2 got standardized into MEFI FAT and that document got incorporated into the EFI spec which is now the mechanism how x86 boots.
  - mananaysiempre 3y ago
    There’s more fun stuff like that: because Microsoft wrote the spec for the Language Server Protocol, the offsets in it are in UTF-16 code units even though the transport format is UTF-8. (This is less awful than it sounds, because a code point takes two UTF-16 code units iff it takes the maximum allowed four UTF-8 ones, i.e. if its UTF-8 starts with ≥ 0xF0. But it’s still pretty awful.) And of course UCS-2 had also been baked into Java and Java/ECMAScript at about the same time (circa 1990) and only afterwards was it half-brokenly extended to UTF-16. In defense of all those usages (except the LSP one, which is indefensible), the original pitches for Unicode[1] literally said that it was intended to be fixed-width, an international ASCII of sorts; that was to be achieved by restricting it to “commercially-relevant” text (and Han unification). Then it turned out there are plenty of very rare Han characters people really, really want to see encoded (for place and personal names, etc.). Of course, in hindsight an encoding with nontrivial string equivalences (e.g. combining diacritics) was never going to be as simple to handle as ASCII. [1] https://unicode.org/history/unicode88.pdf https://unicode.org/history/unicode88.pdf
- 3y ago

CodesInChaos 3y ago

I wonder what the PHP specific part is. Does it automatically convert the encoding based on a request header?

smsm42 3y ago
I seriously doubt you can make PHP convert anything to that exotic charset automatically even with creative configuration, and pretty much sure it wouldn't do any of the sort in common configuration. What I suspect is going on is that the author is interested in exploiting PHP engine and is assuming PHP code using iconv() and wants to talk about how to get from there to full scale RCE. It is indeed a fascinating and non-trivial topic, though the relationship between a particular CVE and the PHP angle is rather coincidental - any buffer overflow would do, it's just the author happened to have one in a reasonably common function.
fweimer 3y ago
That's the other direction (legacy charset conversion to UCS-4 or UTF-8). This other direction is often reachable using the charset parameter in the Content-Type header and similar MIME contexts. HTTP theoretically supports Accept-Charset, but it's deprecated: https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-charset https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-char... But I think on-the-fly charset conversion in the web server is quite rare. Apache httpd does not seem to implement it: https://httpd.apache.org/docs/2.4/content-negotiation.html#methods https://httpd.apache.org/docs/2.4/content-negotiation.html#m... The charset in question does not have a locale associated with it (it's not even ASCII-transparent), so I don't think it's usable in a local context together with SUID/SGID/AT_SECURE programs.
lyu07282 3y ago
My guess is, it's application specific, php applications that use the iconv function in some specific way, in some specific context, will be vulnerable. https://www.php.net/manual/en/function.iconv.php https://www.php.net/manual/en/function.iconv.php
pengaru 3y ago
Your comment knocked loose a long dormant memory https://en.wikipedia.org/wiki/Magic_quotes https://en.wikipedia.org/wiki/Magic_quotes