search

astsam / rtl8812au

RTL8812AU/21AU and RTL8814AU driver with monitor mode and frame injection
350 stars 946 forks source link

rtl8814au and rtl8812au remotely exploitable driver vulnerabilities #89

Open gripedthumbtacks opened 6 years ago

gripedthumbtacks commented 6 years ago

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 commented 6 years ago

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

kimocoder commented 6 years ago

We've patched the KARMA over here

gripedthumbtacks commented 6 years ago

@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 commented 6 years ago

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

gripedthumbtacks commented 6 years ago

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 commented 6 years ago

Can you please provide a specific reference to the 2018 buffer vulnerability you are referring to?

On Feb 15, 2018 10:18 AM, "DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K" < notifications@github.com> 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 https://github.com/astsam/rtl8812au/issues/89#issuecomment-365998248, or mute the thread https://github.com/notifications/unsubscribe-auth/AZHJRccyv4kGbTizdPZPVibIfGhnqMyEks5tVGbhgaJpZM4SFtSy .

usuarionuevor commented 6 years ago

@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 commented 6 years ago

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 :roll_eyes: 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). :smiley_cat:

kimocoder commented 6 years ago

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 :1st_place_medal:

gripedthumbtacks commented 6 years ago

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

gripedthumbtacks commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

gripedthumbtacks commented 6 years ago

@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.