The following security advisories have been published:
GLIBC-SA-2024-0004:
===================
ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence
The iconv() function in the GNU C Library versions 2.39 and older may
overflow the output buffer passed to it by up to 4 bytes when converting
strings to the ISO-2022-CN-EXT character set, which may be used to
crash an application or overwrite a neighbouring variable.
ISO-2022-CN-EXT uses escape sequences to indicate character set changes
(as specified by RFC 1922). While the SOdesignation has the expected
bounds checks, neither SS2designation nor SS3designation have its;
allowing a write overflow of 1, 2, or 3 bytes with fixed values:
'$+I', '$+J', '$+K', '$+L', '$+M', or '$*H'.
CVE-Id: CVE-2024-2961
Public-Date: 2024-04-17
Vulnerable-Commit: 755104edc75c53f4a0e7440334e944ad3c6b32fc (2.1.93-169)
Fix-Commit: f9dc609e06b1136bb0408be9605ce7973a767ada (2.40)
Fix-Commit: 31da30f23cddd36db29d5b6a1c7619361b271fb4 (2.39-31)
Fix-Commit: e1135387deded5d73924f6ca20c72a35dc8e1bda (2.38-66)
Fix-Commit: 89ce64b269a897a7780e4c73a7412016381c6ecf (2.37-89)
Fix-Commit: 4ed98540a7fd19f458287e783ae59c41e64df7b5 (2.36-164)
Fix-Commit: 36280d1ce5e245aabefb877fe4d3c6cff95dabfa (2.35-315)
Fix-Commit: a8b0561db4b9847ebfbfec20075697d5492a363c (2.34-459)
Fix-Commit: ed4f16ff6bed3037266f1fa682ebd32a18fce29c (2.33-263)
Fix-Commit: 682ad4c8623e611a971839990ceef00346289cc9 (2.32-140)
Reported-By: Charles Fol
Notes:
======
Published advisories are available directly in the project git repository:
https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories;hb=HEAD
On Wed, Apr 17, 2024 at 02:36:02PM -0300, Adhemerval Zanella Netto wrote:
> GLIBC-SA-2024-0004:
> ===================
> ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence
>
> The iconv() function in the GNU C Library versions 2.39 and older may
> overflow the output buffer passed to it by up to 4 bytes when converting
> strings to the ISO-2022-CN-EXT character set, which may be used to
> crash an application or overwrite a neighbouring variable.
>
> ISO-2022-CN-EXT uses escape sequences to indicate character set changes
> (as specified by RFC 1922). While the SOdesignation has the expected
> bounds checks, neither SS2designation nor SS3designation have its;
> allowing a write overflow of 1, 2, or 3 bytes with fixed values:
> '$+I', '$+J', '$+K', '$+L', '$+M', or '$*H'.
>
> CVE-Id: CVE-2024-2961
> Public-Date: 2024-04-17
> Vulnerable-Commit: 755104edc75c53f4a0e7440334e944ad3c6b32fc (2.1.93-169)
> Fix-Commit: f9dc609e06b1136bb0408be9605ce7973a767ada (2.40)
> Fix-Commit: 31da30f23cddd36db29d5b6a1c7619361b271fb4 (2.39-31)
> Fix-Commit: e1135387deded5d73924f6ca20c72a35dc8e1bda (2.38-66)
> Fix-Commit: 89ce64b269a897a7780e4c73a7412016381c6ecf (2.37-89)
> Fix-Commit: 4ed98540a7fd19f458287e783ae59c41e64df7b5 (2.36-164)
> Fix-Commit: 36280d1ce5e245aabefb877fe4d3c6cff95dabfa (2.35-315)
> Fix-Commit: a8b0561db4b9847ebfbfec20075697d5492a363c (2.34-459)
> Fix-Commit: ed4f16ff6bed3037266f1fa682ebd32a18fce29c (2.33-263)
> Fix-Commit: 682ad4c8623e611a971839990ceef00346289cc9 (2.32-140)
>
> Reported-By: Charles Fol
I hope Charles will share further detail with oss-security in due time,
but meanwhile his upcoming OffensiveCon talk abstract reveals a bit:
https://www.offensivecon.org/speakers/2024/charles-fol.html
> CHARLES FOL
> ICONV, SET THE CHARSET TO RCE: EXPLOITING THE GLIBC TO HACK THE PHP ENGINE
>
> Abstract
> A few months ago, I stumbled upon a 24 years old buffer overflow in the
> glibc. Despite being reachable in multiple well-known libraries or
> programs, it proved rarely exploitable. Indeed, this was not a foos bug:
> with hard-to-achieve preconditions, it did not even provide a nice
> primitive. On PHP however, it lead to amazing results: a new
> exploitation technique that affects the whole PHP ecosystem, and the
> compromission of several applications.
>
> This talk will first walk you through the discovery of the bug and its
> limitations, before describing the conception of several remote binary
> PHP exploits, and through them offer unique insight in the internal of
> the engine of the web language, and the difficulties one faces when
> exploiting it.
>
> BIO
> Charles Fol, also known as cfreal, is a security researcher at LEXFO /
> AMBIONICS. He has discovered remote code execution vulnerabilities
> targeting renowned CMS and frameworks such as Drupal, Magento, Symfony
> or Laravel, but also enjoys binary exploitation, to escalate privileges
> (Apache, PHP-FPM) or compromise security solutions (DataDog's Sqreen,
> Fortinet SSL VPN, Watchguard). He is the creator for PHPGGC, the go-to
> tool to exploit PHP deserialization, and an expert in PHP internals.
The event is on May 10-11th, so in 3 weeks from now.
Alexander
* Adhemerval Zanella Netto:
> The following security advisories have been published:
>
> GLIBC-SA-2024-0004:
> ===================
> ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence
For those who haven't prepared/shipped updates yet: we've got a fix for
a stack-based buffer overflow in nscd under review.
[PATCH 0/4] Various nscd security fixes
<https://inbox.sourceware.org/libc-alpha/[email protected]/>
These are initial patches, still under review. The glibc security team
will send a separate notification once official patches are ready.
The initial issue was reported in Bugzilla without an embargo period,
hence the public patch development. The other bugs concern the same
code and are very minor compared to the initial finding, so a separate
embargo for them doesn't make sense.
Thanks,
Florian
Hello all,
Although very late, here is a follow up explaining the impact of the
vulnerability.
Provided that you can force an application to convert a partially
controlled buffer to ISO-2022-CN-EXT, you get an
overflow of 1 to 3 bytes whose value you don't control.
This can be triggered in at least two ways in PHP:
- Through direct calls to iconv()
- Through the use of PHP filters (i.e. using a "file read" vulnerability)
Due to the way PHP's heap is built, you can use such a memory corruption
to alter part of a free list pointer,
which can in turn give you an arbitrary write primitive in the program's
memory.
With this bug, any person that has a file read vulnerability with a
controlled prefix on a PHP application has RCE.
Any person that can force PHP into calling iconv() with controlled
parameters has RCE.
We have provided more explanations on a blogpost of ours (I do not think
that I can post it here, it shouldn't be too
hard to find if you're interested).
Best regards,
Charles
On 18/04/2024 18:42, Solar Designer wrote:
> On Wed, Apr 17, 2024 at 02:36:02PM -0300, Adhemerval Zanella Netto wrote:
>> GLIBC-SA-2024-0004:
>> ===================
>> ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence
>>
>> The iconv() function in the GNU C Library versions 2.39 and older may
>> overflow the output buffer passed to it by up to 4 bytes when converting
>> strings to the ISO-2022-CN-EXT character set, which may be used to
>> crash an application or overwrite a neighbouring variable.
>>
>> ISO-2022-CN-EXT uses escape sequences to indicate character set changes
>> (as specified by RFC 1922). While the SOdesignation has the expected
>> bounds checks, neither SS2designation nor SS3designation have its;
>> allowing a write overflow of 1, 2, or 3 bytes with fixed values:
>> '$+I', '$+J', '$+K', '$+L', '$+M', or '$*H'.
>>
>> CVE-Id: CVE-2024-2961
>> Public-Date: 2024-04-17
>> Vulnerable-Commit: 755104edc75c53f4a0e7440334e944ad3c6b32fc (2.1.93-169)
>> Fix-Commit: f9dc609e06b1136bb0408be9605ce7973a767ada (2.40)
>> Fix-Commit: 31da30f23cddd36db29d5b6a1c7619361b271fb4 (2.39-31)
>> Fix-Commit: e1135387deded5d73924f6ca20c72a35dc8e1bda (2.38-66)
>> Fix-Commit: 89ce64b269a897a7780e4c73a7412016381c6ecf (2.37-89)
>> Fix-Commit: 4ed98540a7fd19f458287e783ae59c41e64df7b5 (2.36-164)
>> Fix-Commit: 36280d1ce5e245aabefb877fe4d3c6cff95dabfa (2.35-315)
>> Fix-Commit: a8b0561db4b9847ebfbfec20075697d5492a363c (2.34-459)
>> Fix-Commit: ed4f16ff6bed3037266f1fa682ebd32a18fce29c (2.33-263)
>> Fix-Commit: 682ad4c8623e611a971839990ceef00346289cc9 (2.32-140)
>>
>> Reported-By: Charles Fol
> I hope Charles will share further detail with oss-security in due time,
> but meanwhile his upcoming OffensiveCon talk abstract reveals a bit:
>
> https://www.offensivecon.org/speakers/2024/charles-fol.html
>
>> CHARLES FOL
>> ICONV, SET THE CHARSET TO RCE: EXPLOITING THE GLIBC TO HACK THE PHP ENGINE
>>
>> Abstract
>> A few months ago, I stumbled upon a 24 years old buffer overflow in the
>> glibc. Despite being reachable in multiple well-known libraries or
>> programs, it proved rarely exploitable. Indeed, this was not a foos bug:
>> with hard-to-achieve preconditions, it did not even provide a nice
>> primitive. On PHP however, it lead to amazing results: a new
>> exploitation technique that affects the whole PHP ecosystem, and the
>> compromission of several applications.
>>
>> This talk will first walk you through the discovery of the bug and its
>> limitations, before describing the conception of several remote binary
>> PHP exploits, and through them offer unique insight in the internal of
>> the engine of the web language, and the difficulties one faces when
>> exploiting it.
>>
>> BIO
>> Charles Fol, also known as cfreal, is a security researcher at LEXFO /
>> AMBIONICS. He has discovered remote code execution vulnerabilities
>> targeting renowned CMS and frameworks such as Drupal, Magento, Symfony
>> or Laravel, but also enjoys binary exploitation, to escalate privileges
>> (Apache, PHP-FPM) or compromise security solutions (DataDog's Sqreen,
>> Fortinet SSL VPN, Watchguard). He is the creator for PHPGGC, the go-to
>> tool to exploit PHP deserialization, and an expert in PHP internals.
> The event is on May 10-11th, so in 3 weeks from now.
>
> Alexander
* Charles Fol:
> Hello all,
>
> Although very late, here is a follow up explaining the impact of the
> vulnerability.
>
> Provided that you can force an application to convert a partially
> controlled buffer to ISO-2022-CN-EXT, you get an
> overflow of 1 to 3 bytes whose value you don't control.
>
> This can be triggered in at least two ways in PHP:
>
> - Through direct calls to iconv()
> - Through the use of PHP filters (i.e. using a "file read" vulnerability)
>
> Due to the way PHP's heap is built, you can use such a memory
> corruption to alter part of a free list pointer,
> which can in turn give you an arbitrary write primitive in the
> program's memory.
>
> With this bug, any person that has a file read vulnerability with a
> controlled prefix on a PHP application has RCE.
Out of curiosity, why would PHP translate a file to ISO-2022-CN-EXT
while reading it? It's not even an ASCII-transparent charset.
Thanks,
Florian
Hi,
On Mon, May 27, 2024 at 12:31:46PM +0200, Florian Weimer wrote:
> >
> > Although very late, here is a follow up explaining the impact of the
> > vulnerability.
> >
> > Provided that you can force an application to convert a partially
> > controlled buffer to ISO-2022-CN-EXT, you get an
> > overflow of 1 to 3 bytes whose value you don't control.
> >
> > This can be triggered in at least two ways in PHP:
> >
> > - Through direct calls to iconv()
> > - Through the use of PHP filters (i.e. using a "file read" vulnerability)
> >
> > Due to the way PHP's heap is built, you can use such a memory
> > corruption to alter part of a free list pointer,
> > which can in turn give you an arbitrary write primitive in the
> > program's memory.
> >
> > With this bug, any person that has a file read vulnerability with a
> > controlled prefix on a PHP application has RCE.
>
> Out of curiosity, why would PHP translate a file to ISO-2022-CN-EXT
> while reading it? It's not even an ASCII-transparent charset.
According to <https://www.ambionics.io/blog/iconv-cve-2024-2961-p1>, PHP
can be told to do so via "php://filter/…", a default behavior of PHP,
it seems (I have just skimmed that page and do not know any details).
HTH,
Erik
On Mon, May 27, 2024 at 11:16:53AM +0200, Charles Fol wrote:
> Although very late, here is a follow up explaining the impact of the
> vulnerability.
>
> Provided that you can force an application to convert a partially
> controlled buffer to ISO-2022-CN-EXT, you get an
> overflow of 1 to 3 bytes whose value you don't control.
>
> This can be triggered in at least two ways in PHP:
>
> - Through direct calls to iconv()
> - Through the use of PHP filters (i.e. using a "file read" vulnerability)
>
> Due to the way PHP's heap is built, you can use such a memory corruption
> to alter part of a free list pointer,
> which can in turn give you an arbitrary write primitive in the program's
> memory.
>
> With this bug, any person that has a file read vulnerability with a
> controlled prefix on a PHP application has RCE.
> Any person that can force PHP into calling iconv() with controlled
> parameters has RCE.
>
> We have provided more explanations on a blogpost of ours (I do not think
> that I can post it here, it shouldn't be too
> hard to find if you're interested).
Surely you can post a link to a blog post, although we strongly prefer
that besides the link you also post a plain text copy of most content,
for archival.
I assume you refer to:
https://www.ambionics.io/blog/iconv-cve-2024-2961-p1
This ends with:
> This concludes the first part of the series on CNEXT (CVE-2024-2961).
> The exploit is now available on our GitHub. There is still much more to
> explore: what about direct calls to iconv() ? What happens the file read
> is blind?
>
> In part 2, we'll dive deeper in the PHP engine to target an iconv() call
> found in a very popular PHP webmail. I'll describe the impact of such
> direct calls on the PHP ecosystem, and show you some unexpected sinks.
> Finally, in part 3, we'll cover blind file read exploitation.
The GitHub link is:
https://github.com/ambionics/cnext-exploits/
I understand it'd be difficult to convert a so nicely formatted blog
post into a plain text posting, but perhaps you can now post the plain
text description you had shared with the distros list?
Are your OffensiveCon slides online or will be soon? A link to them can
also be shared.
Thanks,
Alexander
* Erik Auerswald:
> Hi,
>
> On Mon, May 27, 2024 at 12:31:46PM +0200, Florian Weimer wrote:
>> >
>> > Although very late, here is a follow up explaining the impact of the
>> > vulnerability.
>> >
>> > Provided that you can force an application to convert a partially
>> > controlled buffer to ISO-2022-CN-EXT, you get an
>> > overflow of 1 to 3 bytes whose value you don't control.
>> >
>> > This can be triggered in at least two ways in PHP:
>> >
>> > - Through direct calls to iconv()
>> > - Through the use of PHP filters (i.e. using a "file read" vulnerability)
>> >
>> > Due to the way PHP's heap is built, you can use such a memory
>> > corruption to alter part of a free list pointer,
>> > which can in turn give you an arbitrary write primitive in the
>> > program's memory.
>> >
>> > With this bug, any person that has a file read vulnerability with a
>> > controlled prefix on a PHP application has RCE.
>>
>> Out of curiosity, why would PHP translate a file to ISO-2022-CN-EXT
>> while reading it? It's not even an ASCII-transparent charset.
>
> According to <https://www.ambionics.io/blog/iconv-cve-2024-2961-p1>, PHP
> can be told to do so via "php://filter/…", a default behavior of PHP,
> it seems (I have just skimmed that page and do not know any details).
Oh, right:
| Obviously, base64-encoding is not the only thing you can do. Many
| filters are available.
| […]
|
| » convert.iconv.X.Y, which converts charset from X to Y
|
| Let's take a look at the last filter: convert.iconv.X.Y. Say that I need
| to convert my file from UTF8 to UTF16. I can use:
|
| php://filter/convert.iconv.UTF-8.UTF-16/resource=/etc/passwd
Unfortunately, that exposes all installed iconv converters in all
directions (unlike glibc's ,ccs= parameter for fopen), once there is an
arbitrary URL read injection vulnerability in a PHP application.
Thanks,
Florian
Here's what I sent the glibc's security team a few weeks back; I fixed
some typos:
# PHP's heap in 2 sentences
PHP's heap is page-based; each page contains chunks of some specific
size, such as 8, 0x10, 0x18, etc.
Chunks do not have any header or footer, they are raw data. Therefore,
an overflow from some chunk on the heap directly lands on the next chunk.
Now, for each chunk size, a singly-linked list stores chunks that are
not allocated (similar to tcache in ptmalloc).
# Exploiting iconv()
Say some PHP application allows you to convert some text from UTF-8 to
some arbitrary charset. It uses PHP's iconv() function to do so,
which internally calls glibc's iconv(). You ask the application to
convert some buffer of size 0x50 from UTF-8 to ISO-2022-CN-EXT. It allocates
an output buffer of the same size. Imagine that, by chance, the output
buffer is on top of a free chunk. We have something like this:
0x7fCCBBAA1000 [output_buffer]
0x7fCCBBAA1050 [free_chunk]
Since free_chunk is not allocated, its first 8 bytes contain a pointer
to the next free chunk in the 0x50 free list, say 0x7fCCBBAA10A0.
We trigger a one byte overflow. Since our vulnerability is not that
good, the byte that overflow can only have a few values: 0x48 (H), 0x49
(I), etc.
Consider that it is 0x48 for this example.
So, we overflow one byte into free_chunk, which will effectively modify
the LSB of the free list pointer. It was 0x7fCCBBAA10A0 and becomes
0x7fCCBBAA1048.
Using the vulnerability, we have modified the free list for chunks of
size 0x50. If we manage to force PHP into allocating a few 0x50 chunks,
it will therefore allocate one chunk at address 0x7fCCBBAA1050
(free_chunk's address), and the next one at address 0x7fCCBBAA1048.
The two chunks overlap, so we can overwrite one's content with the other.
This is the basic idea behind using this vulnerability for PHP
exploitation.
I have built a reliable exploit against a popular PHP application.
## PHP: file read to RCE
Another funny thing: in PHP, when you call a file-read function (such as
file_get_contents()), you can perform encoding modification on the data
before it is returned. For instance:
```php
echo
file_get_contents('php://filter/convert.iconv.utf-8.utf-16/resource=/etc/passwd');
```
This returns the contents of /etc/passwd, but converted to utf-16 using
iconv.
I managed to build a fully reliable, PHP-agnostic exploit that converts
a file read primitive (for instance, a call to file_get_contents() with
a controlled
parameter) to remote code execution.
Therefore, with this bug, any person that has a file read vulnerability
on a PHP application has RCE. Any person that can force PHP into calling
iconv()
with controlled parameters has RCE.
Charles
On 27/05/2024 13:34, Solar Designer wrote:
> On Mon, May 27, 2024 at 11:16:53AM +0200, Charles Fol wrote:
>> Although very late, here is a follow up explaining the impact of the
>> vulnerability.
>>
>> Provided that you can force an application to convert a partially
>> controlled buffer to ISO-2022-CN-EXT, you get an
>> overflow of 1 to 3 bytes whose value you don't control.
>>
>> This can be triggered in at least two ways in PHP:
>>
>> - Through direct calls to iconv()
>> - Through the use of PHP filters (i.e. using a "file read" vulnerability)
>>
>> Due to the way PHP's heap is built, you can use such a memory corruption
>> to alter part of a free list pointer,
>> which can in turn give you an arbitrary write primitive in the program's
>> memory.
>>
>> With this bug, any person that has a file read vulnerability with a
>> controlled prefix on a PHP application has RCE.
>> Any person that can force PHP into calling iconv() with controlled
>> parameters has RCE.
>>
>> We have provided more explanations on a blogpost of ours (I do not think
>> that I can post it here, it shouldn't be too
>> hard to find if you're interested).
> Surely you can post a link to a blog post, although we strongly prefer
> that besides the link you also post a plain text copy of most content,
> for archival.
>
> I assume you refer to:
>
> https://www.ambionics.io/blog/iconv-cve-2024-2961-p1
>
> This ends with:
>
>> This concludes the first part of the series on CNEXT (CVE-2024-2961).
>> The exploit is now available on our GitHub. There is still much more to
>> explore: what about direct calls to iconv() ? What happens the file read
>> is blind?
>>
>> In part 2, we'll dive deeper in the PHP engine to target an iconv() call
>> found in a very popular PHP webmail. I'll describe the impact of such
>> direct calls on the PHP ecosystem, and show you some unexpected sinks.
>> Finally, in part 3, we'll cover blind file read exploitation.
> The GitHub link is:
>
> https://github.com/ambionics/cnext-exploits/
>
> I understand it'd be difficult to convert a so nicely formatted blog
> post into a plain text posting, but perhaps you can now post the plain
> text description you had shared with the distros list?
>
> Are your OffensiveCon slides online or will be soon? A link to them can
> also be shared.
>
> Thanks,
>
> Alexander