I do not see any new snapshot/rc/beta versions for the AR300M, AR300M16, AR750, or AR750S, where other models like the A1300 have been updated to 4.4.6, and have 4.5.0 in beta. Looking at the 4.5.0 release notes, it shows it fixes 10 known security issues. Are these security issues in 4.3.7, and are we at risk running 4.3.7?
Is firmware 4.3.7 the last version for these routers, or should we expect new versions of 4.x firmware for our routers that are still under support?
I was wondering about this myself.
The release notes for firmware 4.3.7 for X750/XE300/etc list many vulnerabilities fixed.
The release notes for firmware 4.5.0 for A1300/AXT1800/etc list the same fixes.
But the release notes for firmware 4.3.7 for AR750S/AR300/etc does not list any vulnerability fixes.
Can anyone from GL-iNet confirm if those same vulnerabilities were fixed in firmware 4.3.7 for AR750S/AR300/etc?
Can anyone from GL-iNet confirm if the vulnerablities fixed in other devices are also fixed in firmware 4.3.7 for AR750S/AR300/etc? No vulnerablity fixes are listed in the release notes.
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.
@ikun 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:
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.
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
@alzhao So, NONE of the attacks can be exploited without the root password?
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.
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
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 @SimBot 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