New small feature request for "Attented-Sysupgrade" : Add an option to specify explicitly the Interface used for the service

Feature Requests
1

Hello.

When we start having complex configurations with OpenWrt, we highly appreciate, as advanced users, that the modularity philosophy of OpenWrt is fully respected.

I have a small feature request for "Attended-Sysupgrade" developers : It would be very handy if we could specify explicitly the "Interface" the Attended-Sysupgrade service is going to use to call the ASU server. This would allow users not to be forced using PBR to create special rules for that and just for that.

As an example, a very important service for OpenWrt, Usteer, used for Wifi Roaming enhancement is according to me "perfectly implemented" and is "perfectly respecting" the modularity philosophy of OpenWrt by allowing the user to specify explicitly the interface to be used by Usteer for its internal traffic.

I am longing forward to hearing from Attended-Sysupgrade's developer for this feature request.

Kind regards to all,

Frederic.

2

You don't need PBR.

You can create a route or rule without PBR. The SRC interface would be loopback (on a Linux-based router, lo indicates traffic initiated from the device).

Your suggestion is good as well.

3

I'm a bit worried with current implementation, because I tried redirecting its traffic without adding a route, and/or without adding a route with PBR, by just using interfaces metrics and it did not work (while it should), while it works perfectly for opkg for example.

This is why I think it would make configurations more easy and simple if we could directly specify the interface to use.

Such change should not be too complicated for Attended-sysupgrade's client developers, and it will make its usage more simple in complex configurations, without requiring manual addition of routes.

4

This is far outside the purview of the ASU clients, they are simply doing GET and POST requests to the OpenWrt servers via standard http/https. ASU has nothing to do with how those requests are routed.

5

I'm talking about the client side implementation details, not about the ASU server.

I thought my example with Usteer's case would be well understood.

6

It is exactly the clients to which I'm referring: auc, owut and LuCI Attended Sysupgrade app. They are simply fancy versions of wget, doing GET and POST against the servers. They know what is in /etc/config/attendedsysupgrade and that's it. Nothing to do with routes or what interfaces exist or anything network related.

7

Don't tell me forcing a specific interface, for convenience, is an hard thing to implement. I have several WAN or VLAN (uplink) interfaces on several OpenWrt routers, and I find it may more handy to be able to specify, for a service like attented-sysupgrade, what interface to use, instead of being forced to add manual routes or other tricks like metrics to force the traffic of a specific app into an interface.

This is a matter of allowing the whole configuration of a module, to be done fully within its own config file, instead of having small parts of it depending on other subsystems or config files in the system.

Take the SSH client's configuration, it accepts choosing a listening interface. Usteer does it too for its usteer-peer to usteer-peer communication too.

The OpenWrt "interface" abstraction is great, it reduces complexity of configuration in a great way, and I find it less interesting to use "linux kernel" low level abstractions to do the job.

In any case, the behavior of attended-sysupgrade client is weird : When changing interfaces metrics in a multiple uplink configuration (Multi-WAN, with VPNs), to force routing default output traffic to a given interface, it works well for opkg, but it fails to work for attended-sysupgrade. I could add specific routes, but I find it more interesting to be able to specify the interface directly into the config file of attended-sysupgrade.

It makes maintaining configurations easier.

Don't loose sight that complexity is always the enemy.

I think, personally, that all these things dealing with system upgrade must really be coded / implemented with a lot of care.

I've been shocked at reading this :

  • The injection mistake is surprising, from skilled developers, working on an essential security part of OpenWrt, it's very surprising.
  • But the SHA256 truncation is absolutely crazy. I mean, I can't imagine a second that "plausible deniability" could apply here.

Supply chain attacks are very dangerous, they are silent, and they harm a lot of people. It is normal for users of OpenWrt to be particularily meticulous on supply chain attacks to ensure nothing bad happens.

A few years ago, I guess it was at 36C3, I remember some folks from the Tor dev team revealing that the agencies with the strongest cyber skills, typicaly NSA/CIA/MOSSAD had developped a system (a weapon) that was delivering "specific compromised binaries" to package managers depending on "who you are", bypassing all the signature thing, forging live true fake signatures. They were saying that forwarding the package managers traffic onto VPN or Tor was the first thing to do to mitigate this risk.

Because of that, I think it is interesting to take care of easily making the attented-sysupgrade used interface customizable directly in its configuration file : It allows, for example, to route its traffic through Tor or a VPN to mitigate more the risk mentionned above.

8

If you can explain to me how I would specify an interface for the following commands, then maybe I can understand how I could do it in the ASU clients:

$ uclient-fetch https://google.com
$ curl https://www.facebook.com
$ wget https://openwrt.org/docs/guide-user/installation/sysupgrade.owut
9

If eth0 is 192.168.1.1 and is the default wan route in your system, and if eth1 is 192.168.2.1 is an alternate wan route, and you want to force wget using the eth1 interface, then you just need to call wget --bind-address=192.168.2.1 https://openwrt.org/docs/guide-user/installation/sysupgrade.owut and you're done. I guess the other commands have similar possibilities.

10

--interface <name>

--bind-address= ADDRESS

1 Like
11

I'm looking and don't see any way to bind an interface here https://github.com/openwrt/uclient/blob/master/ucode.c (owut's underlying fetch library), here https://github.com/openwrt/uclient/blob/master/uclient.h (auc's), or here https://www.javascripture.com/Request (LuCI Attended Sysupgrade app's).

I have no idea how one would go about getting changes made to the JS Request API.

12

Small changes would have to be done in uclient , it's not complicated. It is perfectly feasible. Give me more time to analyse the code, to see where these sockets are opened, because it's where we can specify and force the source interface : Using setsockopt() with the option SO_BINDTODEVICE after the creation of the socket.

For the Java Request object, there is a problem, it cannot be specified. But you could use something else in Java that allows specifying this socket option. The Request object is not the only solution to perform simply your request. If the Java thing is just needed for the Luci interface, maybe you actually don't need to specify an interface here, as I guess all the inputs/outputs with ASU server should be handled by a service daemon process. In any case, there are several alternatives that allow to perform equivalent request with some objects allowing specifying the interface to attach the request to.

13

The attended sysupgrade uses the interface that the rest of the system uses. The entire idea of abstraction is that the software higher up doesn't need to care about the stuff below. Attended sysupgrade just uses the existing network access provided by the system.

14

I think you are way overthinking this. If you can't trust https then you have bigger issues. The issue with sha256 wasn't great but it doesn't apply here since you are talking about the transport level. If you don't want to trust the build server you can always build OpenWRT from source. For that matter you could go though the entire source line by line. I would also like to point out that there was a related vulnerability that allowed remote code execution on the build servers. Luckily the impact of it was minimal since the build server uses podman containers to isolate everything. Last time I checked none of the two security vulnerabilities in the build server had actually been exploited although it is hard to know for certain.

15

Yes, I understand your point too, about what you said about the build servers.

But you have to understand mine regarding this small modification of the code I request. A good integration of modules like luci-app-attended-sysupgrade or auc in the general philosophy of OpenWrt would require, according to me, that every extension of that kind generating traffic over the internet can be configured to use a specific interface. It is already the case for most of the well implemented modules in OpenWrt, and due to the importance of the update system, it worth it doing it. There is no security issue here, there is just a better integration, more simple configurations, with less dependencies on other parts of the system.

But as attended-sysupgrade is a key element for OpenWrt security, it's not just a fancy extension module, it is worth it doing some more efforts according to me.

You have to understand that OpenWrt is out last line of defence when it is have secure routing in our networks. This project is very useful for so many targeted users like I am, and I think, beside my personal case, that as a crypto-anarchist it is important to remind our community to keep the highest standards as possible, not only in terms of security, design, but also of simplicity in configuring strong simple and explicit configurations, and with their corresponding user interfaces with LuCI or CLI.

This improvement I am requesting is aiming as making secure configurations of attended-sysupgrade more easy to implement in a strictly explicit way, and it makes it also easier to use it when we are in complex network setups as mines are.

If I had more decision power or influence in OpenWrt, I would request all modules / extensions developers or integrators into OpenWrt to always add a dropdown menu in LuCI, and its equivalent in CLI, so that when such modules needs to communicate over the internet, an interface could be configured, as it was done for Usteer or the SSH Client : Here, it is a matter of harmony in the integration of extensions to OpenWrt, it is a matter of regularity or constance in the way such extensions can easily be safely and knowingly configured.

These points are important points to maintain a coherent whole, and it is important for less skilled users or new users to OpenWrt to ensure they understand well their configurations and their consequences. Hidden or indirect mechanisms based on linux kernel properties and functionalities (Like adding routes manually, or playing with metrics) to handle such issues are, according to me to be avoided the best we can. And I insist that in any case, adding a route or playing with metrics provide a less perfect result, a less safe and explicit configuration, than directly specifying OpenWrt interfaces for specific modules/extensions that need to generate traffic over the internet, or between routers. Many developers would agree with me it is important to maintain harmony and coherency here, for less advanced or skilled users.

This reminds me the begining of iOS and iPhone, where many developpers were raging at the fact that Apple was forcing them to respect a few standards, including for their application user interface and its flow. If they did that, it was clearly in the end to make the whole ecosystem more coherent and usable for most users, and actually it was a good thing. Later on, Apple has given developers more freedom in this regard, but many non-computer friendly users where lost in those user interfaces that where all very different, and the global usability of the iPhone ecosystem decreased somehow a lot.

OpenWrt is a very nice thing, and it is unique in its kind to help us maintain safe networks, I would find it a waste to lower our standards at all levels.

It's important to keep systems coherent and uniform in terms of configuration philosophy, it maintains clarity, simplicity, over the way we configure them, and this is important for many users that are not skilled sysadmins or who are newcomers to OpenWrt.

Complexity is the enemy. Always.

Kind regards,

Frederic.

16

I don't believe either of those have options for the selection of an interface for communication over the internet. In both cases it's to allow a user to select an interface (and in the case of dropbear it's not a required option) for the service to listen on. (And while I appreciate in the case of usteer that means traffic will be sent on that interface it's clear its for purely internal traffic.)

If we're going to get into the nitty-gritty of harmony/regularity/cohesiveness then I think it's important to be looking at like-for-like. And the options in the two packages you mention are not the same thing as an option to direct which interface should be used for external communications.

17

While I am not a part of the OpenWRT project I have been in the forums for a little bit. The OpenWRT maintainers tend to be open to new ideas but they are unlikely to implement something unless there is a very clear benefit. If you make a PR they likely would accept it assuming it doesn't have any obvious issues. At the end of the day OpenWRT is made up of volunteers who have limited time. If you want something you need to put in the work.

Also it isn't the greatest look to call yourself a crypto-anarchist who wants to "influence maintainers." While I don't particularly care it is important to note that OpenWRT is unlikely to embrace any form of political affiliation. It is just a software project at the end of the day and is open to whoever wants to use or contribute to it. The people here are mostly respectful and will try to help anyone who needs it but I doubt they would go along with anything remotely political.

2 Likes
19

Right... I think this thread has turned a corner now. If you want to make a PR for the required functionality then you're free to do so. Beyond that we're now starting to get seriously off-track from the purpose of this forum.

20

I hope you were not shocked.

And yes, I will either do a request, or do the work myself.

I exposed you logical and honest arguments, you are free to dismiss them.

Don't worry, I'm used to this. I've been advocating almost alone for more than 15 years in the French Hacker scene to promote end-user verifiable free integrated circuits, because free software without free integrated circuits is a joke. You have no idea of the level of ostracism I had to face for committing the crime of telling the truth on this other topic. But I don't care.

This is the level of my standards. I wish Snowden would be there, as his educated opinion would invariably be aligned with mine.

Kind regards,

Frederic.

21

Let's take a step back, looking just at the facts here.

auc/ owut is not a server process, it's a client querying the server for upgrade meta data (and effectively an upgrade image). This means binding to an interface does not apply here, at all. It's just a routing question, like ntp, opkg/ apk upgrades, DNS resolution, ddns updates, etc. Your router -normally- needs 'internet access' for the aforementioned tasks, if those aren't wanted, it can do without all that (as long as you somehow set a roughly correct system time, which is needed for https/ ssl).

If you have very special routing policies, it's up to you to configure them accordingly - I don't see how binding to an interface would help with that. Keep in mind that image metadata and signed images are another safeguard, meaning it effectively doesn't matter how the data reaches you, via trusted routes or not, as long as the cryptographic signatures are verified.

…and if you have such elevated security expectations, running owut/ auc wouldn't be on your plate anyways, as you'd want the extra auditing of reproducable image compilation and (manual) signature checks, as well as archival of the flashed images (for potential post-mortem analysis).

Around here, we have a saying - "wash me, but don't get me wet" or "you have to die one death", there's no reasonable approach to have it both ways, with rather arbitrary security requirements that don't actually improve security (just the theatrics around it).