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.
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.
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?
`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.
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.
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.
12 comments
[ 3.0 ms ] story [ 48.7 ms ] threadThere 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.
`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.
Related: https://news.ycombinator.com/item?id=40103188
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?
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.