Updating firmware blob on security advisory from vendor

What is the policy for openWrt when a vendor releases an advisory and updates their firmware? Is there a process to check if the firmware blob (that openWrt users still rely on) was updated by the vendor, and push it to the openWrt build?

To take a specific example, on January 21st, Netgear published a security advisory for a stack-based buffer overflow remote code execution vulnerability.

This vulnerability affected a long list of Netgear routers, which include several supported by openWrt (e.g. Netgear R7000).

I could not find a reference to this advisory in openWrt forums or builds (but I am unfamiliar with the documentation, so I might very well have missed it).

Following this advisory which of the following happened?

  1. no checks were made in the openWrt community
  2. openWrt devs checked that the firmware blob was not updated by Netgear and therefore made no change
  3. openWrt devs updated the firmware blob for the Netgear R7000 build.

For that example in particular, here are the details: https://www.zerodayinitiative.com/advisories/ZDI-21-206/

It affects the upnpd daemon, which is not installed in a default OpenWrt installation, nor it is evident that Netgear's version is even provided by OpenWrt.

4 Likes

Thanks for that. It is quite interesting that they would take 4 months to fix a vulnerability that allows remote control of the router, as root. It’s among the most serious vulnerability, and on so many of their routers...

Thanks for your response. I am still interested to hear what the general process is for openWrt and advisories from vendors, if anyone knows.

Well, you can read what's been done in three (one is without any comments/feed back though) recent cases in

Note that some of the vulnerabilities are discovered in 3rd party software, which means they may need to be fixed upstream, and not in openwrt.

But it might trigger a service release, once it's fixed, if the bug is severe enough.

2 Likes

Thanks for that. I did read it, but it does not give a full picture, hence why I asked my question.

There are many fewer patches than patches released by vendor. That is absolutely to be expected, as not all vulnerabilities will affect openWrt. However I am trying to get a sense if there is a systematic process to review vendor’s patches/advisory to determine whether openWrt needs to patch the blob, or needs to look at its own implementation.

In other words, this link is great to give color on what happened, but gives no information on patches that were not made.

patches where ?
from openwrt or from maintainer of a certain piece of software, used by openwrt ?

if you want to get the full picture, you probably have to add not only fixes made by openwrt, but also fixes made in the sub modules/sw used by openwrt.

If there's a fix in say the kernel, it will probably not pop up in Openwrt as a fix too.

3 Likes

Yes, I agree with that. We are in agreement that getting the full picture for all the security patches would be a time consuming process. Correlating it to vendor's advisories would take even longer.

So I was inquiring about whether there is a monitoring process for vendor's advisories for openWrt itself, so that I can understand the big picture. I am not including individual packages in that question.

I'd say no, because a lot of what they publish is irrelevant for openwrt, and the sw versions they use (if shared with openwrt) are outdated.

3 Likes

I agree, except for the blob part that stands out in my mind.
I have the overall impression that the blob part is not managed too carefully.

LibreCMC tries to get rid of this closed source code, but they seem to update much more infrequently than openWrt.

If a vendor discovers a security flaw in the code of a blob, it is likely to be overlooked by the openWrt project if there is no monitoring of when the vendor updates it.

Monitoring of updates on closed source code is particularly important, because even if you keep updated on what the latest security risks are, you don't know how the code works, and so you will not be aware of how it's impacted.

In other words, while I agree with your assertion that "a lot of what they publish is irrelevant", the problem with security matters is that you need to cover the corner cases. That space between "a lot" and "all". That's were attackers go.

A device supported by LibreCMC doesn't need blobs on OpenWrt either. They don't magically replace the blobs with free software, they only support the restricted subset of devices that don't need any to begin with (basically ath79+ath9k, there are no blob-free 802.11ac/ ax devices); or leave parts of the hardware disabled.

4 Likes

Most of the blobs included in OpenWrt belong to hardware drivers, and most of them correspond to wireless cards, probably.

Security issues on these blobs do exist, but are not as common as on other software: they are drivers after all.

If the drivers (and their blobs) are included in the mainstream Linux kernel, then any updates should be handled there. Otherwise, there is a package and the corresponding maintainer.

These blobs are provided by the manufacturer, and in very rare (if any) occasions are extracted from firmware updates as the one linked above.

4 Likes

Thanks, that makes sense.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.