As firmware regularly disappears from the GL iNet firmware site, I was downloading the current versions for my different routers to my own archive and found that the sha256 was wrong for the ar300m16. Has someone corrupted your site? Is the firmware safe? Do you do auto-checks of your firmware site to make sure it doesn't get corrupted?
This is the 4.3.11 firmware for the ar300m16. It shows a date of 2024-03-20, so it has been posted for 2 about months.
fsum -sha256 openwrt-ar300m16-4.3.11-0320-1710939596.bin
SlavaSoft Optimizing Checksum Utility - fsum 2.51
Implemented using SlavaSoft QuickHash Library <www.slavasoft.com>
Copyright (C) SlavaSoft Inc. 1999-2004. All rights reserved.
; SlavaSoft Optimizing Checksum Utility - fsum 2.51 <www.slavasoft.com>
;
; Generated on 05/18/24 at 11:08:26
a3f5fa4642df519b60d60440c49a8233521735ee7d6f6485f7706b9818b4c4bb ?SHA256*openwrt-ar300m16-4.3.11-0320-1710939596.bin
The download page shows the sha256 sum is: 7c568e65114f62c37bd77cb7ad2afdff93b549ce93d8c8b4dbebf2a13a21f4b1
I downloaded the firmware file 3 times, and each time it has the same wrong sha256 sum.
Wild guess: The checksum is manually added to the website and someone simply forgot about it.
Talking about "corruption of the site" is pretty useless because if someone can corrupt the site, the attacker can modify the checksum as well ...
That is the reason for asking about automated tools to check the checksums and data on the firmware site on a regular basis. If its just a manual process, then it can be easily bypassed or corrupted. Automated tools to produce and check, check-sums files, are very easy to write in any number of scripting languages. I do this for all my cloud file storage to make sure I get notified if the data is ever corrupted.
If the file is 2 months old, and no one noticed there is a checksum issue, then I feel the system is broken. I am looking forward to hearing about this from support.
A Wild Guess is not a great response in today's Internet environment.
This is really, really weird. The exact same file I downloaded about 7 weeks ago shows the correct SHA256 value currently on the firmware webpage wherase the one I just downloaded now to verify has a completely different value. The firmware file on the firmware download page is now different to the one that was there a few weeks back. How is that even possible?????
¡Wow! If that is so, then someone has corrupted the data, OR GL iNet engineering is releasing different versions of the firmware with the exact same filename. If its the first case, then the whole site should be considered at risk.
If its the second case, then GL iNet has NO firmware revision control. GL iNet really should go to a git based site so end users can see the history of the file, even if its a binary file.
Either GL has recompiled the exact firmware file to fix some issues forgetting to update the hash. Or the firmware might have been recompiled (backdoored for example) by an internal or external attacker and uploaded! I hope it is not the later !
I believe GL should investigate this case thoroughly which might be linked to the significant downtime of the development server !
But surely they should have updated the version if they were issuing some fix and not left it with exactly the same name, same date and without notifying users at all.
Btw. It's not the first time that the SHA256 hashes don't fit. So I wouldn't be too concerned. They are useless anyway - since they are provided by the same server and are not signed.
Hello, due to previous user feedback indicating issues with the grammar in some release notes, we have made changes to the release notes in the firmware. As a result, the process of erasing the original release notes and incorporating the revised release notes into the firmware has led to a change in the firmware's hash value. However, as the website failed to update the hash value promptly, it caused a mismatch between the hash value displayed on the download page and the firmware's actual hash value. It's important to note that the firmware itself remains unchanged, only the release notes have been revised. Now, the hash value on the website has been synchronized accordingly.
Wow! So there are two or more 4.3.11 update bin files that have the same filename and different sha256 hashes. If I updated 2 identical routers, at different times, with 4.3.11, I may have different release notes in each router? If so, this is bad, as I expect my routers to be identical if I load the same name .bin file on each router.
I feel that if you change anything, and rebuild the .bin file, you should change the filename, and let us know in the release notes. It is just good software release practice.
No, seriously: I understand that you wanted to symbolize that you are upset ... but hey, no need to write everything in bold. It's a bit like this “NEED HELP!11!!!ONEONEONE”
I feel software control is a 911 event. Just look at the resent issue with the xz backdoor. Bad engineering practices that enables bad people to corrupt firmware without a trace leads to big security issues. At this point no one can trust this firmware, as they don't know which version they really have, or if it is good, as there are at least 2 if not many more version of the file: openwrt-ar300m16-4.3.11-0320-1710939596.bin that has been released by GL iNet engineering
Also, I think you are over-stepping your volunteer job.
Also, I think you are over-stepping your volunteer job.