Iconv, set the charset to RCE: Exploiting the glibc to hack the PHP engine | Hacker News Reader

Iconv, set the charset to RCE: Exploiting the glibc to hack the PHP engine

ambionics.io

76 pointstodsacerdoti11 comments

What is the relationship between glibc's iconv and libiconv? Both are GNU. They have the same API (but different symbols). Is glibc's iconv more or less a copy of libiconv code? Do they have the same bugs?

I can't really tell you the why, but they're different implementations with different bugs.

`iconv` and `libiconv` both provide character encoding conversion functionality using the same API, but they are distinct implementations. glibc's `iconv` is integrated directly into glibc, making it the default option for systems that use glibc, such as most GNU/Linux distros. inconv is kept updated with glibc.

`libiconv` is a standalone library designed to provide encoding conversion on systems where the standard C library does not include this functionality, or where additional or different conversions are needed.

Despite their API compatibility, the two implementations have different internal symbols to avoid conflicts, allowing both to coexist on the same system if necessary. The two are maintained by separate teams within the GNU project, with glibc's version being tailored specifically for integration with the GNU C Library and `libiconv` serving as a more portable solution for a variety of environments.

Might be a little naive but this looks to be mostly exploited by blindly trusting user input which pretty much always should be avoided

Yes, but people make mistakes, and escalating that to 100 and an RCE is not brilliant.

There really should be an option to just these stupid fopen wrappers. The entire feature is profoundly misguided, and not even that useful.

The post says "Big applications (such as Drupal or Magento) have been disabling the phar:// protocol", but I can't even figure out how to do that in a quick check, other than a configure option.

As this vulnerability exploits weird charset, is is possible to just whitelist the encodings system-wide ? Ideally all charset libraries should reject charsets out of that list.

There are so many implementations of charset conversions (each programming language has one or many implementations) and so many document format that allow to trigger them. If I write an internal backoffice application I should be able to constrain that any use of an exotic charset is suspect and should be blocked.

After programming in php for 10+ years, I had never heard of the filter syntax.

Given it’s pretty trivial to implement what filter is doing in procedural code, it doesn’t seem like the syntax sugar is worth it.

Any idea of the motivation for supporting building conversion chains this way and why the complexity in the base langue was deemed worth it?

Finally, really nice writeup and exploit, I didn't expect it to be an arbitrary read to RCE. This is definitely gonna change the fate of quite a few forgotten servers out there.

Can someone explain how the "hello world" prefixing example works? I assume it has to do with converting a base64 encoded string to a different charset then base64 decoding but I don't understand how that would get extra characters.

Some encodings add a prefix, which then get sanitised by the liberal base64_decode. https://www.synacktiv.com/en/publications/php-filters-chain-...

Explained here nicely: https://github.com/DownUnderCTF/Challenges_2022_Public/blob/...

Reply on news.ycombinator.com