hi,
These vulnerabilities were found and fixed after the release of firmware 4.3.7 for AR750S/AR300/etc, and fixed in firmwares released after about December 2023, such as 4.3.7 for X750/XE300/SFT1200, 4.5.0 for A1300/MT2500/MT3000/AX1800/AXT1800/X300B, and 4.4.4/4.4.5 for X3000/XE3000.
1 Like
@fangzekun Thank you for this information. Since the security bugs are not fixed in firmware 4.3.7 for these products that are still under support, what are GL iNet’s recommended mitigations to protect our routers and home networks from the following open CVEs:
- CVE-2023-47464
- CVE-2023-47463
- CVE-2023-50919
- CVE-2023-50920
- CVE-2023-50921
- CVE-2023-46454
- CVE-2023-46455
- CVE-2023-46456
- CVE-2023-50922
How much risk are we in from each of the above CVEs? Several of these are rated CRITICAL
@alzhao - As some of these products are still being sold and promoted by GL iNet, and there are a lot more Shadows and Mangos in use then many of your newer router models, why is firmware updates no longer a priority for these products?
What about a snapshot version with the same firmware version number (4.3.7) dated after December, would the snapshop firmware include any new CVE patches?
Nearly none of them are really critical.
Critical would be if there was a way to use those exploits from outside the LAN.
However, most CVEs can either only be carried out from the LAN or only after logging into the GUI.
Of course, chaining could mean “root” access to the router - but in serious environments, the router interface would not be accessible anyway or only SSH would be available, for example.
I agree that the CVEs should be fixed - but I wouldn’t fall into the alarm mode for most of them.
The CRITICAL ratings are given in the CVE. You may disagree with their rating, but as I have some routers on other people’s networks, I consider them CRITICAL.
Almost all of the CVEs requires you to have the root password to do the attack. So it is like flaws of the APIs which may be prone to command injection.
But if you have the root password you can have full control of the router already.
So nothing critical in reality.
1 Like
CVE ratings are not really binding, you always have to check them against your own environment.
Critical is not necessarily critical, as I described above. You usually take these ratings and read through for yourself what the problem is - then you think about what the mitigation looks like or whether the criticality applies. In short, that’s what @alzhao already wrote.
There is a nice article here about why “critical” does not directly mean alert: CVE-2020-19909 is everything that is wrong with CVEs | daniel.haxx.se
I checked them for you:
| CVE | without root password? |
|---|---|
| CVE-2023-47464 |  |
| CVE-2023-47463 |
 (when WebDAV is active, fixed in 4.5.0) |
| CVE-2023-50919 |
(fixed in 4.5.0) |
| CVE-2023-50920 |
(requires physical access) |
| CVE-2023-50921 |
(fixed in 4.5.0) |
| CVE-2023-46454 |
(requires upload of OpenVPN file) |
| CVE-2023-46455 |
(requires upload of OpenVPN file) |
| CVE-2023-46456 |
(requires upload of OpenVPN file) |
| CVE-2023-50922 |
(but not really, since you need to steal a Cookie before) |
Guess @alzhao can confirm this?
Yes. This is correct. There is one critical if you open port and allow access from the WAN side.
1 Like
Thank you so much for doing this. Lets look at CVE-2023-50919 which is rated as CRITICAL
From: https://github.com/gl-inet/CVE-issues/blob/main/4.0.0/Authentication-bypass.md
Impact
It allows an attacker to easily gain access to a system without knowing a valid username and password. Addressing this vulnerability often requires redesigning the authentication mechanism of the system, avoiding hard-coding credentials in the code, and adopting more secure authentication methods, such as using hash password stores and salt values to protect user credentials.
You can look at the link to see that this attack is just a simple set of script-able curl commands. As I am on travel, and don’t have a spare GL iNet router to test with, I was not able to verify this CVE, so I am going on just what is documented.
As I don’t think many GL iNet router models, even including the relatively new A1300, has stable 4.5.x code released yet, there must be many GL iNet routers open to this attack, if they are on LAN networks that are not under your full control, or possibly have open WIFI access.
Is this CVE-2023-50919?
It is, yes.
You can mitigate it by disabling the Web GUI or using firewall rules to make it unreachable for all but your IP.
I will setup an iptable rule while I am waiting for GL iNet to eventually provide fixed firmware for all my supported routers. Sure would have been nice to know this weeks ago, without having to do so much digging.
Hopefully this firmware shows up before any more of my GL iNet routers get beyond their end of support dates, as I’m still disappointed that GL iNet never provided the promised 4.x software for my USB150s or N300, as firmware 2.1.6 seems to have the same CVEs. EOL/support policy for gl.inet products - #8 by yuxin.zou
1 Like
We are working on plans to quickly release a version that addresses the vulnerabilities for these models.
We have released the stable version 4.3.10 to address these vulnerabilities. Please let us know promptly if you encounter any issues.
Nice. Thanks @luxibao and @alzhao
Any chance that my microuter-N300 will receive this update soon as per this page its under support until November 2024?
Back to the original question of this post:
What is the firmware roadmap for the: AR300M, AR300M16, AR750, and AR750S? Any chance for a 4.5.x or later firmware release
All guys is in holiday now. Slow reponses!
Yes, the microuter-N300 is included in the support plan. Please bear with us while we work on it. I apologize for the delayed response.