750-3.100-1217, unsecure firmware validation check

Changed sevice on subdmain https://bugs.gl-inet.com from bugtracker to goodcloud :

  • What are the benefit of this ?
  • For what dit i tested some weeks the glinet firmware again and again and reported the bugs on bugtracker ?
  • Does ist help to fix bugs or improve the development of new features ?

By the way. Depend on law of some countrys (p.e. european union), known security bugs need to be fixed for selling in this countrys.

There has always been an internal bug tracker. GL just decided not to have a public tracker and just use the forums for bugs, where most users are. A lot of the developers don’t speak any english, so moving bugs from the public tracker to the private was taking a lot of extra time.

All your bug reports and feature requests have been noted, and will be applied if GL decides they are needed or not.

Laws in the EU don’t give any time frame. If that was the case, then no company could sell routers, as Asus routers for example are running on really old linux kernels that have vulnerabilities, they also knowingly ignore actual vulnerabilities. GL has patched many such over the years.

Btw, the MD5 has is only used to make sure the file has not corrupted during the download (ie file checksum), but since the traffic is HTTPS, there is no MITM attacks and firmware auto upgrade is safe in any case. HTTPS SSL already uses SHA256 or higher depending on server config, so why have double encryption? If the user uploads a fimrware file own their own, without the auto upgrade, then it’s up to them to make sure the file was downloaded from the correct source and not modified. There is no vulnerability there, or insecurities.

Securing the data integrity of the firmware image is a classic task of the manufacturer. It is a purchase argument for many a customer and in return strengthens customer loyalty.

It must be ensured that the firmware :

  • is not defective, tampered with or replaced on the glinet server
  • nor that the firmware was defective when it was downloaded to the customer or that it was manipulated or exchanged for another

If this does not happen yet, then this should be considered to introduce one. MD5 is unsuitable today because it has been broken for more than 20 years. SHA256, on the other hand, seems to me to be suitable for this.

1 Like

There are no such things as purchase arguments. Buy an Apple product and see what i mean. They only acknowledge there is an issue until the news papers the courts take over the issue. Actually it is the other way around, most of the time you will accept a EULA without reading that states “we are not resposible for any damage that may be caused” for most of the software you use every day.

Sorry but even if you use SHA256, if the main server is comprimised, the attacker can replace firmware and update the checksum values. Using a different checksum algorithm does not help with that. Also, unlike other vendors, GL uses open source firmware. Anyone can download the code, check it, audit it and then compile and flash it. There is no need for a lot of checks. You can see an example here:

You also should know that if a router is comprimised from inside a network, the check code can be replaced and firmware flashed. The only fix is to use Secure Boot like new pc’s have, but that is not implemented in any router apart from high end Cisco ones.

You can also check here:

1 Like

You are right. Your webserver have a realy high secure B grade configuration. Dont need to do change too:

Protocols:
TLS 1.3 No, _____________Not activatet !!!
TLS 1.2 act
TLS 1.1 Yes_____________Not deactivatet !!!
TLS 1.0 Yes ____________ Not deactivatet !!!
SSL 3 No
SSL 2 No

Please check the endlos list of your used WEAK chiper suites on your webserver by self.
More than 90% are WEAK !!!.

Remark:

  • What d you think what are the coast of replace the broken MD5 by non broken SHA256 or so on ?

It’s not my server, i don’t work for GL :slight_smile:

Yes, servers must still support older clients.

MD5 checks are generally still good enough to ensure that the firmware is not corrupted on download. Since downloads are over HTTPS, you’ve got an additional layer of security there as a valid download host.

If you follow what going on in other spaces, with secure boot, signing of SW images - this can be done as well perhaps, but at a risk of locking down the devices so that only signed firmware from the OEM could be loaded.

Tempest in a teacup perhaps…

  • The broken TLS 1.1 are replaced by TLS 1.2 twelf years ago.

  • TLS 1.0 replaced by TLS 1.1 more than 12 years ago

  • gl-inet.com dont support the since 2016 or 2018 actual one TLS 1.3 …

  • TLS 1.0 and 1.1 will no longer be supported by the major browsers Apple Safari, Google Chrome, Mozilla Firefox, Microsoft Edge and Internet Explorer from early 2020. This is because TLS 1.0 and 1.1 are considered unsafe because they use outdated algorithms and features such as SHA-1 and MD5.



  • I dont know what good cloud ist, a if user data saved on good cloud on gl-inet.com, it should be a little bit hardened…

Security problems, should be fixed. Especially those that are clear and easy to fix and dont need any investment.

1 Like

I am not a security expert so I don’t know all the details, and I think GL.inet routers are some of the best in the world right now, but I thnk it’s not a very big investment to improve the security from average or maybe OK to excellent.

Just like the firmware and hardware is much better than most of the normal routers, GL.inet should also make their security (and privacy) much better than the other companies.

It only takes one incident where firmware was changed or hacked, and the whole reputation can be spoiled for a long time. The risk of bad security is bad for business!

Its looks for me the gl firmware auto update process are neither by secured by actual sha256 nor by since many years broken MD5.

GL secured his webpage a little bit, some days ago. A this can be only one first step. If I remember right:

  • The unsecure TLS 1.1 and older are now deactivated. Thanks.
  • The actual TLS standard, TLS 1.3 are still not supported.
  • A long list of weak shipper suites are still used (The list of used weak shipper suites its much shorter than one or two weeks ago)

Thanks for your feedback.
I will try to improve the security again, after done, I will reply this thread.

1 Like

Hi, how about this now, SSL Server Test: dl.gl-inet.com (Powered by Qualys SSL Labs)
TLS 1.3 are supported, no weak cipher,
Thanks for your suggestions!

2 Likes

Very nice Leo :partying_face: :partying_face: :partying_face:

1 Like

Thanks a lot, Leo.
Can you please also take a look at www.goodcloud.xyz if you can. There the general situation is already quite good. There the choice of the chipper suites can possibly be improved a bit.

Done.
Thank Henry again for your advice. :smiley:

1 Like

Thanks a lot, Leo. Thats looks now excellent for me.

On other point for possible improvements are the actual by gl used validation check for firmware by MD5.

It can be, it’s possible, to optimize the security in this point a little bit too from good to excellent, by replace the MD5 by sha256.

VBR

I have given this advice to the firmware development team, they will improve the side.

For some customers are, improving safety from Good to Excellent is an important argument for their purchase decision.

Thank you, Leo.

Addendum:
Is there already an approximate timetable ?
THX

Addendum:
Push up from the Easter Bunny

1 Like

Push up from end of April.
Thank you, Leo.
Is there already an approximate timetable ?
THX

I have urged relevant colleagues today, and there is no timetable yet. Thank you for your patience.