In most cases the machine used to view/control cams won't be on a more restricted portion of the network. It will be a general-use computer and have much greater access to your network and to the outside. Though it usually won't be, a dual-homed machine in that role can hurt more than it helps. While traffic from one side to the other won't hop through on its own (unless set up to do so), something running on that machine does at least potentially have access to both sides. That's a prime target and how things can easily jump from general to secure sides and/or from administrative to process control networks and really shouldn't be permitted in such cases.
DNS restrictions only work where a DNS request is made. Lots of ways that traffic can bypass DNS-based limitations.
There are various process monitoring systems that can be run but most won't won't be or they'll be intrusive or unclear, typically to the point that if broad enough to catch such things they effectively get turned off or ignored. The permission request when the plug-in is installed here is one such system-level restriction and we can see how that works out at a practical level.
What happens as a result doesn't even need an outside connection, If I can install a service to act as a websocket server, then I can install a service to do pretty much anything else. Just as an example, ransomware. Don't need for something like that to establish an outside connection from the compromised machine, That host willl be done and contact will be made in another way. If the compromised machine happens to be dual-homed between open/secure sides, then potentially it jumps that gap.
And again I'm not implying anything about this case in particular or any ill intent on the part of Dahua. Rather, just as a matter of general practice.
This of course depends on your deployment. In truly secure deployments you DO identify the machine(s) / devices that are restricted for / to accessing live feed + historic / retained data with associated access controls for those individuals using them. This is expected and required in many global deployments and for me is something I get asked about and work on a lot. However, your point is very valid, this depends on your deployment, threat model, access requirements, use case and associated 'risks' you are then willing / need to take. While residential deployments do not carry the absolute requirements of commercial, government etc, there is a positive rising trend in end users taking more of a proactive approach to their own privacy and security, thats a good thing.
Dual homed machines
can cause issues IF not configured correctly and are a ripe target to hackers BUT does give you options for those wanting to go down that path IF you have no other alternatives. They key as I think you and I would agree, is not assuming that this one approach will solve everything. Similarly with DNS restrictions, these are 1 part of an overall plan, never to be seen as all inclusive. They do however form an effective layer (when running your own server as well) that most people do miss or gloss over. Yes they are focused on a key area, targets on a DNS request starting the process but are still effective. Look at Lorex and many other manufacturers that while again not necessarily doing anything nefarious are continually looking to poll out and do this utilizing a DNS request to start. This plus reducing your surface area from a DNS perspective is also a plus. Added bonus is reducing / removing ads, encrypting your requests, potential performance bump etc all of course dependent on how you are configured for DNS already vs taking this approach
Like I said, not an all inclusive solution but a key as part of an overall one.
As you said with process control, Yes spoofing a process or another man in the middle type of attack can absolutely be a problem. As we know, a number of security penetrations do come within the local systems and generally are most impactful when a) there are not precautions being taken at all and / or b) when human intervention plays a role (making incorrect decisions to open/access/grant control etc or general lack of awareness). As we know, you'll never protect against everything BUT you can certainly take effective measures to detect, block, alert and ultimately be more aware. Taking decisive action to lockdown completely or just harden an infrastructure (regardless to which level and depth you go) and its associated devices is a choice, one that I'm happy most here do take step towards in order to protect themselves.
As you said,
@Mike A. no one is implying that the Dahua plugin is malicious or nefarious in any way, just highlights the potential risks that always exist and reminds us all to pay attention, as
@bigredfish did when he saw this. Good conversation on this thread for sure and also highlights the attention of any forum user to the fact that when it comes to your privacy, your security and that of your home and business, be your own advocate for ensuring you take the security of it seriously. That starts with being aware, leads to a block first, allow later mentality and ultimately forms the path to how and where you implement your chosen security design in relation to overall desired goals, needs and associated threat model.