750-3.100-1217, unsecure firmware validation check

The firmware 750-3.100-1217 still use the unsecure firmware validation by unsecure and since years broken MD5.

That should changed to p.e. SHA256

If its a problem on open wrt and not only on gli.inet firmware, please open a request on open wrt website. THX

See the same on bug tracker:
https://bugs.gl-inet.com/my_view_page.php

I didnt find a info about its fixed p.e. on bug tracker. Thats sounds the fix will be open on follow version too:

  • Beta 750-3.100-1218

Is there already news or a schedule for replacing the unsafe firmware MD5 validation check with, for example by secure SHA256 ?

MD5 are broken since 1996:

Known security problems should be fixed.

The gli bugtracker can open now by follow link:
See the same on bug tracker:

No, you found a link to the goodcloud. The bug tracker is not available anymore.

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.

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:

https://www.laptopmag.com/articles/asus-hack-malware-response

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.