It’s annual Wii U exploit time! 😄
 |
| Image of the Wii U connection test screen on the GamePad. |
After reverse engineering parts of the Wii Us’ NET stack for another project I was working on, I realized it’s using a modified version of NicheStack.
NicheStack is a TCP/IP stack developed by InterNiche Technologies and is designed for use in embedded systems.
INFRA:HALT
If you end up searching for NicheStack on the internet, one of the first things you’ll find is a security research report called INFRA:HALT, published by Forescout Research Labs and
JFrog Security Research. This report contains a set of 14 vulnerabilities, which all affect various parts of NicheStack.
While most of these vulnerabilities “only” lead to a DoS, two vulnerabilities might lead to remote code execution. One of them affects the HTTP server, which is not used on the Wii U. The other one sounds a lot more interesting though…
CVE-2020-25928
CVE-2020-25928 is a vulnerability in the DNS client, which is also in use on the Wii U. It has a CVSS v3.1 Score of 9.8 and results in a heap buffer overflow which can lead to remote code execution.
The code described by the INFRA:HALT write-up looks something like this:
uint8_t *cp;
cp = (uint8_t *)&dnshdr[1];
dns_entry->alist[0] = 0;
dns_entry->ipaddrs = 0;
for (i = 0; i < records; i++)
{
// …
cp = getoffset(cp, (char *)dns, &offset);
cp = getshort(cp, &type);
cp = getshort(cp, &netclass);
// …
cp = getlong(cp, &ttl);
cp = getshort(cp, &rdlength);
switch (type)
{
// …
case 0xCu:
if ( type == 1 && rdlength != 4 )
err = 7;
if ( !err )
{
++dnsc_good;
if ( i < ( queries + answers ) )
{
if ( nameoffset == 0 )
{
nameoffset = offset;
// …
}
dnc_set_answer(dns_entry, type, cp, rdlength);
// …
}
else
{
if ( nameoffset == offset )
{
dnc_set_answer(dns_entry, type, cp, rdlength);
}
// …
}
// …
}
break;
// …
}
}
As we can see dnc_set_answer is called for each record with type 0xC (PTR).
The dnc_set_answer implementation does something like this:
void
dnc_set_answer(dns_querys *entry, unshort type, uint8_t *cp, int rdlen)
{
// …
switch ( type )
{
// …
case 0x0c:
memcpy(entry->ptr_name, cp + 1, rdlen – 1);
// …
break;
// …
}
}
As we can see the DNS client basically copies the record data into a fixed size buffer on the heap without checking the size.
At this point I was interested and decided to take a look if the Wii U implementation suffers from the same issue. To my surprise the Wii U implementation looks something like this instead:
if (type == 0xC)
{
dnc_copyin(dns_entry->ptr_name, cp, dns);
}
else
{
dnc_set_answer(dns_entry, type, cp, rdlength);
}
The affected dnc_set_answer call is explicitly not called for the type 0xC (PTR) records. Instead a function called dnc_copyin is called, which does proper bounds checks.
So someone (at Nintendo?) fixed this several years before INFRA:HALT was discovered and disclosed? Well, they tried!
As we can see from the full code above there are two places where dnc_set_answer is called. The first one for answer records and the second one for additional records pointing to the first answer. But they only added the check for the first one?!
The second one still blindly calls dnc_set_answer without doing any size checks.
Exploiting it on the Wii U
After writing a quick PoC server to confirm this actually works on a Wii U, I decided to try and exploit this.
Since the dns_querys struct is stored on the heap, this is a basic heap overflow. The Wii U added a few additional fields to the dns_querys struct, which we can overwrite. Due to the NET stack running on
