Logo Firmware Update
Bertoldo Beyer
So, one exploit to run arbitrary code, one to elevate permissions in order to install this exploit? Sounds like the kind of thing state actors would resort to as it seems like an awful lot of work for your run of the mill ransomware extortion campaign.
This was my original reaction as well, but was pointed to this slide in their BH presentation that suggests OEMs may load the logo in different ways, including placing them in an unsigned part of the firmware update:
image1776984 270 KB
(For those platforms, the attacker can presumably craft and load a firmware update to the ESP that passes Secure Boot and Intel Boot Guard verification, but contains the payload with malicious boot image data.)
Based on analysis from Binarly, we believe each of our currently launched platforms except Chromebook Edition is vulnerable to some form of LogoFAIL. We are working with our upstream UEFI supplier, Insyde, in order to get the necessary update from them to resolve this. This is occurring as part of our sustaining software initiative.
2019 Update: This is definitely the Stack Overflow logo, not something that just looks similar. When Stack revised the logo to change the number of the bars, the qnap implementation of our logo changed too:
At the very least they are very generic although interestingly the particular icon in question is labelled "Stackoverflow" and is part of the "Social Networks" category of icons (the cog icon appears to be different, but they obviously use a little creative licence if they have the vectors).
IMPORTANT: I can't state 100% that these icons are the ones in the picture. They could have been made by the company if they have a talented graphics designer, and they could have come from one of multitude of iconset sites out there (increasingly developing for Windows 8 metro style).
In this instance the company has taken the decision to manipulate the vector by mirroring the icon before using it in their software, which for a paid licence is perfectly acceptable (as far as Icons8 licencing is concerned).
which I completely agree with. It will be up to Stack Overflow to decide whether they want to pursue the matter further, I imagine though that this is common practice especially in icon set creation circles.
If Stack Exchange has trademark rights over the Stack Overflow icon, they would have grounds for requiring that the icon be removed from that firmware. Note here that QNAP has a US presence and SE is US-based, so my response here is based on US law.
The fact that QNAP has paid for the icon set and has a license from Icons8 is not sufficient to absolve QNAP. (If Icons8 got a license from SE that allows them to license to others is a different matter, but there is no evidence that this is the case.)
The fact that the icon used in the firmware is somewhat different from the icon on SO does not constitute a bar to successfully demonstrating infringement. Trademark infringement occurs even if the presumably infringing logo is somewhat different but would still cause people to think that they are looking at the SO logo. Similarity is what the court looks for, not identity.
You must admit anyone could come up with graphics similar to Stack Overflow's logo for various reasons. I remember seeing nearly 20 years ago when I did some graphics design a graphics that is extremely similar to current Stack Overflow's logo. The design was something related to organizing papers... In fact, I am 100% sure some company specialized in graphics designed something that is the same, or similar to Stack Overflow's logo long before Stack Overflow was made.
So I ran into an issue with the firmware. Flashing failed and now the Mk3S doesn't progress past the "Original Prusa" logo screen. It does respond to flashing attempts (failing), but no factory reset is possible (no reaction past the fan stopping shortly)
If you are still getting, the Dell logo after upgrading to 5.9.2.13 , try a control f5 to refresh the browser, if it still doesn't go then type in the below but replacing with your IP address, then enter
Nope, there is nothing going around with 5.9.2.13 version. Ultimately, this is the latest firmware for all Gen 5 devices. If you can share the numbers (Bug ID) of the cumulative fixes that you are looking for on this firmware version, I can possibly help out to confirm.
What I meant by requirements was, lets say you got suggested to upgrade the firmware on your SonicWall to a specific version as a fix for a specific issue then that's a requirement scenario. The scenarios may vary and what I told you is an example.
Answer: Not necessarily any latest firmware version can fix problems reported on the predecessor firmware. An example is, 5.9.2.7 firmware version may contain fixes for the issues reported on the previous versions. The firmware 5.9.2.13 version simultaneously releases containing new features that are originated only from this version. Hence the necessity to check with either our Support team or reading release notes would help clarify and choose the right firmware version based on the issue/requirement for the SonicWall appliance. In this similar situations, we always try to accommodate all the fixes on the latest version but this can change and there are exceptions.
Well, your feedback is always helpful to groom our product and its associated resources to a greater extent. We are always grateful to our customers on this part. Thanks for your feedback on the documentation release notes part.
As @Halon5 mentioned, it's very confusing from a customer point of view having multiple releases, there should be just a single latest firmware. It's ok if you have multiple branches 5.9.1 and 5.9.2, but the forth digit should show just be an indicator what the latest is in that specific branch, IMHO.
Our existing Gen5 units are running on 5.9.1.13-5o, Until now we are not faced any issue and its stable. But as per the sonicwall recommendation for fixing the vulnerability we would have to upgrade the firmware so kindly let me know which Firmware should need to use out of the below list; As per the list both firmware will cover the vulnerability.
Sorry for the inconvenience. I know how much frustrating it would be. I would feel the same way if I were at your place. This is totally code based issue on the firmware. Please approach our support team to report the issue to our back-end team and find a fix.
Recent updates may have expanded access to feature(s) discussed in this FAQ. Visit your product's support page, select the correct hardware version for your device and check either the Datasheet or the firmware section for the latest improvements added to your product.
Note: You may obtain simply a BIN file which applies to powerline extender, a GGL file or a combination of NVM and PIB files, depending on the product model which applies to powerline adapter.
We have updated our Policies. Read Privacy Policy and Terms of Use here.
This website uses cookies to improve website navigation, analyze online activities and have the best possible user experience on our website. You can object to the use of cookies at any time. You can find more information in our privacy policy .
Hi All,
Recently had a TC8 running V3.7 refusing to pair to a 4.1 G7500.... after a few network changes we got them able to discover and pair. Great!
Finally I told the TC8 to perform its upgrade to match the G7500's SW up to V4.1.... It got to 98% with a blank screen on the TC "REBOOTING"..... then hung for 2 hours. After a POE reset, the TC8 now stays on the "Poly" logo..... undiscoverable to the LAN, no status, looks like the firmware failed.
All we have is a reset button and a RJ45 connection, the MicroUSB-B on the back does nothing.... there must be a way to bring this unit back to life.
RMA is out of the question - our AV Vendor went bankrupt and registered out unit early, warranty lapsed.
Thanks in advance
Nope, no solution so far. Looks like we're in possession of a bricked TC8 having to either a) pay for support to RMA the unit or b) purchase a replacement TC8 ourselves.
I'll keep trying to find some other way to resolve this, but it's not looking hopeful.
I am extremely sorry for the delay in response.
As the issue is not being resolved, I request you to please reach out to Poly customer support at 800-985-9815 for further warranty and replacement related queries and further assistance.
Regards,
Meghana
We are a sizable organization, with around 20 Poly Studio X50 units configured with a paired TC8 panel. We run Zoom Rooms on them. While trying to deploy some additional systems (we'll eventually get up to around 25 or so) we ran into this issue. Our TC8 units shipped with Poly OS 3.5.x on them, and will thus not run a reasonably recent version of the Zoom controller software. We HAVE to update the Poly OS on both the X50 and the TC8 immediately upon deployment in order to run an up-to-date version of Zoom. Recently - in the last couple of weeks or so - we've run into the issue where trying to update the TC8 from 3.5.x to 4.x.x bricks the TC8 in exactly the way the original poster described. The firmware update seems to proceed normally, then hangs at the reboot. Completely bricks the TC8. As recently as a month ago or so, the normal update process worked fine with no problems. This is a very recent occurrence, that makes me think there is some sort of problem recently introduced with the firmware/updaters. We ended up bricking 3 - count them, 3! - TC8 units. Fortunately they're under warranty and I have RMA'd them for replacement successfully.
The only way to work around this problem is to NOT use the usual on-line update process (i.e. log in to the Poly Studio administrative interface, then use the firmware update tool). This WILL brick the TC8 every time. Instead, once you've paired the TC8 to the Poly Studio (or whatever you're pairing it to) use the manual USB update method to update the TC8 manually to 3.14.2. Once this is done, you can do the subsequent updates the normal way until you are fully updated. You can go here to find the manual firmware update files: -47441-nexgen-poly-os-upgradedowngrade-files-from-le... Please note: even though I SPECIFICALLY downloaded and prepped the 3.14.2 software, the TC8 (successfully, without bricking) updates to 4.0.x. Not sure why, but it does. Using this method I've been able to field and update new TC8 units without bricking them. Additional note: all of our systems are on line (i.e. they can see the Internet, albeit through a firewall). I assume that during the manual update process - even though it's the MANUAL process - the TC8 "phones home" and somehow grabs the later firmware. Mystery to me why THIS download works but the normal update process download destroys the TC8.
I know the above is no help for EXISTING bricked units - RMA (if you can) seems to be the only recourse. But the above steps will prevent further damage as you deploy new units. As far as I know TC8 units continue to be shipped with ancient firmware (the ones I'm fielding were purchased just four months ago and they arrived with 3.5.x!). Trying to update a NEW out-of-the-box unit bought TODAY will DESTROY it if you do it the normal way. If you haven't updated your TC8 since purchase, then trying to update it today the normal way will DESTROY it. The manual USB update method is the only way I know to get past the danger point. Be careful out there - I'm not guaranteeing anything. Just describing what I've seen and what worked for me.