rtl8814au and rtl8812au remotely exploitable driver vulnerabilities

[gripedthumbtacks]

The current drivers are vulnerable to multiple remotely exploitable vulnerabilities. Where are the latest 2018 rtl8814 and rtl8812 patched driver updates with the official upstream source code fixes from Realtek? Someone should probably also file a security bug with Ubuntu and other distros to get them updated there too.

[pablocyber]

Could you please provide reference or CVE# for vulnerability mentioned?

[kimocoder]

We've patched the KARMA over here

[gripedthumbtacks]

@kimocoder unfortunately KARMA is not applicable. There are multiple vulnerabilities including KRACK and some buffer management issues that still don't have CVEs.

This also raises the question of where the rtl8812/4 source code originated from. The original code was supposedly distributed in 2014 and pulled into Ubuntu. Did they even verify it was actually from realtek? This code has not been updated in Ubuntu since. All other changes seem to be heavily diverging from the upstream driver fixes. Eg it was forked in 2014 and new upstream changes have not been kept up, including security fixes from realtek.

The most recent quasi official source code for the 8814 able to be located was from 2016 via TP Link. No one here has the official 8814 source code from realtek with the 2018 security fixes? Does anyone have code from realtek 2018 or even a partner product manufacturer? Who knows if this 2016 code is even the official realtek sources since it is not gpg signed and may just be a modified version of older OEM code.

https://static.tp-link.com/Archer%20T9UH_V1_Beta_160619.zip

The problem with the existing driver is it seems like many untrusted people just started uploading code to GitHub and no one really knows how the driver came to be in it's current state and which code is trusted and which code is tainted by unofficial development that has deviated from upstream to make reintegrating the upstream changes difficult. What's the status?

[kimocoder]

It was supposed to be the KRACK attack. It's patched over there.

[gripedthumbtacks]

KRACK is from 2017. There are additional memory management flaws with 2018 realtek code fixes. Has anyone sourced them?

And where did the original source code originate from anyway? No one knows? There are numerous forks, none of which are officially sourced from realtek it seems or that can be traced to official realtek code. The problem is that the 2018 vulnerability shows that someone may have planted a backdoor into into these forks.

[pablocyber]

Can you please provide a specific reference to the 2018 buffer vulnerability you are referring to? On Feb 15, 2018 10:18 AM, "DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K" < [email protected]> wrote: KRACK is from 2017. There are additional memory management flaws with 2018 realtek code fixes. Has anyone sourced them? And where did the original source code originate from anyway? No one knows? There are numerous forks, none of which are officially sourced from realtek it seems or that can be traced to official realtek code. The problem is that the 2018 vulnerability shows that someone may have planted a backdoor into into these forks. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#89 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZHJRccyv4kGbTizdPZPVibIfGhnqMyEks5tVGbhgaJpZM4SFtSy> .

[usuarionuevor]

@DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K @pablocyber this is the most close to realtek original driver https://github.com/gordboy/rtl8812au you should ask him for source, I don't know why but they don't share links publicly.

[kcdtv]

KRACK is irrelevant here. It does not have anything to do with the drivers but with the network clients implementation. It is patched in wpa_supplicant and hostapd since a long time and in all distributions.

The problem is that the 2018 vulnerability shows that someone may have planted a backdoor into into these forks.

Don't worry: This backdoor is just for mining bitcoins 🙄
More seriously.
Yes, it is shame, we all do agree, that realtek does not publish the source codes in github or somewhere else.
But that it is not a reason to spread unfounded rumors like you do. Speaking about KRACK is a nonsense and nobody implemented a backdoor.
This is just people trying their best to deal with Realtek Linux "support" (lack of). 😺

[kimocoder]

Clearing out (flush) the keys in AP mode as seen here didn't got time to look it up a week ago.

And a backdoor.. well, haven't found any of 'em yet 🥇

[gripedthumbtacks]

Someone else mislabeled KRACK as KARMA, not me. Check the buf management details and calculations. These vulns are not FUD.

[gripedthumbtacks]

@kcdtv do you or anyone have any reference to vendor provided rtl8814 code that is newer than this 2016 link? It appears this source code was provided from Realtek as of June 19, 2016. If anyone had a new link, please provide it and I will diff the latest identified vendor code versus the GitHub code and see how these bugs slipped in and remain unlatched. But I need the latest vendor code. The link below is the best 8814 code able to be found this far.

https://static.tp-link.com/Archer%20T9UH_V1_Beta_160619.zip

[zebulon2]

I maintain 8811/8812/8814/8821AU PKGBUILDs for Archlinux, and unfortunately there is no universal driver for all of these, leading to having to maintain several versions in parallel. The Realtek FTP provides 5.2.20 for RTL8812AU only, which is the most recent and "secure" code but there is no access for other versions of the chipset that I know of. 8814AU is old and comes from vendors. 8821AU uses an old version of 8812AU. some developers have tried to unify these drivers (paspro) but the codebase seems to change significantly between versions (5.2.20 is very different from 5.1.5), making this task very difficult without realtek help. Usually the missing bit is the hal code for all chipsets.

[kcdtv]

Thanks for your work zebulon2.
@ DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K
I do not have /did not find anything newer

[gripedthumbtacks]

@zebulon2 thanks for the info. Please see the memcpy ioctl and pointer arithmetic that is vulnerable and see if it was patched or not upstream. It sounds like the updated driver code has not been published yet so would need to be patches everywhere in each of the separate repos. There are multiple issues but that's at least one I was able to reverse from an updated driver release. And noticed the open source code still semmes vulnerable.