CMS and firewall
carericb
Posts: 12
My security software shows that your Content Management tool includes Spyware (trojan)
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
The CMS communicates with DS4 and Carrara 8.5 via local ports, like most database servers. It does not access the internet.
Mike is correct, it only references 127.0.0.1 (localhost) aliases. It is a database server though and that can cause some false positives. Although none that I have used have complained (MS Defender, Avast, AVG, Sophos, Trend).
The real problem is that some of the alternative AV/Firewall don't recognize the ValentinaDB or the ports that it is on. SQL Databases such as MySQL, Oracle, DB2, etc are all recognized by pretty much everyone. FirebirdSQL has similar problems with some of the "alternative" software.
For the record DS4 and ValentinaDB communicate using localhost (127.0.0.1) port 27997. But ValentinaDB will also monitor these ports by default: Port_SSL=15434, Port_SNMP=15161
Kendall
On Macs at least, the CMS for 4.0 on through 4.5.1 binds to 27997 from anywhere (sudo /usr/sbin/lsof -i -n) - not just localhost. In other words, you can connect to the server from the LAN via "telnet machinename 27997". It also appears to run as root, not as an unprivileged user. Ostensibly this is to be able to work with the content files. I don't offhand know the protocol for conversing with it, though it'd be easy enough to run it through tcpdump or wireshark.
For anyone security-minded, this means any oversights in the ValentinaDB developer or DAZ is potentially a major security problem for your machine. I've resorted to shutting the CMS down when not in use, and more recently learning low-level firewall configuration to block external traffic to the CMS port. This is not something a typical end-user wants to have to do.
Hopefully DAZ will figure out how to fix this someday, so I can start recommending DAZStudio 4 to my artist friends. Better yet if they could get DAZStudio sandboxed properly. The internet is not a tame place anymore (was it ever?).
You've made a lot of assumptions that aren't correct. CMS (aka valentinadb) does not access "content" only its database file. Studio uses the path returned by the CMS to access the files. Also, EVERY modern SQL database uses TCP ports for communications, it is how it goes. Blame Apple for botching Darwin's configs to make OSX more "Windows Like" for the DB running as a privileged user. MANY MANY MANY OSX "services" are in that same boat.
Protecting the port(s) from access is part of setting up any Unix system. A simple tcp-wrappers entry will suffice to stop unwanted connections to the ports. Any "security minded" person would know enough to have at least tcp-wrappers set for installed software. Something as heavy as a sandbox is unnecessary in this context. That thinking is for Windows, not Posix.
It would behoove you to research what you are working with a bit more before making blanket statements.
Kendall
You're looking at this from a Unix perspective. Most Mac users don't come from the Unix world, and have only the barest knowledge of the Unix features under the hood, so it's quite possible that a "security minded" person would NOT "know enough to have at least tcp-wrappers set for installed software", or even know what that means. And while "something as heavy as a sandbox" may be unnecessary, having this thing run with full root privileges seems like a problem waiting to happen.
You're looking at this from a Unix perspective. Most Mac users don't come from the Unix world, and have only the barest knowledge of the Unix features under the hood, so it's quite possible that a "security minded" person would NOT "know enough to have at least tcp-wrappers set for installed software", or even know what that means. And while "something as heavy as a sandbox" may be unnecessary, having this thing run with full root privileges seems like a problem waiting to happen.
If the person does not know, and is not willing to learn, then, by definition, they are not "security minded." tcp-wrappers is the easiest of the methods available for securing access to network ports, and it is NOT hard to understand.
Having to running the daemon with full privileges is Apple's issue, not DAZ's. Apple changed the BSD setup to cause the problem. Devs have to deal with the environment with which they are given.
Kendall
My assumptions attempted to give DAZ CMS the benefit of the doubt, that it has good reason to run as root, and that it doesn't have defects that may make machines vulnerable to denial-of-service or worse due to it opening a port to the world. The part about being able to telnet to the server from another machine on the LAN, or check lsof -i available service entries, that can be independently verified. It is unlikely, but not impossible, that my machine is misconfigured. I did do a fresh install of DAZ Studio 4.5.1 after running an uninstall of the CMS this afternoon, just to be certain.
Not all modern database systems require TCP ports open to the world. MySQL can, and often is, set up to only allow connections from localhost, rather than everything. In other words, it binds the loopback (127.0.0.1) adapter only so that only clients co-hosted on the machine can connect. SQLite doesn't require a daemon at all and is sufficient for many purposes, including multiple process simultaneous access on a single machine. Localhost-only binding is probably appropriate for the DAZ CMS since it's dealing with files and applications that are, well, local.
I don't have source code access to DAZStudio, nor do I fully know (nor is it really my business to know) the requirements that were considered that made ValentinaDB a good choice over SQLite or MariaDB or MySQL or PostGRES. It may have superior development tools, or object features that make it very useful for managing the metadata. I would still like to think that the one-line change required to make the service bind localhost instead of everything would be an improvement, and arguably a bugfix to the software, that would not impact function at all.
There is also the express possibility that DAZ CMS spawns itself into a chroot jail or sandbox where it can only access the database files it needs to - I would be interested to hear if it does. Possibly I can test it. Still, that is only a partial defense from black hats.
Setting the wayback machine a few years, tcp-wrappers was a shim which allowed inetd to launch unprotected service tasks with filtering protections from outside attack. Using specialized launchd entries on OS X could be done to only launch the database on-demand or even on-login if you really wanted to go there, but DAZ has opted toward always-on service mode (/Library/LaunchDaemons/com.daz3d.content_management_service.plist) and I doubt that they've linked the daemon with libwrap.
It may also be an assumption (but a pretty good one) that end-users will install the software as instructed by the installer software. That installation sequence requests administrator privilege from the user in order to install DAZ CMS, and conveys that privilege to the CMS launchd configuration (again, the plist file, "Username" = "root"), circumventing firewall and code-signing security features of the OS. It's true that OS X's firewall defaults are "all or nothing" and lack finesse - you either block tasks from external networking (which would currently make the CMS database useless) or fully allow it. Most users will not take the time to research the necessary pfctl firewall tuning rituals required to lock out outside-world access to port 27997. By the way, you basically have to add "block quick on { en0, en1 } proto tcp from any to port 27997" to /etc/pf.conf and then pfctl -Rf /etc/pf.conf - on a machine with ethernet and wifi and firewall enabled, at least. And it differs between 10.7-and-newer versus 10.6-and-older. Not really the Mac way of doing things, it's got that Linux smell. (Not to say I don't like Linux - I do tons of it for my dayjob.)
Yes, Apple binds a bunch of services like the MDNS responder, netbios services, network printing, etc, to listen globally. It's necessary to their function. Dropbox opens a port; again, necessary to its function - and turning off LAN sync at least opts you out of the TCP *:17500 open port. It boils down to this: I do not believe having an open port to the outside is necessary to DAZ CMS' function - and it should be easy to fix! And yes, I did submit tickets in 2011 on the topic, and they have been acknowledged, and I still await further action on them. Which means I may be very patient and hoped they'd get to it sooner or later, or that I'm very busy, or that I was satisfied with the workarounds, albeit disappointed in what would have otherwise been a reasonable solution to a real problem of data management.
Anyway:
If there is no need for administrator access, best practices are to run it as an unprivileged user with access to only its database files.
If there is no need for outside-the-machine client support, best practices are to bind localhost:27997 instead of *:27997, or a unix-domain socket.
Those best practices date back to the days of tcp_wrappers, even.
I'll try to keep this cordial and informative and stop here. Have a great weekend!
Except the problem is the way Apple decided to do things...
It's pretty simple... ValentinaDB has a Qt development widget.
I spun up a stock Win7 machine and installed DAZ; it still opens up 0.0.0.0:27997 according to netstat -a (not 127.0.0.1:27997) but the firewall covers for it (assuming it's turned on, which is default for stock Win7). If firewall is off or the service is granted permission, you can still open a port to the server from the outside.
OS X's default is to trust root processes. I'm not versed enough in Windows internals to say whether "Local Service" counts as administrator; likely not. Curious to know, however.
So, essentially, a guest of the king knocks a hole in the castle wall for no good reason, and it's the guards' fault for not catching it?
It meanders back to the point of privilege conveyance from the administrator, which looks to be different between the two OSes, or possibly that the service runs as a less-privileged account on Windows. So this could devolve rapidly into minor semantic differences becoming OS holy wars, which are pretty pointless.
So I'll stand behind "binding to 0.0.0.0:27997 is a bug" and "running as root is also a bug, but not quite as bad if you're binding 127.0.0.1:27997" and see whether DAZ or ValentinaDB folks come to the plate. I'm locally fine with my personal workaround and might look into patching the startup plist and/or the binary itself to fix the accounting and binding.
Best regards,
-RKG
From the Paradigma Software FAQ: (emphasis mine)
How can developers connect applications to Valentina Server /5?
Paradigma Software's Valentina DB ADK products include support for local databases as well as support for remotely connecting to Valentina Server. The local connection feature is a commercial feature. The remote connection feature in Valentina ADK can be used for free. Download the Valentina DB ADK that matches your development environment, and use the Valentina Client portion to work with Valentina Server.
AdamR answered this.
ValentinaDB has its problems, as does every RDBMS. We all have our favorites. I would have used FirebirdSQL, but it's not my software. DAZ can't go embedded because Carrara also uses the CMS. Once the embedded solution is knocked out, then one is back to the use of the TCP route.
Kendall
Having paid hundreds of dollars for DAZ Studio Pro prior to it going "free-as-in-razors-not-blades", I think it reasonable to consider it commercial software. I won't say I regret the investment, and I applaud DAZ for opening it up to the community and steadily improving it. However, I wish some of my money had gone toward licensing the commercial ValentinaDB components, if (a very big if) that's the missing piece here to prevent it from binding 0.0.0.0:27997. Again, getting too far into conjecture.
Side note, kudos to DAZ for getting the download/install manager beta out the door. Getting out from under the installer grind is awesome.
Cheers,
-RKG