VDOM separation flawed?

[echo]

I've seen long time ago and even now with newer versions of FortiOS that when managing one VDOM, I can actually see important information about other VDOMs in CLI. I just rechecked it in a device with 6.2.10 where I have been given access to one VDOM only as a tenant that yes, I can see the names of other clients using the same device, some other important IP-addresses of theirs and possibly more if I would want. It's the same with 6.4.4.

At the same time, I can read from the documentation: "VDOM administrators will be unable to view global settings or VDOMs not assigned to them because the scope of their role is restricted to managing specific VDOMs only. An example of a VDOM administrator is the administrator working for a company which is a client, or tenant, of an MSSP’s multi-tenant FortiGate."

Well, getting the list of names of all clients isn't really separating, is it? Should I write down those few commands that show this information that I've tried so far? They are nothing special, typical commands for CLI. Or is it a public secret that VDOMs are not really separated so tenants can see information about other tenants? Because, as I said, I've seen this already ~5 years ago and they are still there behaving the same way today.

[gfleming]

It would certainly be helpful for you to share the commands you are concerned about so others may provide guidance. Please share more details. Thanks.

[echo]

I am concerned about these commands:

1. This command: diag netlink interface list

This shows ALL the interfaces with their names, even outside the VDOM I am limited to administer. If there are different tenants then typically the interfaces are named after their name or abbreviated and so I got to know all the names of other tenants in that Fortigate. I must not see any other interface besides the VDOM I am administering in the first place.

2. VPN debug commands:

diag debug app ike -1
diag debug enable

Running this without filter shows me all the ongoing actions related to tunnels in ALL VDOMs. Using this I got information about another tenant: that they have two datacentres (two tunnels named accordingly), I saw their IP-s where they do tunnels to from this Fortigate. If they exchange keys then I will see the security parameters too when the tunnel is rekeyed or for some reason restarted. If they use something weak that could be attacked more easily... If I would be a bad actor, that would be quite easy way to get this information for a directed attack. But I must not see this information about other VPN-s from my VDOM, isn't it?

There could be more such commands (how about packet capture?) but that's not my interest to find which others would give more information and if some of them could even have write permission (I hope not).

From these examples if I would like to keep my information to my service provider only and firstly because of having some security in mind, I wouldn't use their solution if that's based on Fortigate's VDOM separation.

[echo]

I mentioned this to a fellow administrator and he recalled that this has been actually acknowledged by Fortinet:

https://www.fortiguard.com/psirt/FG-IR-22-036

[gfleming]

I'm not sure that's the same thing. That's specifically mentioning checksum info. I am able to see the interface and tunnel info from other VDOMs and I am running an unaffected FOS release from that PSIRT.

[echo]

Thanks for clarification and testing, I missed the checksum text in that PSIRT.

[gfleming]

I'll review more bug reports on Monday and submit one if needed.

[echo]

I add here another one I just discovered as an addition to the first example.

3. Multicast debug command:

diag ip multicast group-membership

This also shows all the (usually nicely descriptive) names of interfaces in all VDOMs.